isnan() and family seems to have stopped working in my code. The only thing I can remember is updating from 1.36 to 1.37. Any idea why the following wouldn't work? float nan = FP_NAN; int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan); isnan never returns anything. The value of ret is still 0xdeadbeef after invoking isnan() I'm on OSX10.5.6 using XCode 3 if that helps. Thijs
isnan() and family seems to have stopped working in my code. The only thing I can remember is updating from 1.36 to 1.37. Any idea why the following wouldn't work?
float nan = FP_NAN; int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan);
isnan never returns anything. The value of ret is still 0xdeadbeef after invoking isnan()
I'm on OSX10.5.6 using XCode 3 if that helps.
No idea: the tests all seem to be passing on that platform. Are you able to step into the code for isnan to see what's happening? It has to return *something* IMO... John.
* Thijs Koerselman [2009-01-04 23:11]:
isnan() and family seems to have stopped working in my code. The only thing I can remember is updating from 1.36 to 1.37. Any idea why the following wouldn't work?
float nan = FP_NAN;
That's just 3. Use std::numeric_limits<float>::quiet_NaN() from <limits>. See the example below that works for me on Linux with Boost 1.36 and g++ 4.3.2.
int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan);
isnan never returns anything.
Well, in my tests on Linux that is set to 0 in your example. Regards, Bernhard #include <iostream> #include <limits> #include <boost/math/special_functions/fpclassify.hpp> int main(int argc, char *argv[]) { float nan = std::numeric_limits<float>::quiet_NaN(); int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan); std::cout << ret << std::endl; return 0; }
On Mon, Jan 5, 2009 at 11:05 AM, Bernhard Walle <bernhard.walle@gmx.de>wrote:
float nan = FP_NAN;
That's just 3.
Use std::numeric_limits<float>::quiet_NaN() from <limits>. See the example below that works for me on Linux with Boost 1.36 and g++ 4.3.2.
Aha! thanks. I was wondering why it was an enum :) (it's 1 on my platform).
int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan);
isnan never returns anything.
Well, in my tests on Linux that is set to 0 in your example.
Sorry it DOES work. When i step over the last assignment to the end of the function block, XCode doesn't update the value of ret in the debugging window. It still displays 0xdeadbeaf, even though the value has changed. So it did return a value. I wonder if this is intended. I can't think of a good reason why XCode it would work like that. So the enum was the original reason for my code not working. The only thing I'm still wondering about is why it did work before, when I was using the enum with the earlier version. It's a completely different value for NaN. It doesn't matter anymore, now everything is sorted. Thanks everyone for helping out. Cheers, Thijs
* Thijs Koerselman [2009-01-05 21:23]:
Sorry it DOES work. When i step over the last assignment to the end of the function block, XCode doesn't update the value of ret in the debugging window. It still displays 0xdeadbeaf, even though the value has changed. So it did return a value. I wonder if this is intended. I can't think of a good reason why XCode it would work like that.
That could be an optimisation. Do you compile with -O0 (or without any -O)? Regards, Bernhard
On Tue, Jan 6, 2009 at 9:46 AM, Bernhard Walle <bernhard.walle@gmx.de>wrote:
Sorry it DOES work. When i step over the last assignment to the end of the function block, XCode doesn't update the value of ret in the debugging window. It still displays 0xdeadbeaf, even though the value has changed. So it did return a value. I wonder if this is intended. I can't think of a good reason why XCode it would work like that.
That could be an optimisation. Do you compile with -O0 (or without any -O)?
I accidentally had it set to -Os, but changing it back to -O0 doesn't seem to make a difference in this case. You may be right about the optimization though, because if I put an extra dummy statement in like "ret = ret" it is also skipped by gdb. Thijs
* Thijs Koerselman [2009-01-06 17:38]:
On Tue, Jan 6, 2009 at 9:46 AM, Bernhard Walle <bernhard.walle@gmx.de>wrote:
Sorry it DOES work. When i step over the last assignment to the end of the function block, XCode doesn't update the value of ret in the debugging window. It still displays 0xdeadbeaf, even though the value has changed. So it did return a value. I wonder if this is intended. I can't think of a good reason why XCode it would work like that.
That could be an optimisation. Do you compile with -O0 (or without any -O)?
I accidentally had it set to -Os, but changing it back to -O0 doesn't seem to make a difference in this case. You may be right about the optimization though, because if I put an extra dummy statement in like "ret = ret" it is also skipped by gdb.
Works here: kopernikus % cat boost.cc #include <iostream> #include <limits> #include <boost/math/special_functions/fpclassify.hpp> int main(int argc, char *argv[]) { float nan = std::numeric_limits<float>::quiet_NaN(); int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan); return 0; } kopernikus % g++ -g -o boost boost.cc kopernikus % gdb ./boost GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) break 11 Breakpoint 1 at 0x8048651: file boost.cc, line 11. (gdb) r Starting program: /home/bwalle/boost Breakpoint 1, main () at boost.cc:11 11 return 0; (gdb) p ret $1 = 1 (gdb) quit The program is running. Exit anyway? (y or n) y Regards, Bernhard
participants (3)
-
Bernhard Walle
-
John Maddock
-
Thijs Koerselman