On Jan 15, 2008 12:29 AM, [EMAIL PROTECTED] wrote:
Ben Franksen writes:
[EMAIL PROTECTED] wrote:
...
Does *MATH* answer the question what is: (0/0)==(0/0) ? Nope!
Exactly. So why try to give an answer in Haskell? MATH says: the
expression 0/0 is undefined, thus comparing (0/0)==(0/0)
On Thu, 10 Jan 2008 19:38:07 +0200, Tillmann Rendel
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Although it could be argued that laziness is the cause of some very
obscure bugs... g Niko
Example, PLEASE.
Prelude sum [1..100]
*** Exception: stack overflow
Not true in Hugs.
On Fri, 11 Jan 2008 09:16:12 +0200, Lennart Augustsson
[EMAIL PROTECTED] wrote:
Thank you Duncan, you took the words out of my mouth. :)
On Jan 10, 2008 5:42 PM, Duncan Coutts [EMAIL PROTECTED]
wrote:
So let's imagine:
ones = 1 : ones
ones' = repeat 1
where repeat n = n : repeat n
Am Freitag, 11. Januar 2008 08:11 schrieb Lennart Augustsson:
Some people seem to think that == is an equality predicate.
This is a big source of confusion for them; until they realize that == is
just another function returning Bool they will make claims like
[1..]==[1..] having an unnatural
On Fri, 11 Jan 2008 09:11:52 +0200, Lennart Augustsson
[EMAIL PROTECTED] wrote:
Some people seem to think that == is an equality predicate.
This is a big source of confusion for them; until they realize that == is
just another function returning Bool they will make claims like
[1..]==[1..]
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking.
In my opinion it is the better than yielding True. 0/0 doesn't make
sense. So it can't be compared to anything else which doesn't make
sense.
Whether == should yield False at all is another matter. It may be better
to
On Fri, 11 Jan 2008 09:11:52 +0200, Lennart Augustsson
[EMAIL PROTECTED] wrote:
Some people seem to think that == is an equality predicate.
This is a big source of confusion for them; until they realize that == is
just another function returning Bool they will make claims like
[1..]==[1..]
On Jan 11, 2008 7:47 AM, Miguel Mitrofanov [EMAIL PROTECTED] wrote:
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking.
Just for the record: the following is from Firebug (JavaScript debugger for
Firefox) session:
a = 0/0
NaN
a == a
false
a === a
false
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking.
Just for the record: the following is from Firebug (JavaScript debugger for
Firefox) session:
a = 0/0
NaN
a == a
false
a === a
false
___
Haskell-Cafe mailing list
As GNU is not Unix, NaN is not a number,
Since NaN /= NaN, I think, we should decipher NaN as Not a NaN instead.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It
doesn’t adhere to any meaningful axiom set for Eq.
Tough luck, but that's how floating point works, and what the
numericalists know, and possibly even love (although I have
Achim Schneider wrote:
The list instance for Eq might eg. know something about the structure
of the lists and be smart enough not to get caught in the recursion of x
= 1:1:x and y = 1:1:1:y so it could successfully compare x == y to
True in six compares.
This would not be something about the
On Fri, 11 Jan 2008 13:29:35 +0200, Wolfgang Jeltsch
[EMAIL PROTECTED] wrote:
Am Freitag, 11. Januar 2008 10:54 schrieb Wilhelm B. Kloke:
Wolfgang Jeltsch [EMAIL PROTECTED] schrieb:
However, the fact that (0 / 0) == (0 / 0) yields False is quite
shocking.
It doesn?t adhere to any
Am Freitag, 11. Januar 2008 11:33 schrieben Sie:
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking.
It doesn’t adhere to any meaningful axiom set for Eq.
Tough luck, but that's how floating point works, and what the
Am Freitag, 11. Januar 2008 10:54 schrieb Wilhelm B. Kloke:
Wolfgang Jeltsch [EMAIL PROTECTED] schrieb:
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking.
It doesn?t adhere to any meaningful axiom set for Eq. So I think that
this behavior should be changed. Think
Ketil Malde [EMAIL PROTECTED] writes:
The bombing of NaN *might* be a profound compilation option, but for
people who really do numerical work, this is a blessing NOT to have
it.
I'll expand a bit of this, after I've checked with Wikipedia. Please
correct me (and it) if I'm wrong, but:
1)
On Fri, 11 Jan 2008 14:21:45 +0200, [EMAIL PROTECTED]
wrote:
Ketil Malde:
Wolfgang Jeltsch:
However, the fact that (0 / 0) == (0 / 0) yields False is quite
shocking.
It doesn’t adhere to any meaningful axiom set for Eq.
Tough luck, but that's how floating point works, and what the
Wolfgang Jeltsch wrote:
Am Freitag, 11. Januar 2008 11:33 schrieben Sie:
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking.
It doesn’t adhere to any meaningful axiom set for Eq.
Tough luck, but that's how floating point works,
That would give you a language with a semantics I don't want to touch.
Sometimes useful, yes, but far to intensional for my taste.
-- Lennart
On Jan 11, 2008 5:59 AM, Achim Schneider [EMAIL PROTECTED] wrote:
Yes, thanks. I actually do think that many things would be easier if
every
[EMAIL PROTECTED] writes:
The difference between you (and/or Wolfgang J.) and myself is that I enjoy
more my freedom, even if I have to pay with a little more work. You want
to enforce rigid reactions of the system. You should be free to do it on
*your* machine, not on mine.
You are putting
On Jan 11, 2008 9:27 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It
doesn't adhere to any meaningful axiom set for Eq. So I think that this
behavior should be changed. Think of a set implementation which uses (==) to
If you talk to anyone who uses floating point numbers for real they would
find (0/0)==(0/0) perfectly natural.
It disobeys some axioms that Eq instances don't fulfill anyway, but changing
it would make a lot of people surprised too.
In general, the floating point instances break almost all axioms
Am Freitag, 11. Januar 2008 13:21 schrieb [EMAIL PROTECTED]:
Ketil Malde:
Wolfgang Jeltsch:
However, the fact that (0 / 0) == (0 / 0) yields False is quite
shocking. It doesn’t adhere to any meaningful axiom set for Eq.
Tough luck, but that's how floating point works, and what the
[EMAIL PROTECTED] writes:
People, you are monsters.
Well, bring on the torches and the pitchforks (although the image in
my mind is more like a mob carrying lenses and bananas).
no, some users are victims of its success as a formal language, not
just as a coding tool
I think Haskell's
The thing is that y already is a *builtin* function in Haskell.
On Fri, 11 Jan 2008 15:59:50 +0200, Achim Schneider [EMAIL PROTECTED] wrote:
Cristian Baboi [EMAIL PROTECTED] wrote:
So let's imagine:
ones = 1 : ones
ones' = repeat 1
where repeat n = n : repeat n
(==) :: Eq a = a - a
If you can't stomach the weirdness of floating point then perhaps you should
try to define your own type that obeys all the expected laws? :)
On Jan 11, 2008 3:36 AM, Wolfgang Jeltsch [EMAIL PROTECTED]
wrote:
Am Freitag, 11. Januar 2008 11:03 schrieb Felipe Lessa:
Another thing for the
On 11 Jan 2008, at 5:13 AM, Achim Schneider wrote:
Jonathan Cast [EMAIL PROTECTED] wrote:
What kind of mathematics? I don't know of any mathematics where
algebraic simplifications are employed without proof of the
underlying equations (in some denotational model).
Mathematics as, as my
On Jan 10, 2008 3:36 PM, Achim Schneider [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Niko Korhonen writes:
...
Although it could be argued that laziness is the cause of some very
obscure bugs... g
Niko
Example, PLEASE.
[1..] == [1..]
, for assumed operational
[EMAIL PROTECTED] wrote:
Although it could be argued that laziness is the cause of some very
obscure bugs... g Niko
Example, PLEASE.
Prelude sum [1..100]
*** Exception: stack overflow
Prelude Data.List.foldl' (+) 0 [1..100]
5050
Tillmann
rendel:
[EMAIL PROTECTED] wrote:
Although it could be argued that laziness is the cause of some very
obscure bugs... g Niko
Example, PLEASE.
Prelude sum [1..100]
*** Exception: stack overflow
Prelude Data.List.foldl' (+) 0 [1..100]
5050
See,
On Thu, Jan 10, 2008 at 10:10:21AM -0800, Don Stewart wrote:
rendel:
[EMAIL PROTECTED] wrote:
Although it could be argued that laziness is the cause of some very
obscure bugs... g Niko
Example, PLEASE.
Prelude sum [1..100]
*** Exception: stack overflow
Prelude
Achim Schneider wrote:
[1..] == [1..]
[some discussion about the nontermination of this expression]
The essence of laziness is to do the least work necessary to cause the
desired effect, which is to see that the set of natural numbers equals
the set of natural numbers, which, axiomatically,
G'day all.
Quoting [EMAIL PROTECTED]:
Perhaps another example is more relevant, the tradeoffs
space-time in the
optimized version of the powerset generator...
Yeah, I was going to bring up that topic.
I've been lazy programming for 15 or so years, and the only bugs that I
can think of are:
On Jan 11, 2008 12:09 AM, [EMAIL PROTECTED] wrote:
1. Indirect black holes that are not expressible in a strict
language. You generally have to be doing something bizarre for this
to occur, and it doesn't take too long before you can accurately
predict when they constitute a likely risk.
G'day all.
Quoting Luke Palmer [EMAIL PROTECTED]:
What do you mean by black hole here?
A black hole is what happens when evalation of something recursively
depends on its own evaluation in such a way that no useful work can be
done. An example is:
let omega = omega + 1 in omega
In
On Fri, 2008-01-11 at 01:12 +0100, Achim Schneider wrote:
Tillmann Rendel [EMAIL PROTECTED] wrote:
Achim Schneider wrote:
[1..] == [1..]
[some discussion about the nontermination of this expression]
The essence of laziness is to do the least work necessary to cause
the
On 10 Jan 2008, at 7:55 AM, Achim Schneider wrote:
Daniel Yokomizo [EMAIL PROTECTED] wrote:
On Jan 10, 2008 3:36 PM, Achim Schneider [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Niko Korhonen writes:
...
Although it could be argued that laziness is the cause of some
very obscure
Some people seem to think that == is an equality predicate.
This is a big source of confusion for them; until they realize that == is
just another function returning Bool they will make claims like [1..]==[1..]
having an unnatural result.
The == function is only vaguely related to the equality
Thank you Duncan, you took the words out of my mouth. :)
On Jan 10, 2008 5:42 PM, Duncan Coutts [EMAIL PROTECTED] wrote:
On Fri, 2008-01-11 at 01:12 +0100, Achim Schneider wrote:
Tillmann Rendel [EMAIL PROTECTED] wrote:
Achim Schneider wrote:
[1..] == [1..]
[some discussion
39 matches
Mail list logo
