Jump to content

Float rounding


JFn
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

@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).

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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 ?

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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 ? 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 6 months later...

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.

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...