change default precision of faker.number.float

[matthewmayer]

I note that faker.helpers.float defaults to a precision of 0.01, which means this is biased for small percentages. What's the cleanest way to request the max precision for the random float?

Maybe open a new issue for that (max precision float)?

Originally posted by @ST-DDT in #1654 (comment)

[matthewmayer]

I was thinking we could add a new method like faker.number.fraction (naming?) which simply returns a random number in the interval [0,1).

The current implementation of faker.number.float always uses faker.number.int so it isn't ideal for getting full precision floats.

this could use a new method on Mersenne, e.g.

nextReal(): number {
      return twister.genrandReal2();
},

[matthewmayer]

Other alternative ideas

• Make this the default behavior of faker.number.float when no precision is passed
• Add the function to Mersenne, but only use it internally, don't make a new public method for this yet

[ST-DDT]

@matthewmayer Do explicitly need a max precision float or do you just need more than 2 fractional digits?
AFAICT 8 is the max we can safely generate, after that the float precision starts taking its toll.

[matthewmayer]

Doesn't have to be fully max precision. In reality for any real-world use case e.g. in #1654 5 or 6 digits is usually more than enough.

[ST-DDT]

Having a few more decimal digits from float (e.g. 6) aligns with my expectation regarding that method so I'm fine with it. What do the others think?

[Shinigami92]

I made some extrem tests

But unfortunately every precision I tried has some caveats 😕
Somehow I feel like 1e-14 is the best to pick, but nothing I can proof

[ST-DDT]

Please note that we loose precision due to the math in faker.number.float

[matthewmayer]

Also given the way Mersenne twister works you're only going to get 2^32 possible values even though there are an way more possible float values than that.

I don't think the precise precision matters that much as long as it's considerably smaller than any reasonable weight value.

If you care that much about precision and error values, you are almost certainly not going to use the JavaScript Number class

[ST-DDT]

Is 0.000_001 (10 ** -6) for precision ok for everyone?
Please use thumps for voting.

[matthewmayer]

Just to clarify, are you talking about modifying the default precision of faker.number.float or adding a new method for generating float values?

[ST-DDT]

Just to clarify, are you talking about modifying the default precision of faker.number.float or adding a new method for generating float values?

Modifying the existing. I assume that the current percentage result might be useful for some as well, so we could theoretically introduce a new method/alias with the old precision as default, but thats optional for me.

[matthewmayer]

Cool I agree. The current behavior was somewhat surprising to me. If we change the default then in most cases if you want a fixed number of decimal places you would be much better served by doing

faker.number.float().toFixed(2)