|
Jeremy Falcon wrote: complete accuracy on numbers
So, not a government project then? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Ha ha ha ha. Nope.
Jeremy Falcon
|
|
|
|
|
Okay, I'm now having flashbacks to my numerical methods class in college. One of the central points in the course was that managing precision was important, but it had to be appropriate to the calculation.
You've hit on that with currency. I remember a story where a programmer at a bank embezzled a lot of money based on harvesting roundoff error in the bank's software that he wrote. There are certifications and legal mechanisms that define how calculations are performed now. Scientific computation is similar. It's hard to imagine the analysis that the Large Hadron Collider experiments require, since the data of interest is embedded in unbelievable amounts of noise.
Heck, it's even a problem in my world of commercial ink-jet printing systems. Our internal unit of measurement is µinches (micro-inches) in a 64-bit signed integer. We deal with positioning data in 1/3600ths of an inch that can be noisy, and our resolution is 600 dots/inch. Using µinches solves a lot of scaling issues.
Software Zen: delete this;
|
|
|
|
|
This is the only correct answer: it has to be appropriate to the calculation. In some cases, perfect precision is not even mathematically possible (e.g. pi = ratio of a circle's diameter to circumference, or anything involving it like sin() or cos()).
Rational libraries are great when appropriate, but (a) they can be a lot of computing for no real world benefit, and (b) if you have any intrinsically irrational number like pi in there anywhere, their usefulness instantly becomes limited (or you have to factor out the irrationals and express the answers as ratios of them...)
So, yeah, in real life, calculate at higher than needed* precision and round to needed precision. For accounting, use appropriate accounting rounding rules for exact 0.5 values.
*what precision? Max total of your errors all added and multiplied together appropriately according to the calculations involved must be less than half of the actual final precision.
|
|
|
|
|
"floating point precision" is an oxymoron. Which is why I don't do math in JavaScript unless I don't care about rounding errors.
|
|
|
|
|
Yeah, but to be fair... this issue is with all languages.
Edit: Unless you mean the decimal type in C#? In which case... totally gotta give props to that.
Jeremy Falcon
modified 21-Mar-24 11:31am.
|
|
|
|
|
Yes exactly, the decimal type in C#. I was going to mention it but it seemed like the context of your question was JavaScript. 
And for SQL, there's a really interesting post here[^] about how to use the money and decimal types correctly. Learned something looking that up!
|
|
|
|
|
I work in engineering applications so my answer is "I don't use floating point arithmetic", everything is fixed point - many microcontrollers do not have an FPU at all and what I do is mostly real-time so forget software emulation. Any desktop tool has to provide or receive data from these systems so it's mostly fixed point until it's time to show to the user.
On non engineering applications I just use floating points as they are, if I have qualms about precision I just use double or long double and call it a day - I don't work on servers or high throughput / low latency services so I just don't care.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
One thing to consider, there is a worldwide standard that most operating systems follow, IEEE 64-BIT. To me it wouldn't be unreasonable to follow that. Anyone situation that requires more would be highly specialized.
|
|
|
|
|
I'll check it out. Thanks.
Jeremy Falcon
|
|
|
|
|
When seeking consistency, I would wrap all of that in a utility class. This way I know it's consistent and works the same everywhere. If I need something a little different, then I either overload or add a default parameter as the occasion requires.
I agree that storing the numerator and denominator would be the best way to prevent most headaches. In C#, I would use a Fraction struct for this (home grown if one doesn't exist already). Only collapse the fraction to a primitive type as necessary. This also has the benefit of letting you use money with a decimal value, so you don't have to do the extra math to get the cents back.
Speaking of money, you only have to store 4 decimals with money to be accurate for accounting purposes. I deal with fiduciary escrow accounts for my job, and that's all we've every used. Never had a problem being out of balance by a penny in 24 years. However, we don't do multiplication and division on the money. I don't think that would change much though as long as you kept the division and rounding to the end of the math problem.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Matt Bond wrote: When seeking consistency, I would wrap all of that in a utility class. This way I know it's consistent and works the same everywhere. If I need something a little different, then I either overload or add a default parameter as the occasion requires.
Ultimately, that's what I did. Except they were utility functions because I'm more functional than oop. Same concept though.
Matt Bond wrote: I agree that storing the numerator and denominator would be the best way to prevent most headaches. In C#, I would use a Fraction struct for this (home grown if one doesn't exist already). Only collapse the fraction to a primitive type as necessary. This also has the benefit of letting you use money with a decimal value, so you don't have to do the extra math to get the cents back.
Yeah, it's an awesome idea. A pretty cool piece of code was posted earlier for rational numbers. My only concern with a language like JavaScript is the speed of that. In something like C/C++ I wouldn't think twice about using it.
Matt Bond wrote: Speaking of money, you only have to store 4 decimals with money to be accurate for accounting purposes.
Whoops. I was storing 2. Thanks for this. 
Matt Bond wrote: However, we don't do multiplication and division on the money.
How do you do arithmetic on it then? Like, to calculate interest then?
Thanks for the reply btw.
Jeremy Falcon
|
|
|
|
|
The program deals with escrow accounts for settlement of a house sale. We just have to track incoming and outgoing money to make sure 1) each sale balances, 2) everyone gets paid the right amount, and 3) the entire bank statement balances. Thus, no multiplication nor division.
For a different part of the program, we do calculate per diem and monthly payments from an interest rate. The interest rate goes out to 6 decimal points, just in case (normally only 3 are used because they are multiples of 1/8 or .125 in the USA). The math is straight multiplication, then rounds to 2 decimals using 4 down/5 up rounding. We round at this point because this result is displayed to the user and summed with other amounts for a grand total. If we stored to 4 decimals, then we could have rounding errors appear in the grand total.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Thanks for the reply man. It was helpful.
Jeremy Falcon
|
|
|
|
|
Financial apps as far as I know use four decimal digits during calculations to avoid problems with only two, then round at the end.
|
|
|
|
|
Yeah, someone else just posed this. I'm gonna do the same then. Thanks man.
Jeremy Falcon
|
|
|
|
|
"project that requires complete accuracy on numbers"
A couple of thoughts. Is not the above requirement impossible on a binary system? By the very definition, you are going to lose precision be it float, double, double double.... how far do you want to go?
For me, I work a lot in machine HMIs. Some users want metric, others want English. I've always had a requirement to allow the user to switch between units and maintaining what is displayed. For example, 1" is 25.4 mm. If I switch between metric and English, the value must be consistent.
As for complete accuracy - this for me has always fallen into fixed point arithmetic to avoid rounding errors. COBOL has been mentioned. I've done COBOL - a very long time ago, but as I recall, it did fixed point arithmetic very well. Or I might be missing something...
Please elaborate on what you mean for "complete accuracy"? This sounds like a requirement from someone who really does not understand their request - sort of like a rare steak, but the temp should be 175F....
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
You're overthinking it man. The numbers need to be correct, as verifiable by secondary or tertiary means.
Jeremy Falcon
|
|
|
|
|
you could do this:
decimal result = decimal(1.0) * decimal(2.0);
or this:
double resulta = Math.Round(x + y, 5);
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Rounding with every calculation is what I was doing. I decided to move to just using integers and cents. That's for the reply though.
Jeremy Falcon
|
|
|
|
|
If you're using c# you can use decimal types and cast if/when you need to go back to floats/doubles.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I'm not, but yeah that's actually a great feature of C#. Turns out COBOL has that type too, found that one out.
Jeremy Falcon
|
|
|
|
|
It will largely depend on your application and requirements.
For currency type applications, consider using a BCD (Binary Code Decimal, used in COBOL) package. See below for references.
For integer type applications, there are a few "large" int packages.
For scientific applications, there are a number of packages for large number processing.
************ BCD references ********************
https://web.archive.org/web/20081102170717/http://webster.cs.ucr.edu/AoA/Windows/HTML/AdvancedArithmetica6.html#1000255
https://handwiki.org/wiki/Binary-coded_decimal#EBCDIC_zoned_decimal_conversion_table
Notes:
1) BCD numbers can be packed (2 digits/byte) or unpacked (1 digit per byte)
2) The low order byte (right most) of packed is nnnnssss where nnnn is the low order digit and ssss is the sign (0x0D for negative, 0x0F for positive)
3) The spec is (www,ddd) where www is the total bytes and ddd is the digits to right of decimal point. E.g.: 5,2 is a 5 digit number with 2 digits to the right of the decimal point--"123.45" This field would require 3 bytes packed, 6 bytes unpacked.
4) From IBM: For a field or array element of length N, if the PACKEVEN keyword is not specified, the number of digits is 2N - 1; if the PACKEVEN keyword is specified, the number of digits is 2(N-1).
5) Some documentation refers to BCD as DECIMAL but others use DECIMAL to refer to floating point.
********************* For large int ********************
Microsoft SafeInt package
SafeInt Class | Microsoft Learn[^]
The decNumber package can handle decimal integer number of user defined precision
GitHub - dnotq/decNumber: Decimal Floating Point decNumber C Library by IBM Fellow Mike Cowlishaw[^]
(I have not yet used or investigate the cran project.)
CRAN - Package VeryLargeIntegers[^]
******************** For Floating Point ********************
Floating point gets very complex and confusing because there has never been a really good, consistent standard for floating point. Most conventions are vendor/system design dependent.
Here's a list of packages and some brief explanations:
GCC stores and performs operations on a variable defined as long double as fp80 (10 bytes), but 16 bytes are used.
General reference: https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software
https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
GCC Floating point: https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/additional-floating-types.html
Floating point specifications: https://speleotrove.com/decimal/dbspec.html
Performance specs: https://speleotrove.com/decimal/dpquad.html
http://speleotrove.com/decimal/decbits.html
IBM decimal arithmetic package: https://github.com/hercules-390/decNumber-icu-368
Half precision: https://en.wikipedia.org/wiki/Half-precision_floating-point_format
Half precision software (16 bit) https://half.sourceforge.net/
Comparison BID vs DFP:
1) https://www.researchgate.net/publication/224114304_Performance_analysis_of_decimal_floating-point_libraries_and_its_impact_on_decimal_hardware_and_software_solutions
2) http://iccd.et.tudelft.nl/Proceedings/2007/Papers/3.3.1.pdf
3) libdpf source: https://github.com/libdfp/libdfp
---------------------------------------------------------------------------------------------
-----------------16 bit (half) -------------------------------------
The IEEE 754 standard[9] specifies a binary16 as having the following format:
* Sign bit: 1 bit
* Exponent width: 5 bits
* Significand precision: 11 bits (10 explicitly stored)
The format is laid out as follows:
The format is assumed to have an implicit lead bit with value 1 unless the exponent field is stored with all zeros. Thus, only 10 bits of the significand appear in the memory format but the total precision is 11 bits. In IEEE 754 parlance, there are 10 bits of significand, but there are 11 bits of significand precision (log10(211) ≈ 3.311 decimal digits, or 4 digits ± slightly less than 5 units in the last place).
-------------------------------32 bit format -----------------------------------------------------
https://en.wikipedia.org/wiki/Single-precision_floating-point_format
-------------------------------64 bit format -----------------------------------------------------
https://en.wikipedia.org/wiki/Double-precision_floating-point_format
------------------------------80 bit format--------------------------------------------------------
https://en.wikipedia.org/wiki/Extended_precision#x86_extended_precision_format
--------------------IBM HFP-------------------------------
https://en.wikipedia.org/wiki/IBM_hexadecimal_floating-point
------------------------------96 bit format--------------------------------------------------------
96 bit FP occupies 128 bits in x86 platforms
The Motorola 6888x math coprocessors and the Motorola 68040 and 68060 processors support this same 64-bit significand extended precision type (similar to the Intel format although padded to a 96-bit format with 16 unused bits inserted between the exponent and significand fields[9]). The follow-on Coldfire processors do not support this 96-bit extended precision format.[10]
The FPA10 math coprocessor for early ARM processors also supports this extended precision type (similar to the Intel format although padded to a 96-bit format with 16 zero bits inserted between the sign and the exponent fields), but without correct rounding.
|
|
|
|
|
Thanks for this. I should probably say, for my use case in particular, I'm in a Node project. But, it's cool to know this libs exist. Granted, I could make a C/C++ module and use that within Node, but for this project at least I'm trying to keep it zippy since JavaScript isn't as fast as C/C++.
Jeremy Falcon
|
|
|
|
|
And you accuse me of overthinking it 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
