Perl-Sensitive Sunglasses | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
The IEEE standards specify the binary formats, but not the functions (hardware or software) that manipulate them. The C standards leave some relevant details undefined or implementation dependent. I don't recall that the exact format of floating point numbers is specified or that the details of conversions are specified (e.g. rounding Vs. truncating). There are many relevant hardware and software features that sane people might be inclined to call bugs. The operations you are performing in your test program are conceptually simple, yet your experience demonstrates the variability that exists in implementations. For floating point calculations generally, not only does changing the compiler make a difference, but sometimes running the same executable on different hardware makes a difference. I would be surprised if Microsoft would fix the old compiler, even if you sent a bug report - their response would almost certainly be that they have fixed it in release 8.0. Even if they did provide a patch for the older compiler, it might be difficult to get everyone compiling your program to install the patch before compiling. You could test for the bug in your test suite and fail the build if it is present. If you haven't already, you might try different combinations of of compiler options. Sometimes changing optimization or debug settings will make a difference to such issues. If PDL is doing non-trival floating point calculations and must work with a variety of combinations of compiler, libraries and hardware, then it will have to cope with varying results. The paper I linked to gives some good guidance for writing floating point calculations and in particular comparisons to minimize and accommodate the variations. In reply to Re^3: [Win32, C, and way OT] C floats, doubles, and their equivalence
by ig
|
|