Refactor number.float parameter precision to fractionDigits

[Shinigami92]

Clear and concise description of the problem

We want to refactor the behavior of the precision parameter of number.float to be adjusted to Number#toFixed behavior.

This wont affect the legacy datatype.float method!

Suggested solution

• precision -> fractionDigits
• We then want to have a well defined developer experience and support steps like 0.4 and such
  So we might need an addition parameter like step(s) or precision and then talk about how this behaves
  • see Number functions can generate values out of bound #1595

Alternative

No response

Additional context

Extracted from

• feat(number): move methods to new module #1122

[Shinigami92]

Team Decision:

We want support both parameters: fractionDigits and the second one
If they are incompatible throw an FakerError

[xDivisionByZerox]

I will take this.

[ST-DDT]

Please wait for #1675 to be merged.

[ST-DDT]

Continuation of the discussion that came up in #1855 (comment)

@matthewmayer suggested adding a new method for stepped values to separate it from float.

[ST-DDT]

@matthewmayer Do you have a suggestion for a method name for the new step method?

Maybe faker.number.stepped?

[ST-DDT]

Team decision

The proposal to move the precision/step logic into a different method has been rejected.
We will keep this precision/step option in the float method's single signature and document that the parameters are mutually exclusive.

[ST-DDT]

Team Decision

We don't need this for v8.0.
(We will likely immediately start with v9 after v8.0)

[ST-DDT]

Related issue: #2186

[matthewmayer]

So basically

• this would add a new parameter fractionDigits as an alternative to precision
• fractionDigits must be an integer
• if set then precision = 10 ** -fractionDigits

Would you allow negative fractionDigits? (multipleOf:10 is probably clearer than fractionDigits:-1)

[ST-DDT]

Would you allow negative fractionDigits? (multipleOf:10 is probably clearer than fractionDigits:-1)

I'm not sure whether we should actually forbid badly readable input (unless it has other side effects).

[matthewmayer]

So probably allow between -18 and +18 (or whatever range works without issues)

[ST-DDT]

If we already have a check for the range then we can limit it to useful values. E.g. 0-18