3 ms·

I too want fewer bits of mantissa in my floating point! But what I wish is that there had been fp64 encoding with a field for number of significant digits. st

I too want fewer bits of mantissa in my floating point! But what I wish is that there had been fp64 encoding with a field for number of significant digits. strtod() would encode this, fresh out of an instrument reading (serial). It would be passed along. It would be useful EVEN if it weren't updated by arithmetic with other such numbers. Every day I get a query like "why does the datum have so many decimal digits? You can't possibly be saying that the instrument is that precise!" Well, it's because of sprintf(buf, "%.16g", x) as the default to CYA. Also sad is the complaint about "0.56000 ... 01" because someone did sprintf("%.16f"). I can't fix this in one class -- data travels between too many languages and communication buffers. In short, I wish I had an fp64 double where the last 4 bits were ALWAYS left alone by the CPU.

slwvx 6mo ago
I've seen more packages that do interval arithmetic than those which keep track of significant digits. For example: https://github.com/JuliaIntervals/IntervalArithmetic.jl https://github.com/JuliaIntervals/IntervalArithmetic.jl
ErroneousBosh 6mo ago
> It would be passed along. It would be useful EVEN if it weren't updated by arithmetic with other such numbers. It would be useful if you could then pass it to an "about equal" operator, too. I don't need to know that the alternator is putting out 13.928528V, and sure as hell I know you're not measuring that accurately. It's precise but wrong. I want an "about equals" thing so I can say "if Valt == 14 alt_ok=true" kind of thing but tag it to be "about 14" not "exactly 14".