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

61–70 of 85 posts

Re: Toward an API for the Real Numbers

#61

Post by lmm »

taylodl wrote: post #21

IEEE 754. If you're going to do any serious computation in floating point, serious meaning people's lives are going to depend on the outcome or a lot of money is on the line, then you MUST know what you're doing. We have standards in place so people can learn it, people creating math libraries can adhere to it, and those creating these kinds of applications can have confidence that things are going to work. I'm sorry…

It's a lot more than "a few basic rules of the road". Why squander your attention budget on a numeric type with so many caveats and edge cases? What do you gain from it? If you actually need the performance of IEEE 754, then sure, use it, and have fun debugging all of the problems it has. But it's an extremely poor default for general-purpose programming.

Re: Toward an API for the Real Numbers

#62

Post by yxhuvud »

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…

> But with integer overflows

Some languages give exceptions here, unless specially told not to.

Re: Toward an API for the Real Numbers

#63

Post by black_knight »

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…

> no computational model can represent all real numbers (by a trivial cardinality argument).

I agree with your points about this problem being difficult. But the cardinality argument is neither here nor there. The cardinality argument is based on classical logic, and has no relevance to computation.

In constructive mathematics it is perfectly possible that all real numbers can be represented by finite algorithms. And even that all functions defined on all the reals are continous: a finite constraint of the output can be computed from a finite constraint on the input.

But, starting from a definition of the reals as a Cauchy sequence we have a long way to go to get something which can be practically computed on. I think RealPCF [0] was a step in the right direction.

[0]: https://www.cs.bham.ac.uk/~mhe/papers/realpcf.pdf

Re: Toward an API for the Real Numbers

#64

Post by H8crilA »

_ouml_ wrote: post #55
modeless wrote: post #6

Looks like a cool library. I'm curious why the Android calculator app needs reliable exact equality tests. It doesn't appear to have an equality test function. Edit: the paper claims that you need exact equality tests to avoid printing unnecessary zeros at the end of decimal expansions, among other things. Interesting that this work was done by Hans-J. Boehm, better known for the widely used Boehm garbage collector.

The equality test is equivalent to deciding if something is 0. You can probably ask the app to calculate sqrt(2) * sqrt(2). If that doesn't show a 2 as answer, you've lost. Same goes for sin(arcsin(1/2)). You want the exact answer.

Equality is also needed if you want to know whether "xProof: 1) suppose you can decide whether "x<y" for all x,y. 2) Then, for all x,y you can decide whether x==y because that's just "!(x<y) && !(y<x)"

Re: Toward an API for the Real Numbers

#65

Post by qsort »

black_knight wrote: post #63
qsort wrote: post #19

Earlier quoted context omitted.

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

> no computational model can represent all real numbers (by a trivial cardinality argument). I agree with your points about this problem being difficult. But the cardinality argument is neither here nor there. The cardinality argument is based on classical logic, and has no relevance to computation. In constructive mathematics it is perfectly possible that all real numbers can be represented by finite algorithms. And…

Again, I don't disagree with any of this. The argument advanced by the OP is that floating point numbers are not intuitive to use for the general public because they don't work like the unique complete ordered field up to isomorphism.

All I'm saying with the cardinality argument is that because real numbers are fundamentally unlike integers, obvious methods of doing things won't work, and we are stuck (at least for the time being) with leaky abstractions.

I make no claim about the existence of better/more intuitive solutions. My only counterpoint is that while the ideas outlined in the paper are certainly valuable, I don't think the framework is mature enough to replace the default representation for real numbers in a programming language like Java, at least not without further work and/or proof that it can be adapted to a more general setting without disastrous performance decay.

> But, starting from a definition of the reals as a Cauchy sequence...

I trust that what you're saying is true, but I'm not familiar with that topic, I'm sorry. Thanks for sharing the paper.

Re: Toward an API for the Real Numbers

#66

Post by ogogmad »

dllthomas wrote: post #57
ogogmad wrote: post #49

Earlier quoted context omitted.

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

You can compute on any real number you're given, but IIUC that's not what "computability" means. By the cardinality argument above (there are more infinite streams of digits than finite streams of digits, in an important sense) there will exist streams of digits that you cannot produce by any program (regardless of how you encode it).

You can produce an arbitrary infinite stream using a random number generator, for instance.

Re: Toward an API for the Real Numbers

#67

Post by kevincox »

unnouinceput wrote: post #45
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?

Yes. I use gnome personally and macOS at work and both default calculators are not nearly as nice to use.

Re: Toward an API for the Real Numbers

#68

Post by TeMPOraL »

unnouinceput wrote: post #15

Quote: "Operations complete in under a millisecond, not GFLOPS performance, but certainly good enough for many applications". Then you have a scientist reading this, wants it for research and then wonders why a simple 3 lines in Python code takes 3 days to complete. True story!

If these 3 lines of Python give you correct results...

I keep wondering and never have this answered to my satisfaction: if so many people are just using floating point numbers in scientific calculations, and arguably even most scientists don't understand FP math any way better than the users of Android's Calculator app, then how many bad results are out there, that could be attributed to FP errors?

Related: I don't understand why the default in scientific computing isn't some kind of scheme with error band propagation. What I mean is, when dealing with measurements, the result of 2.1 * 2.12345 isn't 4.459245, because the result exceeds the precision of the first factor. I'd like a common API that handles this, whether implicitly (through notation) or explicitly (through requiring you to state the precision of every number you use).

Re: Toward an API for the Real Numbers

#69

Post by otabdeveloper4 »

lmm wrote: post #61
taylodl wrote: post #21

IEEE 754. If you're going to do any serious computation in floating point, serious meaning people's lives are going to depend on the outcome or a lot of money is on the line, then you MUST know what you're doing. We have standards in place so people can learn it, people creating math libraries can adhere to it, and those creating these kinds of applications can have confidence that things are going to work. I'm sorry…

It's a lot more than "a few basic rules of the road". Why squander your attention budget on a numeric type with so many caveats and edge cases? What do you gain from it? If you actually need the performance of IEEE 754, then sure, use it, and have fun debugging all of the problems it has. But it's an extremely poor default for general-purpose programming.

I disagree. IEEE 754 is a fantastic solution if you want a no-brainer plug-and-play approximation of the real numbers.

Most people who complain really just want a rational number type.

Re: Toward an API for the Real Numbers

#70

Post by karatinversion »

ogogmad wrote: post #66
dllthomas wrote: post #57

Earlier quoted context omitted.

You can compute on any real number you're given, but IIUC that's not what "computability" means. By the cardinality argument above (there are more infinite streams of digits than finite streams of digits, in an important sense) there will exist streams of digits that you cannot produce by any program (regardless of how you encode it).

You can produce an arbitrary infinite stream using a random number generator, for instance.

The probability of generating any given infinite stream is 0, though.
Post reply on HN