Null<double> and arithmetics

[Vadim Ogranovich-3]

Life may be more simple than I thought, it seems like comipilers have
support for NaN and Inf numbers. Below is a VC++ help page that makes me
think this is the case

_finite
Determines whether given double-precision floating point value is finite.

int _finite( double x );

Function Required Header Compatibility
_finite <float.h> Win 95, Win NT


For additional compatibility information, see Compatibility in the
Introduction.

Libraries

LIBC.LIB Single thread static library, retail version
LIBCMT.LIB Multithread static library, retail version
MSVCRT.LIB Import library for MSVCRT.DLL, retail version


Return Value

_finite returns a nonzero value (TRUE) if its argument x is not infinite,
that is, if -INF < x < +INF. It returns 0 (FALSE) if the argument is
infinite or a NaN.

Parameter

x

Double-precision floating-point value

Floating-Point Support Routines

See Also   _isnan, _fpclass


----------------------------------------------------------------------------
----
Send feedback to MSDN.Look here for MSDN Online resources.


Hi,

Just want to make a suggestion. Currently
double x = Null<double>() * 0.01;
produces a valid double, which is confusing (I ran into it when I read
interest rates in %% and then converted to non-percent numbers).

I heard that there is a IEEE standard + libraries for things like NaN, Inf,
etc. It would be nice if  Null<numeric> conform to that standard.
Another option is to use Rmath library (a standalone byproduct of R-project)
which seems to handle NaN-s properly, but I don't have first-hand experience
with it.

Thanks, Vadim

--------------------------------------------------
DISCLAIMER
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information.  If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free.  The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.

NOTICE REGARDING PRIVACY AND CONFIDENTIALITY

Knight Trading Group may, at its discretion, monitor and review the content
of all e-mail communications.

[Luigi Ballabio-4]

At 02:17 PM 5/7/02 -0500, Vadim Ogranovich wrote:
>Life may be more simple than I thought, it seems like comipilers have
>support for NaN and Inf numbers. Below is a VC++ help page that makes me
>think this is the case

I've been looking at the C++ standard and it defines a <limits> header with
a template class numeric_limits<Type>. However, support for it is kind of
erratic, namely:

gcc 2.95.x : doesn't implement <limits>

gcc 3.0.x  : std::numeric_limits<int>::has_quiet_NaN = false
              std::numeric_limits<double>::has_quiet_NaN = false

Borland C++: std::numeric_limits<int>::has_quiet_NaN = false
              std::numeric_limits<double>::has_quiet_NaN = true
              std::numeric_limits<double>::quiet_NaN() / 100.0  -> crashes

Visual C++ : std::numeric_limits<int>::has_quiet_NaN = true
              std::numeric_limits<double>::has_quiet_NaN = true
              std::numeric_limits<double>::quiet_NaN() / 100.0  -> gives a NaN

so in this case, surprisingly enough, VC++ is the compiler with the best
support of the standard...

I think what we can do is:

a) we can #define Null<T> in a compiler-dependent way, so that we get to
use NaNs for VC++ and stick to some ql-defined value for the other compilers;

b) or we can redefine Null<T> to throw an error when one tries to cast it
to an actual int or double or whatever T is. Albeit rudely, this would
notify the user, should he ever try to do Null<double>()/100.0, instead of
letting wrong values enter the computations.

c) both of the above (NaN for VC++, throw for the others)

Thoughts?

Bye,
                 Luigi

[Vadim Ogranovich-3]

I did some research / experiments with g++3.0.4 on Linux. They have isnan(),
et. al. defined in <cmath>. Below is the code that generates a NaN and
confirms that the NaN behaves as expected.

//foo.cpp
#include <iostream>
#include <cmath>

using namespace std;

int main()
{
  double x = 1.0/0.0;

  cout << "NaN=" << isnan(x) << " Inf=" << isinf(x) << '\n';

  x = 0.0/0.0;

  cout << "NaN=" << isnan(x) << " Inf=" << isinf(x) << '\n';

  x *= 0.1;
  cout << "NaN=" << isnan(x) << " Inf=" << isinf(x) << '\n';

  return 0;
}

$ ./foo
NaN=0 Inf=1
NaN=1 Inf=0
NaN=1 Inf=0

I'd wrap Null<double> around this.


Another comment. I find the b) proposal overly restrictive for doubles at
least. I do want to be able store NaN in a double to indicate that a value
is either not initialized or can not possibly have a reasonable value, e.g.
implied volatility of an option traded below intrinsic value, or whatever.

I have no opinion what to do about Null<int>. I can see a situation where
Null<int> can be involved in arithmetics, for example a class can represent
the number of stock shares by int, set it to Null<int> when the value is not
known, and then compute price*shares and expect it to come out Null<double>.
However I am not sure that all this is worth the trouble given that there is
no compiler support for this.

Thanks, Vadim

-----Original Message-----
From: Luigi Ballabio [mailto:[hidden email]]
Sent: Thursday, May 09, 2002 7:27 AM
...

I think what we can do is:

a) we can #define Null<T> in a compiler-dependent way, so that we get to
use NaNs for VC++ and stick to some ql-defined value for the other
compilers;

b) or we can redefine Null<T> to throw an error when one tries to cast it
to an actual int or double or whatever T is. Albeit rudely, this would
notify the user, should he ever try to do Null<double>()/100.0, instead of
letting wrong values enter the computations.

c) both of the above (NaN for VC++, throw for the others)

Thoughts?

Bye,
                 Luigi


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [hidden email]
_______________________________________________
Quantlib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

--------------------------------------------------
DISCLAIMER
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information.  If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free.  The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.

NOTICE REGARDING PRIVACY AND CONFIDENTIALITY

Knight Trading Group may, at its discretion, monitor and review the content
of all e-mail communications.