What's y'all's favorite way of dealing with floating point precision?
-
Not sure if this counts as a programming question, since I'm not asking for code but rather preference. I'm in a project that requires complete accuracy on numbers. So, given the following... We all know the famous of examples of stuff like this:
0.1 + 0.2 // 0.30000000000000004
Up until now, I've been content with rounding off any operations after the fact and calling it a day, as close enough was good enough. For applications, say that deal with currency, the age old trick is to just use integers based on a cent value. So, a `$1.23` would be stored as `123` in a variable. Sweet, but, consider this:
// $123.45 / $2.25
12345 / 225 // 54.86666666666667If I move along powers of the base, I never run into issues. But for your typical run of the mill calculations, even with integers, you still have to deal with fractional floating points in the arithmetic. So, I've been using integers _and_ rounding off any calculations to their nearest integer value. Maybe sometimes I'll `floor` or `ceil` depending on context, but that's been my current solution, which is a lot more accurate but not 100% accurate. But, good enough-ish. Soooo.... 1) You guys prefer using a library to handle stuff like this? IMO I don't use one for arithmetic because most libraries for this (at least in JavaScript) are clunky and slow and don't really do a better job anyway. 2) You think integers and rounding is also the way to go? Keeps crap simple and all that, despite needing to remember to always round after division calculations or calculations against fractional types. 3) Never do arithmetic? Tell the user to go home.
Jeremy Falcon
-
Not sure if this counts as a programming question, since I'm not asking for code but rather preference. I'm in a project that requires complete accuracy on numbers. So, given the following... We all know the famous of examples of stuff like this:
0.1 + 0.2 // 0.30000000000000004
Up until now, I've been content with rounding off any operations after the fact and calling it a day, as close enough was good enough. For applications, say that deal with currency, the age old trick is to just use integers based on a cent value. So, a `$1.23` would be stored as `123` in a variable. Sweet, but, consider this:
// $123.45 / $2.25
12345 / 225 // 54.86666666666667If I move along powers of the base, I never run into issues. But for your typical run of the mill calculations, even with integers, you still have to deal with fractional floating points in the arithmetic. So, I've been using integers _and_ rounding off any calculations to their nearest integer value. Maybe sometimes I'll `floor` or `ceil` depending on context, but that's been my current solution, which is a lot more accurate but not 100% accurate. But, good enough-ish. Soooo.... 1) You guys prefer using a library to handle stuff like this? IMO I don't use one for arithmetic because most libraries for this (at least in JavaScript) are clunky and slow and don't really do a better job anyway. 2) You think integers and rounding is also the way to go? Keeps crap simple and all that, despite needing to remember to always round after division calculations or calculations against fractional types. 3) Never do arithmetic? Tell the user to go home.
Jeremy Falcon
I would argue that “complete accuracy on numbers” doesn’t exist. 1/3 cannot be represented exactly. You can do tricks like working with fractions and postponing the actual division until the very end, but in the end, if you have to print the result, you will have to print an approximation.
Mircea
-
integers with rounding (really a form of fixed decimal) is ok, but with money there may be accounting rules for rounding.
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
but with money there may be accounting rules for rounding
Yeah, fortunately, for this application at least... that's not a concern. I think... :laugh: :laugh: :laugh:
Jeremy Falcon
-
I would argue that “complete accuracy on numbers” doesn’t exist. 1/3 cannot be represented exactly. You can do tricks like working with fractions and postponing the actual division until the very end, but in the end, if you have to print the result, you will have to print an approximation.
Mircea
Fair enough. But the approach of using integers and rounding after the fact... that be your favorite? Does it give you warm fuzzies?
Jeremy Falcon
-
Fair enough. But the approach of using integers and rounding after the fact... that be your favorite? Does it give you warm fuzzies?
Jeremy Falcon
No, my favorite would be to work with
rationalobjects (I use c++ most of the time). A library for operations with those can probably be found easily, or I can whip my own without much effort. Edit: As expected, first Google hit was Rational Number Library - 1.58.0[^]Mircea
-
No, my favorite would be to work with
rationalobjects (I use c++ most of the time). A library for operations with those can probably be found easily, or I can whip my own without much effort. Edit: As expected, first Google hit was Rational Number Library - 1.58.0[^]Mircea
If I understand you correctly, then you'd be in favor of your own library/class/etc. to wrap this then? For JavaScript, there's no way I'd use most libraries as they're too bloated for this. Rolling one's own would be an option, but the end result would still use approximation inside the rational class right, if there was an expression that involved a floating point? Keep in mind, I'm not a math major.
Jeremy Falcon
-
If I understand you correctly, then you'd be in favor of your own library/class/etc. to wrap this then? For JavaScript, there's no way I'd use most libraries as they're too bloated for this. Rolling one's own would be an option, but the end result would still use approximation inside the rational class right, if there was an expression that involved a floating point? Keep in mind, I'm not a math major.
Jeremy Falcon
No approximation until the very end. You keep numerator and denominator integer values and you operate with those as you learned to do it with fractions in high school. Edit again: a few days ago I had to do something like that in JavaScript but for complex numbers. If you are interested, it’s here: Numerical Examples - Modified Stereographic Conformal Projection[^]
Mircea
-
No approximation until the very end. You keep numerator and denominator integer values and you operate with those as you learned to do it with fractions in high school. Edit again: a few days ago I had to do something like that in JavaScript but for complex numbers. If you are interested, it’s here: Numerical Examples - Modified Stereographic Conformal Projection[^]
Mircea
-
jmaida wrote:
but with money there may be accounting rules for rounding
Yeah, fortunately, for this application at least... that's not a concern. I think... :laugh: :laugh: :laugh:
Jeremy Falcon
-
Gotcha :thumbsup:
Jeremy Falcon
I found the good link for the JS code I was talking about before: https://neacsu.net/js/mod_stereo.js[^] Look at the
complexclass and you can probably model arationalone based on that.Mircea
-
No approximation until the very end. You keep numerator and denominator integer values and you operate with those as you learned to do it with fractions in high school. Edit again: a few days ago I had to do something like that in JavaScript but for complex numbers. If you are interested, it’s here: Numerical Examples - Modified Stereographic Conformal Projection[^]
Mircea
-
Not sure if this counts as a programming question, since I'm not asking for code but rather preference. I'm in a project that requires complete accuracy on numbers. So, given the following... We all know the famous of examples of stuff like this:
0.1 + 0.2 // 0.30000000000000004
Up until now, I've been content with rounding off any operations after the fact and calling it a day, as close enough was good enough. For applications, say that deal with currency, the age old trick is to just use integers based on a cent value. So, a `$1.23` would be stored as `123` in a variable. Sweet, but, consider this:
// $123.45 / $2.25
12345 / 225 // 54.86666666666667If I move along powers of the base, I never run into issues. But for your typical run of the mill calculations, even with integers, you still have to deal with fractional floating points in the arithmetic. So, I've been using integers _and_ rounding off any calculations to their nearest integer value. Maybe sometimes I'll `floor` or `ceil` depending on context, but that's been my current solution, which is a lot more accurate but not 100% accurate. But, good enough-ish. Soooo.... 1) You guys prefer using a library to handle stuff like this? IMO I don't use one for arithmetic because most libraries for this (at least in JavaScript) are clunky and slow and don't really do a better job anyway. 2) You think integers and rounding is also the way to go? Keeps crap simple and all that, despite needing to remember to always round after division calculations or calculations against fractional types. 3) Never do arithmetic? Tell the user to go home.
Jeremy Falcon
In good old days, we had
DOUBLE PRECISIONin Fortran anddoublein C. At least these had better precision thanREALandfloat. Somehow, it seems that the designers of later languages put more emphasis onstrings, perhaps, because layman-type of users/applications started outnumbering scientific/numerical users/applications. -
Not sure if this counts as a programming question, since I'm not asking for code but rather preference. I'm in a project that requires complete accuracy on numbers. So, given the following... We all know the famous of examples of stuff like this:
0.1 + 0.2 // 0.30000000000000004
Up until now, I've been content with rounding off any operations after the fact and calling it a day, as close enough was good enough. For applications, say that deal with currency, the age old trick is to just use integers based on a cent value. So, a `$1.23` would be stored as `123` in a variable. Sweet, but, consider this:
// $123.45 / $2.25
12345 / 225 // 54.86666666666667If I move along powers of the base, I never run into issues. But for your typical run of the mill calculations, even with integers, you still have to deal with fractional floating points in the arithmetic. So, I've been using integers _and_ rounding off any calculations to their nearest integer value. Maybe sometimes I'll `floor` or `ceil` depending on context, but that's been my current solution, which is a lot more accurate but not 100% accurate. But, good enough-ish. Soooo.... 1) You guys prefer using a library to handle stuff like this? IMO I don't use one for arithmetic because most libraries for this (at least in JavaScript) are clunky and slow and don't really do a better job anyway. 2) You think integers and rounding is also the way to go? Keeps crap simple and all that, despite needing to remember to always round after division calculations or calculations against fractional types. 3) Never do arithmetic? Tell the user to go home.
Jeremy Falcon
This is why COBOL has a decimal type. Your approach of using integers to represent currency will work, subject to a few caveats: 1. Accounting rules require that calculations (e.g. multiplication, division) be performed with greater than 1 cent accuracy (5 decimal places, IIRC). This allows interest calculations, currency conversions etc. to work properly. 2. Rounding is performed using accounting rules - round to nearest or AWAY. The difference between this and round to nearest or EVEN is when the fraction is exactly 0.5. If this case, one rounds AWAY from 0. For example, 3.145 would round to nearest or EVEN as 3.14, but round to nearest or AWAY as 3.15. There may be other rules for accounting, but these are the major ones.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I found the good link for the JS code I was talking about before: https://neacsu.net/js/mod_stereo.js[^] Look at the
complexclass and you can probably model arationalone based on that.Mircea
Thanks for the link. My only concern with doing stuff like that, is if I start using arrays to store the fractional parts, this app is gonna slow down. Keep in mind, for this app it'll need to do thousands (potentially) of calculations per second. I may just have to settle for close enough, for this specific app.
Jeremy Falcon
-
In good old days, we had
DOUBLE PRECISIONin Fortran anddoublein C. At least these had better precision thanREALandfloat. Somehow, it seems that the designers of later languages put more emphasis onstrings, perhaps, because layman-type of users/applications started outnumbering scientific/numerical users/applications.Amarnath S wrote:
we had DOUBLE PRECISION in Fortran and double in C.
Even with binary DOUBLE PRECISION, you would get errors in accounting formulas. This is why COBOL was specified to have a decimal type.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
This is why COBOL has a decimal type. Your approach of using integers to represent currency will work, subject to a few caveats: 1. Accounting rules require that calculations (e.g. multiplication, division) be performed with greater than 1 cent accuracy (5 decimal places, IIRC). This allows interest calculations, currency conversions etc. to work properly. 2. Rounding is performed using accounting rules - round to nearest or AWAY. The difference between this and round to nearest or EVEN is when the fraction is exactly 0.5. If this case, one rounds AWAY from 0. For example, 3.145 would round to nearest or EVEN as 3.14, but round to nearest or AWAY as 3.15. There may be other rules for accounting, but these are the major ones.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
This is why COBOL has a decimal type.
:laugh: :laugh: :laugh: :laugh: Never thought I'd say this about COBOL, but that's cool.
Daniel Pfeffer wrote:
There may be other rules for accounting, but these are the major ones.
Thanks for this man.
Jeremy Falcon
-
In good old days, we had
DOUBLE PRECISIONin Fortran anddoublein C. At least these had better precision thanREALandfloat. Somehow, it seems that the designers of later languages put more emphasis onstrings, perhaps, because layman-type of users/applications started outnumbering scientific/numerical users/applications.Sometimes I do wish JavaScript had better types like that. I can push a precision to about 9 or 10 in JavaScript before the storable value becomes too small to be worth while. Good enough for kiddie stuff at least. But yeah, also what Daniel said. :laugh:
Jeremy Falcon
-
Daniel Pfeffer wrote:
This is why COBOL has a decimal type.
:laugh: :laugh: :laugh: :laugh: Never thought I'd say this about COBOL, but that's cool.
Daniel Pfeffer wrote:
There may be other rules for accounting, but these are the major ones.
Thanks for this man.
Jeremy Falcon
I don't get how noone on this site has mentioned that .Net supports decimal type. [Floating-point numeric types - C# reference - C# | Microsoft Learn](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/floating-point-numeric-types) As does most proper databases.
Wrong is evil and must be defeated. - Jeff Ello
-
Not sure if this counts as a programming question, since I'm not asking for code but rather preference. I'm in a project that requires complete accuracy on numbers. So, given the following... We all know the famous of examples of stuff like this:
0.1 + 0.2 // 0.30000000000000004
Up until now, I've been content with rounding off any operations after the fact and calling it a day, as close enough was good enough. For applications, say that deal with currency, the age old trick is to just use integers based on a cent value. So, a `$1.23` would be stored as `123` in a variable. Sweet, but, consider this:
// $123.45 / $2.25
12345 / 225 // 54.86666666666667If I move along powers of the base, I never run into issues. But for your typical run of the mill calculations, even with integers, you still have to deal with fractional floating points in the arithmetic. So, I've been using integers _and_ rounding off any calculations to their nearest integer value. Maybe sometimes I'll `floor` or `ceil` depending on context, but that's been my current solution, which is a lot more accurate but not 100% accurate. But, good enough-ish. Soooo.... 1) You guys prefer using a library to handle stuff like this? IMO I don't use one for arithmetic because most libraries for this (at least in JavaScript) are clunky and slow and don't really do a better job anyway. 2) You think integers and rounding is also the way to go? Keeps crap simple and all that, despite needing to remember to always round after division calculations or calculations against fractional types. 3) Never do arithmetic? Tell the user to go home.
Jeremy Falcon
.toFixed(x) should do the trick. And maybe even
+(0.1 + 0.2).toFixed(2), which displays 0.3 just fine X| A user never wants to see more than three digits anyway. But ultimately, I do all my calculations in C# that has a decent decimal type. I once had a customer who wanted to calculate VAT for each sales order row and then got mad the total didn't add up due to rounding errors :sigh:Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I would argue that “complete accuracy on numbers” doesn’t exist. 1/3 cannot be represented exactly. You can do tricks like working with fractions and postponing the actual division until the very end, but in the end, if you have to print the result, you will have to print an approximation.
Mircea
One effective approach for managing floating-point precision is using relative comparisons or epsilon comparisons. This involves comparing the absolute difference between two floating-point numbers with a small epsilon value, rather than comparing them directly. Additionally, utilizing data types like BigDecimal in Java or Decimal in Python can offer higher precision when dealing with financial or critical calculations to mitigate rounding errors.
