[HN Gopher] Fixed-point arithmetic as a replacement for soft floats
___________________________________________________________________
Fixed-point arithmetic as a replacement for soft floats
Author : kaycebasques
Score : 23 points
Date : 2024-10-04 23:35 UTC (23 hours ago)
(HTM) web link (pigweed.dev)
(TXT) w3m dump (pigweed.dev)
| mikequinlan wrote:
| What is the advantage of fixed point arithmetic over rational
| arithmetic? Rational arithmetic seems to include fixed point
| arithmetic as a subset (in fixed point arithmetic the denominator
| is always a power of the base).
| the_gorilla wrote:
| It has to run on a computer. How would you simulate rational
| arithmetic?
| mikequinlan wrote:
| Rational arithmetic represents numbers as a numerator and
| denominator (rational numbers). There are hundreds (at least)
| of libraries that implement rational arithmetic on a
| computer.
|
| https://www.google.com/search?q=rational+arithmetic+library
| the_gorilla wrote:
| I meant run on the cpu itself. Most processors have
| floating-point support, and fixed-point just uses integer
| operations. All those heavy libraries require an arbitrary
| amount of memory for their calculations.
| dzaima wrote:
| The article here is about hardware without native FP
| already; that said, rationals (even before getting to the
| need of bigints) are quite bad regardless, likely
| requiring division & gcd around basic arith, which are
| slow both in software and in hardware.
| codr7 wrote:
| As stated: rationals are more general purpose, hence more
| complicated.
| Isognoviastoma wrote:
| - after few operations denominator exceeds 64-bit range, so you
| either need bigint, or make fractions approximate, what is in
| affect fixed point
|
| - often you use decimal fraction on output and input anyway
|
| - it's slower, even slower with bigint
|
| - no square root, sin, and so on with rationals
| crabbone wrote:
| > no square root, sin, and so on with rationals
|
| Are you thinking about a specific library? You aren't the
| only person who commented this way. But, the truth is that
| root, sin and so on don't "work" with floats either. In fact,
| there are common ways to implement these functions by either
| using tables (which are approximate) or algebraic
| approximations (that give you... drum roll: rationals!)
|
| But, really, there isn't any way (except symbolically) to
| represent transcendental functions in computers. It doesn't
| matter what kind of number you choose to do it.
| Isognoviastoma wrote:
| [?]2 with floating point is obviously closest representable
| number. With fixed point it is obviously closest
| representable number as well. With rationals, you need to
| arbitrarily limit precision, and the point of using
| rational was to use exact values.
| tliltocatl wrote:
| Unless you allow the denominator to grow unbound, rational have
| no real advantage over FP and are much slower. If you allow
| unbound denominator, you will run out of memory after perhaps a
| few thousand operations (and having to dynamically allocate
| memory will kill performance even further). And then there are
| transcendent functions which cannot be represented by rationals
| anyway.
| crabbone wrote:
| > And then there are transcendent functions which cannot be
| represented by rationals anyway.
|
| They cannot be represented by floats either. So this doesn't
| matter.
| dzaima wrote:
| The meaningful difference with irrational computations on
| rationals vs floats is that in floats you have some
| inherent, expected, and well-understood imprecision that
| applies evenly over results of add/mul/div/sqrt/sin/etc,
| whereas in unbounded rationals add/mul/div are all
| infinitely precise always (and presumably this property is
| why one would want rationals over floats) but has no such
| possible equivalent for sqrt/sin (at which point your
| options are either just giving up, or capping the required
| precision, at which point you could just use floats).
| librasteve wrote:
| the Raku language https://raku.org defaults to bigint (Int)and
| rational (Rat) numerics since that gives fewer unexpected results
| with eg decimals (0.1+0.2==0.3) ... it's easy enough to reach for
| floating point (Num), but this is deliberately the non default so
| that you the coder need to know that is what you want to trade
| performance vs precision
|
| all irrational operations (sqrt, sin, cos and so on) return Num
| in a consistent way
| martinky24 wrote:
| In most other languages, aren't rationals "deliberately the non
| default so that you the coder need to know that ais what you
| want to trade precision vs performanc"?
|
| My point being, your point doesn't actually make Raku sound
| like they made a good design decision, it's just different for
| the sake of being different when put that way.
| amelius wrote:
| I'd say the best choice is correctness over performance. So
| bignums win.
| gatane wrote:
| You can also use a library for it:
|
| https://github.com/PetteriAimonen/libfixmath
|
| I saw this getting forked for a custom SDK for the PS1 (which
| doesnt have a FPU).
| turtledragonfly wrote:
| That's a good library (I use it myself), but just to be clear
| for anyone reading: that's a standalone fixed-point
| implementation, not a compiler-provided one like the article
| discusses (via -ffixed-point).
| phkahler wrote:
| I just converted a big fixed point algorithm to float on
| Cortex-M4f. It runs very close to the same speed, but
| significantly more readable.
|
| In the fixed code I used straight c but wrote functions for sin,
| cos, and reciprocal square root.
|
| I can't see getting just a 2x improvement over soft float, while
| using llvm specific features and modifying libraries just
| eliminates portability.
| jonathrg wrote:
| Cortex-M4F has an FPU, i.e., hardware floating point support
| (albeit single precision only). You likely would see a much
| greater performance drop without it.
___________________________________________________________________
(page generated 2024-10-05 23:00 UTC)