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

# office-comment message

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

Subject: RE: [office-comment] Error in FLOOR function specification

• From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
• Date: Sat, 21 Feb 2015 08:23:26 -0800

```OK, thanks for bringing this back to the list Joe.

I think the point is that it is the absolute value that is taken "away from zero" so for x < 0 that will be the correct result after the sign is put back on the result (and it is rescaled back to a multiple of N as required).

I find some other things strange about this, including the undefined case that Andreas points out.  I had not looked at that part of the definition.

Although Excel gets floor(-53,5) correctly, Apache OpenOffice treats it as an error.  On the other hand, Excel does not like floor(53,-5) at all even though, mathematically, that is perfectly good as well.

I think what is mistaken here, and perhaps in other places in OpenFormula, is the use of an operational, implementation-sounding definition when the definition of the mathematical behavior that is desired is perfectly clean and allows implementations to do whatever is appropriate that preserves the defined invariant.

KEEPING IT SIMPLE

In particular, floor(x) is the largest integer not greater than x, ceiling(x) is the smallest integer not less than x.  Similarly, floor(x,p) is the largest integer multiple of p not greater than x and ceiling(x,p) is the smallest integer multiple of p not less than x.  p=0 needs to be dealt with of course, but whether p is positive or negative, the definition still works (the sign of the appropriate integer multiplier will change is all -- it is the multiple, not the multiplier, that matters, the same as when x is negative).

The definitions for interchange purposes can be restricted, but I see no reason to specify error results where there is no problem with the mathematics.  Implementation-defined would be more suitable.

- Dennis

-----Original Message-----
Sent: Friday, February 20, 2015 17:02
Cc: office-comment@lists.oasis-open.org
Subject: Re: [office-comment] Error in FLOOR function specification

On Fri, Feb 20, 2015 at 9:39 AM, Dennis E. Hamilton
<dennis.hamilton@acm.org> wrote:
>
> Please read the definition I gave for classical floor one more time.  The result is never greater than the given argument.  For ceiling, the result is never less than the given argument.
>
> And I agree, with the significance parameter, floor(53,5) is 50 (i.e., the greatest integer multiple of 5 not greater than 53).  Likewise, floor(-53,5) is -55.
>
> Note that I did not ever use toward or away from zero in my statement of the classical condition, but pointed out how those statements could line up.  Remember, the away from zero statement in OpenFormula is when x < 0 for FLOOR(x,s).

I don't really disagree with any of your arguments - they seem quite
sound - but also seem to be tangential to the issue that I am trying

Your last sentence here, however, seems contrary to my reading of the
standard.  The "away from zero" statement ("If mode is given and not
equal to zero, the absolute value of N is rounded away from zero")
seems to apply in the case that the mode (s) is given and not equal to
zero, and doesn't seem to hinge on the value of x at all.

And even if it did apply when x < 0, "away from zero" would still be
incorrect, since the text states that the absolute value of x/N is
what is being rounded.

And so according to this definition, floor(53,5) would pretty clearly
be 55.  The mode is given (5) and not equal to zero, so abs(53) is
rounded away from zero, to 55.  And I think we can all agree that
floor(53,5) should not be 55.

There may well be other issues with these definitions, but the "away
from zero" in the definition of FLOOR seems pretty clearly a simple
typographical/copy-paste error that can be addressed in a fairly
straightforward manner.

>
>
> I agree that the elaborations in the OpenFormula specification can be confusing.  It would be far better to stick with a mathematical definition avoiding all that operational business about stripping and restoring "-" signs.  A couple of careful examples would demonstrate to people that they need to pay careful attention to the basic rule, which is very clean.  And of course, it is even more painful to introduce "rounding" as explanatory in this context.  FLOOR and CEILING are very simple, in all of their forms, and there is no need to get weird about how to handle negative arguments at all, so long as the implementation gets it right.
>
>  - Dennis
>
> -----Original Message-----
> From: cowan@ccil.org [mailto:cowan@ccil.org]
> Sent: Friday, February 20, 2015 08:28
> To: dennis.hamilton@acm.org
> Cc: office-comment@lists.oasis-open.org
> Subject: RE: [office-comment] Error in FLOOR function specification
>
> Dennis Hamilton scripsit:
>
> > Let's simplify this as it applies to having integer results:
>
> Your argument is impeccable where the significance is not present.
> But where it is present, if the "away from zero" were correct,
> then floor(53,5) would be 55, whereas in fact it is 50.  So
> "away from zero" is incorrect, and it should be changed to
> "toward zero", as Joel says.
>
> Alternatively, it would also be correct to say "toward negative infinity"
> in both cases, since the value being rounded, being an absolute value, is
> in fact always positive.
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
> At times of peril or dubitation,
> Perform swift circular ambulation,
> With loud and high-pitched ululation.
>
>
>
> --
> This publicly archived list offers a means to provide input to the
> OASIS Open Document Format for Office Applications (OpenDocument) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: office-comment-subscribe@lists.oasis-open.org
> Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
> List help: office-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/office-comment/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
> Join OASIS: http://www.oasis-open.org/join/
>
>
> --
> This publicly archived list offers a means to provide input to the
> OASIS Open Document Format for Office Applications (OpenDocument) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: office-comment-subscribe@lists.oasis-open.org
> Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
> List help: office-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/office-comment/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
> Join OASIS: http://www.oasis-open.org/join/
>

--
This publicly archived list offers a means to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: office-comment-subscribe@lists.oasis-open.org
Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
List help: office-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/office-comment/