> You might be surprised at where fixed point is already used
Not really, I have worked on all those kinds of things professionally, in fixed point, floating point, and arbitrary precision where appropriate. You apparently have not.
> Finance software: if you're using floats, you're doing something horribly wrong. All balances are measured in integer multiples of some quantum; depending on the system, that may be cents, it may be 0.1 cents, or it may be 0.01 cents. Gradations finer than that simply do not exist,
I take it you have never actually worked in finance; I have. This is so ludicrously wrong that this is clear.
Your claim might work for a free app that only handles your checkbook. Actual finance software has to do things like deal with multiple currencies, high precision compounded calculations, exchange rates that go to high precision and can handle trillions (4T+ a day goes through exchange markets), and on an on. To show you how ludicrous your claim it, let's do a simple experiment. I'll take a 64-bit double, you take 64 bit fixed point math, and let's compute compound interest (a tiny, tiny, trivial computation) tables. We'll make each input trivially simple (real code would handle vastly more cases). Here's your spec:
P = beginning principal in pennies, say loans from 0 to $100M (which is small, but I'll try to help your case, which will still fail...)
R = rate to 0.001, say mult by 1000 so it's an integer for you.
C = times compounded per year, 1-365 (again trivial, but this helps your cause)
Y = # of years to compound, 1-100 (again smaller than real code must handle, but it helps your case).
Your goal is to compute the amount the principal has grown to each compounding period, and at the end, return the amount rounded to the nearest penny (bankers rounding, or round up, or round down, whatever you can muster).
So let's see your function of form `long scaleFV(long P, long R, long C, long Y)` using fixed point.
An trivially simple version with doubles would look like
double FV2(long P, long R, long C, long Y)
{
long N = C * Y; //total number of compounding periods
double p = P;
double r = R/1000.0;
while (N-- > 0)
{
p += p * r / (100.0 * C); // most trivial thing one can do
}
return (long)round(p);
}
Compare both of these to the truth using big float or similar. Trying to do the above, for any trivial fixed point version, will fail over 80% of the time (uniformly sampled inputs from the range above). You likely will never find a case where the fixed point succeeds and the trivial double version fails.
Try it. Show your code that uses the claim you so confidently (and incorrectly) claim above.
And remember this is a trivial, tiny part of the real needs for finance codebases. Once you realize how badly you fail at this simple task where the trivial floating point version works, then please stop claiming things you know nothing about.
> and this matters when you have a regulator asking uncomfortable questions
Oh, I take it you have had this happen? Or did you make this up based on zero experience?
> but at least for PCB design, layout is done in fixed point
In a few systems, like KiCAD it is, not it's certainly not for high end professional systems. Try laying out an ASIC with fixed point, where you might have features at the sub-nm level up to several cm, and you need to track error bounds. And once you need to simulate just about anything (SPICE, etc..) all your fixed point fails.
(Note I use KiCAD a lot for PCB design myself for gadgets I sell; it's good for a few things, but not anywhere as good as a high end PCB design and analysis tool you'd want for high freq stuff and getting past FCC requirements for emissions, which I have also done).
> and avoiding edge cases in your geometry kernel from precision issues makes everything much easier
Yes, easier but larger error. There's a reason pro CAD kernels use floating point, not fixed point. Rotating things in fixed point anything other than 90 degree increments has larger errors by orders of magnitude, and soon your squares are not squares, and your intersections end up with all sorts of bad behavior (see some neat discussion on this in Matt Pharr's Oscar winning book PBRT).
And throughout all this, fixed-point is an order of magnitude slower when hardware float is available, such as places KiCAD runs.
> Robotics: maybe this one's just me, but expressing motion control algorithms in fixed point has saved me €1/part on more than a few occasions as a result of being able to use an MCU without hardware floating point. Compared to the €0.20/part saved by muntzing the rest of the circuit, the small amount of additional work was totally worth it.
It is just you. Yes, at some end-point controller you might use fixed point, but the robotics stuff I've done I often also need stuff like inverse kinematics for motion planning (I'd hate to solve Jacobian inverse stuff in fixed point!), done stuff like probabilistic SLAM flavors (also would diverge so badly as fixed point...), use all flavors of Kalman and other filtering to do sensor fusion, used KF and deep learning stuff to get better estimates from 9DOF mag/gyro/accel sensors, and on and on.
So yes, it may be just you, but I don't know anyone working professionally on robotics systems (and I know a few dozen, having worked with them a loooong time, writing, guess what, numerical code for and with them.).
> I made a header-only fixedpoint.h ...
Same, with also parameter for underlying type so I can plug in int32 where available (e.g., ESP32) int16 where it is not (many microchip chips), or even put in yet another custom type like an int64 emulation built on two int32s.... I've got templated versions to do naive mults and divs (which it seems most people do), one that has correct last bit (takes slightly more bit twiddling, but useful if you want a little more precision). And versions to do faster divs for chips that have software emulated divs (because for fixed point, since at the end you're going to rescale the answer, you can make your div much faster than a naive div followed by a shift). So yes, I have been down all this.
Remember, please show your fixed point code that handles the trivial financial code task above, or stop claiming things you apparently have not done and do not understand.
> When you say "finance" I assume you mean Wall Street type stuff?
Nope, pretty much any common financial software. Excel is most likely the most used software for doing finance of any type - it's floating point. Quicken is the most common personal finance - floating point. I'd guess the majority of personal finance programs do stuff like mortgages and credit card calculations, which will hit the same compound interest failures I listed above if you try to do it in fixed point, so they'd all be floating point.
If ALL you do is addition, then fixed point could work. But it fails at every other basic accounting task that it would be ludicrous to do any modern or even toy programs in it any more. Compound interest, mortgages, taxes, wealth planning - all floating point. Top 20 hits on github for finance - all use floating point for the math.
All the top hits for ERP on github - floating point. Top ERP commercial systems [1], list Microsoft Dynamics as #1. Looking at features it's most certainly floating point (it has calculated fields allowing arbitrary probabilities, for example). Second place on list is Syspro. Same thing - looking through their documentation they allow arbitrary spreadsheet like computations, even allowing machine learning stuff to be integrated for computations - this is certainly floating point. Third on list is QT9 ERP. Same result - they have modules called "Finance" that allow arbitrary calculations, which is certainly not done in fixed point. Multiple other modules look like they'd need floating point since fixed point would simply accumulate error too quickly (and be slow).
Alternatively if you have any of these programs, you could pull them apart pretty quickly with Ghidra and you'd likely find all floating point math in them.
While fixed-point has uses, it is not used nearly as much any more as people want to believe, and it's certainly a terrible idea for any finance beyond addition if simple numbers, i.e., a checkbook (which itself is getting outdated). If you cannot even do something as simple as compound interest, then I'd hesitate to call it finance software.
In the 1980s, floating point hardware was uncommon, there was no IEEE 754. The computing and finance has moved so far beyond the 1980s that I even doubt much modern greenfield accounting software is fixed point any more.
The databases use NUMERIC/DECIMAL data types almost exclusively. Once in a while you will find a floating point type but it's pretty rare.
The code they write is not generally available to the public so I'm not sure what they are doing inside their code. Some probably use java's BigDecimal, some probably wrote their own libraries to handle data types (e.g. SAP).
> If ALL you do is addition, then fixed point could work. But it fails at every other basic accounting task that it would be ludicrous to do any modern or even toy programs in it any more.
How about the basic task of storing 0.1 or 0.01, it seems pretty good at that and float (binary float) struggles.
Decimal float works, which is why IBM but the DFP units on the Power and Z cpu's.
Clearly you haven't looked at my CV. I spend about half my day reading this country or that one's regulations to make sure that the small bit of the worlds largest CSD (by at least one measure) that I work on follows the law, and I have the insatiable curiosity to read the rest of it as light bedtime reading. I know whereof I speak regarding financial systems. You don't.
Specifically, accounting law is old. Computers were used to automate what the bookkeepers did by hand, which was emphatically not floating point. At the end of an interest period, interest was computed and booked in rounded form. The next period, interest would be computed based on the number in the books, not the "floating point" number that was rounded from the last time interest was booked. More clearly: put 1c into a bank account earning 1% interest compounded daily. After 1000 years, that account will have precisely 1c in it, because there was never enough interest to earn at least one quantum. This is the difference between math and bookkeeping, and between the sort of math that passes for correct in an ERP system versus the sort of math needed by a bank.
Also, fixed point is not slow, at least not on the systems relevant to actual financial infrastructure. It's all on IBM Z, which has hardware instructions for fixed point decimal calculation because if it didn't, it would run like treacle.
Not really, I have worked on all those kinds of things professionally, in fixed point, floating point, and arbitrary precision where appropriate. You apparently have not.
> Finance software: if you're using floats, you're doing something horribly wrong. All balances are measured in integer multiples of some quantum; depending on the system, that may be cents, it may be 0.1 cents, or it may be 0.01 cents. Gradations finer than that simply do not exist,
I take it you have never actually worked in finance; I have. This is so ludicrously wrong that this is clear.
Your claim might work for a free app that only handles your checkbook. Actual finance software has to do things like deal with multiple currencies, high precision compounded calculations, exchange rates that go to high precision and can handle trillions (4T+ a day goes through exchange markets), and on an on. To show you how ludicrous your claim it, let's do a simple experiment. I'll take a 64-bit double, you take 64 bit fixed point math, and let's compute compound interest (a tiny, tiny, trivial computation) tables. We'll make each input trivially simple (real code would handle vastly more cases). Here's your spec:
P = beginning principal in pennies, say loans from 0 to $100M (which is small, but I'll try to help your case, which will still fail...) R = rate to 0.001, say mult by 1000 so it's an integer for you. C = times compounded per year, 1-365 (again trivial, but this helps your cause) Y = # of years to compound, 1-100 (again smaller than real code must handle, but it helps your case).
Your goal is to compute the amount the principal has grown to each compounding period, and at the end, return the amount rounded to the nearest penny (bankers rounding, or round up, or round down, whatever you can muster).
So let's see your function of form `long scaleFV(long P, long R, long C, long Y)` using fixed point.
An trivially simple version with doubles would look like
Compare both of these to the truth using big float or similar. Trying to do the above, for any trivial fixed point version, will fail over 80% of the time (uniformly sampled inputs from the range above). You likely will never find a case where the fixed point succeeds and the trivial double version fails.Try it. Show your code that uses the claim you so confidently (and incorrectly) claim above.
And remember this is a trivial, tiny part of the real needs for finance codebases. Once you realize how badly you fail at this simple task where the trivial floating point version works, then please stop claiming things you know nothing about.
> and this matters when you have a regulator asking uncomfortable questions
Oh, I take it you have had this happen? Or did you make this up based on zero experience?
> but at least for PCB design, layout is done in fixed point
In a few systems, like KiCAD it is, not it's certainly not for high end professional systems. Try laying out an ASIC with fixed point, where you might have features at the sub-nm level up to several cm, and you need to track error bounds. And once you need to simulate just about anything (SPICE, etc..) all your fixed point fails.
(Note I use KiCAD a lot for PCB design myself for gadgets I sell; it's good for a few things, but not anywhere as good as a high end PCB design and analysis tool you'd want for high freq stuff and getting past FCC requirements for emissions, which I have also done).
> and avoiding edge cases in your geometry kernel from precision issues makes everything much easier
Yes, easier but larger error. There's a reason pro CAD kernels use floating point, not fixed point. Rotating things in fixed point anything other than 90 degree increments has larger errors by orders of magnitude, and soon your squares are not squares, and your intersections end up with all sorts of bad behavior (see some neat discussion on this in Matt Pharr's Oscar winning book PBRT).
And throughout all this, fixed-point is an order of magnitude slower when hardware float is available, such as places KiCAD runs.
> Robotics: maybe this one's just me, but expressing motion control algorithms in fixed point has saved me €1/part on more than a few occasions as a result of being able to use an MCU without hardware floating point. Compared to the €0.20/part saved by muntzing the rest of the circuit, the small amount of additional work was totally worth it.
It is just you. Yes, at some end-point controller you might use fixed point, but the robotics stuff I've done I often also need stuff like inverse kinematics for motion planning (I'd hate to solve Jacobian inverse stuff in fixed point!), done stuff like probabilistic SLAM flavors (also would diverge so badly as fixed point...), use all flavors of Kalman and other filtering to do sensor fusion, used KF and deep learning stuff to get better estimates from 9DOF mag/gyro/accel sensors, and on and on.
So yes, it may be just you, but I don't know anyone working professionally on robotics systems (and I know a few dozen, having worked with them a loooong time, writing, guess what, numerical code for and with them.).
> I made a header-only fixedpoint.h ...
Same, with also parameter for underlying type so I can plug in int32 where available (e.g., ESP32) int16 where it is not (many microchip chips), or even put in yet another custom type like an int64 emulation built on two int32s.... I've got templated versions to do naive mults and divs (which it seems most people do), one that has correct last bit (takes slightly more bit twiddling, but useful if you want a little more precision). And versions to do faster divs for chips that have software emulated divs (because for fixed point, since at the end you're going to rescale the answer, you can make your div much faster than a naive div followed by a shift). So yes, I have been down all this.
Remember, please show your fixed point code that handles the trivial financial code task above, or stop claiming things you apparently have not done and do not understand.