cancellation happens for instance here: 1 + 1e-50 - 1 == 0
the function again (in the wasteful original form, for clarity).
where do you think cancellation may take place? isn't what you call
canellation a generic rounding error?
On Thu, 2 Mar 2006, Matthias Fischmann wrote:
cancellation happens for instance here: 1 + 1e-50 - 1 == 0
the function again (in the wasteful original form, for clarity).
where do you think cancellation may take place? isn't what you call
canellation a generic rounding error?
On Fri, Mar 03, 2006 at 01:29:06PM +0100, Henning Thielemann wrote:
To: Matthias Fischmann [EMAIL PROTECTED]
cc: haskell-cafe@haskell.org
From: Henning Thielemann [EMAIL PROTECTED]
Date: Fri, 3 Mar 2006 13:29:06 +0100 (MET)
Subject: Re: [Haskell-cafe] rounding errors with real numbers
On Fri, 3 Mar 2006, Matthias Fischmann wrote:
1 + epsilon - 1 == epsilon, which is zero except for a very small
rounding error somewhere deep in the e-minus-somethings. how is the
error getting worse than that, for which numbers?
I meant the relative error. epsilon should be the result, but
:44 +0100 (MET)
Subject: Re: [Haskell-cafe] rounding errors with real numbers.
On Fri, 3 Mar 2006, Matthias Fischmann wrote:
1 + epsilon - 1 == epsilon, which is zero except for a very small
rounding error somewhere deep in the e-minus-somethings. how is the
error getting worse than
On Sun, 26 Feb 2006, Matthias Fischmann wrote:
I think this is the well-known issue of using real numbers in decimal
representation on a machine that thinks binary, but I don't know what
to do with it, and some of you maybe do.
I want to shift+stretch a list of doubles into a given interval.
On Mon, Feb 27, 2006 at 03:11:35PM +0100, Henning Thielemann wrote:
To: Matthias Fischmann [EMAIL PROTECTED]
cc: haskell-cafe@haskell.org
From: Henning Thielemann [EMAIL PROTECTED]
Date: Mon, 27 Feb 2006 15:11:35 +0100 (MET)
Subject: Re: [Haskell-cafe] rounding errors with real numbers
On Mon, 27 Feb 2006, Matthias Fischmann wrote:
On Mon, Feb 27, 2006 at 03:11:35PM +0100, Henning Thielemann wrote:
Is there a cancellation problem?
what's a cancellation problem?
zu deutsch: Auslöschung
cancellation happens for instance here: 1 + 1e-50 - 1 == 0
Maybe you should use a
hi,
I think this is the well-known issue of using real numbers in decimal
representation on a machine that thinks binary, but I don't know what
to do with it, and some of you maybe do.
I want to shift+stretch a list of doubles into a given interval.
example:
| x1 = [2, 3, 4, 5, 10]
| y1 =
Your solution works, but is slightly wasteful with (repair) traversing
the whole list again. Here is a slightly more efficient expression:
-- Precondition: The first parameter (xs) is sorted (ascending) :
-- assert (all (zipWith (=) (xs, tail xs)))
-- low' high'
--
Well, if you are relying on exact results from floating point
arithmetic you're in trouble no matter what you do.
I would just ignore the slight error and when finally printing
the results do some rounding. Trying to fudge things is just
going to bite you somewhere else.
(BTW, I much prefer the
Well, if you are relying on exact results from floating point
arithmetic you're in trouble no matter what you do.
As long as you don't do anything irrational (exp, sin, sqrt, etc.),
you should be able to get away with using Rational. Number constants
with decimals are not automatically
Matthias Fischmann wrote:
| -- fix rounding error:
| repair [i] = [upper]
| repair (h:t) = h : repair t
Just to point out that this only fixes the last element of the list, so
inputs like [1,2,10.8,10.8] would not be handled properly if you require the
same input values to map to
13 matches
Mail list logo
