Hacker News Reader

Comment by darkmighty | Hacker News Reader

> So we might be interested in low-precision arithmetic to save energy in a battery powered mobile device, or to save clock cycles in a server application manipulating a lot of data. This means that the numerical tricks that most people have forgotten about are relevant again

The more I experience engineering advances the more I see how cyclical techniques and technologies are. Almost everything old that was useful will eventually be needed again. Early computers were severely memory and cpu restricted. Then we got giant computers. Then we're putting microcontrollers everywhere and need those frugal techniques again. And so on the cycle will continue.

A possible conclusion is that the danger of obsolescence from a really profound knowledge in a field is far lower than one would expect, specially if you can weather the cycles of technology and find new markets to apply your expertise.

View on HN

Or do what I do and work with integers and do the heavy stuff on a big computer with lots of CPU and memory.

Integer math is fast, easy, and not error prone, unless you cross the limits in limits.h . But those are simple bounds checking, or you size the vars large enough so that you never need to worry about them. Primarily, if you use floats, you grab the data and send it on its way. Don't process if you don't have to. Drop it to MQTT/CoAP/AMQP.

I'm thinking in the similar way Klipper offloads 3d printer math to a heavy computer with GHz and GBs of ram for trig math and array compensation.

I'm pretty sure integer (i.e., fixed point) math suffers from the same problem here. The only difference is that (a) for a given size, you get a little more precision, since you're not spending bits on the exponent, and (b) you have to hand-code the shift where you lose precision, instead of letting the FPU automatically make the shift where you lose precision.

Sometimes you can get clever with the modular arithmetic--like, it's okay to add (or subtract) a list of fixed-point numbers where partial sums overflow and wrap, as long as the final result doesn't. I don't know any useful analogy to that here, though.

When dealing with floating point, every conversion and computation leads to 'wrong answers', that are only in close proximity to the correct answer.

This paper discusses a great deal the sources of error, and how the IEEE standard does things. https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...

Using integers instead bypasses this source of error. The only caveat that I keep attenion to is that you have to be able to expand the size of the space to prevent decimals from being used (think of multiplying by 100 when dealing with cash). And if you do deal with floats, do the math you have to and then drop back into ints, or save them and send them off.

Your comment is deeply misleading. Floating point is mostly just fixed point plus some rules for automatically moving the decimal point. The point is that depending how you express the formula, you need to "expand the size of the space to prevent decimals from being used" (what do you even mean by that, if your answer has no exact binary representation? how would you express 1/7, or 10000/7, or 65536/7?) by spectacularly more or less.

If you think I'm wrong: Can you code the quadratic formula using integer or other fixed-point math, and demonstrate why it doesn't need the attention to bad numerical conditioning noted in the parent?

> Your comment is deeply misleading. Floating point is mostly just fixed point plus some rules for automatically moving the decimal point.

Uhhhhh..... I hope this is a farcical comment. Because if you believe this, then you might want to read up here: https://en.wikipedia.org/wiki/Floating-point_arithmetic

Perhaps I'm misunderstanding you somewhere; but this is basically what I do for a living, so I don't think I'm wrong. I have carefully re-read my comments above, and would urge you to do the same.

Again: Can you write the quadratic formula in the way that you think is better (in pseudocode, or a language of your choice), and give examples of inputs where it performs better than floating point? If you don't do this and I'm wrong, then you're missing the opportunity to teach me (and all the people I'm misleading with my comments) something. If I'm right, then you're missing the opportunity to learn something yourself.

Oh, and to be complete: The reason why multiplying by 100 = 2^2 * 5^2 helps when dealing with cash is that 0.20 isn't exactly representable in a finite-length binary number (since that's 1/5, and 5 isn't a power of two). It's the multiplication by 5^2 = 25 that makes previously inexact things exact. The additional multiplication by 2^2 = 4 just moves the decimal place by two digits, nothing the FPU couldn't have done on its own. You could represent cash in units of four cents (or two cents, or 256 cents) instead of one cent, and the result would be unchanged except for the location of the decimal place.

There is no useful, general analogy to this in numerical analysis. If you're using any fixed-sized representation of numbers--floating point, fixed point, or otherwise--then some ways to calculate an expression will be less accurate than others. You can avoid this with variable-length representations, but then some ways are slower. There is no way to avoid thinking about numerical conditioning.

Reply on news.ycombinator.com