Float and double fields not saving correctly?

[MarkE]

If I have a float or double field in the Admin with a value such as -0.00001253 then saving initially shows this as -1.253E-5, which is fine, but saving again changes it to -1.2535

(v3.0.184 and 3.0.190)

In my FieldtypeMeasurement module I have fixed this (in a not yet released version) by using a text field and using (float)$value in the wakeupValue rather than $sanitizer because $sanitizer->float($value) returns -1.2535 from -1.253E-5. 

Is this a bug or is there something subtle that I don't understand here? It seems to me that InputfieldFloat may be using $sanitizer->float() which does not convert the scientific notation.

[Jan Romero]

Confirmed on PW 3.0.188 and 3.0.191. Also, the HTML5 input for floats seems to be broken? It tells me the nearest valid values are -1 and 0 when trying to input -0.00001253.

You should open an issue on GitHub about this. It seems pretty messed up for PW to fudge numbers by a factor of 100,000.

[MarkE]

12 hours ago, Jan Romero said:

You should open an issue on GitHub about this. It seems pretty messed up for PW to fudge numbers by a factor of 100,000.

Will do @Jan Romero. I'm pretty sure that the problem is with $sanitizer->float() since hacking that to just return (float)$value fixes the problem with float fields.

[MarkE]

Github issue opened at https://github.com/processwire/processwire-issues/issues/1502

Suggested fix is to amend the regexes in $sanitizer->float() to not remove 'E-', 'E+', 'e-' or 'e+', but I have (yet?) to devise a suitable regex. If anyone is a regex whizz then please save me some head-scratching ?

EDIT: I have also suggested, in the GIthub, a simple fix to deal with the internally-generated scientific notation that causes the InputfieldFloat problem. That's what I'm using for now, otherwise I consider InputfieldFloat is unsafe for live use! (I appreciate that may sound a bit dramatic, but I cannot risk major calculation errors).