Opened 14 years ago

Closed 13 years ago

#190 closed defect (fixed)

utility::vector and utility::matrix expects quiet_NaN is supported but it might not be.

Reported by: Jari Häkkinen Owned by: Jari Häkkinen
Priority: major Milestone: yat 0.4
Component: build Version: trunk
Keywords: Cc:

Description

Somewhere we should check that quiet_NaNs are supported std::numeric_limits<double>::has_quiet_NaN has to be true.

Change History (15)

comment:1 Changed 14 years ago by Jari Häkkinen

Summary: utility::vector and utility::matrix expects quit_NaN is supported but it might not be.utility::vector and utility::matrix expects quiet_NaN is supported but it might not be.

comment:2 Changed 14 years ago by Markus Ringnér

This is checked in data_lookup_1d_test.cc which gives an understandable error message. At the time this test was implemented we agreed that it was ok that yat required compilers with quiet NaNs?, and that the failure of this test to signal this problem was ok to begin with. It would perhaps be better that also matrix_test and vector_test fail as this would be more alarming to a user/installer. However, do we think that all functionality that depends on matrix and vector such as the classifiers etc should have tests that fail if there are no quiet NaN support?

comment:3 Changed 14 years ago by Peter

What happens to a user not having quiet NanN, meaning how much functionality will he lose?

Is it possible to check this already in configure?

comment:4 Changed 14 years ago by Jari Häkkinen

Milestone: 0.4

comment:5 Changed 14 years ago by Markus Ringnér

Here is how to do it in configure. I did not check it in since

1) I do not know which configure file one is supposed to hack in and I leave it to the autoconf experts.

2) What should we report in case the test fails (the example gives a simple message)? I guess a bigger error message is the way to go as fallback to some other nan handling will not be implemented in yat.

3) I think it works based on my reading of the AC_TRY_COMPILE definition, but have not tested it on a system without quiet_nan (all my old machines have been modernized).

AC_MSG_CHECKING([for std::numeric_limits<>::quiet_NaN()])
quiet_nan=yes
AC_TRY_COMPILE([#include <limits>
	extern void f(double);],	
	[f(std::numeric_limits<double>::quiet_NaN())],
	[quiet_nan=yes[,quiet_nan=no]])
AC_MSG_RESULT($quiet_nan)
if test "${quiet_nan}" = "no" ; then
	AC_MSG_NOTICE([Yat will not work on this system!])
fi

comment:6 Changed 14 years ago by Markus Ringnér

Some issues

1) The language has to be set

2) There was a bug in the [] for the yes/no alternatives

The following works and has been tested (ok with quiet NaN and barfs if I change to test for blaha_NaN):

AC_LANG(C++)
AC_MSG_CHECKING([for std::numeric_limits<>::quiet_NaN()])
quiet_nan=yes
AC_TRY_COMPILE([#include <limits>
	extern void f(double);],	
	[f(std::numeric_limits<double>::quiet_NaN())],
	[quiet_nan=yes],[quiet_nan=no])
AC_MSG_RESULT($quiet_nan)
if test "${quiet_nan}" = "no" ; then
	AC_MSG_NOTICE([Yat will not work on this system because 
there is no quiet NaN!])
	exit
fi

However, AC_TRY_COMPILE has been replaced by AC_COMPILE_IFELSE so we should use that instead. Also, maybe all our examples will be in C++ and AC_LANG should be set early. Tests not in C++ (for whatever reason) should then be surrounded by AC_LANG_PUSH(language) and AC_LANG_POP([language]).

comment:7 Changed 14 years ago by Jari Häkkinen

Status: newassigned

comment:8 Changed 14 years ago by Jari Häkkinen

I'll remove the check for quiet_NaN in data_lookup_1d_test.cc. configure will fail if quite_NaN check fails, that is yat will not support machines without quite_NaNs.

comment:9 Changed 14 years ago by Jari Häkkinen

Resolution: fixed
Status: assignedclosed

Fixed in changeset:922

comment:10 Changed 14 years ago by Jari Häkkinen

Resolution: fixed
Status: closedreopened

The AC check may pass but the quiet_NaN support is flaky in the compiler. Need to check that has_quiet_NaN return true.

comment:11 Changed 14 years ago by Markus Ringnér

In [924] I added a run-time test that checks if has_quiet_NaN is true. The disadvantage of having run-time tests is that it prevents people from configuring yat for cross-compiling. The way it is handled now is that autoconf should issue a warning if it tries to create a configure for cross-compiling.

See http://www.gnu.org/software/automake/manual/autoconf/Runtime.html

If we can live with this restriction then this ticket can be closed. So can we?

comment:12 Changed 14 years ago by Jari Häkkinen

Well, I can live without cross-compiling support, but I suppose we need to document this somewhere. I prefer the check in configure and the previous check in the test program would not resolve the problem? Cross-compiling will not run the tests I suppose.

comment:13 in reply to:  12 Changed 14 years ago by Markus Ringnér

Replying to jari:

Well, I can live without cross-compiling support, but I suppose we need to document this somewhere.

Yes, Maybe this is related to ticket:208: we should document both requirements and limitations.

I prefer the check in configure and the previous check in the test program would not resolve the problem?

I also prefer testing as much as possible in configure.

I do not think the test at the compilation level in configure would resolve the problem (at least not with g++) but have not tested it on any system without quiet_NaN.

Cross-compiling will not run the tests I suppose.

I tried to test it but I did not manage to set '--build' for configure on my machine to something that I could cross-compile to with my compilers. Does anyone feel like testing this?

However, AC_RUN_IFELSE takes an optional argument [action-if-cross-compiling] and we could of course set a flag here and then report a failure message. Is this what we want?

comment:14 Changed 13 years ago by Jari Häkkinen

Component: utilitybuild

comment:15 Changed 13 years ago by Jari Häkkinen

Resolution: fixed
Status: reopenedclosed

Let us close this ticket and hope we'll never cross compile.

Note: See TracTickets for help on using tickets.