digitalmars.D - Remainder wat
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (11/11) Mar 04 2012 Hi,
- Adam D. Ruppe (11/11) Mar 04 2012 What's weird about this? Processors raise
- deadalnix (4/11) Mar 04 2012 That is the problem. No floating point operation is involved here. And
- Adam D. Ruppe (3/4) Mar 04 2012 It is a Linux issue, not a D one.
- James Miller (6/9) Mar 04 2012 Division is probably handled by the floating-point section of the
- deadalnix (2/6) Mar 04 2012 OK, now read the other half of the post.
- Adam D. Ruppe (2/3) Mar 04 2012 Try reading the second half of my first post.
- Timon Gehr (3/6) Mar 04 2012 Presumably it lacks drama (compare "a little weird" to "very
- deadalnix (4/7) Mar 04 2012 I did, it doesn't address why in one case we have a floating point
- Adam D. Ruppe (10/12) Mar 04 2012 If you use literals, the compiler catches it at compile
- deadalnix (2/14) Mar 05 2012 The 0 is known at comile time. You should get the error at compile time.
- Martin Nowak (6/24) Mar 05 2012 e.
- Timon Gehr (3/11) Mar 04 2012 I bet he did, but settled to responding to the part that was explicitly
- deadalnix (7/19) Mar 04 2012 You'll find 2 problems, not one.
- Martin Nowak (6/26) Mar 04 2012 ly
- James Miller (12/45) Mar 04 2012 t
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
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
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
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
James Miller <james aatch.net> 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: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 MillerNo floating point operation is involved here.
Mar 04 2012
Le 04/03/2012 22:11, Adam D. Ruppe a écrit :On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:OK, now read the other half of the post.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
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
On 03/04/2012 10:59 PM, Adam D. Ruppe wrote:On Sunday, 4 March 2012 at 21:52:15 UTC, deadalnix wrote:Presumably it lacks drama (compare "a little weird" to "very inconsistent, and counterintuitive"), and therefore is not worth reading?OK, now read the other half of the post.Try reading the second half of my first post.
Mar 04 2012
Le 04/03/2012 22:59, Adam D. Ruppe a écrit :On Sunday, 4 March 2012 at 21:52:15 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 (which is in the first place why I do a drama about inconsistency, as Timon said).OK, now read the other half of the post.Try reading the second half of my first post.
Mar 04 2012
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 errorIf 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
Le 05/03/2012 00:33, Adam D. Ruppe a écrit :On Sunday, 4 March 2012 at 23:27:45 UTC, deadalnix wrote:The 0 is known at comile time. You should get the error at compile time.I did, it doesn't address why in one case we have a floating point error, and in the other a divide errorIf 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 05 2012
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 :e. The divide by zero is an error during constfolding not a specific compil= er = check.On Sunday, 4 March 2012 at 23:27:45 UTC, deadalnix wrote:The 0 is known at comile time. You should get the error at compile tim=I did, it doesn't address why in one case we have a floating point error, and in the other a divide errorIf 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 05 2012
On 03/04/2012 10:58 PM, deadalnix wrote:Le 04/03/2012 22:11, Adam D. Ruppe a écrit :I bet he did, but settled to responding to the part that was explicitly marked as being 'the problem'.On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:OK, now read the other half of the post.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
Le 04/03/2012 22:59, Timon Gehr a écrit :On 03/04/2012 10:58 PM, deadalnix wrote: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.Le 04/03/2012 22:11, Adam D. Ruppe a écrit :I bet he did, but settled to responding to the part that was explicitly marked as being 'the problem'.On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:OK, now read the other half of the post.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
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 :lyOn 03/04/2012 10:58 PM, deadalnix wrote:Le 04/03/2012 22:11, Adam D. Ruppe a =C3=A9crit :I bet he did, but settled to responding to the part that was explicit=On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:OK, now read the other half of the post.No floating point operation is involved here.It is a Linux issue, not a D one. Try doing the same thing in C.o =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 =is =triggered and some other a floating point error. This is the =inconsistent part.http://en.wikipedia.org/wiki/SIGFPE
Mar 04 2012
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=:tLe 04/03/2012 22:59, Timon Gehr a =C3=A9crit :On 03/04/2012 10:58 PM, deadalnix wrote: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=Le 04/03/2012 22:11, Adam D. Ruppe a =C3=A9crit :I bet he did, but settled to responding to the part that was explicitly marked as being 'the problem'.On Sunday, 4 March 2012 at 21:07:50 UTC, deadalnix wrote:OK, now read the other half of the post.No floating point operation is involved here.It is a Linux issue, not a D one. Try doing the same thing in C.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 Millerpart.http://en.wikipedia.org/wiki/SIGFPE
Mar 04 2012