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

["David A. Wheeler" <dwheeler@dwheeler.com>]

> OOo currently tries to calculate GCD and LCM with non-integer arguments,
> more or less (more less) successfully. Btw, GCD(18.1;24.1) actually
> returns 7.105427357601E-015 ...
> 
> Even if there may be applications to calculate a LCM of non-integers,
> e.g. recurring period of overlapping wave forms, finding a corresponding
> LCM/GCD pair that suffices the relation
> 
> |a*b| = GCD(a,b) * LCM(a,b)
> 
> with GCD really being the _greatest_ common divisor would probably go
> beyond what we want to define here. I therefor propose to define that
> 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.

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)?

> As for negative integer arguments: definitions of GCD say it is the
> largest integer of the factorization and usually do not define that the
> two numbers have to be positive integers or natural numbers, but speak
> of integers. So negative arguments would be permittable, and as there
> are always two possible solutions a and b for each GCD with a = -b, it
> would also be correct to return a negative result if one of the
> arguments is negative, as OOo currently does. However, most GCD
> definitions say to ignore negative factorization, but it isn't required.
> 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?

This is one area that we could probably leave implementation-defined for this version, with maybe a note about what many implementations do.  But if we can get even better consensus, we should.  In cases where (1) it doesn't matter for practically everyone and (2) there's no consensus, I'd rather go with "implementation-defined" for this version.

> 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.

--- David A. Wheeler