www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Remainder wat

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
Hi,

$ cat test.d
import std.conv;

void main()
{
     uint x = to!uint("1") % 0u;
}
$ rdmd test.d
Floating point exception


-- 
- Alex
Mar 04 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
What's weird about this? Processors raise
an exception when you ask them to divide by
zero.

Perhaps "Floating point exception" is a weird
message to give, but that's something the operating
system does; it is the default signal handler's
message.


I guess it is also a little weird that it didn't
say "test9.d(2): Error: divide by 0".. the to!uint
seems to trick dmd into not realizing what you are
saying. It catches the literal 1 % 0.
Mar 04 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 04/03/2012 20:20, Adam D. Ruppe a écrit :

 What's weird about this? Processors raise
 an exception when you ask them to divide by
 zero.

 Perhaps "Floating point exception" is a weird
 message to give, but that's something the operating
 system does; it is the default signal handler's
 message.



That is the problem. No floating point operation is involved here. And 
if you replace to!uint("1") by just plain old 1, you don't get the same 
message, which is very inconsistent, and counterintuitive.
Mar 04 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 04/03/2012 22:11, Adam D. Ruppe a écrit :

 On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:

 No floating point operation is involved here.



 It is a Linux issue, not a D one.

 Try doing the same thing in C.



OK, now read the other half of the post.
Mar 04 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/04/2012 10:58 PM, deadalnix wrote:

 Le 04/03/2012 22:11, Adam D. Ruppe a écrit :

 On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:

 No floating point operation is involved here.



 It is a Linux issue, not a D one.

 Try doing the same thing in C.



 OK, now read the other half of the post.



I bet he did, but settled to responding to the part that was explicitly 
marked as being 'the problem'.
Mar 04 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 04/03/2012 22:59, Timon Gehr a écrit :

 On 03/04/2012 10:58 PM, deadalnix wrote:

 Le 04/03/2012 22:11, Adam D. Ruppe a écrit :

 On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:

 No floating point operation is involved here.



 It is a Linux issue, not a D one.

 Try doing the same thing in C.



 OK, now read the other half of the post.



 I bet he did, but settled to responding to the part that was explicitly
 marked as being 'the problem'.



You'll find 2 problems, not one.

Problem one is the floating point reference, which is a problem when no 
floating point is involved. This is the counterintuitive part.

Problem two is the inconsistency of behavior. Sometime a divide error is 
triggered and some other a floating point error. This is the 
inconsistent part.
Mar 04 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/04/2012 10:59 PM, Adam D. Ruppe wrote:

 On Sunday, 4 March 2012 at 21:52:15 UTC, deadalnix wrote:

 OK, now read the other half of the post.



 Try reading the second half of my first post.



Presumably it lacks drama (compare "a little weird" to "very 
inconsistent, and counterintuitive"), and therefore is not worth reading?
Mar 04 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 04/03/2012 22:59, Adam D. Ruppe a écrit :

 On Sunday, 4 March 2012 at 21:52:15 UTC, deadalnix wrote:

 OK, now read the other half of the post.



 Try reading the second half of my first post.



I did, it doesn't address why in one case we have a floating point 
error, and in the other a divide error (which is in the first place why 
I do a drama about inconsistency, as Timon said).
Mar 04 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 05/03/2012 00:33, Adam D. Ruppe a écrit :

 On Sunday, 4 March 2012 at 23:27:45 UTC, deadalnix wrote:

 I did, it doesn't address why in one case we have a floating point
 error, and in the other a divide error



 If you use literals, the compiler catches it at compile
 time. "Error: divide by zero" happens when you run the
 compiler.

 If not, the operating system catches it at runtime.
 "Floating point exception" happens when you run the
 program.

 There's nothing inconsistent about this; it is just
 the difference between a compile time error and a
 run time error.



The 0 is known at comile time. You should get the error at compile time.
Mar 05 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:

 No floating point operation is involved here.



It is a Linux issue, not a D one.

Try doing the same thing in C.
Mar 04 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 5 March 2012 10:11, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:

 No floating point operation is involved here.






Division is probably handled by the floating-point section of the
processor, so that's probably why the error says that. However i agree
that it is not helpful.

--
James Miller
Mar 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 4 March 2012 at 21:52:15 UTC, deadalnix wrote:

 OK, now read the other half of the post.



Try reading the second half of my first post.
Mar 04 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 4 March 2012 at 23:27:45 UTC, deadalnix wrote:

 I did, it doesn't address why in one case we have a floating 
 point error, and in the other a divide error



If you use literals, the compiler catches it at compile
time. "Error: divide by zero" happens when you run the
compiler.

If not, the operating system catches it at runtime.
"Floating point exception" happens when you run the
program.

There's nothing inconsistent about this; it is just
the difference between a compile time error and a
run time error.
Mar 04 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Mon, 05 Mar 2012 00:29:44 +0100, deadalnix <deadalnix gmail.com> wrot=
e:


 Le 04/03/2012 22:59, Timon Gehr a =C3=A9crit :

 On 03/04/2012 10:58 PM, deadalnix wrote:

 Le 04/03/2012 22:11, Adam D. Ruppe a =C3=A9crit :

 On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:

 No floating point operation is involved here.



 It is a Linux issue, not a D one.

 Try doing the same thing in C.



 OK, now read the other half of the post.



 I bet he did, but settled to responding to the part that was explicit=







 marked as being 'the problem'.



 You'll find 2 problems, not one.

 Problem one is the floating point reference, which is a problem when n=





 floating point is involved. This is the counterintuitive part.

 Problem two is the inconsistency of behavior. Sometime a divide error =





 triggered and some other a floating point error. This is the  =




 inconsistent part.



http://en.wikipedia.org/wiki/SIGFPE
Mar 04 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 5 March 2012 14:39, Martin Nowak <dawg dawgfoto.de> wrote:

 On Mon, 05 Mar 2012 00:29:44 +0100, deadalnix <deadalnix gmail.com> wrote=




 Le 04/03/2012 22:59, Timon Gehr a =C3=A9crit :

 On 03/04/2012 10:58 PM, deadalnix wrote:

 Le 04/03/2012 22:11, Adam D. Ruppe a =C3=A9crit :

 On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:

 No floating point operation is involved here.




 It is a Linux issue, not a D one.

 Try doing the same thing in C.




 OK, now read the other half of the post.




 I bet he did, but settled to responding to the part that was explicitly
 marked as being 'the problem'.




 You'll find 2 problems, not one.

 Problem one is the floating point reference, which is a problem when no
 floating point is involved. This is the counterintuitive part.

 Problem two is the inconsistency of behavior. Sometime a divide error is
 triggered and some other a floating point error. This is the inconsisten=







 part.




 http://en.wikipedia.org/wiki/SIGFPE



Ok, so it turns out I wasn't completely wrong.

While the C standards states that SIGFPE will never be thrown for uint
types, D presumably makes no such guarantee. Also, the example there
uses `int`s and the compiler warns about a division by zero, then
running it causes a floating point error.

So other than the fact that you are using `uint`s rather than `int`s
the behaviour is identical to that of C.

--
James Miller
Mar 04 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Mon, 05 Mar 2012 12:01:40 +0100, deadalnix <deadalnix gmail.com> wrot=
e:


 Le 05/03/2012 00:33, Adam D. Ruppe a =C3=A9crit :

 On Sunday, 4 March 2012 at 23:27:45 UTC, deadalnix wrote:

 I did, it doesn't address why in one case we have a floating point
 error, and in the other a divide error



 If you use literals, the compiler catches it at compile
 time. "Error: divide by zero" happens when you run the
 compiler.

 If not, the operating system catches it at runtime.
 "Floating point exception" happens when you run the
 program.

 There's nothing inconsistent about this; it is just
 the difference between a compile time error and a
 run time error.



 The 0 is known at comile time. You should get the error at compile tim=




The divide by zero is an error during constfolding not a specific compil=
er  =

check.
Mar 05 2012