cl_inhibit_floating_point_underflow
Hi. I cannot get this option to work. I set is globally as follows
using namespace std; using namespace cln;
bool cl_inhibit_floating_point_underflow = true;
But the program still aborts with the following error message:
terminate called after throwing an instance of 'cln::floating_point_underflow_exception' what(): floating point underflow.
Am I doing something wrong? Regards, Kåre Olaussen
On 10/02/2011 12:22 PM, Kåre Olaussen wrote:
Hi.
I cannot get this option to work. I set is globally as follows
using namespace std; using namespace cln;
bool cl_inhibit_floating_point_underflow = true;
Try without the "bool" e.g. cl_inhibit_floating_point_underflow = true;
Den 2. okt. 2011 kl. 20.17 skrev Michael Miller:
I cannot get this option to work. I set is globally as follows
using namespace std; using namespace cln;
bool cl_inhibit_floating_point_underflow = true;
Try without the "bool" e.g.
cl_inhibit_floating_point_underflow = true;
I had tried that (among several other things). The compiler complains
preciseEigenvalues.cc:19: error: expected constructor, destructor, or type conversion before ‘=’ token
presumably because 'cl_inhibit_floating_point_underflow' is declared extern in the header.
Hi! On 10/02/2011 06:22 PM, Kåre Olaussen wrote:
I cannot get this option to work. I set is globally as follows
using namespace std; using namespace cln;
bool cl_inhibit_floating_point_underflow = true;
But the program still aborts with the following error message:
terminate called after throwing an instance of 'cln::floating_point_underflow_exception' what(): floating point underflow.
Am I doing something wrong?
As Michael Miller noted already, re-declaring this global variable won't work. Apart from that: Did you #include <cln/float.h>? Where is that assignment (as you write it it could be outside a function body)? Generally, when reporting bugs, you should attach code that enables your audience to reproduce the bug. Bye! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Apart from that: Did you #include <cln/float.h>? Where is that assignment (as you write it it could be outside a function body)?
As I said I tried several things. My experience is that if one includes <cln/cln.h> all the rest is automatically included. I have never registered any difference with explicit inclusion on various linux and MacOS distributions. Here is a minimal demonstration /* File: demo.cc Compilation: g++ -g -O2 -o demo demo.cc -lcln */ //bool cln::cl_inhibit_floating_point_underflow = true; #include <cln/cln.h> #include <cln/float.h> //using namespace std; using namespace cln; //bool cln::cl_inhibit_floating_point_underflow = true; bool cl_inhibit_floating_point_underflow = true; int main() { float_format_t precision = float_format(50); cl_F x = least_positive_float(precision); while(x > cl_float(0, precision) ) { std::cout << x << std::endl; x *= x; } } which produces the output:
7.241484622111747243360392473658128214691955086151413286838L-2776511644261678567 terminate called after throwing an instance of 'cln::floating_point_underflow_exception' what(): floating point underflow. Abort trap
Try moving the line bool cl_inhibit_floating_point_underflow = true; inside the function main, without the bool, so the first three lines look like: int main() { cl_inhibit_floating_point_underflow = true; On 10/02/2011 06:42 PM, Kåre Olaussen wrote:
Here is a minimal demonstration
/* File: demo.cc Compilation: g++ -g -O2 -o demo demo.cc -lcln */
#include <cln/cln.h> #include <cln/float.h>
using namespace cln;
bool cl_inhibit_floating_point_underflow = true;
int main() { float_format_t precision = float_format(50); cl_F x = least_positive_float(precision); while(x > cl_float(0, precision) ) { std::cout << x << std::endl; x *= x; } }
which produces the output:
7.241484622111747243360392473658128214691955086151413286838L-2776511644261678567 terminate called after throwing an instance of 'cln::floating_point_underflow_exception' what(): floating point underflow. Abort trap
Den 3. okt. 2011 kl. 00.40 skrev Michael Miller:
Try moving the line
bool cl_inhibit_floating_point_underflow = true;
inside the function main, without the bool, so the first three lines look like:
int main() { cl_inhibit_floating_point_underflow = true;
Yes, indeed that works! Also for functions called from main(). I almost tried this, but with the bool declaration... Thanks a lot! I wonder if section 12.2 of the manual should be modified? The behaviour maybe depends on compilers and systems. By the way, I think it most of the time is a bad idea to turn on this option. Usually underflow is a signal that some lowprecision variables have contaminated your calculation.
Kåre Olaussen wrote:
I wonder if section 12.2 of the manual should be modified? The behaviour maybe depends on compilers and systems.
The manual is as precise and unambiguous as it can be: "If you set the global variable cl_boolean cl_inhibit_floating_point_underflow to `cl_true', the error will be inhibited, and a floating-point zero will be generated instead. The default value of `cl_inhibit_floating_point_underflow' is `cl_false'." This means: 1) You should _set_ the variable. 2) The variable is already defined, and it has a default value. Setting a global variable means assigning it. This behaviour is not compiler or system dependent. What you have tried to do, is to _redefine_ the variable in your code. Here the effect is system dependent: On ELF systems, a redefinition of a variable or function usually overrides (takes precedence over) the original one (*), whereas on other systems (Windows, MacOS X, AIX, HP-UX), it usually does when you are linking with cln as a static library but *not* when you are linking with it as a shared library. But that is common knowledge; I don't think the CLN manual should explain the difference between assignment and redefinition. Bruno (*) The cases where a redefinition does not override the original definition imply dynamic loading of shared libraries.
Hi, I'm using CLN within a large software package and trying to build it with cmake. Just before I put a lot of effort in it, did someone try to make a "Findcln.cmake" script already? It would help to have pkg-config support for this as well, e.g. to get the gmp library linked in automatically. If no-one did it before I will do it myself. It would be nice if it got incorporated in the cln distribution in that case. Cheers, -- David van der Spoel, Ph.D., Professor of Biology Dept. of Cell & Molec. Biol., Uppsala University. Box 596, 75124 Uppsala, Sweden. Phone: +46184714205. spoel@xray.bmc.uu.se http://folding.bmc.uu.se
Hello, On Wed, Oct 26, 2011 at 10:02:04AM +0200, David van der Spoel wrote:
I'm using CLN within a large software package and trying to build it with cmake. Just before I put a lot of effort in it, did someone try to make a "Findcln.cmake" script already? It would help to have pkg-config support for this as well, e.g. to get the gmp library linked in automatically.
include(FindPkgConfig) pkg_check_modules(cln REQUIRED cln>=1.2.2) include_directories(${cln_INCLUDE_DIRS}) link_directories({cln_LIBRARY_DIRS}) # On ELF systems (such as GNU/Linux) this prevents the infamous `error # while loading shared libraries: libfoo.so: cannot open shared object # file: no such file or directory' set(CMAKE_INSTALL_RPATH_USE_LINK_RPATH TRUE) list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${cln_LIBRARY_DIRS}" isSystemDir) if("${isSystemDir}" STREQUAL "-1") set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_RPATH}:${cln_LIBRARY_DIRS}") endif() # Tell CMake to link target(s) with CLN target_link_libraries(hello ${cln_LIBRARIES}) Note: the above code is rather unorthodox, as CMake refers libraries by their absolute path, and does not trust pkg-config (I don't think any of these is a good idea, but that's how things work with CMake). Also, rpath should be configurable (so whoever makes deb/rpm packages won't write you hate mails), etc.
If no-one did it before I will do it myself. It would be nice if it got incorporated in the cln distribution in that case.
I'm working on CMake based build system for GiNaC (and CLN), Find* will be written as a side effect. Best regards, Alexei
participants (6)
-
Alexei Sheplyakov
-
Bruno Haible
-
David van der Spoel
-
Kåre Olaussen
-
Michael Miller
-
Richard B. Kreckel