Your arguments all over this thread are not “simple accounting applications”. Mortgages are ridiculously complicated. Even if they aren’t, the simplest of prepayment models requires exponents and fractions all of which will fail spectacularly if your system used just a fixed decimal range. When you first mentioned it in this thread, I thought you meant like simple surface level applications or accounting things, not heavily complex stuff like mortgages or derivatives. The latter require precise math in their (very non linear) modeling. You cannot eschew floats in that case.
All simple addition, subtraction, multiplication and division. This stuff was invented long before computers --- like way back in ancient Babylon.
will fail spectacularly if your system used just a fixed decimal range.
Really? Wonder how the US economy gets by on a fixed decimal range? Have you ever paid for anything in fractions of a penny?
You cannot eschew floats in that case.
I'm sure it's possible to craft a "derivative" that no one understands using higher level math. But accounting and mortgages are all built around simple 4 function arithmetic. All you really need to do is insure you have enough range for penny accuracy and you can stumble by somehow.
See the routine I posted above in this thread.
NOTE: Nothing prevents you from using floating point math in an isolated routine if you think you really need it.
My real objection is using FP everywhere, including storage. This creates lots of potential problems that can be avoided by simply using integers. And with 64 bit processors, the required math is very efficient.
Mortgages are not simple mathematical operations. Don’t betray your ignorance of modern finance. What the other guy gave you was a simple calculation of a mortgage rate. Actual financial modeling (which is done day in and day out and uses more compute cycles than you can imagine) cannot be done by reducing it to 4 operations. If you think modern mortgages are what the Babylonians worked with, you might as well call a computer a clay tablet.
> paid anything in fractions of a penny?
Yes. Fx operations routinely require sub penny operations. You’re claiming, as someone on a moderately technical (if heavily ignorant) forum, that you’re going to divorce your system for settling with mom and pop outfits who deal with nothing less than a penny - from the system that the same bank may need to use to run highly advanced operations (on the settlement layer)? If so, I don’t know what to tell you except ask you to understand how money works.
You cannot stumble by on low end systems. There are incredibly complicated operations a bank does every single day in volumes of thousands that are not “complicated derivatives” which require much much more than the 4 basic operators. If finance was that fucking easy, any moron could do it. I’m not saying it is particularly difficult but you seem to think finance is accounting. It is not. It is almost anything but accounting.
You’re still missing the point. Sure in storage it may make sense to cut it off at 2 decimals. But you seem to have a bad understanding of financial math in general where you think most of the operations are just the 4 basic operators. While it is strictly true, this is like saying most coding it just loops, so we can destroy the rest of the scaffolding and just put loops everywhere. No need for abstractions. That just sounds ignorant.
See my reply to it showing an incredible amount of errors.... I bet you work in crypto pricing, right? From your claims it is clear you do not even understand how your code works (claiming it's using int64, when I clearly showed it's using arbitrary sized integers since your intermediate results don't fit in int64).
>All you really need to do is insure you have enough range for penny accuracy
