www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Detecting inadvertent use of integer division

reply Don <nospam nospam.com> writes:
Consider this notorious piece of code:

assert(x>1);
double y = 1 / x;

This calculates y as the reciprocal of x, if x is a floating-point 
number. But if x is an integer, an integer division is performed instead 
of a floating-point one, and y will be 0.

It's a very common newbie trap, but I find it still catches me 
occasionally, especially when dividing two variables or compile-time 
constants.

In the opPow thread there were a couple of mentions of inadvertent 
integer division, and how Python is removing this error by making / 
always mean floating-point division, and introducing a new operator for 
integer division.

We could largely eliminate this type of bug without doing anything so 
drastic. Most of the problem just comes from C's cavalier attitude to 
implicit casting. All we'd need to do is tighten the implicit conversion 
rules for int->float, in the same way that the int->uint rules have been 
tightened:

"If an integer expression has an inexact result (ie, involves an inexact 
integer divison), that expression cannot be implicitly cast to a 
floating-point type."

(This means that double y = int_val / 1;  is OK, and also:
  double z = 90/3; would be OK. An alternative rule would be:
"If an integer expression involves integer divison, that expression 
cannot be implicitly cast to a floating-point type").

In the very rare cases where the result of an integer division was 
actually intended to be stored in a float, an explicit cast would be 
required. So you'd write:
double y = cast(int)(1/x);

Like the implicit uint->int casts which have recently been disallowed, I 
think this would prevent a lot of bugs, without causing much pain.
Dec 14 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Consider this notorious piece of code:
 
 assert(x>1);
 double y = 1 / x;
 
 This calculates y as the reciprocal of x, if x is a floating-point 
 number. But if x is an integer, an integer division is performed instead 
 of a floating-point one, and y will be 0.
 
 It's a very common newbie trap, but I find it still catches me 
 occasionally, especially when dividing two variables or compile-time 
 constants.
 
 In the opPow thread there were a couple of mentions of inadvertent 
 integer division, and how Python is removing this error by making / 
 always mean floating-point division, and introducing a new operator for 
 integer division.
 
 We could largely eliminate this type of bug without doing anything so 
 drastic. Most of the problem just comes from C's cavalier attitude to 
 implicit casting. All we'd need to do is tighten the implicit conversion 
 rules for int->float, in the same way that the int->uint rules have been 
 tightened:
 
 "If an integer expression has an inexact result (ie, involves an inexact 
 integer divison), that expression cannot be implicitly cast to a 
 floating-point type."

But the compiler cannot reliably tell if it will produce an inexact result.
 (This means that double y = int_val / 1;  is OK, and also:
  double z = 90/3; would be OK. An alternative rule would be:
 "If an integer expression involves integer divison, that expression 
 cannot be implicitly cast to a floating-point type").

This is kinda complicated if one has, say: double z = x/y + 3;
 In the very rare cases where the result of an integer division was 
 actually intended to be stored in a float, an explicit cast would be 
 required. So you'd write:
 double y = cast(int)(1/x);
 
 Like the implicit uint->int casts which have recently been disallowed, I 
 think this would prevent a lot of bugs, without causing much pain.

Maybe it's easier to simply disallow 1/x, where x is an int, and the numerator is '1'. But then maybe that will cause problems with generic code. I don't think there's an easy answer here.
Dec 14 2009
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Don wrote:
 Consider this notorious piece of code:

 assert(x>1);
 double y = 1 / x;

 This calculates y as the reciprocal of x, if x is a floating-point 
 number. But if x is an integer, an integer division is performed 
 instead of a floating-point one, and y will be 0.

 It's a very common newbie trap, but I find it still catches me 
 occasionally, especially when dividing two variables or compile-time 
 constants.

 In the opPow thread there were a couple of mentions of inadvertent 
 integer division, and how Python is removing this error by making / 
 always mean floating-point division, and introducing a new operator 
 for integer division.

 We could largely eliminate this type of bug without doing anything so 
 drastic. Most of the problem just comes from C's cavalier attitude to 
 implicit casting. All we'd need to do is tighten the implicit 
 conversion rules for int->float, in the same way that the int->uint 
 rules have been tightened:

 "If an integer expression has an inexact result (ie, involves an 
 inexact integer divison), that expression cannot be implicitly cast to 
 a floating-point type."

But the compiler cannot reliably tell if it will produce an inexact result.
 (This means that double y = int_val / 1;  is OK, and also:
  double z = 90/3; would be OK. An alternative rule would be:
 "If an integer expression involves integer divison, that expression 
 cannot be implicitly cast to a floating-point type").

This is kinda complicated if one has, say: double z = x/y + 3;

Integer expressions remain inexact until there's a cast. (It's very simple to implement, you just use the integer range code, adding an 'inexact' flag. Division sets the flag, casts clear the flag, everything else just propagates it if a unary operation, or ORs the two flags if a binary operation).
Dec 14 2009
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Don Wrote:

 Walter Bright wrote:
 Don wrote:
 (This means that double y = int_val / 1;  is OK, and also:
  double z = 90/3; would be OK. An alternative rule would be:
 "If an integer expression involves integer divison, that expression 
 cannot be implicitly cast to a floating-point type").

This is kinda complicated if one has, say: double z = x/y + 3;

Integer expressions remain inexact until there's a cast. (It's very simple to implement, you just use the integer range code, adding an 'inexact' flag. Division sets the flag, casts clear the flag, everything else just propagates it if a unary operation, or ORs the two flags if a binary operation).

Assuming it really is this easy, I'd love to see the change. I've run into this bug countless times reviewing code, and it can be a tricky one to find. I tend to be pretty particular about always appending the ".0" for literals involved in floating-point assignments for this reason.
Dec 14 2009
parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Kelly wrote:
 Don Wrote:
 
 Walter Bright wrote:
 Don wrote:
 (This means that double y = int_val / 1;  is OK, and also:
  double z = 90/3; would be OK. An alternative rule would be:
 "If an integer expression involves integer divison, that expression 
 cannot be implicitly cast to a floating-point type").

double z = x/y + 3;

(It's very simple to implement, you just use the integer range code, adding an 'inexact' flag. Division sets the flag, casts clear the flag, everything else just propagates it if a unary operation, or ORs the two flags if a binary operation).

Assuming it really is this easy, I'd love to see the change. I've run into this bug countless times reviewing code, and it can be a tricky one to find. I tend to be pretty particular about always appending the ".0" for literals involved in floating-point assignments for this reason.

Ditto. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLJpLwT9LetA9XoXwRAmejAKCcoo9VMgotTyYugy+bLGjyr4iFKgCgvmSH l39YGMF98WLx5gaJ7HtcrZg= =FYgY -----END PGP SIGNATURE-----
Dec 14 2009
prev sibling next sibling parent lws <invalid email.com> writes:
On 2009-12-14 03:16:27 -0800, Don <nospam nospam.com> said:

 Walter Bright wrote:
 Don wrote:
 Consider this notorious piece of code:
 
 assert(x>1);
 double y = 1 / x;
 
 This calculates y as the reciprocal of x, if x is a floating-point 
 number. But if x is an integer, an integer division is performed 
 instead of a floating-point one, and y will be 0.
 
 It's a very common newbie trap, but I find it still catches me 
 occasionally, especially when dividing two variables or compile-time 
 constants.
 
 In the opPow thread there were a couple of mentions of inadvertent 
 integer division, and how Python is removing this error by making / 
 always mean floating-point division, and introducing a new operator for 
 integer division.
 
 We could largely eliminate this type of bug without doing anything so 
 drastic. Most of the problem just comes from C's cavalier attitude to 
 implicit casting. All we'd need to do is tighten the implicit 
 conversion rules for int->float, in the same way that the int->uint 
 rules have been tightened:
 
 "If an integer expression has an inexact result (ie, involves an 
 inexact integer divison), that expression cannot be implicitly cast to 
 a floating-point type."

But the compiler cannot reliably tell if it will produce an inexact result.
 (This means that double y = int_val / 1;  is OK, and also:
  double z = 90/3; would be OK. An alternative rule would be:
 "If an integer expression involves integer divison, that expression 
 cannot be implicitly cast to a floating-point type").

This is kinda complicated if one has, say: double z = x/y + 3;

Integer expressions remain inexact until there's a cast. (It's very simple to implement, you just use the integer range code, adding an 'inexact' flag. Division sets the flag, casts clear the flag, everything else just propagates it if a unary operation, or ORs the two flags if a binary operation).

Seems like when the product of integer devision is cast to a double is when it should produce a warning. -SC
Dec 14 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Integer expressions remain inexact until there's a cast.
 
 (It's very simple to implement, you just use the integer range code, 
 adding an 'inexact' flag. Division sets the flag, casts clear the flag, 
 everything else just propagates it if a unary operation, or ORs the two 
 flags if a binary operation).

That sounds like a very good idea.
Dec 14 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Don wrote:
 Integer expressions remain inexact until there's a cast.

 (It's very simple to implement, you just use the integer range code, 
 adding an 'inexact' flag. Division sets the flag, casts clear the 
 flag, everything else just propagates it if a unary operation, or ORs 
 the two flags if a binary operation).

That sounds like a very good idea.

I think the same (though I personally am not liable because it's been burned in my brain to always add ".0" to FP-involved literals). It's an improvement in the same vein as value range propagation. Should we make this part of the language, or as a quality of implementation issue? I prefer the former, because the latter means that code compiles on one machine and doesn't on another. Andrei
Dec 15 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:
 In the opPow thread there were a couple of mentions of inadvertent 
 integer division, and how Python is removing this error by making / 
 always mean floating-point division, and introducing a new operator for 
 integer division.

In Pascal too (and OCaML, but the situation is different) they are separated. I think here having two operators is better, Niklaus Wirth was right again (but I don't know if D can grow another division operator, it's unlikely). Bye, bearophile
Dec 14 2009
parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 In the opPow thread there were a couple of mentions of inadvertent 
 integer division, and how Python is removing this error by making / 
 always mean floating-point division, and introducing a new operator for 
 integer division.

In Pascal too (and OCaML, but the situation is different) they are separated. I think here having two operators is better,

Why? Niklaus Wirth was right again (but I don't know if D can grow another division operator, it's unlikely).
 
 Bye,
 bearophile

Dec 14 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:
 In Pascal too (and OCaML, but the situation is different) they are separated.
I think here having two operators is better, 

Why?

You are intelligent and expert so you must know my answer, so I fear yours is a trick question :-) Two operators allow to reduce the need for casts (and rounding/truncation), and are more explicit, allowing the code to express its meaning better to people that come after the original programmer. You can put them in the middle of a long expression, so you know what it's happening in the middle of it. This is useful for programming newbies too. I know there's a C translation of every usage of those two operators, but this is beside the point: even if the Laws of C language are sometimes explicit, sometimes they are not so natural and easy to remember, because normal people are not computers. Not every part of the C language is designed perfectly, there's space for improvements. Bye, bearophile
Dec 14 2009
next sibling parent "Aelxx" <aelxx yandex.ru> writes:
"bearophile" <bearophileHUGS lycos.com> wrote:
 Don:
 In Pascal too (and OCaML, but the situation is different) they are 
 separated. I think here having two operators is better,

Why?

You are intelligent and expert so you must know my answer, so I fear yours is a trick question :-) Two operators allow to reduce the need for casts (and rounding/truncation), and are more explicit, allowing the code to express its meaning better to people that come after the original programmer. You can put them in the middle of a long expression, so you know what it's happening in the middle of it. This is useful for programming newbies too. I know there's a C translation of every usage of those two operators, but this is beside the point: even if the Laws of C language are sometimes explicit, sometimes they are not so natural and easy to remember, because normal people are not computers. Not every part of the C language is designed perfectly, there's space for improvements. Bye, bearophile

intuiteve that 1/2 = 0.5 and 1 div 2 = 0. Or worse - what newbies use to input things like : const int b=1, a=0, n = 10 ; double h = (b-a)/n ; // haha who expect it be 0.0 As fact integer division is very different operation then floating point one. IMHO giving them one is a little like giving < and > operators second usage for templates. But besides that all it's only a convenience issue. Having enough expierience and making explicit casting is rather quick thing.
Dec 14 2009
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 In Pascal too (and OCaML, but the situation is different) they are separated.
I think here having two operators is better, 


You are intelligent and expert so you must know my answer, so I fear yours is a trick question :-)

No, it's not a trick question. You've used Python extensively, I haven't.
 Two operators allow to reduce the need for casts (and rounding/truncation),
and are more explicit, allowing the code to express its meaning better to
people that come after the original programmer.

OK. I'm trying to get most of the benefits without needing an extra operator. What I wonder is, in what contexts is / ambiguous or difficult to read? My feeling is that intentionally mixing integer division and floating-point in the same expression is extremely rare. The effect of my rule would be, that if you see an int anywhere, it's an integer division; and if you see a floating point number anywhere, it's a floating point division. BTW, does Python allow integer division of floating point numbers? eg, int_a = float_b // float_c; ? (meaning cast(int)float_b / (cast(int)float_c); ). My idea fails if: * I'm completely wrong about the frequency of mixing integer division with floating point. So the cost is high. OR * Inadvertant integer division commonly occurs in things like int a = b/c; (which would mean that I'm wrong in assuming it's primarily an implicit casting problem). If the benefit is low, it's not much use. OR * There's something I didn't think of. Which is quite probable <g>.
 You can put them in the middle of a long expression, so you know what it's
happening in the middle of it. This is useful for programming newbies too. 

I know there's a C translation of every usage of those two operators, but this
is beside the point: even if the Laws of C language are sometimes explicit,
sometimes they are not so natural and easy to remember, because normal people
are not computers.

Yeah, I agree. C never errs on the side of caution <g>. Much of D involves tightening things up considerably.
Dec 14 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:

You've used Python extensively, I haven't.<

The situation with Python isn't the same of D because Python has dynamic typing, so your operations must always know what they return (and their return type can change when necessary).
in what contexts is / ambiguous or difficult to read?<

A silly example, maybe useless for you: auto x = 5 / foo();
BTW, does Python allow integer division of floating point numbers?<

This is how Python2.x used to work:
 5 / 2



 -5 / 2



 5.0 / 2



 5 / 2.0



 -5.0 / 2



This is how Python3.x now works:
 from __future__ import division



 5 / 2



 -5 / 2



 5.0 / 2



 5 / 2.0



 -5.0 / 2



 5 // 2



 -5 // 2



 5.0 // 2



 5 // 2.0



 -5.0 // 2



I am not saying that Python behaviour is the best possible :-) I think I'd like // to always return a int. In Pascal: int / int => float float / int => float int / float => float float / float => float int div int => int float div int => idontremember int div float => idontremember Bye, bearophile
Dec 14 2009
prev sibling next sibling parent reply "Bob Jones" <me not.com> writes:
"Don" <nospam nospam.com> wrote in message 
news:hg5nkk$1n37$1 digitalmars.com...
 bearophile wrote:
 Don:
 In Pascal too (and OCaML, but the situation is different) they are 
 separated. I think here having two operators is better,


You are intelligent and expert so you must know my answer, so I fear yours is a trick question :-)

No, it's not a trick question. You've used Python extensively, I haven't.
 Two operators allow to reduce the need for casts (and 
 rounding/truncation), and are more explicit, allowing the code to express 
 its meaning better to people that come after the original programmer.

OK. I'm trying to get most of the benefits without needing an extra operator.

Having made the switch from Delphi to C++ a few years ago I ran into this alot. I dislike that I have to litter my arithmetic expresions with casts in order to get the division operator to do what I want it to. And I suspect all of those who are used to having seperate intdiv & fltdiv operators will agree. So using cast(int) to mean "actualy I did intend the integer division inside the following expression" instead of it's usual "convert this to" makes an ugly situation even more so imo. The fact that adding a specific intdiv operator would not only avoid more casting, but remove the the need for casting in a lot of existing cases should count pretty well against the "no more operator/keywords" argument. Imo it should count enough to override it. But i guess cheap&ugly is more likely to make it in than expensive&expresive&ellegant.
Dec 14 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bob Jones:
 The fact that adding a specific intdiv operator would not only avoid more 
 casting, but remove the the need for casting in a lot of existing cases 
 should count pretty well against the "no more operator/keywords" argument.

In D you can't use // used in Python, because it's used to denote comments and this will not change. You probably can't use "div" beause that adds another keyword, and people don't like that. And it goes against the C usage of using symbols for operators (so for example D devs don't like 'or' and 'and' as boolean operators, even if they can avoid some of the bugs caused by writing & instead of && or the other way). You can't use \ (it's also not different enough to tell them apart well). I don't know if you can use \\. Even if you find a fitting operator, how can you restrict \ to just floating point division and keep some compatibility with C code? Bye, bearophile
Dec 14 2009
parent "Bob Jones" <me not.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hg6rns$ta6$1 digitalmars.com...
 Even if you find a fitting operator, how can you restrict \ to just 
 floating point division
 and keep some compatibility with C code?

Isnt compatibility with C already broken anyway? But yeah if C compatibility is a condition then I dont see how to get around it. Weird thing is I get the impression that breaking compatibility between D and C is more of a sin than breaking compatibility between versions D. Is source compatibility with C really that important? Surely link compatibility should be enough?
Dec 14 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Bob Jones wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:hg5nkk$1n37$1 digitalmars.com...
 bearophile wrote:
 Don:
 In Pascal too (and OCaML, but the situation is different) they are 
 separated. I think here having two operators is better,


yours is a trick question :-)

 Two operators allow to reduce the need for casts (and 
 rounding/truncation), and are more explicit, allowing the code to express 
 its meaning better to people that come after the original programmer.

operator.

Having made the switch from Delphi to C++ a few years ago I ran into this alot. I dislike that I have to litter my arithmetic expresions with casts in order to get the division operator to do what I want it to. And I suspect all of those who are used to having seperate intdiv & fltdiv operators will agree.

Your arithmetic expressions would only become "littered with casts" if you regularly use integer division inside floating-point expressions. Personally, I cannot recall *ever* having intentionally used integer division inside a floating point expression. (I've seen inadvertent uses of it, plenty of times).
 So using cast(int) to mean "actualy I did intend the integer division inside 
 the following expression" instead of it's usual "convert this to" makes an 
 ugly situation even more so imo.

Well, it's really a bizarre situation. It's a very strange thing to be doing.
 The fact that adding a specific intdiv operator would not only avoid more 
 casting, but remove the the need for casting in a lot of existing cases 

I bet there are negligible cases where casting is required.
 should count pretty well against the "no more operator/keywords" argument. 
 Imo it should count enough to override it.
 
 But i guess cheap&ugly is more likely to make it in than 
 expensive&expresive&ellegant.

Dec 15 2009
parent reply "Bob Jones" <me not.com> writes:
"Don" <nospam nospam.com> wrote in message 
news:hg7gbm$1vln$1 digitalmars.com...
 Bob Jones wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:hg5nkk$1n37$1 digitalmars.com...
 bearophile wrote:
 Don:
 In Pascal too (and OCaML, but the situation is different) they are 
 separated. I think here having two operators is better,


yours is a trick question :-)

haven't.
 Two operators allow to reduce the need for casts (and 
 rounding/truncation), and are more explicit, allowing the code to 
 express its meaning better to people that come after the original 
 programmer.

operator.

Having made the switch from Delphi to C++ a few years ago I ran into this alot. I dislike that I have to litter my arithmetic expresions with casts in order to get the division operator to do what I want it to. And I suspect all of those who are used to having seperate intdiv & fltdiv operators will agree.

Your arithmetic expressions would only become "littered with casts" if you regularly use integer division inside floating-point expressions. Personally, I cannot recall *ever* having intentionally used integer division inside a floating point expression. (I've seen inadvertent uses of it, plenty of times).

I grepped around 60 instances of double y = a / double(b); In my last project. That's what I'm talking about. Where you have to cast either top or bottom to float in order to get the division operator to do float division of two int operands. There's also the (perhaps MSVC specific) issue that I have to cast doubles to floats to get rid of the loss of precision warning message. It's a usuful warning on ints, but for floats it's completely redundant imo.
 The fact that adding a specific intdiv operator would not only avoid more 
 casting, but remove the the need for casting in a lot of existing cases

I bet there are negligible cases where casting is required.

I didnt find any instances of an expresion containg intdiv being assigned to a float, so yeah, that is rare. But not the case where you have two ints and want the actual division done in float.
Dec 15 2009
parent reply Don <nospam nospam.com> writes:
Bob Jones wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:hg7gbm$1vln$1 digitalmars.com...
 Bob Jones wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:hg5nkk$1n37$1 digitalmars.com...
 bearophile wrote:
 Don:
 In Pascal too (and OCaML, but the situation is different) they are 
 separated. I think here having two operators is better,


yours is a trick question :-)

haven't.
 Two operators allow to reduce the need for casts (and 
 rounding/truncation), and are more explicit, allowing the code to 
 express its meaning better to people that come after the original 
 programmer.

operator.

alot. I dislike that I have to litter my arithmetic expresions with casts in order to get the division operator to do what I want it to. And I suspect all of those who are used to having seperate intdiv & fltdiv operators will agree.

regularly use integer division inside floating-point expressions. Personally, I cannot recall *ever* having intentionally used integer division inside a floating point expression. (I've seen inadvertent uses of it, plenty of times).

I grepped around 60 instances of double y = a / double(b); In my last project. That's what I'm talking about. Where you have to cast either top or bottom to float in order to get the division operator to do float division of two int operands.

OK, I misunderstood you. You're completely right. At least my proposal won't let them slip through silently. I don't think we can do anything else without silently breaking C compatibility.
 There's also the (perhaps MSVC specific) issue that I have to cast doubles 
 to floats to get rid of the loss of precision warning message. It's a usuful 
 warning on ints, but for floats it's completely redundant imo.
 
 
 The fact that adding a specific intdiv operator would not only avoid more 
 casting, but remove the the need for casting in a lot of existing cases


I didnt find any instances of an expresion containg intdiv being assigned to a float, so yeah, that is rare. But not the case where you have two ints and want the actual division done in float.

Dec 15 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

 Bob Jones:
 double y = a / double(b);


 OK, I misunderstood you. You're completely right. At least my proposal 
 won't let them slip through silently. I don't think we can do anything 
 else without silently breaking C compatibility.

A silly idea that may keep C compatibility and avoid that cast: instead of an integer division operator it can be added a operator that always performs a floating point division, as: int a = 5, b = 7; double y = a \\ b; (I don't like that much, Pascal is better here). Bye, bearophile
Dec 15 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Dec 16, 09 05:14, bearophile wrote:
 Don:

 Bob Jones:
 double y = a / double(b);


 OK, I misunderstood you. You're completely right. At least my proposal
 won't let them slip through silently. I don't think we can do anything
 else without silently breaking C compatibility.

A silly idea that may keep C compatibility and avoid that cast: instead of an integer division operator it can be added a operator that always performs a floating point division, as: int a = 5, b = 7; double y = a \\ b; (I don't like that much, Pascal is better here). Bye, bearophile

Just introduce real fdiv(real, real) (or /fdiv/) if this is the solution. Works right now without changing the language.
Dec 15 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"KennyTM~" <kennytm gmail.com> wrote in message 
news:hg90tu$22od$1 digitalmars.com...
 On Dec 16, 09 05:14, bearophile wrote:
 Don:

 Bob Jones:
 double y = a / double(b);


 OK, I misunderstood you. You're completely right. At least my proposal
 won't let them slip through silently. I don't think we can do anything
 else without silently breaking C compatibility.

A silly idea that may keep C compatibility and avoid that cast: instead of an integer division operator it can be added a operator that always performs a floating point division, as: int a = 5, b = 7; double y = a \\ b; (I don't like that much, Pascal is better here). Bye, bearophile

Just introduce real fdiv(real, real) (or /fdiv/) if this is the solution. Works right now without changing the language.

Reserving the only division operator for intdiv-only for the sake of C compatibility would be terrible design.
Dec 15 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 Reserving the only division operator for intdiv-only for the sake of C 
 compatibility would be terrible design.

Well, no, the (silly) idea is: int / int => int int \\ int => float float / int => float float \\ int => float int / float => float int \\ float => float float / float => float float \\ float => float So the / is not just the int division. The only difference between the two operators is when you have (int,int). Bye, bearophile
Dec 15 2009
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
On Dec 16, 09 06:17, Nick Sabalausky wrote:
 "KennyTM~"<kennytm gmail.com>  wrote in message
 news:hg90tu$22od$1 digitalmars.com...
 On Dec 16, 09 05:14, bearophile wrote:
 Don:

 Bob Jones:
 double y = a / double(b);


 OK, I misunderstood you. You're completely right. At least my proposal
 won't let them slip through silently. I don't think we can do anything
 else without silently breaking C compatibility.

A silly idea that may keep C compatibility and avoid that cast: instead of an integer division operator it can be added a operator that always performs a floating point division, as: int a = 5, b = 7; double y = a \\ b; (I don't like that much, Pascal is better here). Bye, bearophile

Just introduce real fdiv(real, real) (or /fdiv/) if this is the solution. Works right now without changing the language.

Reserving the only division operator for intdiv-only for the sake of C compatibility would be terrible design.

Just introduce real fdiv(real, real) (or /fdiv/) **if this is the solution.** One could also force / to return a real and introduce intdiv(). <off-topic>but if C compatibility is to be broken I'd like to see the comma operator be replaced instead.</off-topic>
Dec 15 2009
prev sibling parent Peter <nospam nospam.org> writes:
Don Wrote:
 BTW, does Python allow integer division of floating point numbers?
 eg, int_a  = float_b // float_c;   ?
 (meaning cast(int)float_b / (cast(int)float_c); ).

Dec 14 2009
prev sibling next sibling parent "Saaa" <empty needmail.com> writes:
Don wrote
 Consider this notorious piece of code:

 assert(x>1);
 double y = 1 / x;

 This calculates y as the reciprocal of x, if x is a floating-point number. 
 But if x is an integer, an integer division is performed instead of a 
 floating-point one, and y will be 0.

 It's a very common newbie trap

Agreed! :(
Dec 14 2009
prev sibling next sibling parent reply "Phil Deets" <pjdeets2 gmail.com> writes:
On Mon, 14 Dec 2009 04:57:26 -0500, Don <nospam nospam.com> wrote:

 In the very rare cases where the result of an integer division was  
 actually intended to be stored in a float, an explicit cast would be  
 required. So you'd write:
 double y = cast(int)(1/x);

To me, double y = cast(double)(1/x); makes more sense. Why cast to int?
Dec 14 2009
parent reply Don <nospam nospam.com> writes:
Phil Deets wrote:
 On Mon, 14 Dec 2009 04:57:26 -0500, Don <nospam nospam.com> wrote:
 
 In the very rare cases where the result of an integer division was 
 actually intended to be stored in a float, an explicit cast would be 
 required. So you'd write:
 double y = cast(int)(1/x);

To me, double y = cast(double)(1/x); makes more sense. Why cast to int?

That'd compile, too. But, it's pretty confusing to the reader, because that code will only set y == -1.0, +1.0, +0.0, -0.0, or else create a divide by zero error. So I'd recommend a cast to int.
Dec 15 2009
parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Tue, 15 Dec 2009 03:02:01 -0500, Don <nospam nospam.com> wrote:
 
 Phil Deets wrote:
 On Mon, 14 Dec 2009 04:57:26 -0500, Don <nospam nospam.com> wrote:

 In the very rare cases where the result of an integer division was 
 actually intended to be stored in a float, an explicit cast would be 
 required. So you'd write:
 double y = cast(int)(1/x);

double y = cast(double)(1/x); makes more sense. Why cast to int?

That'd compile, too. But, it's pretty confusing to the reader, because that code will only set y == -1.0, +1.0, +0.0, -0.0, or else create a divide by zero error. So I'd recommend a cast to int.

I agree with Phil, in no situation that I can think of does: T i, j; T k = i/j; U k = cast(T)i/j; Make sense. I'd expect to see cast(U) there. You can think of it as i/j returns an undisclosed type that implicitly casts to T, but not U, even if T implicitly casts to U. Wow, this is bizarre.

Yeah. (However, mixing integer division with floating point is bizarre to start with. As I mentioned somewhere, I don't think I've ever actually seen it).
 I like the idea, but the recommendation to cast to int makes no sense to 
 me.  I'd also actually recommend this instead:
 
 auto y = cast(double)(1/x);

Fair enough, you won't see the recommendation to cast to int anywhere. But it doesn't really matter much. The important thing is, that by inserting *some* cast, you've drawn attention to the operation. Hopefully, the fact that you got a compiler error will inspire you to put a comment in the code, as well <g>. Personally, I'd always rewrite such a thing as: int z = 1/x; // Note: integer division!! double y = z; Completely separating the integer and floating-point parts.
 On the idea as a whole, I think it's very sound.  Note that the only 
 case where it gets ugly (i.e. requiring casts) is when both operands of 
 division are symbols, since it's trivial to turn an integer literal into 
 a floating point.

Exactly. And I think that's the situation where it happens in practice. Normally, integer literals can be used as floating point literals. This is the one case where integer and floating-point literals have a completely different meaning.
Dec 15 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 15 Dec 2009 03:02:01 -0500, Don <nospam nospam.com> wrote:

 Phil Deets wrote:
 On Mon, 14 Dec 2009 04:57:26 -0500, Don <nospam nospam.com> wrote:

 In the very rare cases where the result of an integer division was  
 actually intended to be stored in a float, an explicit cast would be  
 required. So you'd write:
 double y = cast(int)(1/x);

double y = cast(double)(1/x); makes more sense. Why cast to int?

That'd compile, too. But, it's pretty confusing to the reader, because that code will only set y == -1.0, +1.0, +0.0, -0.0, or else create a divide by zero error. So I'd recommend a cast to int.

I agree with Phil, in no situation that I can think of does: T i, j; T k = i/j; U k = cast(T)i/j; Make sense. I'd expect to see cast(U) there. You can think of it as i/j returns an undisclosed type that implicitly casts to T, but not U, even if T implicitly casts to U. Wow, this is bizarre. I like the idea, but the recommendation to cast to int makes no sense to me. I'd also actually recommend this instead: auto y = cast(double)(1/x); On the idea as a whole, I think it's very sound. Note that the only case where it gets ugly (i.e. requiring casts) is when both operands of division are symbols, since it's trivial to turn an integer literal into a floating point. -Steve
Dec 15 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 15 de diciembre a las 16:14 me escribiste:
 Don:
 
 Bob Jones:
 double y = a / double(b);


 OK, I misunderstood you. You're completely right. At least my proposal 
 won't let them slip through silently. I don't think we can do anything 
 else without silently breaking C compatibility.

A silly idea that may keep C compatibility and avoid that cast: instead of an integer division operator it can be added a operator that always performs a floating point division, as: int a = 5, b = 7; double y = a \\ b; (I don't like that much, Pascal is better here).

What about ./ for floating point division? Maybe it introduces some kind of ambiguity with 1./2, but fortunately the result should be the same if that means 1. / 2 or 1 ./ 2: 0.5 =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- He andáu muchos caminos, muchos caminos he andáu, Chile tiene el buen vino y Suecia, el bacalao. Esta'o Unido tiene el hot do', Cuba tiene el mojito, Guatemala, el cornalito y Brasil la feishoada.
Dec 15 2009