Re: [office] Excel 2007 != Ecma spec YEARFRAC. Not even slightly. What should we do?

["Warren Turkal" <turkal@google.com>]

I don't see any substantive difference beteween using strings and
using numbers to identify the basis. My main reason for suggesting
string representation was so that when I look at an odf formula, I can
use the string as a neumonic instead of having to go back to the
standard to find out what basis==0 means.

wt

On Fri, Apr 18, 2008 at 12:59 PM,  <robert_weir@us.ibm.com> wrote:
>
> From a storage perspective,  is there any backwards compatibility problem
> caused by moving from our current integer bases to strings, where five of
> the strings are "0", "1", "2", "3" and "4" ?
>
> If we did that we could add others like "NYSE_X25", "ISDA_Rule25" or
> whatever.
>
> -Rob
>
>
> "David A. Wheeler" <dwheeler@dwheeler.com> wrote on 04/18/2008 02:56:31 PM:
>
>
>
>  > In general, the formula specification tries to follow EXISTING
>  > conventions wherever reasonable.  _All_ spreadsheet implementations
>  > use integer "basis" values for all their functions that have
>  > such a parameter.  I agree that using a string has its merits,
>  > but using an integer is reasonable enough.
>  > In fact, integers make it easy to create "ranges", and would
>  > actually _ease_ transitions if there are differing interpretations
>  > of basis values.
>  >
>  > I think we should try to AVOID spec'ing something incompatible
>  > with all existing implementations unless we have a pressing
>  > need to do so, and I don't think this is compelling.  That said...
>  >
>  >
>  > > On Fri, Apr 18, 2008 at 7:00 AM, David A. Wheeler
>  > <dwheeler@dwheeler.com> wrote:
>  > > >  The problem is that basis values need not be a constant in the
>  > cell; it might be
>  > > >  from another cell and/or a calculation (directly or indirectly),
> e.g.:
>  > > >  YEARFRAC([.A5];[.B5];[.C5]+1)
>  >
>  > Warren Turkal:
>  > > This seems like an unrealistic use case. In all sincerity, why would
>  > > someone do that? Is it common? I just don't see folks selecting the
>  > > basis by saying I want whatever the basis is identified by taking the
>  > > identifier of some basis (e.g. actual/actual) and adding 1 to it.
>  >
>  > You're right, that was a silly example.
>  >
>  > But a more realistic one is:
>  >
>  >  YEARFRAC([.A5];[.B5]; IF(CONVENTION="US"; 0; 4))
>  >
>  > Now the filter has to start digging through the expression tree,
>  > or end up with a complicated resulting expression.  Ugh.
>  >
>  > > Having said that. If people do it, import filters can just map it to
>  > > whatever fixed string it's value corresponds to on import...
>  >
>  > Yes, import filters can fix it... but let's try to make it easy on
>  > the filters!
>  > Simple implementation is very important for getting a spec implemented.
>  >
>  > Switching from an integer to a string representation does NOT
>  > really ease the "different basis interpretation" problem at all.
>  > It just means that EVERYONE has to convert, instead of only
>  > SOME people having to convert.  That makes things worse, not better.
>  > Integers also tend to be more efficient, and make it easy to
>  > do conversions of whole groups (e.g., we could make the
>  > Excel 2007 and OOXML conventions differ by 128, and then
>  > adding/subtracting 128).
>  >
>  > Since everyone uses integers NOW for basis values, let's try to stick
>  > with that if it's practical to do so.  And I think it is.
>  >
>  > --- David A. Wheeler
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  You may a link to this group and all your TCs in
> OASIS
>  > at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >
>