Float rounding

[JFn]

I know it's an old problem, but is the float rounding broken in 3.0.124 ? Or did it never get solved?

Precision set to 2 digits, but numbers greater than 10000 are rounded to the closest integer, without precision.
ie. 15248.25 is changed to 15248. Everything below 10000 works fine.

[Robin S]

There are limitations to the number of significant figures that can be stored by the FLOAT column type in the database. There are also precision limitations to how floats are handled in PHP.

These are fundamental limitations and PW cannot do anything about them. However it would be good if the PW admin warned the developer about them so people aren't caught out - there is a request for this but it hasn't been actioned yet: https://github.com/processwire/processwire-requests/issues/173

Best to use the Decimal fieldtype in cases where the limitations of the Float fieldtype are a problem.

[LostKobrakai]

There are precision issues with float, but by my understanding the issue here is with the rounding and not the precision. 

[szabesz]

3 hours ago, Robin S said:

Best to use the Decimal fieldtype in cases where the limitations of the Float fieldtype are a problem.

Sorry for repeating myself, but:

 

[Robin S]

@szabesz, there's nothing broken in the "official version" of FieldtypeDecimal that's in the modules directory. I use it in nearly every project without problems. Arjen's fork adds a feature for distinguishing empty and zero values in a selector that a person may or may not need (personally I've never needed it so far).

[Autofahrn]

Out of curiosity I've just dived a little deeper and agree that the limiting factor is the database field. The interesting point is, that my limitation differs, as I get 6 significant digits. So storing 15248.25 returns 15248.2, which is a little surprise, since a regular float should provide 7 significant decimal digits (https://en.wikipedia.org/wiki/IEEE_754).

Anyway, if two decimals are relevant and values larger than 10000 need to be handled, float is not your friend.

Btw: "float" in PHP is double precision, able to provide 14 significant digits.

[JFn]

1 hour ago, Autofahrn said:

The interesting point is, that my limitation differs, as I get 6 significant digits.

You are correct,, it was 6 significant digits I had 15248.01 that changed and rounded to 15248. But I wrongly used 15248.25 in my example.

18 hours ago, Robin S said:

Best to use the Decimal fieldtype in cases where the limitations of the Float fieldtype are a problem.

I'm using the decimal field from now on.

But I'm very frustrated that for some reason this is not stated very clearly anywhere in ProcessWire.
I've used lot's of float fields in the past 5 years, also for webshop transaction data saved in PW. Luckily the total amounts were  never greater than 10000, but it could have been worse... Just stumbled upon it when revamping an invoicing system and porting it's data to PW. I've literally been shortchanged ?

[arjen]

We ran into issues after a few days (luckily we noticed the errors ourselves) so we were pretty quick to use the Decimal field by sforsman. We didn't use floats for money luckily. We pinged Ryan back in the day to implement this in the core or at least throw a warning when someone uses the float field. We also needed to make a distinguish between empty and 0 values so the client could use this in ListerPro to filter on. That is why there a fork. You can see more discussion here -> https://github.com/processwire/processwire-requests/issues/126.

[Autofahrn]

For money stuff you may stick to regular integer field, just calculate in Cent and divide by 100 for display. Easy, stable, reliable and fast. Of course less convenient compared to Fieldtype Decimal.

[LostKobrakai]

That only works well for a single currency. If you need to support any currency you should really use decimals, as different currencies are differently subdivided.

[szabesz]

On 1/25/2019 at 1:47 AM, Robin S said:

@szabesz, there's nothing broken in the "official version" of FieldtypeDecimal that's in the modules directory. I use it in nearly every project without problems.

I know, however,  @sforsman seems to have abandoned the project as he does not pay attention to our pings, while @arjen stated that he is happy to maintain his/their fork.

20 hours ago, Autofahrn said:

For money stuff you may stick to regular integer field, just calculate in Cent and divide by 100 for display. Easy, stable, reliable and fast. Of course less convenient compared to Fieldtype Decimal.

...and in the end, one will probably reinvent the decimal.

 

21 hours ago, arjen said:

We pinged Ryan back in the day to implement this in the core or at least throw a warning when someone uses the float field. We also needed to make a distinguish between empty and 0 values so the client could use this in ListerPro to filter on. That is why there a fork. You can see more discussion here -> https://github.com/processwire/processwire-requests/issues/126.

20 hours ago, Autofahrn said:

Easy, stable, reliable and fast.

The same goes for the module being recommended ? 

[adrian]

Just noticed something in the new php.ini that is shipped with php7.3

; The value is also used for json_encode when encoding double values.
; If -1 is used, then dtoa mode 0 is used which automatically select the best
; precision.
serialize_precision = -1

The php.ini with php7.0 had the precision set to 17.

Not sure what real world impact this will have though.