www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A division problem

reply "bearophile" <bearophileHUGS lycos.com> writes:
This kind of code sometimes is wrong, because you forget to cast 
x to double before the division and you lose precision (but here 
the compiler knows that the result of the division will go inside 
a double):


void main() {
     int x = 15;
     double y = x / 10;
}

The cause is that unfortunately in D the integer division uses 
the same operator as the FP division. In Python there is the / 
and // operators. In OcaML there are the / and /., in Delphi 
there are the / and div operators, in Ada the two operands need 
to be of the same type.

Seasoned C/C++/D programmers watch for the types every time they 
perform a division, to avoid that trap. But less experienced 
programmers introduce bugs with divisions. Can D help the 
programmer reduce the frequency of similar bugs? And do we want 
to?

Bye,
bearophile
Mar 23 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"bearophile"  wrote in message news:nxfidkglrgkqtxdzgojt forum.dlang.org... 

 Seasoned C/C++/D programmers watch for the types every time they 
 perform a division, to avoid that trap. But less experienced 
 programmers introduce bugs with divisions. Can D help the 
 programmer reduce the frequency of similar bugs? And do we want 
 to?

Newbies have to realize that integers aren't real numbers eventually.
Mar 24 2014
prev sibling next sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
                                                        Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

When doing math, I always use parentheses and casts to force a single possible outcome of the result, regardless of the order of evaluation and auto-casting. I also always write all my case/break statements as a set of matching pairs before writing any code in a switch, so the idea that something would fall through on accident seems like something that could never happen. People should have habits like these (and putting constant values on the left side of a comparison), but I suspect that most people would be annoyed at being forced to do it by the compiler, even though if they were aware that this was a "good habit", they'd all start doing it and life would be perfect.
Mar 24 2014
prev sibling next sibling parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
 Seasoned C/C++/D programmers watch for the types every time 
 they perform a division, to avoid that trap. But less 
 experienced programmers introduce bugs with divisions. Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

This is the kind of area where an IDE can shine...
Mar 24 2014
prev sibling next sibling parent reply "Don" <x nospam.com> writes:
On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
 This kind of code sometimes is wrong, because you forget to 
 cast x to double before the division and you lose precision 
 (but here the compiler knows that the result of the division 
 will go inside a double):


 void main() {
     int x = 15;
     double y = x / 10;
 }

 The cause is that unfortunately in D the integer division uses 
 the same operator as the FP division. In Python there is the / 
 and // operators. In OcaML there are the / and /., in Delphi 
 there are the / and div operators, in Ada the two operands need 
 to be of the same type.

 Seasoned C/C++/D programmers watch for the types every time 
 they perform a division, to avoid that trap. But less 
 experienced programmers introduce bugs with divisions. Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

 Bye,
 bearophile

It is indeed a common floating-point bug. I came up with a solution for this a couple of years ago, never got around to doing a pull request, but it's on the newsgroup somewhere. It's a little extension to the range propagation implementation. You add a boolean flag to the range, which indicates 'a fractional part has been discarded'. This flag gets set whenever you perform an integer division (or integer exponentiation with a negative power), and is cleared whenever there is a cast or a bitwise operation. Then, disallow implicit casting from integer to floating point whenever the fractional bit is set. Catches all these kinds of bugs, doesn't require any changes to the language.
Mar 24 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/24/14, 2:51 AM, Don wrote:
 It is indeed a common floating-point bug.

 I came up with a solution for this a couple of years ago, never got
 around to doing a pull request, but it's on the newsgroup somewhere.
 It's a little extension to the range propagation implementation. You add
 a boolean flag to the range, which indicates 'a fractional part has been
 discarded'. This flag gets set whenever you perform an integer division
 (or integer exponentiation with a negative power), and is cleared
 whenever there is a cast or a bitwise operation.

 Then, disallow implicit casting from integer to floating point whenever
 the fractional bit is set. Catches all these kinds of bugs, doesn't
 require any changes to the language.

That seems a sensible thing to do. I've assigned https://d.puremagic.com/issues/show_bug.cgi?id=12452 to you for now. Andrei
Mar 24 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Daniel Murphy:

 Newbies have to realize that integers aren't real numbers 
 eventually.

Of course. But from reviewing plenty of code, I have seen that unfortunately even programmers with some experience once in a while create this bug. Because you have to keep attention to the types of each division usage, and once in a while your attention slips (or perhaps some bugs of this kind are created by successive type changes). Bye, bearophile
Mar 24 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Chris Williams:

 I also always write all my case/break statements as a set of 
 matching pairs before writing any code in a switch, so the idea 
 that something would fall through on accident seems like 
 something that could never happen.

Now D catches most of such implicit case fall-through bugs.
 People should have habits like these (and putting constant 
 values on the left side of a comparison),

void main() { int x; if (x = 5) {} } test.d(3,14): Error: assignment cannot be used as a condition, perhaps == was meant? Bye, bearophile
Mar 24 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 24 Mar 2014 09:51:02 +0000
schrieb "Don" <x nospam.com>:

 It is indeed a common floating-point bug.
 
 I came up with a solution for this a couple of years ago, never 
 got around to doing a pull request, but it's on the newsgroup 
 somewhere. It's a little extension to the range propagation 
 implementation. You add a boolean flag to the range, which 
 indicates 'a fractional part has been discarded'. This flag gets 
 set whenever you perform an integer division (or integer 
 exponentiation with a negative power), and is cleared whenever 
 there is a cast or a bitwise operation.
 
 Then, disallow implicit casting from integer to floating point 
 whenever the fractional bit is set. Catches all these kinds of 
 bugs, doesn't require any changes to the language.

Sounds awesome. Could that also be applied to this as well?: mask = 1 << bitNum; -- Marco
Mar 24 2014
prev sibling next sibling parent "bearophile" <bearophile HUGS lycos.com> writes:
Don:

 It is indeed a common floating-point bug.

I have opened an ER: https://d.puremagic.com/issues/show_bug.cgi?id=12452 Bye, bearophile
Mar 24 2014
prev sibling next sibling parent "Temtaime" <temtaime gmail.com> writes:
It requires a little more attention and that's all.
Please, stop creating such "fake" enchantments and go to fix real 
bugs. Thanks.
Mar 24 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Temtaime:

 It requires a little more attention and that's all.
 Please, stop creating such "fake" enchantments and go to fix 
 real bugs. Thanks.

I don't agree they are fake :-) We have removed several classes of common C bugs from D with those enhancements, and there is still some space left for improvements :-) Bye, bearophile
Mar 24 2014
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
 Seasoned C/C++/D programmers watch for the types every time 
 they perform a division, to avoid that trap. But less 
 experienced programmers introduce bugs with divisions. Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

We are passed the initial stage of designing the language. D is used now in lots of real code. The focus now has to be on completing the original design, and maybe making small non-breaking improvements where practical. Discussions about fundamental changes to the language like this, while interesting, are distracting and counterproductive.
Mar 24 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/24/14, 12:51 PM, bearophile wrote:
 Peter Alexander:

 We are passed the initial stage of designing the language. D is used
 now in lots of real code.

I'd like D improve some more.

The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. Anyone who has any nontrivial interest in the future of D should help us turn the ratchet by reviewing pull requests. Anything - potential bugs found, safety suggestions, efficiency suggestions, LGTM - would help the core team drain that pipe.
 are distracting and counterproductive.

It's not distracting, because it focuses on something you do often (divisions), and it's hopefully productive because it could avoid some bugs and decrease the time spent performing rote manual code review.

If you diverted 1.0/10 (sic!) of the effort you put in these discussions in reviewing pull requests, that would help us all put up a lot better with the distraction. Andrei
Mar 24 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/24/14, 1:11 PM, Andrej Mitrovic wrote:
 On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
 The single most impactful way to improve D some more at this point is,
 without a shred of doubt, reviewing pull requests on github.

I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth.

Those should be closed. -- Andrei
Mar 24 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/24/14, 1:21 PM, bearophile wrote:
 Andrei Alexandrescu:

 The single most impactful way to improve D some more at this point is,
 without a shred of doubt, reviewing pull requests on github.

My time is more efficiently used suggesting people new ideas to create new pull requests :-)

You and I have very different notions of what efficiency would mean here. -- Andrei
Mar 24 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/24/2014 1:53 PM, Brad Roberts wrote:
 Older than 2 weeks and they aren't likely to get tested either.. since any
 change to the branch (ie, a pull being merged) restarts testing, so they're
 effectively just dead weight down the queue.  Only a lull in pull merging would
 allow them to be tested, which is fine since a lull in activity would otherwise
 just result in idle testers.

Is it reasonable to, at least once a week, run the full queue? Like on Sunday morning?
Mar 24 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Steven Schveighoffer"  wrote in message 
news:op.xc8uqgsneav7ka stevens-macbook-pro.local...

 2 things:

 1. Pulls that are waiting for author changes, but haven't been touched in 
 a week (maybe?) should be closed. They can always be reopened.
 2. Pulls that are closed do not get tested, so they are not using up 
 cycles on the auto tester.

Pulls that haven't been touched in a while also don't get auto-tested.
Mar 24 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 24, 2014 at 07:19:58PM +0000, Peter Alexander wrote:
 On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
Seasoned C/C++/D programmers watch for the types every time they
perform a division, to avoid that trap. But less experienced
programmers introduce bugs with divisions. Can D help the programmer
reduce the frequency of similar bugs? And do we want to?

We are passed the initial stage of designing the language. D is used now in lots of real code. The focus now has to be on completing the original design, and maybe making small non-breaking improvements where practical. Discussions about fundamental changes to the language like this, while interesting, are distracting and counterproductive.

Don't we have a wiki page for ideas for "future D" (or D3?)? These ideas can go on that page. T -- English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicests of all possible ways. -- Larry Wall
Mar 24 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Peter Alexander:

 We are passed the initial stage of designing the language. D is 
 used now in lots of real code.

I'd like D improve some more.
 The focus now has to be on completing the original design,

The original D design is to make a language that is "focused on safety", so we are still working to complete it :-)
 and maybe making small non-breaking improvements where 
 practical.

I think the problem raised in this thread could have a very limited negative impact on correct existing D code, and a positive impact in finding wrong code.
 Discussions about fundamental changes to the language like this,

It's not a fundamental change, I think it's a sufficiently limited change. As usual you can be sure only when you apply such ideas on real D code.
 are distracting and counterproductive.

It's not distracting, because it focuses on something you do often (divisions), and it's hopefully productive because it could avoid some bugs and decrease the time spent performing rote manual code review. Bye, bearophile
Mar 24 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 Don't we have a wiki page for ideas for "future D" (or D3?)? 
 These ideas can go on that page.

I don't think Andrei will want a D3 language, so better to keep the focus on D2 first :-) And he is right because there are still some parts of D2 unfinished. The little type system improvement suggested in this thread is meant for D2. Bye, bearophile
Mar 24 2014
prev sibling next sibling parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu 
wrote:
 The single most impactful way to improve D some more at this 
 point is, without a shred of doubt, reviewing pull requests on 
 github.

I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth.
Mar 24 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 The single most impactful way to improve D some more at this 
 point is, without a shred of doubt, reviewing pull requests on 
 github.

My time is more efficiently used suggesting people new ideas to create new pull requests :-)
 If you diverted 1.0/10 (sic!) of the effort you put in these 
 discussions in reviewing pull requests, that would help us all 
 put up a lot better with the distraction.

Instead of ignoring my arguments of this thread, if you want please comment regarding the merits of the idea of catching some of the division-related problems. Bye, bearophile
Mar 24 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
 The single most impactful way to improve D some more at this point is,  
 without a shred of doubt, reviewing pull requests on github.

I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth.

2 things: 1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened. 2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester. -Steve
Mar 24 2014
prev sibling next sibling parent "Asman01" <jckj33 gmail.com> writes:
On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
 This kind of code sometimes is wrong, because you forget to 
 cast x to double before the division and you lose precision 
 (but here the compiler knows that the result of the division 
 will go inside a double):


 void main() {
     int x = 15;
     double y = x / 10;
 }

 The cause is that unfortunately in D the integer division uses 
 the same operator as the FP division. In Python there is the / 
 and // operators. In OcaML there are the / and /., in Delphi 
 there are the / and div operators, in Ada the two operands need 
 to be of the same type.

 Seasoned C/C++/D programmers watch for the types every time 
 they perform a division, to avoid that trap. But less 
 experienced programmers introduce bugs with divisions. Can D 
 help the programmer reduce the frequency of similar bugs? And 
 do we want to?

 Bye,
 bearophile

I think I've see a thread very similar to this... well, most willn't like but a possible solution to help programmer reduce this is do what python did: a new operator.
Mar 24 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/24/14, 1:48 PM, Steven Schveighoffer wrote:
 On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic
<andrej.mitrovich gmail.com> wrote:

 On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
 The single most impactful way to improve D some more at this point is, without
a shred of doubt,
 reviewing pull requests on github.

I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth.

2 things: 1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened. 2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester.

Older than 2 weeks and they aren't likely to get tested either.. since any change to the branch (ie, a pull being merged) restarts testing, so they're effectively just dead weight down the queue. Only a lull in pull merging would allow them to be tested, which is fine since a lull in activity would otherwise just result in idle testers. So, really #2 is a non-issue.
Mar 24 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Mar 2014 16:53:36 -0400, Brad Roberts <braddr puremagic.com>  
wrote:

 On 3/24/14, 1:48 PM, Steven Schveighoffer wrote:
 On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic  
 <andrej.mitrovich gmail.com> wrote:

 On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
 The single most impactful way to improve D some more at this point  
 is, without a shred of doubt,
 reviewing pull requests on github.

I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth.

2 things: 1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened. 2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester.

Older than 2 weeks and they aren't likely to get tested either.. since any change to the branch (ie, a pull being merged) restarts testing, so they're effectively just dead weight down the queue. Only a lull in pull merging would allow them to be tested, which is fine since a lull in activity would otherwise just result in idle testers. So, really #2 is a non-issue.

OK, so it tests in reverse chronological? That makes the most sense. I was worried it was taking away time from other test runs. If a test has been started, and a merge occurs, does it stop the test? -Steve
Mar 24 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/24/14, 2:26 PM, Steven Schveighoffer wrote:
 On Mon, 24 Mar 2014 16:53:36 -0400, Brad Roberts <braddr puremagic.com> wrote:

 On 3/24/14, 1:48 PM, Steven Schveighoffer wrote:
 On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic
<andrej.mitrovich gmail.com> wrote:

 2 things:

 1. Pulls that are waiting for author changes, but haven't been touched in a
week (maybe?) should be
 closed. They can always be reopened.
 2. Pulls that are closed do not get tested, so they are not using up cycles on
the auto tester.

Older than 2 weeks and they aren't likely to get tested either.. since any change to the branch (ie, a pull being merged) restarts testing, so they're effectively just dead weight down the queue. Only a lull in pull merging would allow them to be tested, which is fine since a lull in activity would otherwise just result in idle testers. So, really #2 is a non-issue.

OK, so it tests in reverse chronological? That makes the most sense. I was worried it was taking away time from other test runs. If a test has been started, and a merge occurs, does it stop the test? -Steve

The sync between github and the tester isn't instant, so time is sometimes wasted on an already merged pull. However, it does check between steps to see if the run has been marked as old. If so, it stops working on it.
Mar 24 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Mar 2014 19:33:47 -0400, Brad Roberts <braddr puremagic.com>  
wrote:

 The sync between github and the tester isn't instant, so time is  
 sometimes wasted on an already merged pull.  However, it does check  
 between steps to see if the run has been marked as old.  If so, it stops  
 working on it.

Brad, I wanted to just say that I don't follow the auto tester's development closely (obviously), but it's one of the best things I think has ever happened to D. Thanks for all your hard work. -Steve
Mar 24 2014
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/24/14, 4:50 PM, Walter Bright wrote:
 On 3/24/2014 1:53 PM, Brad Roberts wrote:
 Older than 2 weeks and they aren't likely to get tested either.. since any
 change to the branch (ie, a pull being merged) restarts testing, so they're
 effectively just dead weight down the queue.  Only a lull in pull merging would
 allow them to be tested, which is fine since a lull in activity would otherwise
 just result in idle testers.

Is it reasonable to, at least once a week, run the full queue? Like on Sunday morning?

To do so for all platforms would take more than a morning (probably a full day). I don't, personally, think it'd be all that useful. As soon as it finished, the results would be deprecated and fresh builds started. That the queue focuses on pull requests that are actually the active requests seems pretty much ideal, imho. Also, for what it's worth, the 1 millionth test run was executed some time this past weekend.
Mar 24 2014