Bulat Ziganshin [EMAIL PROTECTED] wrote:
It makes sense to me that the above behaviour is seen: length is
now a good
consumer, but it generates 1+(1+(1+(1+... as it is consuming, and
this causes a stack overflow. I don't think we can fix this while
staying with fold/build fusion,
On Thu, Aug 31, 2006 at 07:44:33AM +0200, Florian Weimer wrote:
* On Wed, 2006-08-30 at 14:58 -0400, David Roundy wrote:
It's sad, but we're stuck with it, as I'm not aware of any
compiler that is capable of generating IEEE arithmetic.
Gcc man page:
-ffast-math
You quoted the
On Wed, Aug 30, 2006 at 06:04:47PM -0400, Lennart Augustsson wrote:
On Aug 30, 2006, at 14:58 , David Roundy wrote:
The trouble here is that ghci is printing more digits than it
really ought to be printing.
No, I don't think it is. Ghci is printing the number that is closest
of all
| Actually, it's sufficient to do good arity-raising transformations,
| and use the definition:
|foldl f z xs = foldr (\x k a - k (f a x)) id xs z
|
| This yields code which looks a bit like this:
|
| let loop [] = id
| loop (x:xs) = let k = loop xs in (\a - k (f a x))
| in loop xs z
Hello Thorkil,
I am very sorry for the late reply. I have been extremely busy and I
wanted to give you a coherent answer.
For a brief overview of the speed of the libraries I looked at
carefully, see
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
(I added a few charts to show
