Mail Archives: djgpp/2000/02/13/10:30:48
djgpp AT delorie DOT com (Eli Zaretskii) wrote in
<Pine DOT SUN DOT 3 DOT 91 DOT 1000213095538 DOT 29873N-100000 AT is>:
>
>On 11 Feb 2000, Dieter Buerssner wrote:
>
>> > if (c != 0.0)
>> > {
>> > temp = 1.0 / c;
>>
>> The last statement may overflow (to Infinity), and thus may cause
>> a floating point exception, i.e when c is a subnormal/denormal
>> number.
>
>Not in DJGPP v2.02 and later (but since the original poster seems to
>use v2.01, it's possible in this case). In latest versions of DJGPP,
>Infinity never causes an exception, it just results in all subsequent
>results being Inf, NaN, or zero.
... or one (tanh(Infinity) = 1.0), or pi/2 ... .
Yes, you are correct, In newer versions of djgpp all math
exceptions are masked. I think this is even suggested in the
IEEE floating point standard. But of course, it can be of
advantage to allow some math exceptions, especially during
development phase, to catch actual bugs. The OP did not
indicate, that he has set the exception mask. So you are
probably correct that he uses and older version of djgpp.
I am agreeing with your suggestion of upgrading djgpp. And this
may cure the problem of the OP. But it is also possible,
that it will actually hide the bug, at the place where it is
occuring.
To the Peter Restall. I am assuming at least a, b, c, temp, u_end and
v_end are floating point variables. In your code snippet
if (c != 0.0)
{
temp = 1.0 / c;
u_end = (a * temp) * txt_buf->f_width;
v_end = (b * temp) * txt_buf->f_height;
}
else
{
u_end = 0;
v_end = 0;
}
you are trading (in the if clause) one division and two
multiplications against two divisions (which probably would
execute a little slower).
You may want to try the method with the two divisions -
u_end = (a / c) * txt_buf->f_width; ...
Your problem might go away then, if, whenever c is denormal,
a and b are also small. But, doing arithmetics with denormals,
will loose precision. To cure this, it might be possible,
to prescale a, b, c. (Find the maximum of fabs(a), fabs(b) and
fabs(c), and divide a, b, c by this maximum).
>What exactly do you mean by ``subnormal'', btw? I know about
>denormals and unnormals (the latter can only happen if the program has
>a bug), but I don't think I've ever heard of subnormals.
I meant it as a synonym to denormal. I thought subnormal was more
descriptive (below normal). I only used subnormal, because
there was some confusion in a private conversation, where I
used denormal, and it was understood as unnormal.
>> execute it with fsdb. Set a breakpoint at the start of
>> this offending function, and single step through the function,
>> while looking at the NPX pane. This should give you some hints.
>
>GDB also supports FP registers, so this can be done with GDB or RHIDE
>as well.
Yes, your suggestions probably are better. My recommendation of
fsdb came from the fact, that Peter Restall mentioned, that he was
cross compiling. I have no experience with this, but I thought
you will need the djdev package (where fsdb is included), even
when cross compiling.
I unintentionally ignored, that he also mentioned, that this
was about some 3d engine. So this all might happen in graphics
mode, and stock fsdb can not be used.
Regards,
Dieter
- Raw text -