www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Oh Dear

reply Steve Teale <steve.teale britseyeview.com> writes:
D Friends/Enemies,

Looking at the current crop of postings, it seems like people are staying off
the subject of where D is going (we've had a lot of that lately, without any
result), and concentrating on less and less important particulars.

So we are we doomed, like the Oomigooly bird, to fly around in ever decreasing
circles, until we eventually disappear up our own asshole?

As per the current fashion, I apologize profusely for any offense I may cause
to anyone as a result of this message. But we do need to arrive at conclusions.
D2 should be stabilized and D1 deprecated, there should be one standard
library, there should be a new linker and object file format, and there should
be a change made to the acceptable content of the primary newsgroup (the learn
suggestion is the best we have so far).

Steve
Jul 11 2009
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Steve Teale wrote:

 D Friends/Enemies,
 
 Looking at the current crop of postings, it seems like people are staying off
the subject of where D is going (we've had a lot of that lately, without any
result), and concentrating on less and less important particulars.
 
 So we are we doomed, like the Oomigooly bird, to fly around in ever decreasing
circles, until we eventually disappear up our own asshole?
 
 As per the current fashion, I apologize profusely for any offense I may cause
to anyone as a result of this message. But we do need to arrive at conclusions.
D2 should be stabilized and D1 deprecated, there should be one standard
library, there should be a new linker and object file format, and there should
be a change made to the acceptable content of the primary newsgroup (the learn
suggestion is the best we have so far).
 
 Steve


Woooaaahh.. dejavu!

Wait a minute...
Jul 11 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steve Teale:

D2 should be stabilized<


That will happen in time, but rushing things is very bad. There are some other
things to be fixed/done first, like:
- concurrency;
- making D2 fitter for the LLVM back-end;
- fixing the import semantics;
- improving arrays and slices;
- improving operator overloading;
- maybe improving matrices and slices;
- maybe improving the data parallelism.
Plus a lot of smaller details to fix, add or improve. I have surely missed
something.



and D1 deprecated,<


I see no purpose in deprecating D1 in the short term. D1 is simpler than D2, so
some people may prefer it. Eventually D1 may vanish, but it doesn't need to be
killed on purpose.



there should be one standard library,<


I don't agree, I'd like to have both Phobos and Tango at the same time, and
useful for different purposes, like I have both STL and Boost (among other
things, like Qt) installed with the C++ compiler.



there should be a new linker and object file format,<


Once LDC supports exceptions on Windows I think LDC can slowly become the
reference implementation of D1/D2, and it will use a new linker, etc.



and there should be a change made to the acceptable content of the primary
newsgroup (the learn suggestion is the best we have so far).<


I don't fully understand you, but it doesn't sound like a too much hard thing
to do.

Bye,
bearophile
Jul 11 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
bearophile wrote:


D2 should be stabilized<


 
 That will happen in time, but rushing things is very bad. There are some
 other things to be fixed/done first, like: - concurrency;
 - making D2 fitter for the LLVM back-end;
 - fixing the import semantics;
 - improving arrays and slices;
 - improving operator overloading;
 - maybe improving matrices and slices;
 - maybe improving the data parallelism.
 Plus a lot of smaller details to fix, add or improve. I have surely missed
 something.


I believe that what D really needs is a complete formal specification of the
language grammar and semantics. Last I heard, there wasn't any.

Just my two cents.


there should be one standard library,<


 
 I don't agree, I'd like to have both Phobos and Tango at the same time,
 and useful for different purposes, like I have both STL and Boost (among
 other things, like Qt) installed with the C++ compiler.


There would seem to be a difference. Boost was designed to complement the
STL. Boost does not offer features that the STL already possesses.

As I understand it, Tango and Phobos both try to be the one and only D
standard library. Perhaps if the two teams sat down together, they could
design one terrific library. But who has the time?

I agree with the Qt analogy. I use it for designing GUIs. But it annoys me
greatly that they try to reinvent every functionality that's already in the
STL. QString, QList, QEverything. There was simply no need.

Disclaimer: My information on the D specification and Tango/Phobos may be
out of date. I haven't actually programmed in D for years. I mostly lurk in
the newsgroup to read the language design discussions.

-- 
Michiel Helvensteijn
Jul 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:

 I believe that what D really needs is a complete formal specification of the
 language grammar and semantics. Last I heard, there wasn't any.


There is a specification. It isn't complete and there are bugs in it, 
but it constantly gets worked on to improve it. Anyone can submit 
improvements on it to bugzilla.

The lack of a 100% specification has never hindered any language I can 
think of from attaining wide use. What mattered there was that the 
language solved the problems that needed solving.
Jul 11 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:


 I believe that what D really needs is a complete formal specification of
 the language grammar and semantics. Last I heard, there wasn't any.


 
 There is a specification. It isn't complete and there are bugs in it,
 but it constantly gets worked on to improve it. Anyone can submit
 improvements on it to bugzilla.
 
 The lack of a 100% specification has never hindered any language I can
 think of from attaining wide use. What mattered there was that the
 language solved the problems that needed solving.


I'm not sure. You may be right.

But in my opinion, the language specification should define the language,
whereas any single compiler should merely implement it. It looks like D
works the other way around.

The D website offers a reference manual for the general workings of D. It
gives examples. Most of it is explained clearly. But it's not a formal
specification. Words are very imprecise.

For example, from the MulExpression sections of D (1.0 and 2.0):

----------
For integral operands, the *, /, and %  correspond to multiply, divide,
and modulus operations. For multiply, overflows are ignored and simply
chopped to fit into the integral type. If the right operand of divide or
modulus operators is 0, an Exception is thrown.
----------

What does "chopped to fit the integral type" mean? What if it's a
multiplication between two differently sized integral types?

And how does D handle integer division when one or both of the operands are
negative? Does it use truncated division, Euclidean division, floored
division? I can't tell by the modulo operator, since it is implementation
defined for negative operands (which seems like a strange decision, since
this makes modulo utterly unreliable in those cases).

---------- (continued)
For integral operands of the % operator, the sign of the result is
positive if the operands are positive, otherwise the sign of the result is
implementation defined.
----------

I believe you want "non-negative" there.

See what I mean? When you get down to the details, the reader is left
guessing, because formal semantics should be given in math, not in English.
That's how compiler writers know how to implement their compiler.

I can understand that when you start designing a programming language, you
write the compiler and document the language from there. But I believe a
language as far along as D should not be working that way anymore.

-- 
Michiel Helvensteijn
Jul 11 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Michiel Helvensteijn wrote:


 What does "chopped to fit the integral type" mean? What if it's a
 multiplication between two differently sized integral types?


I'm sorry. I missed the first sentence of that section, which explains this
part of it nicely:

----------
They undergo integral promotions, and then are brought to a common type
using the usual arithmetic conversions.
----------

But the rest of my example stands.

-- 
Michiel Helvensteijn
Jul 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:

 But the rest of my example stands.



I agree with you that it should be better. I just don't agree with it 
being a showstopper.

I invite you to contribute spec corrections to the examples you pointed out.
Jul 11 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:

 Michiel Helvensteijn wrote:

 But the rest of my example stands.


 
 
 I agree with you that it should be better. I just don't agree with it
 being a showstopper.
 
 I invite you to contribute spec corrections to the examples you pointed
 out.


Said corrections to preferably be submitted through bugzilla so they don't get
lost.
Jul 11 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:

 Walter Bright wrote:

 Michiel Helvensteijn wrote:

 But the rest of my example stands.


 I agree with you that it should be better. I just don't agree with it
 being a showstopper.

 I invite you to contribute spec corrections to the examples you pointed
 out.


 
 Said corrections to preferably be submitted through bugzilla so they don't get
lost.


Yes, absolutely. I should have mentioned that.
Jul 11 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:


 I agree with you that it should be better. I just don't agree with it
 being a showstopper.


You know that the D Wikipedia article states: "The official compiler by
Walter Bright defines the language itself."?

In other words, every bug in DMD is really a feature of the language. Until
you fix it. That kind of permanent instability may be part of the reason
people have been so negative around here lately.


 I invite you to contribute spec corrections to the examples you pointed
 out.


I will file those corrections. However, the MulExpression thing was only an
example. The first one I checked, too. The mentality behind "compiler
first, specification later" just seems wrong to me. And that's not
something I can report to bugzilla (or can I).

By the way, what kind of integer division *does* D use?

-- 
Michiel Helvensteijn
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:

 Walter Bright wrote:
 

 I agree with you that it should be better. I just don't agree with it
 being a showstopper.


 
 You know that the D Wikipedia article states: "The official compiler by
 Walter Bright defines the language itself."?


That's often the way many successful languages are. They only get formal 
standards for them written after they become mainstream, not before.



 In other words, every bug in DMD is really a feature of the language. Until
 you fix it. That kind of permanent instability may be part of the reason
 people have been so negative around here lately.


I don't agree with that characterization. Bugs get reported to bugzilla, 
and get fixed in a regular cycle.



 I invite you to contribute spec corrections to the examples you pointed
 out.


 
 I will file those corrections.


Thank you, I look forward to it.



 However, the MulExpression thing was only an
 example. The first one I checked, too. The mentality behind "compiler
 first, specification later" just seems wrong to me. And that's not
 something I can report to bugzilla (or can I).
 
 By the way, what kind of integer division *does* D use?


To be frank, it is what the x86 DIV instruction does. But I agree that 
the modulus should be defined, regardless of whether that makes it less 
efficient on some machines.
Jul 12 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:


 In other words, every bug in DMD is really a feature of the language.
 Until you fix it. That kind of permanent instability may be part of the
 reason people have been so negative around here lately.


 
 I don't agree with that characterization. Bugs get reported to bugzilla,
 and get fixed in a regular cycle.


Sure they do. But if it's really true that the DMD implementation *is* the D
language specification, any bug in DMD would also be part of that
specification. And as the compiler changes, so does the spec. It's the
danger of that approach.


 I will file those corrections.


 
 Thank you, I look forward to it.


Issue 3165, Issue 3166.


 By the way, what kind of integer division *does* D use?


 
 To be frank, it is what the x86 DIV instruction does.


After a quick Google search, it would seem DIV is the x86 "unsigned divide"
instruction. Are you sure you aren't using IDIV ("signed divide") for
negative operands? If not, you'd actually be interpreting 2's complement
signed ints as unsigned ints. (And surely such a thing would have been
noticed before now?)


 But I agree that 
 the modulus should be defined, regardless of whether that makes it less
 efficient on some machines.


Good. Make sure that your divide operation and your modulo operation are
consistent. The following identity should hold:

if  a / n = q
and a % n = r

a = q*n + r

-- 
Michiel Helvensteijn
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:

 Walter Bright wrote:
 

 In other words, every bug in DMD is really a feature of the language.
 Until you fix it. That kind of permanent instability may be part of the
 reason people have been so negative around here lately.


 I don't agree with that characterization. Bugs get reported to bugzilla,
 and get fixed in a regular cycle.


 
 Sure they do. But if it's really true that the DMD implementation *is* the D
 language specification, any bug in DMD would also be part of that
 specification. And as the compiler changes, so does the spec. It's the
 danger of that approach.


Looking at the kinds of issues reported in bugzilla makes it pretty 
plain that D users well understand the difference between a bug and a 
problem with the specification. I don't believe there is any danger 
there. Nobody is going to mistake a compiler crash, for example, as 
specified behavior.



 

 I will file those corrections.


 Thank you, I look forward to it.


 
 Issue 3165, Issue 3166.


Thank you.


 By the way, what kind of integer division *does* D use?


 To be frank, it is what the x86 DIV instruction does.


 After a quick Google search, it would seem DIV is the x86 "unsigned divide"
 instruction. Are you sure you aren't using IDIV ("signed divide") for
 negative operands? If not, you'd actually be interpreting 2's complement
 signed ints as unsigned ints. (And surely such a thing would have been
 noticed before now?)


If there's any question about it, you can do a quick test and check what 
the compiler generates with obj2asm. If it wasn't doing things 
correctly, you bet people would have noticed by now. A divide that 
doesn't work is going to be very, very obvious.



 But I agree that 
 the modulus should be defined, regardless of whether that makes it less
 efficient on some machines.


 
 Good. Make sure that your divide operation and your modulo operation are
 consistent. The following identity should hold:
 
 if  a / n = q
 and a % n = r
 
 a = q*n + r
Jul 12 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:

 If there's any question about it, you can do a quick test and check what
 the compiler generates with obj2asm. If it wasn't doing things
 correctly, you bet people would have noticed by now. A divide that
 doesn't work is going to be very, very obvious.


Actually I suspect that integer division with negative values is rare
enough that a problem might escape notice for some time.

Python uses floor division, which is 99% of the time the type of
division I want.  C++ uses truncating division, which is almost never
what I want.  D does not specify the type of division used, although if
it uses IDIV then it uses truncating division.  Result: in C++ (and D) I
use my own library function to perform floor division instead of relying
on the built-in division operator.  Signed integer division never gets
tested for negative values.


-- 
Rainer Deyke - rainerd eldwood.com
Jul 12 2009
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Rainer Deyke wrote:


 Actually I suspect that integer division with negative values is rare
 enough that a problem might escape notice for some time.


Yep. It's possible. I suggest someone tests this. I don't have a D compiler
installed, and I don't really have time for this.


 floor division, which is 99% of the time the type of division I want.


Agreed. I'm using floored division in my new programming language. The
quotient rounds towards negative infinity and the result of the mod
operation has the same sign as the divisor.

However, it seems D prides itself on its speed. And since truncated division
is implemented by the hardware, D will probably use that. And that's
acceptable, as long as it's guaranteed (predictable).

-- 
Michiel Helvensteijn
Jul 12 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Michiel Helvensteijn wrote:

 Rainer Deyke wrote:
 

 Actually I suspect that integer division with negative values is rare
 enough that a problem might escape notice for some time.


 
 Yep. It's possible. I suggest someone tests this. I don't have a D compiler
 installed, and I don't really have time for this.
 

 floor division, which is 99% of the time the type of division I want.


 
 Agreed. I'm using floored division in my new programming language. The
 quotient rounds towards negative infinity and the result of the mod
 operation has the same sign as the divisor.
 
 However, it seems D prides itself on its speed. And since truncated division
 is implemented by the hardware, D will probably use that. And that's
 acceptable, as long as it's guaranteed (predictable).


My personal bug-bear is that D inherited C's insane % behaviour.  I had
this cause a really horrible bug in my simulator where if you set the
virtual date to before the epoch (which you would do in the course of
simulating historical events), the scheduling system went completely
bananas.

Took ages to find that one because I'd been testing dates post-epoch.
Jul 12 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Keep:

 My personal bug-bear is that D inherited C's insane % behaviour.


I too don't like that %.
Is this something that can be fixed in D?

Bye,
bearophile
Jul 12 2009
next sibling parent BCS <none anon.com> writes:
Hello bearophile,


 Daniel Keep:
 

 My personal bug-bear is that D inherited C's insane % behaviour.
 


 I too don't like that %.
 Is this something that can be fixed in D?
 Bye,
 bearophile


Short of overflow detection (and the overhead that causes) I think this is 
an issue inherent to discreet systems (a.k.a. all computer systems) that 
we just have to live with.
Jul 12 2009
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
bearophile wrote:

 Daniel Keep:

 My personal bug-bear is that D inherited C's insane % behaviour.


 
 I too don't like that %.
 Is this something that can be fixed in D?
 
 Bye,
 bearophile


No, because that would mean having valid C code which has different
semantics in D.

BCS wrote:

 Short of overflow detection (and the overhead that causes) I think
 this is an issue inherent to discreet systems (a.k.a. all computer
 systems) that we just have to live with.


I was referring to what happens when you have a%b and a is negative.
Every sane language I've used ensures the result is 0<=x<b, whereas C
doesn't.

*grumbles*
Jul 12 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:

 I don't have a D compiler
 installed, and I don't really have time for this.


Thanks to Ary, there's now a one click installer for Windows:

http://ftp.digitalmars.com/dinstaller.exe
Jul 12 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Michiel Helvensteijn wrote:

 I don't have a D compiler
 installed, and I don't really have time for this.


 
 Thanks to Ary, there's now a one click installer for Windows:
 
 http://ftp.digitalmars.com/dinstaller.exe


Awesome! Is everything automated such that whenever you release the 
installer will be in good shape?

Andrei
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Is everything automated such that whenever you release the 
 installer will be in good shape?


Of course not!
Jul 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Is everything automated such that whenever you release the installer 
 will be in good shape?


 
 Of course not!


What steps do we need to take to automate the process?

Andrei
Jul 12 2009
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, Jul 12, 2009 at 03:28:43PM -0500, Andrei Alexandrescu wrote:

 Walter Bright wrote:

Andrei Alexandrescu wrote:

Is everything automated such that whenever you release the installer 
will be in good shape?


Of course not!


 
 What steps do we need to take to automate the process?
 
 Andrei



Here's an idea: make it download d1-latest.zip* and d2-latest.zip. Then,
on the server, make those names redirect to whatever the latest actually is,
using a symlink or a HTTP redirect header.

* Or .php, see below.

My preference would be the HTTP redirect, so you see the correct filename
before the download begins; you could differentiate between the different
versions.

It looks like you have PHP installed on the Digital Mars .com server. This
could be done in just a few lines of that language:

=====
<?php
	header("Location: dmd-1.x.zip");
?>
=====
Then, instead of fetching d1-latest.zip, fetch d1-latest.php.



The script that publishes the new release could them simply overwrite those
php files telling the new file location.


I put it up on my server so you can see what it is like to the user:

http://arsdnet.net/latest.php

Notice how it prompts you to download file.zip automatically.



Granted, going with this, the installer's downloader would need to
understand the http location header, but if you are using a http library,
it probably already does. And if not, it isn't terribly difficult to code
it up yourself.


This shouldn't require much changes to the way things are done, and would
offer a nice generic place for people to fetch the new things.


-- 
Adam D. Ruppe
http://arsdnet.net
Jul 12 2009
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright escribió:

 Michiel Helvensteijn wrote:

 I don't have a D compiler
 installed, and I don't really have time for this.


 
 Thanks to Ary, there's now a one click installer for Windows:
 
 http://ftp.digitalmars.com/dinstaller.exe


Very nice!

You took the time to modify it to download both D1 and D2, and also dmd. :-)

Just one thing: when you select both D1 and D2, both directories are 
added to the path and when you execute dmd it defaults to the first one 
found (D1). How could this be solved?
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:

 You took the time to modify it to download both D1 and D2, and also dmd. 
 :-)
 
 Just one thing: when you select both D1 and D2, both directories are 
 added to the path and when you execute dmd it defaults to the first one 
 found (D1). How could this be solved?


I don't know. I also didn't figure out how to set the menu shortcuts 
properly depending on what was or was not installed. I was hoping you 
could help!
Jul 12 2009
next sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:

 Ary Borenszweig wrote:

 You took the time to modify it to download both D1 and D2, and also
 dmd. :-)

 Just one thing: when you select both D1 and D2, both directories are
 added to the path and when you execute dmd it defaults to the first
 one found (D1). How could this be solved?


 
 I don't know. I also didn't figure out how to set the menu shortcuts
 properly depending on what was or was not installed. I was hoping you
 could help!


Easy suggestion.. rename dmd 2's executable to dmd2.
Jul 12 2009
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, Jul 12, 2009 at 01:30:26PM -0700, Walter Bright wrote:

 Ary Borenszweig wrote:

You took the time to modify it to download both D1 and D2, and also dmd. 
:-)

Just one thing: when you select both D1 and D2, both directories are 
added to the path and when you execute dmd it defaults to the first one 
found (D1). How could this be solved?


 
 I don't know. I also didn't figure out how to set the menu shortcuts 
 properly depending on what was or was not installed. I was hoping you 
 could help!


The Windows SDK uses a little script and an environment variable to pick
your platform. You can do (I forget the actual syntax...):

setenv /x64
make

And it builds you the 64 bit version. Or

setenv /XP

And it sets everything up to target Windows XP.




Perhaps the D installer could set up something similar. It could be very simple:

dversion /d2
dmd

And you get dmd for D2.

Then

dversion /d1
dmd

And you get D1.


Indeed, this could be taken to another level:

dversion /d2  will use the newest version of dmd2 available, but also

dversion /v2.013 will specifically use dmd 2.013.



All dversion does is adjust the PATH to point at the right folder. It
could be a pretty simple script (especially if you limit it to just the /d1
and /d2 switches).





-- 
Adam D. Ruppe
http://arsdnet.net
Jul 12 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Adam D. Ruppe wrote:

 (stuff)


Urgh.  I *hate* programs that screw with my PATH.

Personally, I've found that the simplest way to solve the multiple
compiler problem is to just shove them all in different directories.
AFAIK, dmd works just fine with relative directories, so it's not like
you HAVE to have the compiler on the PATH.

For example, my system has DMD 1.035 + Tango 99.somethingorother as the
"default" compiler (it's the one on PATH).  It's in
\bin\dmd\dmd-default.  Then I have the following other directories in
\bin\dmd:

* dmd-1.035
* dmd-1.042-tango
* dmd-1.046-tango
* dmd-2.023
* dmd-2.025
* dmd-2.026
* dmd-2.028
* dmd-2.029
* dmd-2.030
* dmd-custom (was playing around with compiler patches)
* tango-trunk

(Odd that I have so many 2.x compilers, and yet I don't use them... :P)

Compiling with a particular version is pretty easy; instead of typing
'dmd BLAH', I use '\bin\dmd\dmd-x.yyy\bin\dmd BLAH'.  I also have
rebuild set up to have most of these available as separate compilers.

So, for example, when I was testing a project with 1.046+Tango trunk, I
went from building like so:


 dsss build


to this:


 dsss build -dc=tango-trunk


The only time this system doesn't work is building Tango which doesn't
provide any way to override which compiler gets used.  But then I solve
that with a batch file that just shoves the appropriate compiler on to
the front of the PATH.

Incidentally, thanks for making DMD work like this, Walter.  I have a
big, fairly important project that has its own private copy of the
entire toolchain so it's compiler version is stable.  Absolutely
indispensable.  :D
Jul 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:

 Incidentally, thanks for making DMD work like this, Walter.  I have a
 big, fairly important project that has its own private copy of the
 entire toolchain so it's compiler version is stable.  Absolutely
 indispensable.  :D


A long time ago, I got sick of tools that required environment variables 
to be set.
Jul 13 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:


 I don't have a D compiler
 installed, and I don't really have time for this.


 
 Thanks to Ary, there's now a one click installer for Windows:
 
 http://ftp.digitalmars.com/dinstaller.exe


That's nice. But I run Linux.

Walter, surely this test shouldn't take more than a minute for you (or
anyone else with a D compiler installed). Just see what DMD outputs for:

  8  /   3
  8  / (-3)
(-8) /   3
(-8) / (-3)
  8  %   3
  8  % (-3)
(-8) %   3
(-8) % (-3)

If D uses DIV instead if IDIV, this should be immediately visible. In any
case, we will see exactly what kind of division and modulo D uses. You can
compare with the table on the bottom of page 3 of:

http://www.cs.uu.nl/~daan/download/papers/divmodnote.pdf

That's an informative article, by the way.

-- 
Michiel Helvensteijn
Jul 12 2009
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Michiel Helvensteijn wrote:


 Walter, surely this test shouldn't take more than a minute for you (or
 anyone else with a D compiler installed).


Ok, ok. I'll do it. Here's the results:

----------------------------------
import std.stdio;

int main() {
        writefln(8/3);
        writefln(8/(-3));
        writefln((-8)/3);
        writefln((-8)/(-3));
        writefln(8%3);
        writefln(8%(-3));
        writefln((-8)%3);
        writefln((-8)%(-3));

        return 0;
}
----------------------------------

outputs the following

----------
2
-2
-2
2
2
2
-2
-2
----------

So DMD uses truncated division. The quotient rounds towards zero and the
remainder has the same sign as the dividend. I've updated issue 3165 with
this information.

Hope that helps.

-- 
Michiel Helvensteijn
Jul 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michiel Helvensteijn wrote:

 Michiel Helvensteijn wrote:
 

 Walter, surely this test shouldn't take more than a minute for you (or
 anyone else with a D compiler installed).


 
 Ok, ok. I'll do it. Here's the results:
 
 ----------------------------------
 import std.stdio;
 
 int main() {
         writefln(8/3);
         writefln(8/(-3));
         writefln((-8)/3);
         writefln((-8)/(-3));
         writefln(8%3);
         writefln(8%(-3));
         writefln((-8)%3);
         writefln((-8)%(-3));
 
         return 0;
 }
 ----------------------------------
 
 outputs the following
 
 ----------
 2
 -2
 -2
 2
 2
 2
 -2
 -2
 ----------
 
 So DMD uses truncated division. The quotient rounds towards zero and the
 remainder has the same sign as the dividend. I've updated issue 3165 with
 this information.
 
 Hope that helps.



Thanks, Michiel. Here's what I have in TDPL. Is it 100% in sync with you?

=======================================
The  multiplicative expressions  are multiplication  (\ccbox{a  * b}),
division  (\ccbox{a  / b}),  and  remainder  (\ccbox{a  \% b}).   They
operate on numeric types only. The  result type is same as the type of
\ccbox{true ? a : b}.

If~ b   is  zero in  \ccbox{a  /  b} or  \ccbox{a  \%  b}, a  hardware
exception   is  thrown.    The  sign\footnote{Sign,   not  signedness,
    i.e.,~the sign of  the actual value.}  of \ccbox{a  \% b} is always
the same as  the sign of~ a .  That is, \ccbox{a \%  b} is the closest
number to  zero of the same sign  of~ a  that must be  added to~ a  to
make it divisible by~ b .  For  example, \ccbox{-5 \% 2} and \ccbox{-5
    \% -2} both yield~\cc{-1}.

\dee\ also defines modulus for  floating-point numbers in the same way
as the  IEEE~754  standard.  When  at least one  of  a   and  b   is a
floating-point value in \cc{a \%  b}, the result is the floating-point
number  r  satisfying the relation \cc{a = b * n + r}, where  n  is an
integer\footnote{``integer'' in  the mathematical sense  here} and  r 
is a positive number less than  b 's absolute value.
=======================================


Thanks,

Andrei
Jul 12 2009
next sibling parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Andrei Alexandrescu wrote:


 Thanks, Michiel. Here's what I have in TDPL. Is it 100% in sync with you?
 
 =======================================
 ...
 
 If~ b   is  zero in  \ccbox{a  /  b} or  \ccbox{a  \%  b}, a  hardware
 exception   is  thrown.    The  sign\footnote{Sign,   not  signedness,
 i.e.,~the sign of  the actual value.}  of \ccbox{a  \% b} is always
 the same as  the sign of~ a .  That is, \ccbox{a \%  b} is the closest
 number to  zero of the same sign  of~ a 


Now that I read it again (the last words there), this is not completely
accurate. I know I made the same mistake myself just now, but the remainder
has not necessarily the same sign as 'a', since it may be zero, which is
signless.

Of course, such a triviality won't hinder anyone's understanding, but you
may as well be accurate, no?

Some thing like "same sign as~ a  (or zero)", perhaps? (Also note the
word 'as' instead of 'of', which is not strictly grammatically correct.)


 that must be  added to~ a  to 
 make it divisible by~ b .  For  example, \ccbox{-5 \% 2} and \ccbox{-5
 \% -2} both yield~\cc{-1}.


The rest of the information is accurate, but you still neglect to mention
the type of division. D uses truncated division. The quotient rounds
towards zero. In other words, it cuts off the fractional part of the
result.

Good luck with your book.

-- 
Michiel Helvensteijn
Jul 12 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Andrei Alexandrescu wrote:


 \dee\ also defines modulus for  floating-point numbers in the same way
 as the  IEEE~754  standard.  When  at least one  of  a   and  b   is a
 floating-point value in \cc{a \%  b}, the result is the floating-point
 number  r  satisfying the relation \cc{a = b * n + r}, where  n  is an
 integer\footnote{``integer'' in  the mathematical sense  here} and  r 
 is a positive number less than  b 's absolute value.


Oh, about this part. I left it out because it's not about integer division,
but while I'm at it anyway.

I believe you wanted the word "non-negative" there, instead of "positive".
However, I just ran the following test:

----------------------------
writefln(5.0%2.0);
writefln(5.0%(-2.0));
writefln((-5.0)%2.0);
writefln((-5.0)%(-2.0));
----------------------------

it outputs:

----------
1
1
-1
-1
----------

So the remainder can still become negative, it seems. Same as with integer
modulo. I would expect this consistency, but your paragraph there says
something different.

-- 
Michiel Helvensteijn
Jul 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michiel Helvensteijn wrote:

 Andrei Alexandrescu wrote:
 

 \dee\ also defines modulus for  floating-point numbers in the same way
 as the  IEEE~754  standard.  When  at least one  of  a   and  b   is a
 floating-point value in \cc{a \%  b}, the result is the floating-point
 number  r  satisfying the relation \cc{a = b * n + r}, where  n  is an
 integer\footnote{``integer'' in  the mathematical sense  here} and  r 
 is a positive number less than  b 's absolute value.


 
 Oh, about this part. I left it out because it's not about integer division,
 but while I'm at it anyway.
 
 I believe you wanted the word "non-negative" there, instead of "positive".
 However, I just ran the following test:
 
 ----------------------------
 writefln(5.0%2.0);
 writefln(5.0%(-2.0));
 writefln((-5.0)%2.0);
 writefln((-5.0)%(-2.0));
 ----------------------------
 
 it outputs:
 
 ----------
 1
 1
 -1
 -1
 ----------
 
 So the remainder can still become negative, it seems. Same as with integer
 modulo. I would expect this consistency, but your paragraph there says
 something different.
 


Walter?

Andrei
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Walter?


D % for floating point arguments does what the C99 fmod function does:


 Description
 The fmod functions compute the floating-point remainder of x/y.
 Returns
 The fmod functions return the value x - ny, for some integer n such that, if y
is nonzero,
 the result has the same sign as x and magnitude less than the magnitude of y.
If y is zero,
 whether a domain error occurs or the fmod functions return zero is
implementation-defined.
Jul 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Walter?


 
 D % for floating point arguments does what the C99 fmod function does:
 

 Description
 The fmod functions compute the floating-point remainder of x/y.
 Returns
 The fmod functions return the value x - ny, for some integer n such 
 that, if y is nonzero,
 the result has the same sign as x and magnitude less than the 
 magnitude of y. If y is zero,
 whether a domain error occurs or the fmod functions return zero is 
 implementation-defined.




Great. Could you please now replace the implementation-defined part with 
something well-defined and appropriate? Thanks.

Andrei
Jul 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:

 In any case, we will see exactly what kind of division and modulo D uses.


Given the code:

void foo()
{
     int x,y,z;
     x = y / z;
     x = y % z;

     uint ux,uy,uz;  // unsigned for C
     ux = uy / uz;
     ux = uy % ux;
}

dmd produces:

                 enter   010h,0
                 xor     EAX,EAX
                 mov     -010h[EBP],EAX
                 mov     -0Ch[EBP],EAX
                 mov     EAX,-010h[EBP]
                 cdq
                 idiv    dword ptr -0Ch[EBP]
                 mov     EAX,-010h[EBP]
                 cdq
                 idiv    dword ptr -0Ch[EBP]
                 xor     ECX,ECX
                 mov     -8[EBP],ECX
                 mov     -4[EBP],ECX
                 mov     EAX,-4[EBP]
                 xor     EDX,EDX
                 div     ECX
                 mov     -8[EBP],EAX
                 mov     EAX,-4[EBP]
                 xor     EDX,EDX
                 div     dword ptr -8[EBP]
                 mov     -8[EBP],EDX
                 leave
                 ret

For comparison, gcc produces:

                 push    EBP
                 mov     EBP,ESP
                 sub     ESP,038h
                 mov     EAX,-8[EBP]
                 mov     -034h[EBP],EAX
                 mov     EDX,-034h[EBP]
                 mov     EAX,EDX
                 sar     EDX,01Fh
                 idiv    dword ptr -0Ch[EBP]
                 mov     -4[EBP],EAX
                 mov     EDX,-8[EBP]
                 mov     EAX,EDX
                 sar     EDX,01Fh
                 idiv    dword ptr -0Ch[EBP]
                 mov     -4[EBP],EDX
                 mov     EAX,-014h[EBP]
                 mov     EDX,0
                 div     dword ptr -018h[EBP]
                 mov     -010h[EBP],EAX
                 mov     EAX,-014h[EBP]
                 mov     -038h[EBP],EAX
                 mov     EAX,-038h[EBP]
                 mov     EDX,0
                 div     dword ptr -010h[EBP]
                 mov     -010h[EBP],EDX
                 leave
                 ret

Producing the same results as the corresponding C compiler does is quite 
deliberate. I'd like to emphasize that the code generator has been in 
use for 25 years for several hundred thousand users, and it is 
incredibly unlikely that nobody would notice if it is getting basic 
integer arithmetic wrong. If you'd like to write up a formal definition 
that can be inserted into the D specification, that would be great.
Jul 12 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:

 For comparison, gcc produces:


I think you'll find that VC, DMC, DMC++, g++, Intel C++, Borland C++, 
Watcom, etc., etc., all produce the same results for x86 on Linux, 
Windows, Mac OSX, FreeBSD, etc.
Jul 12 2009
prev sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:


 I'd like to emphasize that the code generator has been in
 use for 25 years for several hundred thousand users, and it is
 incredibly unlikely that nobody would notice if it is getting basic
 integer arithmetic wrong.


I didn't think the compiler would be wrong. I was just replying to your
statement that D does what x86 DIV does (you didn't mention IDIV; hence my
initial confusion).


 If you'd like to write up a formal definition 
 that can be inserted into the D specification, that would be great.


I've given an unambiguous description of D division and modulus in another
subthread here. I've also updated issue 3165 with the information. You can
use that.

-- 
Michiel Helvensteijn
Jul 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Michiel Helvensteijn wrote:

 Walter Bright wrote:
 

 I'd like to emphasize that the code generator has been in
 use for 25 years for several hundred thousand users, and it is
 incredibly unlikely that nobody would notice if it is getting basic
 integer arithmetic wrong.


 
 I didn't think the compiler would be wrong. I was just replying to your
 statement that D does what x86 DIV does (you didn't mention IDIV; hence my
 initial confusion).


No problem, my mistake.



 If you'd like to write up a formal definition 
 that can be inserted into the D specification, that would be great.


 
 I've given an unambiguous description of D division and modulus in another
 subthread here. I've also updated issue 3165 with the information. You can
 use that.


Thank you, this is valuable. I appreciate it.
Jul 12 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Michiel Helvensteijn:

 Walter, surely this test shouldn't take more than a minute for you (or
 anyone else with a D compiler installed). Just see what DMD outputs for:
 
   8  /   3
   8  / (-3)
 (-8) /   3
 (-8) / (-3)
   8  %   3
   8  % (-3)
 (-8) %   3
 (-8) % (-3)


You don't know codepad.org :-)

D version:
http://codepad.org/Mbi9HBjz

void main() {
    writefln(   8  /   3);
    writefln(   8  / (-3));
    writefln( (-8) /   3);
    writefln( (-8) / (-3));
    writefln(   8  %   3);
    writefln(   8  % (-3));
    writefln( (-8) %   3);
    writefln( (-8) % (-3));
}

D output:
2
-2
-2
2
2
2
-2
-2

-------------

Python version:
http://codepad.org/Mbi9HBjz

print   8  //   3
print   8  // (-3)
print (-8) //   3
print (-8) // (-3)
print   8  %   3
print   8  % (-3)
print (-8) %   3
print (-8) % (-3)

Python output:

2
-3
-3
2
2
-1
1
-2

---------------------

BCS:


Short of overflow detection (and the overhead that causes) I think this is an
issue inherent to discreet systems (a.k.a. all computer systems) that we just
have to live with.<


I don't understand what's the purpose of overflow detection in this context.
Are those differences between the D and Python output caused by overflows?

Bye and thank you,
bearophile
Jul 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Python output:


The result of / depends on which version of Python you're using:

http://www.python.org/doc/2.2.3/whatsnew/node7.html
Jul 12 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 The result of / depends on which version of Python you're using:
 http://www.python.org/doc/2.2.3/whatsnew/node7.html


I have used Python 2.6, and the numbers I have shown you are correct for Python
3.1 too.
I don't like how the % behaves in C when there can be negative numbers.

Bye,
bearophile
Jul 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Walter Bright:

 The result of / depends on which version of Python you're using:
 http://www.python.org/doc/2.2.3/whatsnew/node7.html


 
 I have used Python 2.6, and the numbers I have shown you are correct for
Python 3.1 too.
 I don't like how the % behaves in C when there can be negative numbers.


According to the python pep, the integer / divide semantics changed from 
"C" style to match what the floating point / does. While this makes 
sense for a language that is typeless, it doesn't work for D because:

1. it would cause D code to silently produce different results than the 
corresponding C/C++ code. This is extremely important, as I guarantee 
that when someone new tries porting existing C code to D, and it doesn't 
work, their conclusion will not be "perhaps I should recode the / 
expression", it will be "D sux". Note that there is no way the compiler 
could issue a warning about this as it cannot determine a dependency on 
the rounding method.

2. it is slower than the current method.
Jul 12 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 bearophile wrote:

 Walter Bright:

 The result of / depends on which version of Python you're using:
 http://www.python.org/doc/2.2.3/whatsnew/node7.html


 I have used Python 2.6, and the numbers I have shown you are correct 
 for Python 3.1 too.
 I don't like how the % behaves in C when there can be negative numbers.


 
 According to the python pep, the integer / divide semantics changed from 
 "C" style to match what the floating point / does. While this makes 
 sense for a language that is typeless, it doesn't work for D because:
 
 1. it would cause D code to silently produce different results than the 
 corresponding C/C++ code. This is extremely important, as I guarantee 
 that when someone new tries porting existing C code to D, and it doesn't 
 work, their conclusion will not be "perhaps I should recode the / 
 expression", it will be "D sux". Note that there is no way the compiler 
 could issue a warning about this as it cannot determine a dependency on 
 the rounding method.


But C gives the implementation leeway to define '/' as they find fit. 
This is useless because it makes it difficult to write portable code. We 
must improve on that.


 2. it is slower than the current method.


We want something well-defined. I agree to adopt the semantics of IDIV 
but we must understand that those might be slower on other machines.


Andrei
Jul 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 1. it would cause D code to silently produce different results than 
 the corresponding C/C++ code. This is extremely important, as I 
 guarantee that when someone new tries porting existing C code to D, 
 and it doesn't work, their conclusion will not be "perhaps I should 
 recode the / expression", it will be "D sux". Note that there is no 
 way the compiler could issue a warning about this as it cannot 
 determine a dependency on the rounding method.


 
 But C gives the implementation leeway to define '/' as they find fit. 
 This is useless because it makes it difficult to write portable code. We 
 must improve on that.


Right, but the de-facto behavior for C compilers is do behave as D 
currently does.


 2. it is slower than the current method.


 
 We want something well-defined. I agree to adopt the semantics of IDIV 
 but we must understand that those might be slower on other machines.


Yes - not only do I think that is ok, but CPUs have been for a long time 
designed to accommodate C, and the de-facto way C does things, including 
the divide. I don't expect this to change, so I don't expect a penalty 
on some future processor because of it.
Jul 12 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:

 According to the python pep, the integer / divide semantics changed from
 "C" style to match what the floating point / does. While this makes
 sense for a language that is typeless, it doesn't work for D because:


The PEP is wrong (which underlines the need for accurate documentation,
I guess).  Integer division in Python uses floor division instead of
truncated division, and to the best of my knowledge has always used
floor division.  This is the result of a deliberate choice.  Floor
division is usually technically superior to truncated division

The operator for integer division in Python has recently changed from
'/' to '//', but Python still has an integer division operator and this
operator still uses floor division.


-- 
Rainer Deyke - rainerd eldwood.com
Jul 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Rainer Deyke wrote:

 Walter Bright wrote:

 According to the python pep, the integer / divide semantics changed from
 "C" style to match what the floating point / does. While this makes
 sense for a language that is typeless, it doesn't work for D because:


 
 The PEP is wrong (which underlines the need for accurate documentation,
 I guess).  Integer division in Python uses floor division instead of
 truncated division, and to the best of my knowledge has always used
 floor division.  This is the result of a deliberate choice.  Floor
 division is usually technically superior to truncated division
 
 The operator for integer division in Python has recently changed from
 '/' to '//', but Python still has an integer division operator and this
 operator still uses floor division.


If Python always used floor division, why did it add a // operator that 
does exactly the same thing as / ?


http://www.python.org/doc/2.2.3/whatsnew/node7.html
Jul 12 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 If Python always used floor division, why did it add a // operator that 
 does exactly the same thing as / ?


See this (Python 2.6):


 500 / 30






16

 500 // 30






16

 500 / 30.0






16.666666666666668

 500 // 30.0






16.0

 from __future__ import division
 500 / 30






16.666666666666668

 500 // 30






16

 500 / 30.0






16.666666666666668

 500 // 30.0






16.0

// Always return a number with no fractional part.

That "future" is the default in Python 3+

Bye,
bearophile
Jul 12 2009
parent bearophile <bearophileHUGS lycos.com> writes:
bearophile:

 That "future" is the default in Python 3+


So I was wrong in the precedent post, sorry.

Bye,
bearophile
Jul 12 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, Jul 12, 2009 at 5:36 PM, Walter
Bright<newshound1 digitalmars.com> wrote:

 Rainer Deyke wrote:

 Walter Bright wrote:

 According to the python pep, the integer / divide semantics changed fro=






m

 "C" style to match what the floating point / does. While this makes
 sense for a language that is typeless, it doesn't work for D because:


 The PEP is wrong (which underlines the need for accurate documentation,
 I guess). =A0Integer division in Python uses floor division instead of
 truncated division, and to the best of my knowledge has always used
 floor division. =A0This is the result of a deliberate choice. =A0Floor
 division is usually technically superior to truncated division

 The operator for integer division in Python has recently changed from
 '/' to '//', but Python still has an integer division operator and this
 operator still uses floor division.


 If Python always used floor division, why did it add a // operator that d=


oes

 exactly the same thing as / ?


 http://www.python.org/doc/2.2.3/whatsnew/node7.html


The new // forces integer division.  / now means float division always.

1 // 2   --> 0
1 / 2   --> 0.5

They first introduced // as a synonym for / so people could start
switching over to it, then they changed the behavior of / later.
Python's good at staged introductions of major changes like that.
Makes life a lot easier for developers to keep up.

--bb
Jul 12 2009
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Walter Bright wrote:

 If Python always used floor division, why did it add a // operator that
 does exactly the same thing as / ?


Starting with Python 3.0, 'a / b' returns a float even when both
operands are integers.  'a // b' performs floor division, even if both
operands are floats.  Python now has two division operators, neither of
which has C-style truncation (i.e. round toward zero).

This is explained further in the actual PEP 238 text:
http://www.python.org/dev/peps/pep-0238/


-- 
Rainer Deyke - rainerd eldwood.com
Jul 12 2009
prev sibling parent Jussi Jumppanen <jussij zeusedit.com> writes:
Rainer Deyke Wrote:


 Integer division in Python uses floor division instead of
 truncated division, and to the best of my knowledge has always
 used floor division.  


Based on the results produced by Python 2.6.2 and Python 1.5.1 
this does appear to be the case:

Python Version: 2.6.2 (r262:71600, Jul  1 2009, 22:22:20) [MSC v.1500 32 bit
(Intel)]
  
    8  //   3 = 2
    8  // (-3)= -3
  (-8) //   3 = -3
  (-8) // (-3)= 2
    8  %   3  = 2
    8  % (-3) = -1
  (-8) %   3  = 1
  (-8) % (-3) = -2
  
    8  /   3  = 2
    8  / (-3) = -3
  (-8) /   3  = -3
  (-8) / (-3) = 2
    8  %   3  = 2
    8  % (-3) = -1
  (-8) %   3  = 1
  (-8) % (-3) = -2
  
  

  
    8  /   3  = 2
    8  / (-3) = -3
  (-8) /   3  = -3
  (-8) / (-3) = 2
    8  %   3  = 2
    8  % (-3) = -1
  (-8) %   3  = 1
  (-8) % (-3) = -2

Cheers Jussi

Note: These results where created by running the Zeus/Python 
      script shown below using a very old version of the Zeus 
      and the recent version of Zeus.

import sys
import zeus

def key_macro():
    zeus.screen_update_disable()
    zeus.FileNew()
    zeus.write("Python Version: " + sys.version);













    zeus.write("\n\n")
    zeus.write("  8  /   3  = " + str(  8  /   3 )   + "\n", 0)
    zeus.write("  8  / (-3) = " + str(  8  / (-3))   + "\n", 0)
    zeus.write("(-8) /   3  = " + str((-8) /   3 )   + "\n", 0)
    zeus.write("(-8) / (-3) = " + str((-8) / (-3))   + "\n", 0)
    zeus.write("  8  %   3  = " + str(  8  %   3  )  + "\n", 0)
    zeus.write("  8  % (-3) = " + str(  8  % (-3) )  + "\n", 0)
    zeus.write("(-8) %   3  = " + str((-8) %   3  )  + "\n", 0)
    zeus.write("(-8) % (-3) = " + str((-8) % (-3) )  + "\n", 0)

    zeus.screen_update_enable()
    zeus.screen_update()
Jul 12 2009
prev sibling parent BCS <none anon.com> writes:
Hello bearophile,

 BCS:
 

 Short of overflow detection (and the overhead that causes) I think
 this is an issue inherent to discreet systems (a.k.a. all computer
 systems) that we just have to live with.<
 


 I don't understand what's the purpose of overflow detection in this
 context. Are those differences between the D and Python output caused
 by overflows?
 


After puzzling over that bit of thread for a bit, the only interpretation 
I came up with that seemed logical was that it was referring to integers 
being modulo 2^32: (int.max + 1 == int.min). In rereading it, I'm thinking 
you were talking about something else.
Jul 12 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Rainer Deyke wrote:

 Actually I suspect that integer division with negative values is rare
 enough that a problem might escape notice for some time.


Not for 25 years and a few hundred thousand users.
Jul 12 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Steve Teale wrote:


 D Friends/Enemies,
 
 Looking at the current crop of postings, it seems like people are staying
 off the subject of where D is going (we've had a lot of that lately,
 without any result), and concentrating on less and less important
 particulars.
 
 So we are we doomed, like the Oomigooly bird, to fly around in ever
 decreasing circles, until we eventually disappear up our own asshole?
 
 As per the current fashion, I apologize profusely for any offense I may
 cause to anyone as a result of this message. But we do need to arrive at
 conclusions. D2 should be stabilized and D1 deprecated, there should be
 one standard library, there should be a new linker and object file format,
 and there should be a change made to the acceptable content of the primary
 newsgroup (the learn suggestion is the best we have so far).
 
 Steve


Again, what's up with the doom and gloom people? We just had a very good D 
release, lots of bugs fixed and some lovely new features. Happy days!

You are not asking the right questions I think. There *is* 1 standard 
library for D2 which is phobos and could be complemented with Tango if it  
will be ported to D2. But D1 is stable where D2 is in development and Tango 
the library of choice for many. I see no problems here. 

D2 will be stabilized as planned, current date is set for november this year 
already! (Way too soon, probably). The question is, HOW will it be 
stabilized (D3 backwards compatible with D2?) But come on, take a look at 
the changelog for example to see how fast D is developing, which platforms 
DMD already support, look at LDC becoming awesome, Descent's power, full D 
support in slickedit, GtkD, QtD etc. etc.
Jul 11 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:

 Looking at the current crop of postings, it seems like people are
 staying off the subject of where D is going (we've had a lot of that
 lately, without any result), and concentrating on less and less
 important particulars.


Discussions about the bikeshed colors tend to generate lots of postings 
because they are intellectually easy to participate in. That doesn't 
bother me. What does bother me is that such discussions tend to result 
in people digging in and hardening their positions to the point of 
setting their whole D experience on their particular preferred bikeshed 
color. More than once people have left D over such trivia.

The actual development work that I, Andrei, Don, Sean, etc., engage in, 
however, remains focussed on the long term goals. I think you can see 
this in the regular changelog updates.
Jul 11 2009