0 and 0.0 are different values in Pike. They are actually different in C too (in the same sense as e.g. 1 and "1" are different values), but since C has implicit conversion they compare equal there. Pike doesn't have implicit conversion, and that's a design choice. A very good one too, imo.
1 != 1.0 only in Pike, I guess.
No, they are different in e.g. Lisp too. Lisp doesn't have implicit conversion either.
It is not logical to make a difference between 1.0 and 1 with assignment or comparision operation
It wouldn't make sense in a language that has a type that could represent any number, but Pike has no such type. Instead it has ints and floats that represent different subsets in different ways, and then it isn't so obvious that there should be some equivalence between the two value sets. If 1 == 1.0, 2 == 2.0, 3 == 3.0 etc then there's some point where it inevitably breaks, and that wouldn't make sense either.
After all, if two (numerical) types are different, an implicit conversion must be made (because I can assign: float x = 1.0 + 2) /.../
No. You can do that because the + operator takes both ints and floats. That's a property of that specific operator; there's no implicit conversion anywhere. This is also exactly like Lisp (and, I suspect, a fair number of other high level languages).
equal(1, 1.0);
(4) Result: 0
This is a bit misleading, at least.
Not if you consider the fundamental design that every value carries its own type. Then it makes sense that == and equal() looks at both the type part and the value part, without any conversion.
If == and equal() would convert between types, one could just as well argue that equal(1, "1") should be true, and equal("(<1>)", (<1>)), and equal(({'0'}), "0"), and equal(([0: 1]), ({1})), and equal(([0:'0']), "0"), and equal(Stdio.File("foo", "r"), Stdio.read_file("foo")), and...
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-15 21:39: Subject: Re: float type weirdness
On Mon, Sep 15, 2003 at 03:10:01PM -0400, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
The issue here is probably how you consider floats. I see 0.0 as a value that is aproximatly zero. I actually consider `== on floats useless and
0.0 is zero - numerically, mathematically. Precisely. Not "near zero" or "aproximatly". It is treated like zero everywhere. Why it is different in Pike - I can't understand.
`== on floats is not (and never will be) useless. 2.0 == 2.0, and 1.0/7.0 == 10.0/70.0. x = 1.0; y = 1.0; and x == y.
that 0==0.0 as a bug. After all 1!=1.0 so why should 0==0.0?
1 != 1.0 only in Pike, I guess. Because 1 == 1.0. Numerically. Like any other number (if precision allows). But 0.0 is zero regardless of precision (and even most binary representation of floats use all zero bits for 0.0).
It is not logical to make a difference between 1.0 and 1 with assignment or comparision operation, unless you want to make everything as strict as possible (but then - Pike is not strict enough in everything else anyway).
After all, if two (numerical) types are different, an implicit conversion must be made (because I can assign: float x = 1.0 + 2), or will you require explicit cast everywhere?
There is a bit more mislead... From equal() docs:
"This function checks if the values a and b are equal." and later: "For all types but arrays, multisets and mappings, this operation is the same as doing a == b"
But from the tutorial (comparision operators):
"The operators == and != can be used on any type. Note that these two operators check if two things are the same, not just if they are equal."
equal(1, 1.0);
(4) Result: 0
This is a bit misleading, at least. How do I check that two things are _equal_? Again (yes, I know, you hate me already for this :) - in most languages comparision is test for _equality_, at least for numerical types.
So? :) Let's keep Pike as different as possible from everything else? :)
Regards, /Al
/ Brevbäraren