Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
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 - rain...@eldwood.com
Re: Oh Dear
bearophile: > That "future" is the default in Python 3+ So I was wrong in the precedent post, sorry. Bye, bearophile
Re: Oh Dear
On Sun, Jul 12, 2009 at 5:36 PM, Walter Bright wrote: > 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 > 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
Re: Oh Dear
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.668 >>> 500 // 30.0 16.0 >>> from __future__ import division >>> 500 / 30 16.668 >>> 500 // 30 16 >>> 500 / 30.0 16.668 >>> 500 // 30.0 16.0 // Always return a number with no fractional part. That "future" is the default in Python 3+ Bye, bearophile
Re: Oh Dear
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
Python Version: 1.5.1 (#0, Sep 11 2002, 21:19:56) [MSC 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
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);
# This only works for 2.6.2
# 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.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()
key_macro() # run the macro
Re: Oh Dear
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
Re: Oh Dear
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 - rain...@eldwood.com
Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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.
Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
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.
Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
Andrei Alexandrescu wrote:
> Thanks, Michiel. Here's what I have in TDPL. Is it 100% in sync with you?
>
> ===
> ...
>
> i...@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 o...@a@. That is, \ccbox{a \% b} is the closest
> number to zero of the same sign ...@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 a...@a@ (or zero)", perhaps? (Also note the
word 'as' instead of 'of', which is not strictly grammatically correct.)
> that must be added t...@a@ to
> make it divisible b...@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
Re: Oh Dear
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.
Re: Oh Dear
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
idivdword ptr -0Ch[EBP]
mov EAX,-010h[EBP]
cdq
idivdword 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:
pushEBP
mov EBP,ESP
sub ESP,038h
mov EAX,-8[EBP]
mov -034h[EBP],EAX
mov EDX,-034h[EBP]
mov EAX,EDX
sar EDX,01Fh
idivdword ptr -0Ch[EBP]
mov -4[EBP],EAX
mov EDX,-8[EBP]
mov EAX,EDX
sar EDX,01Fh
idivdword 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.
Re: Oh Dear
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
Re: Oh Dear
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}.
i...@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 o...@a@. That is, \ccbox{a \% b} is the closest
number to zero of the same sign o...@a@ that must be added t...@a@ to
make it divisible b...@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
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
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: = = 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
Re: Oh Dear
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
Re: Oh Dear
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.
Re: Oh Dear
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!
Re: Oh Dear
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
Re: Oh Dear
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?
Re: Oh Dear
Andrei Alexandrescu wrote: Is everything automated such that whenever you release the installer will be in good shape? Of course not!
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
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.
Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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 - rain...@eldwood.com
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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.
Re: Oh Dear
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.
Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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
Re: Oh Dear
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.
Re: Oh Dear
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.
Re: Oh Dear
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
Re: Oh Dear
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. What exactly do you expect? Replacing C++/C# within the next year?
Re: Oh Dear
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
Re: Oh Dear
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...
Oh Dear
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
