6 ms·

You might be surprised at where fixed point is already used: * Finance software: if you're using floats, you're doing something horribly wrong. All balances are

• edflsafoiewq 2y ago
  The most common place is probably image/audio processing. Sample values are usually always quantized, even in intermediate stages. Decoding a JPEG for example is a bunch of fixed point math.
  • SideQuark 2y ago
    Professional tools even for audio use floating point engines (Ableton has done this for well over a decade [1]). While fixed point may be ok for input/output formats, it is certainly not suitable for complex audio processing needs, where errors accumulate far too fast for any fixed point system at equivalent bit depth. And fixed point is an order of magnitude slower. > Decoding a JPEG for example is a bunch of fixed point math It can be done that way, but modern decoders use float for accuracy and speed when available. Search libjpeg-turbo [2] codebase for float and surprise yourself. Even the ancient libjpeg [3] uses float when possible. Why not simply used fixed-point? Because it's worse in nearly every way, and an artifact of computing from the 1970s-1980s when JPEG pieces were designed (DCT, lots of work culminating in the final JPEG spec in 1992). When JPEG was designed, computers generally didn't have floating-point hardware. The world of computing has changed a bit since then. [1] https://cdn-resources.ableton.com/80bA26cPQ1hEJDFjpUKntxfqdmG3ZykO/static/manual/pdf/L9Manual_EN.0f97a0bd6041.pdf https://cdn-resources.ableton.com/80bA26cPQ1hEJDFjpUKntxfqdm... [2] https://github.com/libjpeg-turbo/libjpeg-turbo https://github.com/libjpeg-turbo/libjpeg-turbo [3] https://www.ijg.org/files/ https://www.ijg.org/files/
• SideQuark 2y ago
  > 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.