Wilhelm B. Kloke wrote:
Ben Franksen [EMAIL PROTECTED] schrieb:
Wilhelm B. Kloke wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] schrieb:
I would consider a good idea if ghc would provide language support to
this sort of integers.
No need, you can do that for yourself:
{-# LANGUAGE
Richard A. O'Keefe wrote:
On 14 Feb 2008, at 6:01 pm, Roman Leshchinskiy wrote:
I don't understand this. Why use a type which can overflow in the
first place? Why not use Integer?
[...]
Presumably the reason for having Int in the language at all is speed.
As people have pointed out several
G'day all.
Richard A. O'Keefe wrote:
That's one of the warning signs I watch out for. Never compare floats for
equality is a sure sign of someone who thinks they know about
floats but don't.
Quoting Roman Leshchinskiy [EMAIL PROTECTED]:
Hmm. Personally, I've never seen an algorithm
Jed Brown comments the answer of -
-- Roman Leshchinskiy who answers my question concerning the replacement
of floating-point numbers:
First, when I see the advice use something else, I always ask what,
and I get an answer very, very rarely... Well? What do you propose?
For Haskell,
[EMAIL PROTECTED] [EMAIL PROTECTED] schrieb:
G'day all.
Richard A. O'Keefe wrote:
Hmm. Personally, I've never seen an algorithm where comparing for exact
equality was algorithmically necessary.
One trick I've occasionally used is to avoid the need for a discriminated
union of floating
[EMAIL PROTECTED] wrote:
Jed Brown comments the answer of -
-- Roman Leshchinskiy who answers my question concerning the replacement
of floating-point numbers:
First, when I see the advice use something else, I always ask
what,
and I get an answer very, very rarely... Well? What do you
On 2008-02-14, Roman Leshchinskiy [EMAIL PROTECTED] wrote:
Richard A. O'Keefe wrote:
Presumably the reason for having Int in the language at all is speed.
As people have pointed out several times on this list to my knowledge,
Integer performance is not as good as Int performance, not hardly,
Wilhelm B. Kloke wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] schrieb:
G'day all.
Richard A. O'Keefe wrote:
Hmm. Personally, I've never seen an algorithm where comparing for exact
equality was algorithmically necessary.
One trick I've occasionally used is to avoid the need for a
Hello,
On a tangent, probably:
On Thursday 14 February 2008 10:24, Roman Leshchinskiy wrote:
...
Hmm. Personally, I've never seen an algorithm where comparing for exact
equality was algorithmically necessary. Sometimes (rarely) it is
acceptable but necessary? Do you know of one?
Finding
Aaron Denney wrote:
On 2008-02-14, Roman Leshchinskiy [EMAIL PROTECTED] wrote:
Richard A. O'Keefe wrote:
SafeInt is what you should use when you *THINK* your results should all fit
in a machine int but aren't perfectly sure. (And this is nearly all the
time.)
Again, I strongly disagree.
G'day all.
Quoting Thorkil Naur [EMAIL PROTECTED]:
Finding the machine epsilon, perhaps, that is, the smallest
(floating point,
surely) number for which 1.0+machine_eps==1.0 would be a candidate?
The machine epsilon is the smallest relative separation between two
adjacent normalised
On 14 Feb 2008, at 10:24 pm, Roman Leshchinskiy wrote:
Do I understand correctly that you advocate using overflowing ints
(even if they signal overflow) even if Integers are fast enough for
a particular program?
No you most certainly do NOT. There is no way to soundly, and I
would have
On 15 Feb 2008, at 2:03 am, Wilhelm B. Kloke wrote:
IMHO it is a perfectly good idea to use the FP processor for integer
computations. You can use the Inexact Trap as Overflow Exception,
a service you don't get from i386 (and most other) hardware for int
operations.
A neat idea. However, the
Ben Franksen [EMAIL PROTECTED] schrieb:
Wilhelm B. Kloke wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] schrieb:
I would consider a good idea if ghc would provide language support to
this sort of integers.
No need, you can do that for yourself:
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
On 12 Feb 2008, at 5:14 pm, [EMAIL PROTECTED] wrote:
Would you say that *no* typical floating-point software is reliable?
With lots of hedging and clutching of protective amulets around the
word reliable, of course not. What I *am* saying is that
(a) it's exceptionally HARD to make reliable
Trialog:
Roman Leshchinskiy writes:
Richard A. O'Keefe wrote:
[EMAIL PROTECTED] wrote:
Would you say that *no* typical floating-point software is reliable?
With lots of hedging and clutching of protective amulets around the
word reliable, of course not. What I *am* saying is that
(a) it's
Richard A. O'Keefe wrote:
On 14 Feb 2008, at 2:28 pm, Roman Leshchinskiy wrote:
Richard A. O'Keefe wrote:
On 12 Feb 2008, at 5:14 pm, [EMAIL PROTECTED] wrote:
Would you say that *no* typical floating-point software is reliable?
With lots of hedging and clutching of protective amulets
[EMAIL PROTECTED] wrote:
Trialog:
Roman Leshchinskiy writes:
Richard A. O'Keefe wrote:
[EMAIL PROTECTED] wrote:
Would you say that *no* typical floating-point software is reliable?
With lots of hedging and clutching of protective amulets around the
word reliable, of course not. What I
On 14 Feb 2008, at 6:01 pm, Roman Leshchinskiy wrote:
I don't understand this. Why use a type which can overflow in the
first place? Why not use Integer?
Why is this hard to understand?
Dijkstra's classic A Discipline of Programming distinguishes
several kinds of machine. I'm quoting from
On 14 Feb 2008, at 2:28 pm, Roman Leshchinskiy wrote:
Richard A. O'Keefe wrote:
On 12 Feb 2008, at 5:14 pm, [EMAIL PROTECTED] wrote:
Would you say that *no* typical floating-point software is reliable?
With lots of hedging and clutching of protective amulets around the
word reliable, of
Yitzchak Gale wrote:
Ben Franksen wrote:
...and the Unimo paper[1] explains how to easily write a 'correct' ListT.
Are you sure? Maybe I am missing something, but I don't
see any claim that the Unimo ListT satisfies the laws any
more than the old mtl ListT.
ListT-Done-Right could also be
I wrote:
Floating point intentionally trades accuracy for speed,
Jerzy Karczmarczuk wrote:
1. This is not a possible trade-off or not. In scientific/engineering
computation there is really no choice, since you have to compute
logarithms, trigonometric functions, etc., and some inaccuracy
Yitzchak Gale writes:
Jerzy Karczmarczuk wrote:
Would you say that *no* typical floating-point software is reliable?
It depends on how you define reliable.
Floating point intentionally trades accuracy for speed,
...
It used to be true - and may still be - that the engineers
who
Ben Franksen wrote:
...and the Unimo paper[1] explains how to easily write a 'correct' ListT.
BTW, Unimo is an extreme case of the monad laws holding only w.r.t.
the 'right' equality, i.e. in the laws m == m' is to be understood as
observe_monad m == observe_monad m'
(and even this '==' is
Jerzy Karczmarczuk wrote:
Would you say that *no* typical floating-point software is reliable?
It depends on how you define reliable.
Floating point intentionally trades accuracy for speed,
leaving it to the user to worry about round-off errors.
It is usually not too hard to get the probability
Andrew Butterfield wrote:
let m denote the list monad (hypothetically). Let's instantiate:
return :: x - [x]
return x = [x,x]
(=) :: [x] - (x - [y]) - [y]
xs = f = concat ((map f) xs)
Let g n = [show n]
Here (return 1 = g ) [1,2,3] = [1,1,1,1,1,1]
but g[1,2,3] = [1,2,3],
thus violating
On Feb 11, 2008 1:35 PM, Andrew Butterfield
[EMAIL PROTECTED] wrote:
Hugs 1.0 + (2.5e-15 + 2.5e-15)
1.01 :: Double
Hugs (1.0 + 2.5e-15) + 2.5e-15
1.0 :: Double
Prelude (1e30 + (-1e30)) + 1
1.0
Prelude 1e30 + ((-1e30) + 1)
0.0
I love this example from David Goldberg
Richard A. O'Keefe comments:
[floating point addition is not associative]]
And this is an excellent example of why violating expected laws is BAD.
The failure of floating point addition to be associative means that there
are umpteen ways of computing polynomials, for example, and doing it
Am Montag, 11. Februar 2008 16:35 schrieb Andrew Butterfield:
This is precisely Jerzy's point - you can have many mathematical laws as
you like but there is no guarantee that a programming languages
implementation will satisfy them.
But people writing instances of type classes should take care
apfelmus wrote:
Deokjae Lee wrote:
Tutorials about monad mention the monad axioms or monad laws. The
tutorial All About Monads says that It is up to the programmer to
ensure that any Monad instance he creates satisfies the monad laws.
The following is one of the laws.
(x = f) = g == x = (\v -
On 12 Feb 2008, at 4:35 am, Andrew Butterfield wrote:
[floating point addition is not associative]
And this is an excellent example of why violating expected laws is BAD.
The failure of floating point addition to be associative means that
there
are umpteen ways of computing polynomials, for
Dan Piponi wrote:
IOn Feb 11, 2008 9:46 AM, Miguel Mitrofanov [EMAIL PROTECTED] wrote:
It's well known that ListT m monad violates this law in general
(though it satisfies it for some particular monads m). For example,
I went through this example in quite a bit of detail a while ago and
On 11 Feb 2008, at 7:52 AM, Arnar Birgisson wrote:
Hi all,
On Feb 11, 2008 3:14 PM, apfelmus [EMAIL PROTECTED] wrote:
I will be mean by asking the following counter question:
x + (y + z) = (x + y) + z
is a mathematical identity. If it is a mathematical identity, a
programmer need not
Hi all,
On Feb 11, 2008 3:14 PM, apfelmus [EMAIL PROTECTED] wrote:
I will be mean by asking the following counter question:
x + (y + z) = (x + y) + z
is a mathematical identity. If it is a mathematical identity, a
programmer need not care about this law to implement addition + . Can
Deokjae Lee wrote:
Tutorials about monad mention the monad axioms or monad laws. The
tutorial All About Monads says that It is up to the programmer to
ensure that any Monad instance he creates satisfies the monad laws.
The following is one of the laws.
(x = f) = g == x = (\v - f v = g)
35 matches
Mail list logo
