Generating a float with precision of 0.00001 gives larger precision number about faker HOT 14 CLOSED

You could do some kind of special case for precisions which are powers of 10 (most common case), like:

const logPrecision = Math.log10(precision)
if (Number.isInteger(logPrecision)) {
   return parseFloat((int / factor).toFixed(-logPrecision));
} else {
   return int / factor;
}

from faker.

Similarly you would still have issues with precisions which are not powers of 10 e.g.:

> [ ...new Set( Array.from({ length: 500 }, () => faker.number.float({ min: 0, max: 1, precision: 0.3, }) ) ), ].sort();
[ 0, 0.3, 0.6, 0.8999999999999999 ]

from faker.

Another option might be if 1/precision is "almost" an integer (within a small epsilon value) then we round it to an integer

from faker.

I think i have a fairly neat solution in #2581 - please take a look

from faker.

Hi @clocke3 , thank you for your bug.
I'm currently not at home, so I can't verify this (the minimal reproducible example link doesn't work on my phone). I'll give more feedback in a bit.

From your description (and screenshot!) this seems to be legit.
You selected that you are willing to create a PR to fix this. If that's the case, you are welcome to do so.

from faker.

The example doesn't work for me either.

Error: Cannot find module '@faker-js/[email protected]'

I assume the bug is related to a float precision issue.

from faker.

@xDivisionByZerox I apologize I am new to this issue making and checked the section on "creating a PR for issue" on mistake.

from faker.

@ST-DDT Yes it is. Looks like it existed in 8.0.2, 8.2.0, and I did test it out using 8.3.1 locally. I will try to see if I can produce reproduction code using 8.3.1.

from faker.

@xDivisionByZerox I apologize I am new to this issue making and checked the section on "creating a PR for issue" on mistake.

No problem at all. If you have a suggestion for an algorithm that might fix this issue feel free to post it here anyway.

from faker.

@ST-DDT Yes it is. Looks like it existed in 8.0.2, 8.2.0, and I did test it out using 8.3.1 locally. I will try to see if I can produce reproduction code using 8.3.1.

I don't think we changed anything significant in the method in this major version, so the problem is likely still there.
But thank you for your help.

from faker.

Definitely a JS floating point issue. Not all floats can be exactly represented in Javascript.

if (precision !== undefined) {
      if (precision <= 0) {
        throw new FakerError(`Precision should be greater than 0.`);
      }

      const factor = 1 / precision;
      const int = this.int({
        min: min * factor,
        max: max * factor,
      });
      return int / factor;
    }

The code const factor = 1 / precision gives a non-integer for certain values of precision:

> 1/0.1
10
> 1/0.01
100
> 1/0.001
1000
> 1/0.0001
10000
> 1/0.00001
99999.99999999999
> 1/0.000001
1000000
> 1/0.0000001
10000000
> 1/0.00000001
100000000
> 1/0.000000001
999999999.9999999
> 1/0.0000000001
10000000000

from faker.

You could do some kind of special case for precisions which are powers of 10 (most common case), like:

const logPrecision = Math.log10(precision)
if (Number.isInteger(logPrecision)) {
   return parseFloat((int / factor).toFixed(-logPrecision));
} else {
   return int / factor;
}

This might also work for non power 10 cases.

const logPrecision = precision.toString().replace(/\d+\./, '').length;
return parseFloat((int / factor).toFixed(logPrecision));

Not sure about the performance implications though.

from faker.

Any movement on this in development or still brainstorming?

from faker.

Still under discussion. As a workaround,

parseFloat(faker.number.float({precision:0.00001, min:X, max:Y}).toFixed(5)) should do what you want

from faker.