"Numbers to expressions" incorrect for small numbers

[PFPF]

A little confused that my obfuscated code worked differently than the original code, then I found that it's the "numbers to expressions" misbehaving.

Current Behavior

"Numbers to expressions" option loses accuracy for small numbers, turning them into 0.

Steps to Reproduce

1. const epsilon = 1e-13; if(0 < epsilon) alert("math works!");
2. Obfuscate with "numbers to expressions" option on
3. Math doesn't work :(

It'll be great if this feature can be made more robust. I haven't looked at the implementation code, but I guess you can do something like the following:

1. For any number x, extract its integer and decimal part
2. Obfuscate the integer part as what you would do
3. Generate a random integer n between 100 and 100000, and obfuscate the decimal part d as [result of d * n] / n (maybe even obfuscate n as what you would do)
4. add 'em up

[BlackYuzia]

@sanex3339 did you fix anything in obfuscator.io?

Because I try obfuscate this:

const epsilon = 1e-13; if(0 < epsilon) alert("math works!");

and I get math works! result.

I use numbers to expression option.

UPD: Lol, this is random I think. Now I can't get result "math works". Okey ... this should be a random bug.

4 tries and I get it again

[sanex3339]

No, i haven't fixed anything yet.
Right now i'm thinking about the solution but looks like the easiest way is to convert only integer numbers

[PFPF]

@BlackYuzia I think "math works!" iff the last randomized term is < 1024 (because 1024 is the smallest number such that 1024 + 1e-13 == 1024) lol

@sanex3339 Looking forward to it. What do you think about the method I mentioned? So for 1e-13, you would get something like const epsilon = -0x2551+0x12*0x219+-0x71+1.2434e-9/(-0x1*0x149f+-0x1b27*-0x2+0xee3). I think it should be robust and easy, since you can just wrap around the current mechanism.
(Short note, if you will implement that approach: don't forget to not use Math.floor to get the integer&decimal part, or else the decimal part of -1e-20 would be lost again... Math.trunc is better)

[sanex3339]

Ok. I will implement @PFPF approach.

[sanex3339]

Hmm.
The problem is that even with the suggested approach the resulting number may be different from the input value.
For 1e-13 the output expression is -0xa9*-0x29+-0x1df*0xe+-0xdf+(-0xcb6+0x2335*-0x1+12267.00000000686)/0x10be9; and this expression does not match to the input number.

As a simple solution, I can disable transformation of all float numbers.

[PFPF]

Oh, I think we should be obfuscating the denominator (integer) not the numerator (decimal). (Sorry if it's unclear)

[sanex3339]

PR:
#885

[PFPF]

Thanks for the swift response. Could you confirm that it works with -1e-100? (I made a comment about one line in the code where it uses Math.floor)

[sanex3339]

Merged
Will release it later today

[PFPF]

Looks good!

[sanex3339]

Released as 2.10.4

[PFPF]

Great. For better obfuscation purpose, I would still suggest having a random, obfuscated integer as the denominator of the decimal part, but the current implementation does fix the issue. Thx for your time on this!