OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] GCD and LCM non-integer arguments


Hi David,

On Thursday, 2007-01-18 13:25:45 -0500, David A. Wheeler wrote:

> > arguments are to be converted to INT for both functions.
> 
> I think that's a great idea.  I think ALL other implementations
> convert to INT first; non-INT GCD and LCM are interesting, but I doubt
> many actually WANT them.

Most certainly not.

> I don't see a big call for a GCD and LCM that take non-integers.
> Perhaps if OOo keeps them, they can go into the OOo-unique space.  But
> if you think we should, I'd be happy defining two functions that
> accept non-integers (name, anyone)?

For OOo we'll change implementation anyway, as the current non-integer
handling is suboptimal. This will change to conversion to integers.

> > Anyway, negative arguments are perfectly valid, just that other
> > applications don't allow them. We could now define
> > 
> > a) If one of the arguments is negative, the function results in an
> >    error.
> > 
> > b) If exactly one of the arguments is negative the result is negative.
> >    If both arguments are negative the result is positive.
> > 
> > c) The result is always positive.
> > 
> > Opinions?
> 
> All are plausible.  Is there a consensus in the implementations?

Consensus is an error result for negative arguments. I'd be fine with
changing OOo implementation to follow that for interoperability.

This together with the integer handling and the definition of
GCD(0;0)==0 would also make the GCD_ADD and LCM_ADD functions OOo has
for Excel Toolpak compatibility superfluous.

> > Btw, GCD(a;0) results in a. An additional definition allows
> > GCD(0;0)==0, which is useful and also is what Excel and Kspread do.
> 
> Good idea.

Both "when at least one argument is 0" handlings are not implemented in
Gnumeric, even if it claims the function would be Excel compatible. This
seems to be an error in Gnumeric. I think we're fine defining it the
compatible way.

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]