

Flaky: datatypes for real world quantities - knowledgesale
http://dimaborzov.com/flaky-hn.html

======
blackhole
This is a terrible idea. This is a catastrophically bad idea. How do you
compare numbers? How do you figure out that 2.2 is less than exp(65)? You have
to represent these as numbers at some point in the calculation, and in order
to do that, you're probably going to be using either floating point or fixed
point, which means it's still trivially possible to construct an error case
that suffers the exact same problems normal floating point numbers have.
Observe:

    
    
        x=1
        for(i=0;i<n;++i)
          x=0.01+sqrt(x)
    

You can't simplify this, so it will simply loop until it hits the datatype
boundary, and then get rounded into oblivion, because the underlying floating
point representation will break in the exact same way. The only way to get rid
of this would be to use an arbitrary number of bits for precision, in which
case... just use an arbitrary precision library instead! This is _EXACTLY WHY
WE HAVE THEM_.

Most equations that aren't trivial cannot be simplified. This datatype would
only be useful for spoon-fed high school math problems. Furthermore, it costs
so much CPU to perform you might as well just use an arbitrary precision
library, which will probably be faster and be just as effective at preventing
edge cases.

<https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic>

~~~
stiff
Actually, it's a pretty interesting idea. He basically wants to keep track of
the last n operations with every given number and take advantage of this
history to try to minimize the floating point error. To compare 2.2 with
exp(6.5) or anything else you just evaluate the expression, but taking
advantage of possible reorderings or simplifications.

Your critique really boils down to:

 _Most equations that aren't trivial cannot be simplified._

but this is not true, just take a look at what Wolfram Alpha or Mathematica
can do.

~~~
blackhole
If you have an equation in your program that can be effectively simplified,
you should have simplified it before writing in the first place. The thing
about equations that can be simplified is that 99.9% of the time, they can be
simplified _at compile time_.

If you want to write a library to do it for you, great! But don't advertise it
as a replacement for floating point number representations, because it isn't.

~~~
ealloc
He want more than compile-time simplification. He wants runtime simplification
depending on the values encountered at runtime. For example in the quadratic
equation.

And, he clearly isn't marketing it as a replacement for floating point. He
says: "It is important to note, however, that the goal of the project is to
make tools for symbolic calculations, not to create a viable alternative to
the floating point." and he talks a lot about estimating numerical error and
precision.

~~~
stiff
He says this about SymPy...

~~~
ealloc
oops you're right. Nevertheless, he clearly intends to extend rather than
replace floating point since one of the goals is to estimate the errors in the
floating point calculations, and he rounds.

------
eru
> Floating point datatype is the de-facto standard for real world quantities.
> Whether it is a banking account [...]

Is there any bank which uses floating point for accounting?

~~~
reeses
A huge number of ecommerce sites do. (Such as almost every site based on
ATG/Oracle Commerce)

Most banking systems predate standardized FP and use fixed decimal
representations.

~~~
eru
I can see them being used by the quants for fast pricing. But really, for
accounting? Where do the missing cents go?

------
shoo
related: there is a short series of exercises in SICP that explore the idea of
building an interval arithmetic library. i.e. numerical values are represented
by intervals [a, b] which encode their uncertainty/error:

[http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-14.html...](http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-14.html#%_sec_2.1.4)

Exercise 2.14 and onwards point out that two expressions that are
algebraically equivalent for perfectly accurate values stop being equivalent
once we introduce uncertainty. This is only for a toy example expression with
2 variables. Suppose we want to solve a linear system of equations in 100s of
thousands of variables. Is it tractable to track the uncertainty for all of
those variables at once? Will their uncertainties be dependent? ...

~~~
ronaldx
aye, this matches my intuition: having a lower bound and an upper bound (as
rational numbers) on each value means you can:

\- go back and improve if necessary, or otherwise \- express the uncertainty
of a comparison

thanks for the link :)

------
riffraff
Possibly of interest: the Frink programming language has arbitrary precision
math and unit of measurement tracking, and has been around for more than a
decade.

<http://futureboy.us/frinkdocs/index.html>

------
darkmighty
Interesting take on floating point problem, but it seems as if writer isn't
well versed on the centuries old solution of this problem, namely refinement
calculations for lin algebra and more general iterated numerical methods for
nonlinear systems -- and those are the places where the precision matters,
where you are trying to calculate a figure with a given accuracy.

Note however, that solutions to many problems may in a sense 'non-analytic',
there may be no finite set of elementary functions on a given rational number
which yields the solution.

Also, iterative answers are usually the only viable way to reach solutions,
they're usually much faster than the exact solution (or the floating point
precision limited solution), and you can always control how good your solution
is.

Observation: So in a sense what is practically used may indeed very close to
the Kolmogorov complexity of the solutions - the representation as
R=IterativeProblemSolve(Problem,ClosestSolution), where we publish the problem
and the desired solution! (assumig we are efficiently describing the problem)

------
Noughmad
Floating point is not so bad. Yes, when you need fixed precision, such as in
accounting, you should avoid it. But with numerical computations, if you run
into problem because of float limitations, you're doing it wrong.

The first rule of numerics is not to compare variables of very different
magnitude. His first example has coefficients that differ by almost 200
orders. This example is totally outrageous, but still, what any reasonable
person would do is introduce some scaling into the equation.

Yes, you have to think about scales, but you already do that. You never write
programs with meters and seconds, you choose scaled dimensionless quantities.
And unless you choose the scales very badly, you won't get any problems from
floats.

------
weichi
Hard to comment without seeing more concrete examples of his approach. But it
makes me wonder whether processors are now so fast that, for a large class of
numerical problems, the default should be to give up calculational speed in
return for eliminating some of the trickiness involved with floating point.

------
oofabz
How about continued fractions? Unlike floating point, they can represent any
rational number in finite memory. Using generators, you can even represent
many irrational numbers, like square roots and pi, in finite memory.

Richard Schroeppel and Bill Gosper explored continued fractions in the '70s:

<http://www.inwap.com/pdp10/hbaker/hakmem/cf.html>

~~~
darkmighty
What's special about representing rationals in finite memory? By definition
they can be represented by two finite integers. There are many ways of
describing irrational numbers in finite memory if you allow this kind of
generalization, e.g. make a datatype to represent equations and numbers as
solution to the equations.

------
smilekzs
What we need is an open-source alternative of Mathematica's core language.

~~~
GhotiFish
well, off the top of my head, there's GNU Octave.

~~~
riffraff
that'd be matlab not mathematica

------
jamesaguilar
Maybe it's just me, but saying that something in current use in billions of
computers around the globe is . . . somewhat of a stretch of the word
"obsolete."

~~~
eksith
In this case "obsolete" may be the relevant term as in Automobile coach
builders, meet the Buggy Whip makers. The two did co-exist in the early 1900's
so the alternative, "outmoded" didn't happen overnight. But it did eventually
happen.

The numbers, in the billions, of course weren't there, but my guess is that
the proportions are applicable.

Edit: After reading the article, I _strongly_ disagree this approach is
"better" in any sense of the word. More along the lines of using whale oil for
the automobile instead of gasoline. Gasoline isn't perfect, but it works.
Until we have something better (I.E. Electric), I'll stick to that.

------
GhotiFish
floating point will never be obsolete, it is a log scale datatype, and log
scale datatypes represent most natural values perfectly.

The only place where the shoe doesn't fit is where you need a minimum
accuracy. In that case what you should be doing is using integers to represent
your minimum quantifiable unit.

For example, you could represent currency in millicents to give you
respectably accurate rounding. Not accurate enough? Microcents then. Now you
don't have enough range? Good, you're thinking about your requirements now,
floating point DEFINITELY wouldn't of worked.

~~~
qznc
In addition you must prevent overflows.

Microcents with signed long long (64bit) means a maximum value of 2 __63 / 100
/ (10 __6) = 92233720368. In words "92 billion", which might not be enough.

~~~
reeses
In environments with exhaustive partitions and automatic 'promotion' (i.e.,
Common Lisp but probably not Ruby, etc.), your overflow would result in a
correctly calculated bignum.

