Re: COUPDAY* functions

[Neil Booth <neil daikokuya demon co uk>]

Andreas J. Guelzow wrote:-

> It wasn't quite correct (ie. it didn't match XL because they fell into a 
> trap. Well, we can do that too. I committed appropriate change s a few 
> hours ago.

It *was* correct; Excel's bugginess does not detract from the
correctness of your function!

I had a laugh, actually, looking at this.  Asking Excel for COUPNCD
for a bond maturing on 28/11/9999 with settlement around now, leaves
it thinking for over a second, because it does just loop all the way
back.  That's _really_ sad; it is a shameful implementation.

> It turns out that using serial dates makes things awfully complicated. 

Yeah, I can believe that.  However, if you have some improved julian
date functions (only 2 or 3 needed), working on them raw can be easier
than gdates (or, at least, it's a matter of taste).  The thing I miss
the most about gdate is that it doesn't allow you to create an
"invalid" (d, m ,y) triple like (0, m + 1, y).  That is just a slick
(and efficient) way to get the last calendar day of month (m, y), to
give but one example.  gdate is not as efficient as it might be in
this area.  It's (d, m, y) -> julian conversion could be faster too.
If I'm bored I might see if the glib maintainers are interested in any
patches.

> THe basis=0 30/360 convention wasn't quite right, but I nearly got it 
> now. (Febraury 28th sometimes becomes February 30th in the calscs)

Yup, more precisely end-of-feb->30, as does 31.  [You can express the
rule as end-of-month->30; but such an implementation would probably be
less efficient].

> Why can't they use real dates???

It was intended to make things simple before the days of computers.
Otherwise you'd need tables to calculate the number of days between 2
dates; saying every month has 30 makes it a tad simpler for
in-your-head calculations.  This backfired, however, seeing as there
are 5 different definitions on what 30/360 really means.

Anyway, there are only 3 30/360 conventions in use now.  30/360,
30E/360 and 30E+/360.  Excels number "0" is also known as PSA 30/360,
and to the best of my knowledge is totally unused outside of Microsoft
8-).  If anyone has any evidence to the contrary, I'd love to hear it
- Bloomberg doesn't implement it, which must mean it's non-existent.
My description of 30E+/360 was wrong; I will update that soon.

Neil.