Then it seems that you would agree with mast that 0 shouldn't be false either. I'm not sure what your definition of "empty datatype" is, but if 0.0 is included then I expect 0 would be as well.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2003-09-15 20:24: Subject: float type weirdness

---

I disagree. Empty datatypes in pike are not false, as they are in some other langauges. "", (<>), ({}) and ([]) are not false, and so should not 0.0 be either.

/ Martin Nilsson (saturator)

I'd agree with that if the integer 0 was true too. But there's a difference between integer/floats and the other data types: The others have 0 in their domain too, and it's distinct from the empty values (i.e. "", ({}) etc).

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-15 20:24: Subject: float type weirdness

---

I disagree. Empty datatypes in pike are not false, as they are in some other langauges. "", (<>), ({}) and ([]) are not false, and so should not 0.0 be either.

/ Martin Nilsson (saturator)

[Hmm, seems I'm making a habit of commenting myself.]

The last example was actually just a special case of a much more generic scenario with stack variables. E.g. this writes "darn!" thrice:

int main() { float f = (mixed) 1; // The cast is only to defeat the compile time type check. if (f != 0) werror ("darn!"); if (f != 0.0) werror ("darn!"); if (f != 1.0) werror ("darn!"); }

The only difference from the case with the integer 0 is that there's no compile time error in the assignment "float f = 0", and that bug is simple to fix.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-15 20:55: Subject: float type weirdness

---

Actually, it's a bit of a grey zone whether 0 (not 0.0) is in the domain of floats. This produces a run time error:

float f; int main() { f = 0; // Wrong type in assignment, expected float, got int. }

While this works and writes "darn!":

int main() { float f = 0; if (f != 0.0) werror ("darn!"); }

But I consider the second case a bug. The only reason it isn't fixed is that it's very hard to do.

Making 0.0 more equivalent with 0 would actually be a way to cover this ugliness, so in that respect it would be a good thing too.

/ Martin Stjernholm, Roxen IS

Really? When and why do you use that? You should consider changing it to

int|float f = 0;

instead.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-15 21:40: Subject: Re: float type weirdness

---

On Mon, Sep 15, 2003 at 03:20:01PM -0400, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

no compile time error in the assignment "float f = 0", and that bug is simple to fix.

Please don't... This is a feature :)

Regards, /Al

/ Brevbäraren

Because it isn't in the domain of the float type, of course.

So the question becomes: Why isn't the null pointer in the domain of floats? The answer: Implementation details. There's no way to change that without incurring runtime overhead, and even if that's acceptable it'd be a lot of work to change.

Besides, the null pointer isn't in the domain of integers either, but since it happens to be indistinguishable from the integer zero it works to assign it to integer variables anyway.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-15 21:54: Subject: Re: float type weirdness

---

I agree with Al here. Why should you be able to assign NIL to every variable type except floats? It is even possible to do int(1..3) x=0;

/ Martin Nilsson (saturator)

So... Where is the point? 1.0 < 2 but 1.0 == 1 is false... Weird...

Every operator is defined to be as convenient as possible.

It's convenient that == can compare any two values, regardless of type, in a uniform way. In some cases it would be more convenient if it compared ints and floats according to their numerical values, but overall it'd be less convenient.

Similarly, it's convenient that < can order ints and floats according to their numerical values. In some cases it would be more convenient if it could order any two values, regardless of type, in a uniform way. It could do that by specifying an order between types, say int, float, string, array, mapping, multiset, object, function, program. Then 2 < 1.0 would be true. But overall that would be less convenient.

These convenience rules certainly aren't symmetric between the operators, and that can be considered weird. (I'm aware of several thoroughly weird convenience rules in different operators, say when strings are divided by floats, or when arrays containing nonstrings are multiplied with a string.)

There should perhaps be more operators, something like Generic.== (which is the current ==), Generic.<, Numeric.== and Numeric.< (which would be fairly similar to the current <).

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-15 22:38: Subject: Re: float type weirdness

---

On Mon, Sep 15, 2003 at 04:05:05PM -0400, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

Because it isn't in the domain of the float type, of course.

IMHO, any numerical (integer) value is in domain of the float type.

The difference is in fractional part (and precision, somehow), which isn't present in integers.

If I see construct like:

if (x < 2) ...;

I assume that this condition should check if x is _numerically_ less than 2, so it doesn't matter is x float, integer, mpi etc. Anyway:

...

1.0 < 2;

(5) Result: 1

...

1.0 > 2;

(6) Result: 0

So... Where is the point? 1.0 < 2 but 1.0 == 1 is false... Weird...

Regards, /Al

/ Brevbäraren

On Mon, Sep 15, 2003 at 02:25:02PM -0400, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:

other langauges. "", (<>), ({}) and ([]) are not false, and so should not 0.0 be either.

Since there is no "boolean" type in Pike, and since float 0.0 is (numerically) equivalent of integer 0, and since many languages interpret 0 (any type) as "false", it is _logical_ to implement it in Pike as well.

Or does this one of the points which should make Pike "different"?

Many C/Perl/etc programmers would find this difference a bit inconvenient (at least), so migration to Pike would be a bit difficult.

And last - as I quoted from the tutorial already:

"The value zero (0) is considered to be false, and everything else is true. If the value is true, the statement is executed."

If float 0.0 is _not_ zero, then what it is? Either the tutorial is incorrect or something else is wrong...

Regards, /Al

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

On Mon, Sep 15, 2003 at 05:10:04PM -0400, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:

the calculation VERY_BIG_VALUE - VERY_SMALL_VALUE - VERY_BIG_VALUE you will end up with 0.0, and not VERY_SMALL_VALUE, which would be the

Not really. It depends on number of significant digits in both values, and precision of floating point used in calculations (which is irrelevant in our case).

But the same applies to integers (at least 8/16/32/64/128 etc fixed length integers), unless you use MPI and floating precision - even worse, since it is rather strange to get very big value when subtracting one from zero (in case of unsigned ints), or when VERY_BIG_VALUE exceeds precision of integer.

bit-for-bit perspective identical to the constant 0.0, the former is just an approximation.

Not more approximation than 1/3 == 0.

And although 2.0 == 2.0, it is not at all certain that 1.0/7.0 == 10.0/70.0 and 2 == 2.0 in the general case, due to the nature of floats.

It is certain at least for several bits of precision (and it is rare when we have less than 16 bits of precision for floats). The nature (and implementation) of floating-point ops ensures that 10.0/70.0 == 1.0/7.0, even sqrt(x*x) == x (try this with any values that you like - eventually you will find one which doesn't work but again - this will be matter of precision, which is irrelevant),

Well, I'll skip my usual sarcasm and ask directly - is there any pratical reason (and arguments) against my proposal? I already presented several _arguments_, but in return I see only opinions (not only, though, but at least several negative _opinions_) without arguments.

Regards, /Al

On Mon, Sep 15, 2003 at 05:55:03PM -0400, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:

that it is a matter of precision, you have to decide how to deal with the issue.

...

(float)123456789;

(13) Result: 123456792.000000

I remember that there was an exception (on mainframes) on such conversion (when precision is lost). Some compilers even warn on such casts (and I agree with that).

Two values are equal if they are equal once converted to floats.

If at least one is float - yes. They are equal if they are equal once converted to floats.

Two values are equal if they are equal once converted to ints.

The range (numerical) is huge for floats, but extremely limited for ints, so this makes no sense.

A float and an integer are never equal.

This will break the basics of arithmetics :)

A float and an integer are never equal, except 0==0.0.

This will solve one particular problem (which was the reason of this thread), but also it will make a lot of things inconsistent.

A float and an integer are equal if they are equal within the precision bounds of the float (six decimals for single precision floats).

(** the winner :) **) This would be the best solution (with exception throwed when conversion will break the precision bounds, except when explicitly requested). Adding an implicit (light) check for 0.0 case, and avoiding check when conversion is explicit, it wouldn't affect the performance.

A float and an integer are equal if they are equal within the precision bounds of a predefined value (e.g. six decimals so that Pike programs executes the same on regardless of float implementation).

This will lead to inconsistency again. One may need better precision (me :), so it would be nice to have a configuration parameter (pragma?) to rule this.

Regards, /Al

On Mon, Sep 15, 2003 at 07:00:02PM -0400, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:

I don't really understand what you mean here. Should Pike throw an exception if the integer is larger than 999999 (six digits) in an int/float comparision?

Yes. Or, exactly, if the precision is (will be) lost, exception should be thrown. The rules are simple enough (as we know the precision of floats and ints in bits). And at least on Intel there is special flag in FPU to indicate loss of precision (which may or may not be handled, depends on environment).

Say, when we try to cast int with 31 bits of precision (bits 24 and 0 are set) to 32 bit float (actually we will have 23 bits of precision in float - exponent and sign take 9 bits) - precision will be lost.

Precision for floats (IEEE 754; sign is not included):

Single precision: 23 bits Double precision: 42 bits Long double: 64 bits However, it is safe to convert (say) 2 << 64 into single precision float, since it is "floating point" - only one bit is set and exponent will be in effect.

Regards, /Al

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

/.../ There is a "hidden" conversion to MPI from integer (you may argue that this is a "property" of specific type, but anyway - it is implicit).

That conversion is so completely hidden that it's purely an implementation detail, as opposed to ints vs floats. I.e. If we should extend that reasoning to floats then there should be a type that can contain any number, and that would choose between native integer, native float and Gmp object as suitable for the internal representation.

Lisp is _very_ different from anything. On language level.

Well, I don't know what you mean with "language level", but there's a whole slew of languages that are very similar to Lisp in how types and values are handled. It's a large subset of the loosely typed languages.

/.../ it makes sense to keep equal values equal while possible. /.../

Only in cases where both integers and floats are mixed and where only their numerical properties are interesting. Those cases are fairly few compared to those where the types are just as important as their numeric values: There are many functions that behave completely differently when given a float or an integer, i.e. the type itself is used as a flag.

Not really fair. It is like comparing Chinese to English :) Lisp is _very_ different, as I said above,

Not at all. Pike is much more similar to Lisp than it is to C in several fundamental ways. It's mostly the syntax that's much more like C, and we're not discussing that here.

It seems like you're comparing Pike to strongly typed languages like C, C++ and Java. To extend your analogy, that's like comparing poetry to reference manuals, be they written in Chinese or English.

and after all it wasn't intended to do math in the first place.

I generally wouldn't want to use a language that's primarily designed to do math, since that's a very small portion of what a typical program does. Lisp was intended to do anything algorithmic, just like Pike and C.

Not fair again. float and int are _both_ numeric types, while numerics and strings are very different types - in this case explicit conversion is would be logical.

There's only a difference in degree. The primary thing in the equality operations is to treat all values and types uniformly. In that regard the numeric equivalences are comparable to those of values and their string representations.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-16 00:12: Subject: Re: float type weirdness

---

On Mon, Sep 15, 2003 at 05:50:02PM -0400, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

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

Might be. But not really when it concerns numeric types. At least, MPI is converted to int and vice versa. There is a "hidden" conversion to MPI from integer (you may argue that this is a "property" of specific type, but anyway - it is implicit).

...

No, they are different in e.g. Lisp too. Lisp doesn't have implicit conversion either.

Lisp is _very_ different from anything. On language level.

...

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.

But people compare numbers, and they expect some logic behind. We all know about limitations, both concerning integers and floats, but still, it makes sense to keep equal values equal while possible. And, technically, when given precision is not enough to represent specific number, the equality is broken anyway (both technicaly and numerically, the second is the consequence of the first).

...

That's a property of that specific operator; there's no implicit conversion anywhere.

OK, what about 1 < 2.0 then? Also property of `<? The I see no logic to add such properties for `+, `< but not to `==.

...

This is also exactly like Lisp (and, I suspect, a fair number of other high level languages).

Not really fair. It is like comparing Chinese to English :) Lisp is _very_ different, as I said above, and after all it wasn't intended to do math in the first place.

...

If == and equal() would convert between types, one could just as well argue that equal(1, "1") should be true, and equal("(<1>)", (<1>)),

Not fair again. float and int are _both_ numeric types, while numerics and strings are very different types - in this case explicit conversion is would be logical.

Regards, /Al

/ Brevbäraren

Ok, one last answer before I do something useful...

I don't like the idea of arbitrary (compiler/interpreter decision) conversion between numeric types in case when performance matters.

We've discussed this topic before with you. A compiler/interpreter decision is not arbitrary but rule based. If you know the rules you know exactly what happens. Pike is however a high level language, which means that you should not need to learn the rules in normal cases. The goal for us as developers of the langauge Pike is to make the rules soo good that developers in Pike never faces a situation where it is needed to learn the underlying rules.

Ints are faster than floats, but floats are fast enough too, while Gmp objects are extremely slow comparing to both ints/floats.

This is true if you own an Atari. Modern CPUs has a floating point operation pipeline right next to the integer one.

Actually, even implicit bignums in Pike slow down things significantly -

That has never been under dispute. Of course bignums are slower; they perform a larger task.

Even Touring computer can do everything

It's Turing machine, after Alan Turing.

Same with Lisp - it is good for specific, but not general programming, especially for (former) C programmers (while Pike is promoted as "similar to C/C++").

There is no problem in using Lisp for general programming. I made a multithreaded, object oriented adventure game in Lisp once. Someone else made emacs. That is however beside the point. You can't convince us that Pike isn't a lot like Lisp.

...

Not at all. Pike is much more similar to Lisp than it is to C in several fundamental ways.

For instance?

Typed values. Garbage collection. Neither is in C++.

Two numeric types are also comparable if we won't take precision into account. Actually, the only difference between int and float is exactly the "floating point", managed by exponent part, but this is implementation detail.

Am I right in that you don't know how IEEE floating point numbers are actually represented, technically?

/ Martin Nilsson (saturator)

Previous text:

2003-09-16 02:06: Subject: Re: float type weirdness

---

On Mon, Sep 15, 2003 at 07:25:01PM -0400, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

contain any number, and that would choose between native integer, native float and Gmp object as suitable for the internal representation.

I don't like the idea of arbitrary (compiler/interpreter decision) conversion between numeric types in case when performance matters.

Ints are faster than floats, but floats are fast enough too, while Gmp objects are extremely slow comparing to both ints/floats.

Actually, even implicit bignums in Pike slow down things significantly - just compare execution time for sscanf("\x80\0\0\0", "%4c", n) and sscanf("\x7f\0\0\0", n) where n is an int - and this is typical operation when IP numbers processing is necessary. Multiply this by millions - you will see the difference.

...

whole slew of languages that are very similar to Lisp in how types and values are handled.

(programming) languages are tuned for specific tasks. Even Touring computer can do everything, but I don't see anyone who uses this. Same with Lisp - it is good for specific, but not general programming, especially for (former) C programmers (while Pike is promoted as "similar to C/C++").

...

numeric values: There are many functions that behave completely differently when given a float or an integer, i.e. the type itself is

This is a bad idea by itself - the type of numeric value should not be used as a flag, IMHO - it leads to mistakes for beginners and mystical behavior when arguments are mistyped/mispassed. The function may behave differently if it concerns return value, but if it involves something else - this is EvilThing (r) :)

...

Not at all. Pike is much more similar to Lisp than it is to C in several fundamental ways.

For instance? Sure you can find a lot of similarity between Pike and Lisp, but this is true for C++ and Lisp as well. Pike is developed as general purpose language (at least now), or?

...

It seems like you're comparing Pike to strongly typed languages like C, C++ and Java.

Not really. I like the idea of types in general, but I dislike the idea of strict (strongly) types. At least, it would be nice to have pragma or something like that to control this. BTW, what about floats/ints in Java? Is those types so different there as well?

...

I generally wouldn't want to use a language that's primarily designed to do math, since that's a very small portion of what a typical

True, but it is nice to have a language which is well suited for math too, but still is general purpose. Pike could be the one.

...

operations is to treat all values and types uniformly. In that regard the numeric equivalences are comparable to those of values and their string representations.

String may represent something that may not be converted (or interpreted) as numeric value, while numeric value may always be represented as string

• that's why it makes no sense to blindly (or uniformly) compare strings

and numerics.

Two numeric types are also comparable if we won't take precision into account. Actually, the only difference between int and float is exactly the "floating point", managed by exponent part, but this is implementation detail. They both are _numeric_ types - this is important.

Regards, /Al

/ Brevbäraren

But I had to learn that 0.0 is not 0 (which wasn't obvious, according to the tutorial).

The tutorial could be improved then. Do you have access to do that?

Instead, I had to learn that there are two flavor of numbers which are incompatible. Goal is not reached :)

I wouldn't call them incompatible just because == doesn't convert numbers implicitly. Anyway, it's not uncommon that one usability goal conflicts with another. In this case I think the usability of a consistent equality operation by far outweights this issue.

(Btw, I'm still with you on the original issue of making 0.0 false.)

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-16 14:39: Subject: Re: float type weirdness

---

On Mon, Sep 15, 2003 at 09:00:01PM -0400, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:

...

We've discussed this topic before with you. A compiler/interpreter decision is not arbitrary but rule based. If you know the rules you know exactly what happens.

As a developer, I prefer to set my own rules. Unless I can do this, compiler decision is arbitrary (because it does not depend on my preferences).

...

for us as developers of the langauge Pike is to make the rules soo good that developers in Pike never faces a situation where it is needed to learn the underlying rules.

But I had to learn that 0.0 is not 0 (which wasn't obvious, according to the tutorial). Instead, I had to learn that there are two flavor of numbers which are incompatible. Goal is not reached :)

...

This is true if you own an Atari. Modern CPUs has a floating point operation pipeline right next to the integer one.

But still, int are faster than floats. Even on modern CPUs (make a benchmark).

...

There is no problem in using Lisp for general programming.

There is no problem in using anything to make everything. The only difference is how easy and how convenient.

...

Typed values. Garbage collection. Neither is in C++.

It is. There are several GCs for C++. Don't know what do you mean under "typed values" exactly (in this case).

...

Am I right in that you don't know how IEEE floating point numbers are actually represented, technically?

No. I know.

Regards, /Al

/ Brevbäraren

On Thu, Sep 18, 2003 at 10:55:04PM +0200, Fredrik (Naranek) Hubinette (Real Build Master) @ Pike (-) developers forum wrote:

is not int, and implementing the auto-int-to-float conversion in many operators was a mistake that I wouldn't repeat if I were to design

At least it is safe to make auto-conversion (perhaps with warning) when integer (a number without ".") is assigned to the float variable. It would be also _convenient_ to interpret 0 as 0.0 where it seems logical (comparision). But OK. As I said before - I give up.

I thought that Pike was intented for a bit broader usage than closed group who knows-better-than-everybody-else... Seems that I made a mistake...

Regards, /Al

On Fri, Sep 19, 2003 at 01:15:01AM +0200, Per Hedbor () @ Pike (-) developers forum wrote:

Consider "float q = 123456789;" or "float q=1234567898765432123456789;"

Compiler must issue warning in such cases. It must _warn_, but not _enforce_, or _at least_ it must give the developer a choice.

And if you do not want to use pike, feel free not to.

This is different. I want, because it is nice, but there are some _inconsistences_, obvious but denied by the team.

Concering float, again:

2 == 2.0;

(1) Result: 0

2 < 4.0;

(2) Result: 1

2.0 < 4;

(3) Result: 1

There is _no logic_ behind this behavior (unless one care to read all our discussions concerning this topic, and learn that there are several zeros in Pike, etc).

That's why I dislike what is going on. Not the language by itself. May be I was too hard in my wording, but I am just tired after several years trying to do _anything_. Nothing changed - Pike team is _always_ right. At least my bug reports were accepted, that's good reason to stay alive, still... :)

It would be much better if Pike would give _a freedom_ to developers. But there is no freedom. There are rules, which are non-negotiable by definition.

Because legacy of Roxen in Pike modules is more important than something new, because there is no good regexp module, because Nettle is far better than openssl, because... you know what...

Sorry, but I am filled up with all this. I'll do what I do, what I intended to do, in Pike or whatever, but I lost my motivation to share anything that I might do... It wouldn't be accepted anyway, so who cares?

Regards, /Al

On Fri, Sep 19, 2003 at 02:20:01AM +0200, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:

Could you at least present a workable suggestion before you whine about that nobody likes what you are doing.

I did. It is all in this this thread.

x == x.0 is a good idea in theory, but once x gets to big you'll lose precision and you'll end up with buggy code.

Once I disable auto-bignums this leads to the same problem, but with integers. Where is the difference?

Since neither of us likes code features that hides errors or downright promotes buggy code we can't stop here.

A lot of features in Pike (and especially in standard modules) are so non-intuitive (and so dependent on developer's knowledge and experience) that it makes this very weak argument. One day I'll count those...

One suggestion of yours is to introduce loss-of-precision exception.

This is standard way. Since exceptions are rare, it makes no bad.

Exceptions are generally a bad thing and should be kept to a minimum and reserved for truely exceptional circumstances.

The application must be designed to avoid any exceptions where possible, but this doesn't mean that exceptions are bad thing - simply because they help to develop exception-free application. So simple.

Loss of precision exception is truly exceptional circumstance. At least it is more truly than:

my_error( "No argument to option "+opt+".\n", throw_errors ); in Getopt (and a lot of similar places).

developed, idea that others share) it is better to acknoledge the fact that floats are inprecise and thus never "equal" to an integer.

Integers are inprecise too. They are only 32bits (or 64, but anyway).

IMPORTANT NOTE: If you would like to help develop Pike, please do. Write code and show to us how useful it is.

How useful to whom? There are a lot of modules in Pike (core distribution) which are unuseable for ages, but they are still there, while new things (and really usefull) are accepted extremely seldom (it took ages before Bz2 module appeared in core, for instance). The most hard argument against PCRE was that it doesn't support wide strings (while original Regexp does not support those too, even worse, I can't use it to match a _position_ of matching expression).

Well... This is weird... I didn't mean to start all this over again, it just turned out... May be later it will be better...

Regards, /Al

How useful to whom? There are a lot of modules in Pike (core distribution) which are unuseable for ages, but they are still there, while new things (and really usefull) are accepted extremely seldom (it took ages before Bz2 module appeared in core, for instance).

You are taking the wrong aproach here. Modules doesn't appears. They are checked in by someone. Someone thought that there should be a Bz2 module, and now there is.

You can not (well, you can, but that would be crazy big time) compare modules, that are dynamically loaded once someone is interested in using them, with core language changes that breaks all existing Pike code known to man (your suggestions tend to fall in this category).

The most hard argument against PCRE was that it doesn't support wide strings (while original Regexp does not support those too, even worse, I can't use it to match a _position_ of matching expression).

Now you are confusing Pike-managed-by-Roxen with Pike-managed-by-IDA. More importantly you are confusing Pike-development-funded-by-Roxen with Pike-development-not-funded-at-all. Check in a working PCRE module (I've made place for it in Regexp.PCRE) and see if we get mad or not.

Well... This is weird... I didn't mean to start all this over again, it just turned out... May be later it will be better...

I'm pretty sure you get kicks out of this. Why else...

/ Martin Nilsson (saturator)

Previous text:

2003-09-19 03:16: Subject: Re: float type weirdness

---

On Fri, Sep 19, 2003 at 02:20:01AM +0200, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:

...

Could you at least present a workable suggestion before you whine about that nobody likes what you are doing.

I did. It is all in this this thread.

...

x == x.0 is a good idea in theory, but once x gets to big you'll lose precision and you'll end up with buggy code.

Once I disable auto-bignums this leads to the same problem, but with integers. Where is the difference?

...

Since neither of us likes code features that hides errors or downright promotes buggy code we can't stop here.

A lot of features in Pike (and especially in standard modules) are so non-intuitive (and so dependent on developer's knowledge and experience) that it makes this very weak argument. One day I'll count those...

...

One suggestion of yours is to introduce loss-of-precision exception.

This is standard way. Since exceptions are rare, it makes no bad.

...

Exceptions are generally a bad thing and should be kept to a minimum and reserved for truely exceptional circumstances.

The application must be designed to avoid any exceptions where possible, but this doesn't mean that exceptions are bad thing - simply because they help to develop exception-free application. So simple.

Loss of precision exception is truly exceptional circumstance. At least it is more truly than:

my_error( "No argument to option "+opt+".\n", throw_errors );

in Getopt (and a lot of similar places).

...

developed, idea that others share) it is better to acknoledge the fact that floats are inprecise and thus never "equal" to an integer.

Integers are inprecise too. They are only 32bits (or 64, but anyway).

...

IMPORTANT NOTE: If you would like to help develop Pike, please do. Write code and show to us how useful it is.

How useful to whom? There are a lot of modules in Pike (core distribution) which are unuseable for ages, but they are still there, while new things (and really usefull) are accepted extremely seldom (it took ages before Bz2 module appeared in core, for instance). The most hard argument against PCRE was that it doesn't support wide strings (while original Regexp does not support those too, even worse, I can't use it to match a _position_ of matching expression).

Well... This is weird... I didn't mean to start all this over again, it just turned out... May be later it will be better...

Regards, /Al

/ Brevbäraren

On Fri, Sep 19, 2003 at 02:35:43AM +0200, Martin Baehr wrote:

those who do the work are always right,

This is NOT true. Those who do may do it _wrong_ (and often do) :)

to much freetom gets you perl, thanks but no thanks.

Look at Perl... It is used almost everywhere (at least in Unix world). Look at Pike... It is used almost nowhere (comparing to Perl).

Why? May be because of the freedom. May be because of it's license. I don't know exactly, but the fact is - it is more widely used.

contributions. it's just like owning stock. the more you own, the more your vote counts.

Who will decide about value of my shares? :) Or even better - where I can sell them? :)

there IS a good regexp module, it is waiting for someone to find the time to add it to the pike tree.

...and raise again this license and legal bullshit (the reason why PCRE was rejected once, if I remember correctly).

nils would not have received a diploma for updating openssl in pike.

Exactly. This is why Pike is developed - to receive diplomas, right? :)

have you even tried to get anything accepted?

You remember - I did. Long time ago. Not so long ago I tried again (again with PCRE) - it ended with legal problems. So... This thread shows that nothing will be changed regarding floating point (though current behavior is not logical at least - read my posts).

you are assuming based on things that happened in the past, which for a long time has been controlled by roxen.

Well... Now it is controlled by IDA. What is changed? Until there is a need in diplomas, and until most of the core team will be there, Pike will be developed as it convenient for IDA (or can you prove that I am wrong?) :)

many are not contributing because they believe that nothing has changed since then. because they are not contributing, some things are not

Pike is GPLed long time ago. _Nobody_ prevented _anybody_ from doing a fork and developing it outside of Roxen. So... It means that no one was really interested to do so. Conclusions?

things ARE NOT going to change UNTIL YOU start to contribute.

A lot of people tried to contribute. A lot. But there is still separate PExts repository on Caudium, but not on IDA (for example). So what?

Regards, /Al

There is _no logic_ behind this behavior (unless one care to read all our discussions concerning this topic, and learn that there are several zeros in Pike, etc).

There is logic, but in a different way, as is covered by said discussion. You can win me over by good and solid arguments in a constructive discussion; I always try very hard to back up my opinions that way.

That's why I dislike what is going on. Not the language by itself. May be I was too hard in my wording, but I am just tired after several years trying to do _anything_.

What have you contributed besides a couple of bug reports/fixes and making suggestions for core language changes?

It's not surprising that it's hard to succeed with core changes; I know since I've tried that many times and failed more often than not. The core properties of a language are often the result of carefully weighing together a lot of different considerations. They interact with each other very deeply so changing one thing will affect other things, and most likely to the worse. Not to mention the practical problem with that there already is a whole lot of code out there that depends on things working in certain ways.

Suggest something better and we'll listen. For example, figure out a way to add real lightweight threads.

Nothing changed - Pike team is _always_ right.

I resent this, but nevertheless I recognize that it's an all too common opinion so there must be something that we, as the Pike team, is doing very wrong. I don't know exactly what it is though. Should we really accept suggestions that on the whole will make the language worse just to make you feel better? Do you after all this discussion still think that your idea got turned down just because it came from you?

because there is no good regexp module,

There hasn't been any objection to adding PCRE in at least the last one and a half years. Even though working glue already exists it's still not there yet. Why? Afaics it's because noone in the old core gang has taken it upon himself to do the actual work. Will you?

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-19 01:39: Subject: Re: float type weirdness

---

On Fri, Sep 19, 2003 at 01:15:01AM +0200, Per Hedbor () @ Pike (-) developers forum wrote:

...

Consider "float q = 123456789;" or "float q=1234567898765432123456789;"

Compiler must issue warning in such cases. It must _warn_, but not _enforce_, or _at least_ it must give the developer a choice.

...

And if you do not want to use pike, feel free not to.

This is different. I want, because it is nice, but there are some _inconsistences_, obvious but denied by the team.

Concering float, again:

...

2 == 2.0;

(1) Result: 0

...

2 < 4.0;

(2) Result: 1

...

2.0 < 4;

(3) Result: 1

There is _no logic_ behind this behavior (unless one care to read all our discussions concerning this topic, and learn that there are several zeros in Pike, etc).

That's why I dislike what is going on. Not the language by itself. May be I was too hard in my wording, but I am just tired after several years trying to do _anything_. Nothing changed - Pike team is _always_ right. At least my bug reports were accepted, that's good reason to stay alive, still... :)

It would be much better if Pike would give _a freedom_ to developers. But there is no freedom. There are rules, which are non-negotiable by definition.

Because legacy of Roxen in Pike modules is more important than something new, because there is no good regexp module, because Nettle is far better than openssl, because... you know what...

Sorry, but I am filled up with all this. I'll do what I do, what I intended to do, in Pike or whatever, but I lost my motivation to share anything that I might do... It wouldn't be accepted anyway, so who cares?

Regards, /Al

/ Brevbäraren

I don't like the idea of arbitrary (compiler/interpreter decision) conversion between numeric types in case when performance matters.

Me neither. It was not a proposal, it was a thought experiment to show the flaw in the parallell you drew between implicit type conversions and the internal conversions between native ints and bignums.

/.../ (while Pike is promoted as "similar to C/C++").

Syntactically similar, yes, but made simpler and more powerful. That's done by employing techniques seen in higher level languages like Lisp, e.g. loose typing, type-carrying values, runtime consistency checks, and garbage collection.

/.../ the type of numeric value should not be used as a flag, IMHO

• it leads to mistakes for beginners and mystical behavior when

arguments are mistyped/mispassed.

Not in my experience. Sure, it would be if you refuse to see that ints and floats are two different types. But since we don't want to change that by uniting them to a single numeric type, you better accept it. Once you do, it's not harder to hold ints and floats apart than e.g. ints and strings.

Your argument is somewhat similar to if someone would proclaim that there's no difference between single and double quotes and then whines about the "mystical" behavior when the single quoted "strings" are used in place of real strings.

The function may behave differently if it concerns return value, but if it involves something else - this is EvilThing (r) :)

Just out of curiosity, do you think that testing on run time types (i.e. use of intp, objectp, arrayp etc) is evil in general or is it evil only when used to tell the two numeric types apart?

/.../ Pike is developed as general purpose language (at least now), or?

Yes. More specifically, a high level general purpose language.

Not really. I like the idea of types in general, but I dislike the idea of strict (strongly) types.

Hmm, I don't know what you mean with this, but when I speak about strongly typed languages, I mean languages that resolve all types at compile time so that the values don't need to carry the type at runtime.

BTW, what about floats/ints in Java? Is those types so different there as well?

Java is strongly typed and has implicit type conversions, so I assume you'd call them less "different".

/.../ it is nice to have a language which is well suited for math too, but still is general purpose. Pike could be the one.

Unfortunately not if performance is important, which it typically is in those cases. Since Pike isn't strongly typed it's very hard to avoid the runtime type checks that it must do on every operand. Therefore it'll always be slow when all the calculations are done at the pike level. It can only be made efficient by lumping together many calculations into larger operations that are done in C modules, like Math.Matrix operations.

String may represent something that may not be converted (or interpreted) as numeric value, /.../

I already understand the differences you're describing, but that's beside the point I was trying to make. Forget it.

No type conversion whatsoever can be done in the generic == and equal() operations since that would make them lose the uniform behavior that makes them useful: They can compare any two values, and they always compare both the type and the value part of them, as they are.

I don't deny that a more specialized comparison function for numeric values which handles numeric equivalences, i.e. a numeric_equal(), could be useful. But then I think it works just as well use == and write the casts explicitly.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-16 02:06: Subject: Re: float type weirdness

---

On Mon, Sep 15, 2003 at 07:25:01PM -0400, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

contain any number, and that would choose between native integer, native float and Gmp object as suitable for the internal representation.

I don't like the idea of arbitrary (compiler/interpreter decision) conversion between numeric types in case when performance matters.

Ints are faster than floats, but floats are fast enough too, while Gmp objects are extremely slow comparing to both ints/floats.

Actually, even implicit bignums in Pike slow down things significantly - just compare execution time for sscanf("\x80\0\0\0", "%4c", n) and sscanf("\x7f\0\0\0", n) where n is an int - and this is typical operation when IP numbers processing is necessary. Multiply this by millions - you will see the difference.

...

whole slew of languages that are very similar to Lisp in how types and values are handled.

(programming) languages are tuned for specific tasks. Even Touring computer can do everything, but I don't see anyone who uses this. Same with Lisp - it is good for specific, but not general programming, especially for (former) C programmers (while Pike is promoted as "similar to C/C++").

...

numeric values: There are many functions that behave completely differently when given a float or an integer, i.e. the type itself is

This is a bad idea by itself - the type of numeric value should not be used as a flag, IMHO - it leads to mistakes for beginners and mystical behavior when arguments are mistyped/mispassed. The function may behave differently if it concerns return value, but if it involves something else - this is EvilThing (r) :)

...

Not at all. Pike is much more similar to Lisp than it is to C in several fundamental ways.

For instance? Sure you can find a lot of similarity between Pike and Lisp, but this is true for C++ and Lisp as well. Pike is developed as general purpose language (at least now), or?

...

It seems like you're comparing Pike to strongly typed languages like C, C++ and Java.

Not really. I like the idea of types in general, but I dislike the idea of strict (strongly) types. At least, it would be nice to have pragma or something like that to control this. BTW, what about floats/ints in Java? Is those types so different there as well?

...

I generally wouldn't want to use a language that's primarily designed to do math, since that's a very small portion of what a typical

True, but it is nice to have a language which is well suited for math too, but still is general purpose. Pike could be the one.

...

operations is to treat all values and types uniformly. In that regard the numeric equivalences are comparable to those of values and their string representations.

String may represent something that may not be converted (or interpreted) as numeric value, while numeric value may always be represented as string

• that's why it makes no sense to blindly (or uniformly) compare strings

and numerics.

Two numeric types are also comparable if we won't take precision into account. Actually, the only difference between int and float is exactly the "floating point", managed by exponent part, but this is implementation detail. They both are _numeric_ types - this is important.

Regards, /Al

/ Brevbäraren

But something like "function prototypes" (as in C++), where compiler (or runtime) makes the decision which function to call (based on argument types) is more convenient.

That's typically called function overloading. Grubba has made some work on adding that to Pike with the variant modifier, but it doesn't work well yet. What it would do in Pike is simply to join the different functions to one that does the necessary runtime type checks to execute the right variant. C++ can do it better since it resolves the right variant already at compile time.

/.../ What is the point to have types (compile time) at all?

One important benefit is that compile time types help discover many bugs before the program is run. Another is that they make it theoretically possible to remove the runtime type checks in special cases.

If we know the type of some variable at compile time (and flag this), there is no need to make typechecks during runtime, or?

Right. I didn't say it's impossible, only very hard (or perhaps rather a whole lot of work). Flow analysis is necessary to catch cases where the runtime type might not agree with the compile time type, since it's always possible to write code where the compile time typing is thwarted:

void func (int i) { if (!intp (i)) error ("Didn't get an int!\n"); }

int main() { function f = func; f ("fooled you"); }

Furthermore compile time function overloading must be implemented so that it's possible to write a more efficient predef::`+(float,float) that can be chosen instead of the generic predef::`+(mixed...).

And even with all this, runtime checks would still be necessary for ints since they can be either native or bignums.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-17 04:24: Subject: Re: float type weirdness

---

On Tue, Sep 16, 2003 at 08:35:02PM -0400, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

there's no difference between single and double quotes and then whines about the "mystical" behavior when the single quoted "strings" are used in place of real strings.

Not really. Usually compiler signals an error when quotes are misused (at least Pike/C will - double quotes are strings, while singe quotes are ints).

...

Just out of curiosity, do you think that testing on run time types (i.e. use of intp, objectp, arrayp etc) is evil in general or is it evil only when used to tell the two numeric types apart?

Well... Frankly, it is useful, sometimes :) And I've no choice when I want to make run-time checks in function/operator which may take arguments of different types.

But something like "function prototypes" (as in C++), where compiler (or runtime) makes the decision which function to call (based on argument types) is more convenient.

...

in those cases. Since Pike isn't strongly typed it's very hard to avoid the runtime type checks that it must do on every operand.

Why? What is the point to have types (compile time) at all? If we know the type of some variable at compile time (and flag this), there is no need to make typechecks during runtime, or?

Regards, /Al

/ Brevbäraren

True. But I still wouldn't call it proper multiple dispatch since it isn't possible to _not_ dispatch on the implicit first argument, i.e. this_object().

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-17 21:30: Subject: Re: float type weirdness

---

...

That's typically called function overloading. Grubba has made some work on adding that to Pike with the variant modifier, but it doesn't work well yet. What it would do in Pike is simply to join the different functions to one that does the necessary runtime type checks to execute the right variant. C++ can do it better since it resolves the right variant already at compile time.

Which is better is of course a matter of what you're trying to achieve. What you describe sounds like multiple dispatch, i.e. a->f(b) will dispatch polymorphically on both a and b, which is something C++ does not have.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Note that both 0.0 and -0.0 are distinct values. Should both be false? Should they be equal to each other?

/ Henrik Grubbström (Lysator)

Previous text:

2003-09-15 22:07: Subject: Re: float type weirdness

---

Comparing floats in general with == is often bogus, but 0.0 is a special case; division shows that there is a distinct difference between zero and approximately zero, and 0.0 is not just approximately zero.

/ Martin Stjernholm, Roxen IS

Apparently they are equal. I don't know whether that's a good thing or not.

Anyway, there are already plenty of false values in Pike. Some of them are equal to each other, others are not.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-09-15 22:19: Subject: Re: float type weirdness

---

Note that both 0.0 and -0.0 are distinct values. Should both be false? Should they be equal to each other?

/ Henrik Grubbström (Lysator)

0.0 was intentionally left out. Floats are not to be used as boolean values. It also underlines the fact that floats are not ints. Originally, the integer zero was supposed to be the only false value.

With a float, is there even a precise way to determine weather a value is zero or not?

/ Fredrik (Naranek) Hubinette (Real Build Master)

Previous text:

2003-09-15 20:15: Subject: float type weirdness

---

Pike considers these things false:

o The integer zero (with arbitrary subtype). o Destructed objects and functions in destructed objects. o Objects with a `! that returns true.

I don't know whether 0.0 is intentionally left out or not. It's such an odd case I suspect it simply wasn't considered.

From a design viewpoint I don't like that the integer 0 is false to begin with, but now when it is it's not unreasonable that 0.0 should be false too.

/ Martin Stjernholm, Roxen IS

I agree, Math.inf would be better. I still prefer if(f != 0.0) over if(f) though. When I read this code, I see "if f is a float, divide, otherwise..."

/ Fredrik (Naranek) Hubinette (Real Build Master)

Previous text:

2003-09-18 21:42: Subject: float type weirdness

---

Yes. Division works on all numbers but 0.0 and -0.0. So this would make sense:

if (f) f = 1.0/f; else ...

(When it comes to division I'd prefer to get Math.inf or -Math.inf instead of exceptions, though.)

/ Martin Stjernholm, Roxen IS