Re: [Haskell-cafe] Re: Defaulting to Rational [was: Number overflow]

On Friday 13 July 2007, Jon Fairbairn wrote:

Henning Thielemann writes:

...

On Thu, 12 Jul 2007, Jon Fairbairn wrote:

...

(ie limited precision, but unbounded magnitude). If we were to use BigFloat the base would need to be a power of ten to get the desired results for things like Don's example)

People will be confused, that 'sin pi' won't lead to a result since the correct result is zero and it will need forever to normalize that number.

Surely the first few digits can be computed?

That was my first thought, too. We can't define data Real = Real{ wholePart :: Integer, fractionPart :: [Int]} because you can't yield e.g. sin pi as an infinite list of digits, but you can define data Real = Real{ exponent :: Int, mantissa :: Int -> [Int]} where mantissa rounds the number when it's called. But unless these can be memoized fairly well, I would expect performance to be *quite* surprising to new users. . .

I thought sin pi was a computable numer, anyway. Note that in my representation I didn't specify what form the small part would take; I'm not sufficiently familiar with computing on proper reals to know the best choice for that, but as I undestand it, once we reach the point of showing a number to a finite precision, we /can/ compute the necessary digits.

...

They will be confused, that the result of 'sqrt 2 ^ 2' cannot be shown in usual decimal notation, since the formatting algorithm cannot decide between starting with 2.0000 and 1.9999.

Again, if it's being shown to finite precision, it can look at the next digit after the last one to be shown and use that to decide what to start with. There's no reason why show should be defined to truncate rather than defined to round after the last digit, is there?

...

In short, the Real number type will leed to all difficulties known from computable reals.

All the real ones, anyway :-).

Jonathan Cast http://sourceforge.net/projects/fid-core http://sourceforge.net/projects/fid-emacs