[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: why 0.1+0.2-0.3~=0
- From: Axel Kittenberger <axkibe@...>
- Date: Wed, 14 Mar 2012 09:37:45 +0100
> Not that any of this is super-relevant to Lua, due to its "as buggy as the
> platform" design, I was just curious whether Lua made stronger guarantees
> than C (which makes none afaik).
Thats what the Lua take is. it is 99% ANSI and thus derives all
strength and weakness from that.
This kind of "OMG my numbers!" messages happen in all language
discussions, when naive assumptions on how a computer works meets
Like with many things Lua, things out of the box are just a minimum
toolbox, and you need to build on that (or import other packages) that
makes it useable in a mature way.
If anyone has links to suitable packages please share, I don't
remember from last discussions maybe the number crunchers here can
help you, but slightly recall also like usual the Lua library
ecosystem wasn't that satisfactory.
I know of 4 ways to deal with this:
* Just live with your numbers to be inaccurate, compare with Deltas
and so. Fastest solution, most often used, least satisfactory if you
just need the precission.
* Have a "rationals" package. Most useful if you do not use irrational
things like sin(), PI or so, want precission, and don't run into the
big numbers problem. This kind of packages make out of numbers a
package that stores divisor and divident as seperate numbers. Clojure
comes to mind as a language that has this entities in the language
base package already.
* Have a "string numbers package" Useful if you have to deal with very
large numbers (64bit integer and beyond) and need precission to 1. The
computer calculates like a human with numbers represent as text.
Infinte size of numbers, very slow, always precise on integer.
* Have a package that splits every number into to floating points.
Where "your result" is represented by two limits, your result is
larger or equal than A and smaller or equal than B. Professional
calculations should work like this, speed is quite okay compared to
the naive approach.
PS: my personal agenda: if you have numbers represented by complexer
objects like aboth, but also complex numbers or coords in a 2D or 3D
space, you want to want them to immutables. Numbers are immutables, so
should composed object that represents a number, and its a pity there
is no support for this. And no, proxy tables to not cut it.