Comment 3 for bug 127505

Hi Robert,

I'm the guy who opened this bug report. The easiest thing to do is get a
copy of Microsoft's Excel program & use their YEARFRAC function in an
array
of cells with various values, then compare them to openoffice's look-
alike.

The expected results are also implied in the bug report description:
e.g.,
"one day apart"; meaning it is really easy to catch failing values --
just
compute the year by your own calculation, an almanac, or any number of
online tools that return things like "How many days from...".

If you don't want to trust EXCEL then consider that even if EXCEL is
occasionally wrong sometimes the question to consider is this. Is the
goal
for openoffice's version to be CORRECT or just CONSISTENT with EXCEL?
That's
a much trickier question than you might think. Years ago I worked at
IBM on
Instruction Set microcoding in System/370/390 machines & when we
fixed many
of the elementary math library functions (sine, cosine, square root,
etc..)
to be CORRECT then all kinds of things broke for users whose
calculations
manually corrected for inconsistencies in the old routines out there
that
used and depended on these (lots and lots!). Nastily they also broke for
subtle things like the fact that now "new and different" results were
returned because of the difference in roundings between the new (and
correct) and the old (wrong, sometimes, extremely wrong) function
calls and
instructions. E.g. something as simple as x=sqrt(x*x) would produce
an actual inequality if you round both sqrt(x) and Y*Y differently in
one
library versus the other. Lastly there was the fun of old but fixed
routines
having to coexist with old not-fixed yet routines! It was a
nightmare. Lots
of fun. The brilliant mathematicians at IBM Research who devised most
of the
algorithms -- some luminaries there as well! Jim Cooley and Bryant
Tuckerman
-- were both chagrined and humbled by the results of "interfacing
with the
world of users" -- not the ivory tower. :-)

The reason I put in the weird-sounding hints re: leap years is that --
having worked on date and time functions for the Ingres database
(years and
years ago :-)) and fixed issues with certain dates and with certain
times,
esp. between different time zones & the Gregorian, Julian, Russian time
jumps -- I know that leap years cause head-aches as special
conditions: skip leap
years across century changes except for millennium changes and so on ...
So, the programming algorithms, shared functions, and
special-condition handling of anyone's particular date & time
implementation
all have a lot to do with how accurately these work across the large
(but
practically bounded) input arguments spectrum. You can do an extremely
thorough job of testing these, though, as you can, e.g., blast
monotonically
increasing dates and times at it & actually exhaust the valid data
input &
combinations spectrums. Dates way in the future can be excluded as
well as
before the big bang which bounds the spectrums. Computers sure are fast.

Good luck,

-- Jim

On Dec 14, 2010, at 11:32 PM, Robert Roth wrote:

> Can anyone specify what the expected results are for the examples
> specified in the bug description? Thanks.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/127505
>
> Title:
> [Upstream] [hardy] YEARFRAC function returns incorrect results
> for some dates