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

Toward an API for the Real Numbers

blog.acolyer.org

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Toward an API for the Real Numbers

#41

Post by dahart »

slx26 wrote: post #12

In "safe" languages we often talk about how you can't ignore errors in return values. Your program "leaks" if that happens. But with integer overflows and floating point precision, we just ignore the leaks as something that programmers already know about and have to consider while coding. Of course, it's not an easy problem to deal with, as computers don't have infinite memory and they need to be performant, but we r…

> In "safe" languages we often talk about how you can't ignore errors in return values.

It’s pretty important to define what you mean by “error”. We should not conflate state or execution errors with approximation errors, they are very very different kinds of errors. It is quite often not an error condition to have an approximation, and so would not count as a “leak”.

> If it only takes 6k lines to provide an API for more precise real numbers, then almost every programming language should have it.

There are a lot of libraries in a lot of languages for supporting arbitrary precision, big numbers, and other various representations. I’d venture to say that almost every programming language does have it, if you count a third party or open source library as having it.

On the other hand, high precision reals is a performance drain of enormous magnitude if you don’t always need it. Do keep in mind that even with all their problems, 32 bit floats and 64 bit doubles are really fast compared to software number libraries, the IEEE formats have broad hardware support that doesn’t exist for high precision reals.

Re: Toward an API for the Real Numbers

#42

Post by molyss »

agravier wrote: post #24
jepler wrote: post #17

(sin⁻¹(cos⁻¹(tan⁻¹(tan(cos(sin(9))))))−9)^−1 produces "Timeout. Undefined?". That's the closest I could get to baffling or tricking it. (it's division by zero)

cos is not the inverse of sin, cos(sin(9)) is not 9

I think the intended simplification is : (sin⁻¹(cos⁻¹(tan⁻¹(tan(cos(sin(9))))))−9)⁻¹ -> (sin⁻¹(cos⁻¹(cos(sin(9))))−9)⁻¹ -> (sin⁻¹(sin(9))−9)⁻¹ -> (9−9)⁻¹ -> 0⁻¹ -> 1/0

Re: Toward an API for the Real Numbers

#43

Post by SAI_Peregrinus »

fouronnes3 wrote: post #36
skulk wrote: post #4

Earlier quoted context omitted.

For a high-level API, shouldn't this be expressed with types such as a `Result ` at the library level? edit: now that I think about it, that would require some really nice optional chaining syntax to be even slightly usable.

Oh now I'm curious if IEEE 754 NaN rules are isomorphic to a number optional type with monadic chaining syntax

Basically. And you can stick error codes in the value too, so you can know down the line what caused the NaN.

Re: Toward an API for the Real Numbers

#44

Post by agravier »

molyss wrote: post #42
agravier wrote: post #24

Earlier quoted context omitted.

cos is not the inverse of sin, cos(sin(9)) is not 9

I think the intended simplification is : (sin⁻¹(cos⁻¹(tan⁻¹(tan(cos(sin(9))))))−9)⁻¹ -> (sin⁻¹(cos⁻¹(cos(sin(9))))−9)⁻¹ -> (sin⁻¹(sin(9))−9)⁻¹ -> (9−9)⁻¹ -> 0⁻¹ -> 1/0

I see, right. This is curious.

Re: Toward an API for the Real Numbers

#45

Post by unnouinceput »

kevincox wrote: post #2

Tangentially related, the stock Android calculator app is fantastic. It has good accuracy as mentioned in the article and an easy to explore and use history. It is one of the few things that will make me hunt around for my phone when I am working on my desktop.

Why? Your operating system of choice lacks a proper calculator on your desktop PC?

Re: Toward an API for the Real Numbers

#46

Post by flubert »

molyss wrote: post #40
fanf2 wrote: post #8

Earlier quoted context omitted.

You need some way to cope with operations that don’t have real results for some values, such as log and sqrt of negative numbers

you can just represent those as a pair of real numbers, one for the real part, and one for the imaginary part. As long as you only (recursively) apply exponential and trig functions on those numbers, I believe you'll stay within the realm of complex numbers.

0/0, tan(pi/2), log(0)

Re: Toward an API for the Real Numbers

#47

Post by yarg »

MarkSweep wrote: post #20

Another example of how to solve this problem is the rational number library used in the Microsoft Calculator. It is called “RatPak” and it is open source: https://github.com/microsoft/calculator/blob/master/src/Calc...

Rationals are a strict subset of the reals.

There are also the irrationals, and most of those cannot even be expressed (fortunately, since they cannot be expressed, there's no chance of you bumping into them by accident - so it's somewhat of a moot point).

The subset that you want to aim for is not the rationals, but the definable reals: https://en.wikipedia.org/wiki/Definable_real_number.

Re: Toward an API for the Real Numbers

#49

Post by ogogmad »

qsort wrote: post #19
slx26 wrote: post #12

In "safe" languages we often talk about how you can't ignore errors in return values. Your program "leaks" if that happens. But with integer overflows and floating point precision, we just ignore the leaks as something that programmers already know about and have to consider while coding. Of course, it's not an easy problem to deal with, as computers don't have infinite memory and they need to be performant, but we r…

> the ability to define the kind of numbers you want to be working with and their precision is fairly poor in computer science... It's poor because it's undecidable. We would ideally want to work with the real numbers, but no computational model can represent all real numbers (by a trivial cardinality argument). Obviously, we can make useful progress in practice and evolve beyond the floating point representation (at…

> It's poor because it's undecidable. We would ideally want to work with the real numbers, but no computational model can represent all real numbers (by a trivial cardinality argument).

This is a fallacy. The standard model for Computable Real Analysis, Type Two Effectivity, supports computation over all real numbers. See: https://en.wikipedia.org/wiki/Computable_analysis#Real_numbe...

Essentially, in TTE, a real number is an arbitrary stream of digits that can come from any source. Therefore any real number can be computed on.

Additionally, the ability to decide equality of floating point numbers is an illusion. Rounding errors can make numbers that ought to equal each other not equal each other.

Re: Toward an API for the Real Numbers

#50

Post by ogogmad »

qsort wrote: post #37
comex wrote: post #31

Earlier quoted context omitted.

> The paper is interesting and talks about very real problems, but it's still a far cry from something that can be used in production. It’s used in production in the default Android calculator app. Does that not count?

It does count, and it's certainly "points" for the ideas there (not that the author needs my validation...) But an API for a language like Java needs more generality than that. The use case was (relatively) simple, (relatively) predictable, and (relatively) self-contained. Crucially, equality in general is still undecidable (it wouldn't play nice with Collections), and it's not obvious that numerical algorithms would…

> it's not obvious that numerical algorithms would in general play nice with it

Perhaps. Some algorithms in numerical analysis are only "backwards stable" as opposed to forwards stable. This includes all possible algorithms for things like Singular Value Decomposition. See: https://mathoverflow.net/questions/369930/why-is-uncomputabi...

> With the world going more and more the route of ML, efficiency of numerical algorithms is not a secondary concern.

ML is going in the direction of very low precision floating point numbers, like 16 bit floats. High precision doesn't seem to matter there.

Post reply on HN