www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can we drop casts from float to bool?

reply Don <nospam nospam.com> writes:
This issue is inspired by bug 3918.

float f;
if (f) ...

This currently compiles, but if the condition is true, what can you 
conclude about f?
Obviously it's not zero, but can it be NaN?
If it's just translated to:  if (f!=0) ..., then f could be NaN.
Likewise, if (!f) ... is NOT triggered if f is NaN.

I find that rather unintuitive, and I can't easily invent a case where 
it is useful.

As bug 3918 shows, this conversion has never worked properly. Most 
existing code that makes use of it is probably broken.

`cast(bool)f` has the same problem.  I don't think it should compile. 
And compared to `f != 0`, it's very unclear.

This conversion seems to be confusing, bug prone, and not useful. Can we 
just get rid if it?
Mar 22 2010
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Don wrote:
 This issue is inspired by bug 3918.
 
 float f;
 if (f) ...
 
 This currently compiles, but if the condition is true, what can you
 conclude about f?
 Obviously it's not zero, but can it be NaN?
 If it's just translated to:  if (f!=0) ..., then f could be NaN.
 Likewise, if (!f) ... is NOT triggered if f is NaN.
 
 I find that rather unintuitive, and I can't easily invent a case where
 it is useful.
 
 As bug 3918 shows, this conversion has never worked properly. Most
 existing code that makes use of it is probably broken.
 
 `cast(bool)f` has the same problem.  I don't think it should compile.
 And compared to `f != 0`, it's very unclear.
 
 This conversion seems to be confusing, bug prone, and not useful. Can we
 just get rid if it?

I dealt with this in my first ever blog post... largely because I named the blog `while(nan)`. That said, it is pretty strange behaviour.
Mar 22 2010
prev sibling next sibling parent Marianne Gagnon <auria.mg gmail.com> writes:
Don Wrote:

 This issue is inspired by bug 3918.
 
 float f;
 if (f) ...
 
 This currently compiles, but if the condition is true, what can you 
 conclude about f?
 Obviously it's not zero, but can it be NaN?
 If it's just translated to:  if (f!=0) ..., then f could be NaN.
 Likewise, if (!f) ... is NOT triggered if f is NaN.
 
 I find that rather unintuitive, and I can't easily invent a case where 
 it is useful.
 
 As bug 3918 shows, this conversion has never worked properly. Most 
 existing code that makes use of it is probably broken.
 
 `cast(bool)f` has the same problem.  I don't think it should compile. 
 And compared to `f != 0`, it's very unclear.
 
 This conversion seems to be confusing, bug prone, and not useful. Can we 
 just get rid if it?

I never used such feature in thousands of lines of code. I think it can safely go away (and I'd welcome that change too, /me never liked implicit conversion from numeric types to bool anyway)
Mar 22 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:
 This conversion seems to be confusing, bug prone, and not useful. Can we 
 just get rid if it?

So let me understand better the situation. FP can be: various kinds of NaN, +0.0, -0.0, +infinite, -infinite, and normal numbers. The language designers have to decide what to do for those various values in an instruction like if(x). At the moment in D NaNs are true, +0.0 and -0.0 are false, and the other values are true. Considering NaN as true looks like an arbitrary decision, but in general NaN means not a value, so it's not zero nor different from zero. So probably if(NaN) has to be a runtime error. I think that's what happens when NaNs are set as signalling. Your solution is to forbid implicit and explicit casts of floating points to boolean values, because the choice of the true/false values is arbitrary, and because I think you are saying that packing normal values and NaNs as true is not meaningful in real programs. Disabling conversions from FP to bools seems like able to break generic code. If I have a function template that can accept an int or FP and contains an if(x) it can't compile if the type of x is a FP. This can be solved writing if(x==0) that works with both ints and FPs (and it's true for +0.0 and -0.0). In D some people have proposed to change the semantics of the "is" operator, to make it more useful and tidy, so if you want to know if x is a NaN you can then write if(x is nan). Writing if(x==0) is probably a little more explicit anyway, and Pascal/Java programmers are able to survive with it. In conclusion I don't know if your idea can be a little bad for generic code, but overall I don't think it can hurt my code. Bye, bearophile
Mar 22 2010
parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 This conversion seems to be confusing, bug prone, and not useful. Can we 
 just get rid if it?

So let me understand better the situation. FP can be: various kinds of NaN, +0.0, -0.0, +infinite, -infinite, and normal numbers. The language designers have to decide what to do for those various values in an instruction like if(x). At the moment in D NaNs are true, +0.0 and -0.0 are false, and the other values are true.

Even that's not completely clear. Read the bug report. Sometimes NaNs are true, sometimes not!
 Considering NaN as true looks like an arbitrary decision, but in general NaN
means not a value, so it's not zero nor different from zero. So probably
if(NaN) has to be a runtime error. I think that's what happens when NaNs are
set as signalling.
 Your solution is to forbid implicit and explicit casts of floating points to
boolean values, because the choice of the true/false values is arbitrary, 

Yes. if(x) normally checks to see if x is "null". But for FP, there are two different forms of "null", and checking only one of them makes little sense. and because I think you are saying that packing normal values and NaNs as true is not meaningful in real programs. No, I'm not saying that at all. I'm saying that this operation is extremely subtle, and the syntax gives you a false sense of security. BTW, once you change if(x) into if (x == 0), you're may ask a second question: "do I mean exact equality, or should this really be: if (fabs(x)<= TOLERANCE)" ?
 Disabling conversions from FP to bools seems like able to break generic code.
If I have a function template that can accept an int or FP and contains an
if(x) it can't compile if the type of x is a FP. 

The current behaviour breaks generic code, too. Then if x is a class, then if (x) is true if x has been initialized. But if x is floating point, if (x) is true if x hasn't been initialized! This is arguably the main use for `if (x)`. Note that writing generic code that is correct for both FP and ints is very difficult. There are so many cases where the same syntax has different semantics.
 This can be solved writing if(x==0) that works with both ints and FPs (and
it's true for +0.0 and -0.0). 

 In D some people have proposed to change the semantics of the "is" operator,
to make it more useful and tidy, so if you want to know if x is a NaN you can
then write if(x is nan).

2^^62 different NaNs, so a bitwise comparison will not work.
Mar 23 2010
parent reply grauzone <none example.net> writes:
Don wrote:
 In D some people have proposed to change the semantics of the "is" 
 operator, to make it more useful and tidy, so if you want to know if x 
 is a NaN you can then write if(x is nan).

2^^62 different NaNs, so a bitwise comparison will not work.

There are other cases where if and is seem to do non-obvious things, that can lead to subtle bugs. If "x" is an array, if(x) checks if the array descriptor is null, and not whether x has length 0. To be consistent, I see two choices how this could be fixed: 1. "if" is "intelligent", then both the float and the array case should be fixed to do what one would expect 2. just turn if(x) into if(x is x.init) and make "is" a bitwise comparison even for floats If way 2. is chosen, I don't think multiple NaN would be a problem. The programmer just has to be aware that NaN isn't a single value. "is" yields true if the value is exactly the same, and nothing else. In conclusion, if(x) would be about as useless for floats as it is for arrays. In any way, the situation wouldn't be worse than before, but at least more consistent.
Mar 23 2010
parent reply Don <nospam nospam.com> writes:
grauzone wrote:
 Don wrote:
 In D some people have proposed to change the semantics of the "is" 
 operator, to make it more useful and tidy, so if you want to know if 
 x is a NaN you can then write if(x is nan).

2^^62 different NaNs, so a bitwise comparison will not work.

There are other cases where if and is seem to do non-obvious things, that can lead to subtle bugs. If "x" is an array, if(x) checks if the array descriptor is null, and not whether x has length 0. To be consistent, I see two choices how this could be fixed: 1. "if" is "intelligent", then both the float and the array case should be fixed to do what one would expect

What would you expect? For floats, I don't think there's ANY choice that makes sense.
 2. just turn if(x) into if(x is x.init) and make "is" a bitwise 
 comparison even for floats
 
 If way 2. is chosen, I don't think multiple NaN would be a problem. The 
 programmer just has to be aware that NaN isn't a single value. 

Surely you mean if (x !is x.init) ? Won't work for structs. But why bother? If you know that if (x) is true, how does that help? It's not float.init, but it still might be float.nan. You still need a seperate nan test! "is" yields true if the value is exactly the same, and nothing else. In
 conclusion, if(x) would be about as useless for floats as it is for 
 arrays. In any way, the situation wouldn't be worse than before, but at 
 least more consistent.

I really don't think there's a solution. The only thing that makes sense is to disallow it completely. But more importantly, I cannot see any reason to try. I cannot see any reason why the if (x) syntax is desirable for floats. I can see many downsides and opportunities for bugs, but I cannot see ANYTHING good about it at all. It's a silly thing to have in the core language. We don't need it. Get rid of it.
Mar 23 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Don:
 But more importantly, I cannot see any reason to try. I cannot see any 
 reason why the if (x) syntax is desirable for floats. I can see many 
 downsides and opportunities for bugs, but I cannot see ANYTHING good 
 about it at all. It's a silly thing to have in the core language.
 
 We don't need it. Get rid of it.

OK :-) Thank you. Bye, bearophile
Mar 24 2010