Open christianp opened 2 years ago
Er, isn't the problem of telling whether two constructive real numbers are equal non-computable?
The problem of deciding whether two algebraic expressions are equal is non-computable, and yet we have a part type for that.
The real problem is that comparing two constructive reals could take arbitrarily long, even if you know that the process will eventually terminate. In practical use, we'd set a limit for how long the computation can go on, and throw an error when it's reached.
For the vast majority of cases (as measured by how often they're seen, not by density in the reals), where a result can be obtained quickly, this will be a convenient way of ensuring a calculation is exact up to the point it needs to be converted to a decimal.
Could we just replace the decimal
type with constructive real values?
I have ported Hans-J. Boehm's CReal library to JS: christianp/creal.js.
Constructive real numbers are exact: they produce decimal digits of the number through a kind of streaming algorithm. This could be useful for avoiding the kind of floating point rounding errors that regularly trip up question authors.
There are two ways they could be implemented:
creal
data type, likedecimal
, and adds methods to cast to the other number types.creal
property to thenumber
type, and make as many operations as possible modify it, as well as the floatvalue
. There's very little computation cost to this: constructive reals are stored as a tree of operations, and computation only happens when you try to get decimal digits out.Ideally, if we go with the second option, comparison options would use the constructive real form by default, so they are exact. It might be hard to tell which values have
creal
properties attached and which don't, though - it's already hard to make sure that operations ondecimal
values don't inadvertently get cast tonumber
.