Some issues

[Jens Thiel]

Hi Luigi,

can you have a look at the following issues or delegate them to the original
authors?


A) Term Structures:

ZeroSpreadedTermStructure and ForwardSpreadedTermStructure BOTH
implement/override forwardImpl() AND zeroYieldImpl(), resulting in an
identical behaviour.


B) ShortFloatingRateCoupon vs. FloatingRateCoupon

Method amount(): Usage of Preceding for rolling back fixing dates is
different and has changed compared to earlier CVS version.



C) Calendars:

Johannesburg calendar class:

  Saturday not documented but implemented as holiday
  may need to add: Human Rights Day 21 March
        (see http://www.national-holidays.com/)
  (anyone from South Africa here?)


London calendar class:

  Some exceptions not properly documented but implemented


Budapest implementation:

  Nov 1st is "All Saints Day", not Labour day.


Sydney calendar

  Documentation from Wellington???
  New Years day possibly not moved?
        (see http://www.national-holidays.com/)
  (anyone from Australia?)


Toronto:

  Some forwards to Monday are not documented but implemented




Regards,

Jens.

[Ferdinando M. Ametrano-2]

Hi Jens


>A) Term Structures:
>
>ZeroSpreadedTermStructure and ForwardSpreadedTermStructure BOTH
>implement/override forwardImpl() AND zeroYieldImpl(), resulting in an
>identical behaviour.
Unless I'm missing something this is probably due to the fact that the
spread is assumed to be constant: in this case spreading the zero or
forward curve is the same.

Things would be different if the spread was a curve, and there is a warning
in ForwardSpreadedTermStructure:
             //! returns the spreaded forward rate
             Rate forwardImpl(Time, bool extrapolate = false) const;
             //! returns the spreaded zero yield rate
             /*! \warning This method must disappear should the spread become a
                          curve
             */
             Rate zeroYieldImpl(Time, bool extrapolate = false) const;.

and a mirror warning in ZeroSpreadedTermStructure:
             //! returns the spreaded zero yield rate
             Rate zeroYieldImpl(Time, bool extrapolate = false) const;
             //! returns the spreaded forward rate
             /*! \warning This method must disappear should the spread become a
                          curve
             */
             Rate forwardImpl(Time, bool extrapolate = false) const;

>Johannesburg calendar class:
>   Saturday not documented but implemented as holiday
fixed

>   may need to add: Human Rights Day 21 March
>         (see http://www.national-holidays.com/)
it looks to me it's already taken into account

>London calendar class:
>   Some exceptions not properly documented but implemented
done. I'm not sure it's worthwhile to document one-off holidays as December
31 1999, or June 3rd, 2002 (Golden Jubilee Bank Holiday), June 4rd, 2002
(special Spring Bank Holiday). If anybody thinks it should be done, please
just go ahead and commit the appropriate comments

>Budapest implementation:
>   Nov 1st is "All Saints Day", not Labour day.
fixed

>   Documentation from Wellington???
what's the problem here?

>Toronto:
>   Some forwards to Monday are not documented but implemented
done. I have a remaining problem with November 11th, possibly moved to
Monday (Remembrance Day):
((d == 11 || (d == 12 && w == Monday)) && m == November)

from the above line I read that it's moved to Monday 12 if the 11th is on
Sunday, but what if the 11th is on Saturday? Shouldn't the Remembrance Day
move to Monday 13 in thus case?
Luigi?

>B) ShortFloatingRateCoupon vs. FloatingRateCoupon
>Method amount(): Usage of Preceding for rolling back fixing dates is
>different and has changed compared to earlier CVS version.
I'll leave that to Luigi

>Sydney calendar
>
>   Documentation from Wellington???
>   New Years day possibly not moved?
>         (see http://www.national-holidays.com/)
Left to Luigi

We could add http://www.national-holidays.com/ in the documentation if we
think it is a good resource


------------
ciao -- Nando

[Luigi Ballabio-2]

Hi,
         sorry for the delay.

At 06:41 PM 12/31/02 +0100, Ferdinando Ametrano wrote:
>Hi Jens
>>A) Term Structures:
>>
>>ZeroSpreadedTermStructure and ForwardSpreadedTermStructure BOTH
>>implement/override forwardImpl() AND zeroYieldImpl(), resulting in an
>>identical behaviour.

It is not really necessary for ZeroSpreadedTermStructure to implement
forwardImpl(); the same goes for ForwardSpreadedTermStructure and
zeroYieldImpl(). However, while the spread is constant it is more efficient
to implement both---especially in the case of ForwardSpreadedTermStructure,
since the default zeroYieldImpl(t) would perform a numerical integration of
the forwards from 0 to t.


>>   Documentation from Wellington???
>what's the problem here?

Fixed.

>>Toronto:
>>   Some forwards to Monday are not documented but implemented
>done. I have a remaining problem with November 11th, possibly moved to
>Monday (Remembrance Day):
>((d == 11 || (d == 12 && w == Monday)) && m == November)
>
>from the above line I read that it's moved to Monday 12 if the 11th is on
>Sunday, but what if the 11th is on Saturday? Shouldn't the Remembrance Day
>move to Monday 13 in thus case?
>Luigi?

Yes, the above is probably wrong. However, national-holidays.com and a
couple other sources say that the holiday doesn't move at all. Oh well. Fixed.


>>B) ShortFloatingRateCoupon vs. FloatingRateCoupon
>>Method amount(): Usage of Preceding for rolling back fixing dates is
>>different and has changed compared to earlier CVS version.
>I'll leave that to Luigi

Oh, yes. As for the changes, there was quite a bit of confusion about
fixing dates. I think the current version is the correct one. As for the
difference between short and regular floating coupon, it's not really there
as Preceding does nothing just as Following, and Following is the default.
But you're right, I'll throw in a Preceding just for clarity.

>>Sydney calendar
>>
>>   Documentation from Wellington???
>>   New Years day possibly not moved?
>>         (see http://www.national-holidays.com/)

Done.

Bye,
         Luigi

[Ferdinando Ametrano-3]

Luigi wrote:
>It is not really necessary for ZeroSpreadedTermStructure to implement
>forwardImpl(); the same goes for ForwardSpreadedTermStructure and
>zeroYieldImpl(). However, while the spread is constant it is more
>efficient to implement both---especially in the case of
>ForwardSpreadedTermStructure, since the default zeroYieldImpl(t) would
>perform a numerical integration of the forwards from 0 to t.
could we add this as comment/documentation in the source code?


ciao -- Nando

[Jens Thiel]

Luigi,

I'm applying some last minute documentation changes to QL.NET, but I have
most of the "deliverables" finished. Can you contact me two days or so
before you release 0.3.1 so I can finish the .NET release,  update the
website and send you a short "project status and description".

Regarding the term structures discussed below, I really can't see any
difference in the resulting behaviour; but maybe that is by design as long
as we have a constant spread. I'm not sure about it.

Another thing: The PieceWiseFlatForward test (or better: the equivalent .NET
test) fails on holidays (because it will lookup the fixing history for the
preceding business day); I guess the same will be true for the SWIG tests.

Jens.

>
> At 06:41 PM 12/31/02 +0100, Ferdinando Ametrano wrote:
> >Hi Jens
> >>A) Term Structures:
> >>
> >>ZeroSpreadedTermStructure and ForwardSpreadedTermStructure BOTH
> >>implement/override forwardImpl() AND zeroYieldImpl(), resulting in an
> >>identical behaviour.
>
> It is not really necessary for ZeroSpreadedTermStructure to implement
> forwardImpl(); the same goes for ForwardSpreadedTermStructure and
> zeroYieldImpl(). However, while the spread is constant it is more
> efficient
> to implement both---especially in the case of
> ForwardSpreadedTermStructure,
> since the default zeroYieldImpl(t) would perform a numerical
> integration of
> the forwards from 0 to t.
>
>
> >>   Documentation from Wellington???
> >what's the problem here?
>
> Fixed.
>
> >>Toronto:
> >>   Some forwards to Monday are not documented but implemented
> >done. I have a remaining problem with November 11th, possibly moved to
> >Monday (Remembrance Day):
> >((d == 11 || (d == 12 && w == Monday)) && m == November)
> >
> >from the above line I read that it's moved to Monday 12 if the
> 11th is on
> >Sunday, but what if the 11th is on Saturday? Shouldn't the
> Remembrance Day
> >move to Monday 13 in thus case?
> >Luigi?
>
> Yes, the above is probably wrong. However, national-holidays.com and a
> couple other sources say that the holiday doesn't move at all. Oh
> well. Fixed.
>
>
> >>B) ShortFloatingRateCoupon vs. FloatingRateCoupon
> >>Method amount(): Usage of Preceding for rolling back fixing dates is
> >>different and has changed compared to earlier CVS version.
> >I'll leave that to Luigi
>
> Oh, yes. As for the changes, there was quite a bit of confusion about
> fixing dates. I think the current version is the correct one. As for the
> difference between short and regular floating coupon, it's not
> really there
> as Preceding does nothing just as Following, and Following is the
> default.
> But you're right, I'll throw in a Preceding just for clarity.
>
> >>Sydney calendar
> >>
> >>   Documentation from Wellington???
> >>   New Years day possibly not moved?
> >>         (see http://www.national-holidays.com/)
>
> Done.
>
> Bye,
>          Luigi
>
>
>

[Luigi Ballabio-2]

At 05:13 PM 1/8/03 +0100, Jens Thiel wrote:
>Regarding the term structures discussed below, I really can't see any
>difference in the resulting behaviour; but maybe that is by design as long
>as we have a constant spread. I'm not sure about it.

There's no difference in case of constant spread. The zero yield at time t
is the average of the instantaneous forward between 0 and t. If a constant
spread  is added to the latter, it will be factored out and appear as a
zero yield spread. The same happens the other way around. Maybe I'm not
getting what the actual question is?

>Another thing: The PieceWiseFlatForward test (or better: the equivalent .NET
>test) fails on holidays (because it will lookup the fixing history for the
>preceding business day); I guess the same will be true for the SWIG tests.

No, the SWIG tests pass just fine. Are you sure you implemented the lookup
logic as it implemented in C? In short:
- if the fixing date is less than today's date, look the fixing up and
   throw if it's not there;
- if the fixing date equals today's date, try and look the fixing up, but
   if it's not there don't throw and forecast instead;
- if the fixing date is greater than today's date, forecast.
Another possibility is that you're bootstrapping the curve on a deposit
with, say, 2 days of fixing and just 1 of settlement. This would put you
before today's date.

Later,
         Luigi

[Jens Thiel]

> >Another thing: The PieceWiseFlatForward test (or better: the
> equivalent .NET
> >test) fails on holidays (because it will lookup the fixing
> history for the
> >preceding business day); I guess the same will be true for the
> SWIG tests.
>
> No, the SWIG tests pass just fine.


No Luigi, they do not (I dare to contradict the master...):

I changed my machines date to Sunday, and got the following results (VC6 and
python 2.1, if it matters), which are consistent to QL.NET tests (see log
below).

While running the tests, I was also able to reproduce an error in the
DateTest. Since it only "throws" in DEBUG mode, I suspect that it gets
caught by some DEBUG-only REQUIRE or so. Haven't looked further into it yet
(see also log below).

Another thing for the final release: .dsp and .dsw files must be checked out
with DOS line-endings. Otherwise VS6 and VS.NET can not open them (you won't
notice this from a CVS checkout as it will automatically adjust EOL).

Beside this, the gm release is converted w/o problems and compiles fine with
VC7 except for a few warnings which I fixed in the CVS tree (while writing
these I also got your mail concerning CVS trunks). I think you can add VC7
to the lists of supported platforms.


Jens.




C:\dvlp\QL-0.3.1gm\QuantLib-Python-0.3.1>python_d setup.py test
Adding parser accelerators ...
Done.
running test
running build
running build_py
not copying QuantLib\__init__.py (output up-to-date)
not copying QuantLib\QuantLib.py (output up-to-date)
running build_ext
skipping 'QuantLib._QuantLib' extension (up-to-date)
testing QuantLib 0.3.1-debug
Testing cap/floor value against cached values ... ok
Testing consistency between cap, floor and collar ... ERROR
Testing put/call parity for cap and floor ... ERROR
Testing cap/floor dependency on strike ... ERROR
Testing covariance calculation ... ok
Testing dates ... ERROR
Testing actual/actual day counters ... ok
Testing distributions ... ok
Testing binomial European engines against analytic results ... ok
Testing European option greeks ... ok
Testing European option implied volatility ... ok
Testing old-style American-type pricers ... ok
Testing old-style barrier option pricer ... ok
Testing old-style binary option pricer ... ok
Testing old-style cliquet option pricer ... ok
Testing old-style European option pricer with dividends ... ok
Testing old-style finite-difference European option pricer ... ok
Testing old-style Monte Carlo multi-factor pricers ... ok
Testing old-style Monte Carlo single-factor pricers ... ok
Testing observability of stocks ... ok
Testing composite market element ... ok
Testing derived market elements ... ok
Testing observability of market elements ... ok
Testing observability of market element handles ... ok
Testing differential operators ... ok
Testing piecewise flat forward curve ... ERROR
Testing risk statistics ... ok
Testing segment integral ... ok
Testing simple swap calculation against cached value ... ok
Testing simple swap calculation of fair fixed rate ... ERROR
Testing simple swap calculation of fair floating spread ... ERROR
Testing simple swap dependency on fixed rate ... ERROR
Testing simple swap dependency on floating spread ... ERROR
Testing 1-D solvers ... ok
Testing statistics ... ok
Testing swaption value against cached value ... ok
Testing swaption dependency on spread ... ok
Testing swaption treatment of spread ... ok
Testing swaption dependency on strike ... ok
Testing consistency of forward-spreaded term structure ... ERROR
Testing observability of forward-spreaded term structure ... ok
Testing consistency of implied term structure ... ERROR
Testing observability of implied term structure ... ok
Testing consistency of zero-spreaded term structure ... ERROR
Testing observability of zero-spreaded term structure ... ok

======================================================================
ERROR: Testing consistency between cap, floor and collar
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\capfloor.py", line 114, in testConsistency
    if abs((cap.NPV()-floor.NPV()) - collar.NPV()) > 1.0e-10:
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 760, in NPV
    def NPV(*args): return apply(_QuantLib.Instrument_NPV,args)
RuntimeError: Euribor6m act/360 history not loaded
======================================================================
ERROR: Testing put/call parity for cap and floor
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\capfloor.py", line 144, in testParity
    if abs((cap.NPV()-floor.NPV()) - swap.NPV()) > 1.0e-10:
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 760, in NPV
    def NPV(*args): return apply(_QuantLib.Instrument_NPV,args)
RuntimeError: Euribor6m act/360 history not loaded
======================================================================
ERROR: Testing cap/floor dependency on strike
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\capfloor.py", line 70, in testStrikeDependency
    values.append(instrument.NPV())
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 760, in NPV
    def NPV(*args): return apply(_QuantLib.Instrument_NPV,args)
RuntimeError: Euribor6m act/360 history not loaded
======================================================================
ERROR: Testing dates
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\date.py", line 29, in runTest
    dyold  = QuantLib.Date(mindate-1).dayOfYear()
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 417, in __init__
    self.this = apply(_QuantLib.new_Date,args)
RuntimeError: Date 366outside allowed range [January 1st, 1901-December
31st, 20
99]
======================================================================
ERROR: Testing piecewise flat forward curve
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\piecewiseflatforward.py", line 605, in runTest
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 1209, in fixing
    def fixing(*args): return apply(_QuantLib.Index_fixing,args)
RuntimeError: Could not bootstrap curve. segment 7 of 21, last forward =
0.044 ,
 last discount =  0.9670720042 , last zero-yield =  0.044 , last guess was
0.956
368992145496 error generated by dummy6m act/360 history not loaded
======================================================================
ERROR: Testing simple swap calculation of fair fixed rate
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\simpleswap.py", line 60, in testFairRate
    swap = self.makeSwap(length, swap.fairRate(), spread)
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 3127, in fairRate
    def fairRate(*args): return apply(_QuantLib.SimpleSwap_fairRate,args)
RuntimeError: Euribor6m act/360 history not loaded
======================================================================
ERROR: Testing simple swap calculation of fair floating spread
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\simpleswap.py", line 76, in testFairSpread
    swap = self.makeSwap(length, rate, swap.fairSpread())
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 3128, in fairSpread
    def fairSpread(*args): return
apply(_QuantLib.SimpleSwap_fairSpread,args)
RuntimeError: Euribor6m act/360 history not loaded
======================================================================
ERROR: Testing simple swap dependency on fixed rate
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\simpleswap.py", line 94, in testRateDependency
    values.append(swap.NPV())
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 760, in NPV
    def NPV(*args): return apply(_QuantLib.Instrument_NPV,args)
RuntimeError: Euribor6m act/360 history not loaded
======================================================================
ERROR: Testing simple swap dependency on floating spread
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\simpleswap.py", line 117, in testSpreadDependency
    values.append(swap.NPV())
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 760, in NPV
    def NPV(*args): return apply(_QuantLib.Instrument_NPV,args)
RuntimeError: Euribor6m act/360 history not loaded
======================================================================
ERROR: Testing consistency of forward-spreaded term structure
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\termstructures.py", line 100, in testFSpreaded
    forward = self.termStructure.instantaneousForward(test_date)
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 547, in
instantaneousFor
ward
    def instantaneousForward(*args): return
apply(_QuantLib.TermStructure_instan
taneousForward,args)
RuntimeError: Could not bootstrap curve. segment 6 of 10, last forward =
0.044 ,
 last discount =  0.9670720042 , last zero-yield =  0.044 , last guess was
0.956
368992145496 error generated by dummy6m act/360 history not loaded
======================================================================
ERROR: Testing consistency of implied term structure
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\termstructures.py", line 69, in testImplied
    base_discount = self.termStructure.discount(new_settlement)
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 544, in discount
    def discount(*args): return apply(_QuantLib.TermStructure_discount,args)
RuntimeError: Could not bootstrap curve. segment 6 of 10, last forward =
0.044 ,
 last discount =  0.9670720042 , last zero-yield =  0.044 , last guess was
0.956
368992145496 error generated by dummy6m act/360 history not loaded
======================================================================
ERROR: Testing consistency of zero-spreaded term structure
----------------------------------------------------------------------
Traceback (most recent call last):
  File "QuantLib/test\termstructures.py", line 133, in testZSpreaded
    zero = self.termStructure.zeroYield(test_date)
  File "build\lib.win32-2.1\QuantLib\QuantLib.py", line 545, in zeroYield
    def zeroYield(*args): return
apply(_QuantLib.TermStructure_zeroYield,args)
RuntimeError: Could not bootstrap curve. segment 6 of 10, last forward =
0.044 ,
 last discount =  0.9670720042 , last zero-yield =  0.044 , last guess was
0.956
368992145496 error generated by dummy6m act/360 history not loaded
----------------------------------------------------------------------
Ran 45 tests in 235.909s

FAILED (errors=12)
[81311 refs]

[Luigi Ballabio-2]

At 05:55 PM 1/10/03 +0100, Jens Thiel wrote:

> > >Another thing: The PieceWiseFlatForward test (or better: the
> > equivalent .NET
> > >test) fails on holidays (because it will lookup the fixing
> > history for the
> > >preceding business day); I guess the same will be true for the
> > SWIG tests.
> >
> > No, the SWIG tests pass just fine.
>
>
>No Luigi, they do not (I dare to contradict the master...):

Go ahead. You're way too large to be a padawan anyway :)

>I changed my machines date to Sunday, and got the following results

Ouch, I guess I missed the "on holidays" bit.
You're right. Let me think aloud a moment, what happens is that:
- today is Sunday;
- the start date of the deposits is two business days ahead, i.e., Tuesday;
- the deposit looks up the fixing for Tuesday minus two business days, which
   goes all the way back to Friday, which is before Sunday;
- the index doesn't find the fixing and throws (which, I must add, serves you
   right for working on holidays...)

The question now is, what do we do in this case? On the one hand, replacing
     if (fixingDate < today)
with
     if (calendar.roll(fixingDate) < calendar.roll(today))
would "fix" the test, i.e., the code will forecast the fixing.
But on the other hand, if we're really on Sunday, is the above the real
practice? Or do traders do something different?

Ideas?

Later,
         Luigi

[Jens Thiel]

> Go ahead. You're way too large to be a padawan anyway :)

a what...?

> You're right. Let me think aloud a moment, what happens is that:
> - today is Sunday;
> - the start date of the deposits is two business days ahead,
> i.e., Tuesday;
> - the deposit looks up the fixing for Tuesday minus two business
> days, which
>    goes all the way back to Friday, which is before Sunday;
> - the index doesn't find the fixing and throws (which, I must
> add, serves you
>    right for working on holidays...)
>
> The question now is, what do we do in this case? On the one hand,
> replacing
>      if (fixingDate < today)
> with
>      if (calendar.roll(fixingDate) < calendar.roll(today))
> would "fix" the test, i.e., the code will forecast the fixing.
> But on the other hand, if we're really on Sunday, is the above the real
> practice? Or do traders do something different?
>

In C#, I fixed at least the test with
        DateTime todaysDate = calendar.Roll(DateTime.Today);

The "problem" is that the test assumes that it has a current deposit quote
even on sundays, while on the other hand the library behaves more
intelligently and rolls back to friday.

This would at least justify the above fix, since this "missing knowledge of
market behaviour on holidays" does not change the usefullness of the test
case itself. On the long run, the test may roll back to a business day to
build the curve on it's hardcoded data.

Or am I missing something?


Jens.

[Ferdinando M. Ametrano-2]

>- today is Sunday;
>- the start date of the deposits is two business days ahead, i.e., Tuesday;
>- the deposit looks up the fixing for Tuesday minus two business days, which
>   goes all the way back to Friday, which is before Sunday;
>- the index doesn't find the fixing and throws (which, I must add, serves you
>   right for working on holidays...)
>
>The question now is, what do we do in this case?

my opinion is that on Sunday you are supposed to know last Friday fixing

------------
ciao -- Nando

[Ferdinando M. Ametrano-2]

At 06:37 PM 1/10/2003 +0100, you wrote:
>In C#, I fixed at least the test with
>         DateTime todaysDate = calendar.Roll(DateTime.Today);
I second this fix. The problem in my opinion was only in the test, not in
QuantLib. QuantLib assumes that on Sunday you are required to know Friday's
fixings. This is correct, since those fixings happened in the real world.

You are not supposed to run the test on Sunday ;-) without taking into
account Friday's fixings.

Am I missing something?

------------
ciao -- Nando

[Ferdinando M. Ametrano-2]

At 05:55 PM 1/10/2003 +0100, you wrote:
>Another thing for the final release: .dsp and .dsw files must be checked out
>with DOS line-endings. Otherwise VS6 and VS.NET can not open them (you won't
>notice this from a CVS checkout as it will automatically adjust EOL).

I am fully aware of this problem. When I was in RiskMap there was an
automated procedure that  created the DOS Line-ending compliant Windows
version from the unix source distribution OR checked out its own sources.
If that procedure is still working would you Luigi please upload all the
generated files?

If not I cannot use the golden master sources and I'll have to check them
on my own, which should not be a big problem anyway, since I should be
checking out the tip of the release branch that is not supposed to change
frequently

ciao -- Nando  

[Luigi Ballabio-2]

At 07:50 PM 1/10/03 +0100, Ferdinando Ametrano wrote:

>At 06:37 PM 1/10/2003 +0100, you wrote:
>>In C#, I fixed at least the test with
>>         DateTime todaysDate = calendar.Roll(DateTime.Today);
>I second this fix. The problem in my opinion was only in the test, not in
>QuantLib. QuantLib assumes that on Sunday you are required to know
>Friday's fixings. This is correct, since those fixings happened in the
>real world.
>
>You are not supposed to run the test on Sunday ;-) without taking into
>account Friday's fixings.
>
>Am I missing something?

Well, if you're pricing an instrument, you're right.
But the problem is that as far as I see, it's the bootstrapping itsels that
fails. This happens because the swaps inside the SwapRateHelpers look for
Friday's fixing, which they are not supposed to do anyway---that would be
like saying that when bootstrapping the curve on Wednesday afternoon, the
swaps inside the rate helpers should use the mid-day fixings for evaluating
their first coupon. You don't want to do that---the set of deposit and swap
rates you passed to the curve should suffice.

Well, let's say that as a temporary measure we can roll the date in the test.
I'll make the changes after sending this mail. But in the long run, we
can't just say that one can't bootstrap a curve on Sundays. It sounds too
much like the old joke ("Doctor, my arm hurts when I do this." "Well, don't
do it.")

Later,
         Luigi

[Luigi Ballabio-2]

At 08:18 PM 1/10/03 +0100, Ferdinando Ametrano wrote:
>At 05:55 PM 1/10/2003 +0100, you wrote:
>>Another thing for the final release: .dsp and .dsw files must be checked out
>>with DOS line-endings. Otherwise VS6 and VS.NET can not open them (you won't
>>notice this from a CVS checkout as it will automatically adjust EOL).

Just a thought. On my Mac at home, the port of tar I'm using automatically
converts Unix EOLs to Mac EOLs while extracting. Isn't there a tar
extractor for Windows which does the same?

Later,
         Luigi

[Jens Thiel]

> Just a thought. On my Mac at home, the port of tar I'm using
> automatically
> converts Unix EOLs to Mac EOLs while extracting. Isn't there a tar
> extractor for Windows which does the same?
>

Winzip has "TAR file smart CR/LF conversion", which is disabled by default.
I have in mind that this is recommended as it is not really "smart".

Maybe a .zip distribution file is the better choice for Win32 users anyway.

Jens.

[Luigi Ballabio-2]

At 04:28 PM 1/13/03 +0100, Jens Thiel wrote:
> > Just a thought. On my Mac at home, the port of tar I'm using
> > automatically converts Unix EOLs to Mac EOLs while extracting. Isn't
> there > a tar extractor for Windows which does the same?
>
>Winzip has "TAR file smart CR/LF conversion", which is disabled by default.
>I have in mind that this is recommended as it is not really "smart".
>
>Maybe a .zip distribution file is the better choice for Win32 users anyway.

Oh, sure. I was just trying to make life easier for you (when you try a
tarball) and for Nando (who will take the golden master and make Win32
distributions out of it). When we release, normal users will get their .zip
files all right, with the EOLs already converted.

Bye,
         Luigi

P.S. Nando, any news about the files you should modify?

[Ferdinando M. Ametrano-2]

>P.S. Nando, any news about the files you should modify?
go ahead with the golden masters

later

------------
ciao -- Nando