Live data from Hacker News

Flaky: datatypes for real world quantities

dimaborzov.com

11–20 of 42 posts

Re: Flaky: datatypes for real world quantities

#11
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...

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? ...

Re: Flaky: datatypes for real world quantities

#13

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 n…

"You can't simplify this"

I have learned to be careful about making such claims.

http://mathworld.wolfram.com/NestedRadical.html

Re: Flaky: datatypes for real world quantities

#14
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

Re: Flaky: datatypes for real world quantities

#15

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 n…

"You can't simplify this" I have learned to be careful about making such claims. http://mathworld.wolfram.com/NestedRadical.html

Yea but simplifications like this are probably non-computable, even when possible, and hard to do in any case.

Re: Flaky: datatypes for real world quantities

#16
post #4

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

There are a number of these. The one I have been using lately is sympy - a pure python symbolic math library.

You may also be interested in the open source "sage mathematics", which is a frontend/interface to many different open-source symbolic solvers such as sympy, maxima, GAP, PARI, Singular, and octave.

They are not as good as mathematica currently, but can already do quite a lot.

Re: Flaky: datatypes for real world quantities

#17
post #14

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

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.

Re: Flaky: datatypes for real world quantities

#18

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 n…

"You can't simplify this" I have learned to be careful about making such claims. http://mathworld.wolfram.com/NestedRadical.html

Wrong, that isn't what this is. This isn't a nested radical to infinite terms, it's a nested radical to n terms. Thus, it cannot be simplified.
Post reply on HN