JQuantLib

Translation of NULL<T> needs to be fixed

Bug #1209790 reported by Richard Gomes on 2009-06-25

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	JQuantLib	New	Medium	Unassigned

Bug Description

******************************************
IMPORTANT: This is a parent issue. Create as many children issues as needed to address specific steps to complete this task.
******************************************

I've found that our translation of Null<T> is by many times mistaken.
Contrary of what may seem intuitive, in QuantLib/C++ code...

* Null<int> is not zero, it is Integer.MAX_VALUE

* Null<double> is not zero or Double.NaN, but it is Double.MAX_VALUE

* Null<T> is not null, but new T(). Example: Null<Array> is equivalent to new Array()

* we can find Null<Size> being equivalent to Null<int>. Some other use cases can be found.

* we can fin Null<Rate> being equivalent to Null<double>. Several other use cases can be found.

I've created in org.jquantlib.math.Constants:

public static final double NULL_Integer = Integer.MAX_VALUE;
public static final double NULL_Double = Double.MAX_VALUE;

... whilst I think that Null<T> should be translated by hand, depending on the situation.

Aiming give you an idea of how many occurrences we have by package (excluding the test-suite) I'm attaching the following files (as archive ql.tar.bz2) for your information.

  24 ql
  46 ql_cashflows
   2 ql_indexes
103 ql_instruments
  28 ql_legacy_libormarketmodels
   6 ql_legacy_pricers
   1 ql_math
   5 ql_math_integrals
   6 ql_math_interpolations
   3 ql_math_optimization
   2 ql_math_solvers1d
   1 ql_math_statistics
   1 ql_methods_finitedifferences
   3 ql_models
   2 ql_models_shortrate_onefactormodels
  14 ql_pricingengines
  11 ql_pricingengines_asian
   2 ql_pricingengines_barrier
   4 ql_pricingengines_basket
   4 ql_pricingengines_capfloor
  12 ql_pricingengines_cliquet
  13 ql_pricingengines_forward
   1 ql_pricingengines_hybrid
   3 ql_pricingengines_quanto
   2 ql_pricingengines_swaption
  38 ql_pricingengines_vanilla
   7 ql_processes
   2 ql_quotes
   4 ql_termstructures_volatilities
   3 ql_termstructures_yieldcurves
   3 ql_time
   4 ql_time_calendars
   1 ql_time_daycounters
  25 ql_utilities

=============
Relationships
=============
related to http://bugs.launchpad.net/bugs/jquantlib-327
parent of http://bugs.launchpad.net/bugs/jquantlib-360
parent of http://bugs.launchpad.net/bugs/jquantlib-328
child of http://bugs.launchpad.net/bugs/jquantlib-394

Tags:

Revision history for this message

Richard Gomes (frgomes) wrote on 2009-06-25: Attachment

ql.tar.bz2 Edit (5.0 KiB, application/x-bzip)

filename:"ql.tar.bz2",size:"5081"

Revision history for this message

Richard Gomes (frgomes) wrote on 2009-07-26:

The following link describes more about floating pointer in Java:

http://www.concentric.net/~Ttwang/tech/javafloat.htm

In particular, I'm in doubt if we should use Double.NaN, Double.POSITIVE_INFINITY or Double.MAX_VALUE.

Anyway, whatever decision is made, we will have to revisit the entire code, looking for places where we have test for Double.NaN and eventually substitute by something else. We will also have to revisit class Closeness

Revision history for this message

Richard Gomes (frgomes) wrote on 2009-07-30:

I changed
NULL_Double to NULL_REAL and
NULL_Integer to NULL_INTEGER
... in order to mimick QL/C++ names

Revision history for this message

Richard Gomes (frgomes) wrote on 2009-09-10:

Null<Date> deserves some special attention.

QL/C++ defines NULL<Date> as Date(), i.e: new Date() in Java.

At the moment, it's not clear (to me) how Null<Date> is being used by C++ code.
I've found 2 use cases:

1. Comparison

I've seem that most of the time it's needed for comparisons, something like...
if (d.equals(NULL_DATE)) { ... }
... which means that a "constant" (static/singleton) would be enough and efficient for comparisons.

2. A regular Date variable

There's also a possibility that NULL_DATE as is employed as an **initial value** for a Date variable, pretty much the same when we initialize an int variable with zero simply because there's no better thing to do when we create it.

In the former possibility, as static/singleton NULL_DATE is not what we need.

I'd say that the original QL/C++ API should provide something like Date#isNull() in order to efficiently test if a certain Date variable has it's internal value not yet properly initialized (or something like this). This approach would also be important when we plug external date/calendar representations to our Date/Calendar classes.
See:
http://bugs.jquantlib.org/view.php?id=327
http://www.jquantlib.org/index.php/Jquantlib:327

Conclusion

So, I'd recommend that our API adds a method called isNull() in order to satisfy the (1)st use case.

The (2)nd use case can be easily satisfied as soon as we review/rewrite Date classes and implement properly:
a. new Date() constructor.
b. clone() (from interface Cloneable) copy constructor.

Revision history for this message

Richard Gomes (frgomes) wrote on 2009-09-10:

Hi Zahid,

I'm sending this issue to you as it is related to the rewrite work of Date classes. Probably as soon as you finish the rewrite, this issue will be partially solved, at least regarding Null<Date> (our interim NULL_DATE constant).

There are other issues related to other flavours of Null<something>.
So, this issue cannot be resolved/closed without a further code review.

Thanks -- Richard

Revision history for this message

Richard Gomes (frgomes) wrote on 2009-09-19:

Created issue specific to Null<Date>
http://bugs.jquantlib.org/view.php?id=360

Revision history for this message

Richard Gomes (frgomes) wrote on 2009-11-01:

Better kick this issue to v0.1.4.
Reason: changes implied by this fix may require a lot of changes and very accurate tests. We need to have more people helping on this task.

Revision history for this message

Richard Gomes (frgomes) wrote on 2010-11-25:

dropped back to the pot