Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flaky: datatypes for real world quantities

dimaborzov.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Flaky: datatypes for real world quantities

#31

Post by ealloc »

stiff wrote: post #30
ealloc wrote: post #29

Earlier quoted context omitted.

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…

He says this about SymPy...

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.

Re: Flaky: datatypes for real world quantities

#32

Post by qznc »

GhotiFish wrote: post #10

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

In addition you must prevent overflows.

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

Re: Flaky: datatypes for real world quantities

#33

Post by rwallace »

eru wrote: post #6

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

I encountered an insurance company that used floating point as their standard data type for monetary values. On the bright side, that was in the late nineties; hopefully they've switched to a proper decimal type since then.

Re: Flaky: datatypes for real world quantities

#34

Post by 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.

Re: Flaky: datatypes for real world quantities

#35

Post by ronaldx »

shoo wrote: post #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 equivale…

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 :)

Re: Flaky: datatypes for real world quantities

#36

Post by GhotiFish »

qznc wrote: post #32
GhotiFish wrote: post #10

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

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.

yup! Which is scary to think about, because if you had a microcents requirement for accuracy, your ceiling would of being at 2^53/2*(micro) = 4,503,599,627

4 billion. eak.

Re: Flaky: datatypes for real world quantities

#37

Post by GhotiFish »

shoo wrote: post #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 equivale…

... that is a really good idea. Why do I keep putting off reading that book?!

Re: Flaky: datatypes for real world quantities

#38

Post by reeses »

eru wrote: post #6

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

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.

Re: Flaky: datatypes for real world quantities

#39

Post by reeses »

GhotiFish wrote: post #10

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

Integers, BCD, rationals, or other arbitrary precision representations are preferable as well. IBM keeps BCD alive and fast for COBOL and other 'legacy' systems.

Re: Flaky: datatypes for real world quantities

#40

Post by reeses »

qznc wrote: post #32
GhotiFish wrote: post #10

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

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.

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.
Post reply on HN