a simple question

[DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI]

Is there any reason why QL_NULL_REAL  is defined this way :

 

#define QL_NULL_REAL   ((std::numeric_limits<float>::max)())

 

whereas <a href="mk:@MSITStore:C:\Documents%20and%20Settings\duvigf1a\My%20Documents\_my%20Stuffs\QuantLib-docs-ql_svn.chm::/group__limit_macros.html#g8a6736b7bfef354a1fc507317d49117a">QL_MIN_REAL and QL_MAX_REAL  are defined this way :

#define

<a href="mk:@MSITStore:C:\Documents%20and%20Settings\duvigf1a\My%20Documents\_my%20Stuffs\QuantLib-docs-ql_svn.chm::/group__limit_macros.html#g8a6736b7bfef354a1fc507317d49117a">QL_MIN_REAL   -((std::numeric_limits<<a href="mk:@MSITStore:C:\Documents%20and%20Settings\duvigf1a\My%20Documents\_my%20Stuffs\QuantLib-docs-ql_svn.chm::/class_q_l___r_e_a_l.html">QL_REAL>::max)())

#define QL_MAX_REAL   ((std::numeric_limits<QL_REAL>::max)())

 

François

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Fri, 2007-05-18 at 10:08 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> Is there any reason why QL_NULL_REAL  is defined this way :
>
> #define QL_NULL_REAL   ((std::numeric_limits<float>::max)())
>
> whereas QL_MIN_REAL and QL_MAX_REAL  are defined this way :
>
> #define QL_MAX_REAL   ((std::numeric_limits<QL_REAL>::max)())


In theory, QL_REAL might be redefined to float or long double (in
practice it is not, as some tests break.) QL_MIN_REAL and QL_MAX_REAL
should be the min and max value for the actual type chosen, so
numeric_limits<QL_REAL> is used. As for QL_NULL_REAL, it doesn't really
matter what value is used as long as it's a determined one, so there's
no need to use the actual QL_REAL type; also, we define Null<float>,
Null<double> and Null<long double> to be all equal to QL_NULL_REAL,
which is somewhat convenient (this way, Null<T> is the same number, no
matter the actual type) and using float ensured that the resulting
number could be contained in all such types without overflow.

Speaking of which, funny that you came out with a question on Null. Just
yesterday I was thinking of removing it and using boost::optional when a
number might or might not be defined. What do you think?

Later,
        Luigi


----------------------------------------

Lubarsky's Law of Cybernetic Entomology:
There is _always_ one more bug.



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI]

>As for QL_NULL_REAL, it doesn't really matter what value is used as long as >it's a determined one

Since it is now used as some kind of unitialized value by the quotes classes, I would say that it is no longer such an immaterial detail. For example if we can encounter the following problem:

        SimpleQuote quote;
        Real value = (std::numeric_limits<float>::max)(); //limit case test
        Quote.setValue(value);
        //a few lines of code later ... bug !!!!

>Speaking of which, funny that you came out with a question on Null. Just
>yesterday I was thinking of removing it and using boost::optional when a
>number might or might not be defined. What do you think?

Maybe you have thought about boost::optional for the same reason. ;-)
It would be cleaner indeed. However I'm not convinced that it's a good solution yet.
IMO boost::optional a pefect solution in the case of a free function which can return invalid result even in normal situations. (like the second example of boost optional tutorial).

On the hand it seems to me that using it for a function member would add some spurious trickyness to the class. What do you think of this implementation ?

        Quote():isValid_(false){}

        virtual void resetQuote() {
            isValid_ = false;
        }

        virtual bool isValid() const {
            return isValid_;
        };
        private:
        bool isValid_;


regards,

François

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Fri, 2007-05-18 at 15:00 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> >As for QL_NULL_REAL, it doesn't really matter what value is used as long as >it's a determined one
>
> Since it is now used as some kind of unitialized value by the quotes classes, I would say that it is no longer such an immaterial detail.

Sure. We picked a value which is unlikely to be chosen as a valid one;
but since it has to be a value anyway (we could use NaN, but it's not
very portable) it's not foolproof.

> Maybe you have thought about boost::optional for the same reason. ;-)
> It would be cleaner indeed. However I'm not convinced that it's a good solution yet.
> IMO boost::optional a pefect solution in the case of a free function which can return invalid result even in normal situations. (like the second example of boost optional tutorial).
>
> On the hand it seems to me that using it for a function member would add some spurious trickyness to the class. What do you think of this implementation ?
>
> Quote():isValid_(false){}
>
> virtual void resetQuote() {
>    isValid_ = false;
> }
>
> virtual bool isValid() const {
>    return isValid_;
> };
> private:
> bool isValid_;

Is this the base class? In this case, isValid_ should be protected and
derived classes would have to manage it. Using optional wouldn't be so
tricky: we could just write SimpleQuote as (without namespace boost)

class SimpleQuote {
  private:
    optional<Real> value_;
  public:
    explicit SimpleQuote(optional<Real> value = none)
    : value_(value) {}

    bool isValid() const {
        return value_;  // automatic conversion to bool
    }

    Real value() const {
        return *value_; // access the actual Real
    }

    Real setValue(Real x) {
        value_ = x;     automatic conversion to optional
        ... // notify etc.
    }
};

SimpleQuote q1;       // not initialized, isValid() returns false
SimpleQuote q2(42.0); // double automatically converted to optional

Later,
        Luigi




----------------------------------------

The First Rule of Optimization: Don't do it.
The Second Rule of Optimization (For experts only): Don't do it yet.
-- Michael Jackson



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI]

>Is this the base class?
Yes

In this case, isValid_ should be protected and derived classes would have to manage it.

I agree with you, we could also leave it as it is and provide a protected function setQuote() which would set isValid_ to true.

>Using optional wouldn't be so tricky: we could just write SimpleQuote as >(without namespace boost)

I agree again, provided that you add a resetQuote() method to your class, then the use of optional would be transparent to the user. Still, I have two remaining arguments:
->You have to reimplement this machinery in every quote classe.
->What would be the added benefit compare to a more traditionnal solution ? (like mine)

I know that you will destroy these arguments in a couple of seconds, but it is instructive to understand one's error anyway

François

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

Bonjour François,
        sorry for the delay. Here we go:

On May 18, 2007, at 5:41 PM, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD
PHI wrote:

>> In this case, isValid_ should be protected and derived classes would
>> have to manage it.
>
> I agree with you, we could also leave it as it is and provide a
> protected function setQuote() which would set isValid_ to true.
>
>> Using optional wouldn't be so tricky: we could just write SimpleQuote
>> as >(without namespace boost)
>
> I agree again, provided that you add a resetQuote() method to your
> class, then the use of optional would be transparent to the user.

resetQuote() might not be necessary, as we can declare setQuote as
setQuote(optional<Real>). With this declaration,

q.setQuote(42);

would automatically package the Real in the optional, while

q.setQuote(none);

would make q a null quote.


>  Still, I have two remaining arguments:
> ->You have to reimplement this machinery in every quote classe.
> ->What would be the added benefit compare to a more traditionnal
> solution ? (like mine)
>
> I know that you will destroy these arguments in a couple of seconds,
> but it is instructive to understand one's error anyway

Well, it's not an error. I just think it's a less than optimal solution
:)
As for your arguments:

1) your solution actually leads to more machinery. Among the quotes we
currently have, only SimpleQuote manages the value directly, so to
speak. For the other quotes, isValid() is implemented, for instance,
like this:

     bool ImpliedStdDevQuote::isValid() const {
         return !price_.empty()    && !forward_.empty() &&
                 price_->isValid() &&  forward_->isValid();
     }

In your approach, the above becomes:

     bool ImpliedStdDevQuote::isValid() const {
         isValid_ = !price_.empty()    && !forward_.empty() &&
                 price_->isValid() &&  forward_->isValid();
         return isValid_;
     }

i.e., management of the isValid_ data member (directly or via some
method) is forced upon the programmer, which can no longer implement
the interface by just writing the logic (as he does now) but instead
has to worry about the particular implementation of the base class. (*)

2) The added benefit comes from the above. No, let me rephrase this:
the added benefit is the fact that in the current approach, Quote is a
pure interface; the above is a consequence. In your approach, you're
making Quote a somewhat less abstract base class, which is seldom a
benefit. Moreover, you're modeling it after SimpleQuote, which is just
a particular case.

Later,
        Luigi

(*) This is the same issue I had with storing a dayCounter_ data member
in TermStructure itself. On the one hand, we saved having to declare it
in quite a few derived classes, but on the other hand we're left with
classes such as ImpliedTermStructure, which leaves it uninitialized.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev