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] BITAND

Three things:

1. I think these issues should be raised in JIRA.

2. If the statement is a normative one (and I am sure it is intended to be),
it must specify the conformance targets to which it applies.  I am not sure
what they are in this case, although it appears that it is an evaluator that
shall accept parameters of at least 48 bits and be able to produce results
that require up to 48 bits for exact representation.  (In this regard, I
emphatically disagree with the PS in the note from Andreas, and I believe
the OASIS conformance guidelines are also in conflict with that PS.)  Note
that these constraints are semantic (or notional), not syntactic/lexical.  

3. This also raises the question about what is acceptable behavior if an
otherwise-compliant evaluator encounters a value requiring a wider binary
representation than it supports.  This is also a good place to test our
notions of "portability."  And I think there is also an
"implementation-defined" prescription to be made concerning bitwise

 - Dennis

PS: 4. We need some attention to how we talk about bits and sequences of
bits, unless we are presuming a bit-sequence/binary data type.  And even
then, we need careful language.  For example, when the parameters are of
Numeric type, I suspect we must say "exact integer values from 0 to 2^48-1
inclusive" - but with the mathematical form for 2^48-1, not an OpenFormula
form.  Then we must say something such as the function, when given a numeric
operand, operates on the bits of the binary-coded expression of the
exact-integer part of the number's magnitude [or are negative values
forbidden?  Are fractional components forbidden or to be ignored?  What if
there is no exact integer part (the number being too large for the low-order
bits to be represented exactly)?].

PPS: 5. It would be good to express the above as a general rule for operands
that are to be interpreted as sequences of bits (versus operands that are
sequences of bits, being the result of other bit-logical functions or
contents of cells that have such data).  There is also the small issue of
results of functions that are defined to be sequences of bits and what
happens if they are then to be delivered as Number values.  The edge case
here has to do with any complementing that tends to require an indefinite
number of leading "1" bits unless there is some parametric control on what
the maximum number of bits shall be and how more-than-that many leading bits
are safely truncated when logically all "1" or all "0".  

PPPS: 6. I see I should be following my own advice.  See (1, above).  OK, so

P4S: 7. I hope we can all agree that a sufficient result from


(with 42 leading 0's in the string form of the second operand) is the
Numeric value 1.  On the other hand, 

BITAND(1,173000000000000000000000000000000000000000000) might produce either
Numeric value 0 or #VALUE or some other error indicator.  

P5S: 8. I would expect that the containing document should not be flunked in
the case of an exception result, since it generally not possible to know all
of the problems except dynamically, and the containing document might
otherwise be just fine.  This goes beyond OpenFormula to how it is hosted,
so there are some things to say about having error results is not
non-conformant so long as the hosting application and format allows them to
be stored in the persistent document instance.  The OpenFormula spec
probably does need to say something about an exception value being supplied
as a parameter to a function, of course.

[Oh, you got me started.  You would surmise correctly that I spent some
early-career time in a novel-at-the-time [1963] software testing group for a
computer manufacturer.  I hated it, just wanting to write excellent and
properly-tested code myself (and don't get me going on maintaining other
people's code).  The karma of it: These days, over 50 years later, I find
that I can't help thinking like an architect/tester around specifications
and specification-based software (interfaces).  Obviously, I am the same
about specs as I am about solid code.  There's not much difference, really.]

-----Original Message-----
From: Andreas J. Guelzow [mailto:aguelzow@pyrshep.ca] 
Sent: Thursday, December 10, 2009 10:01
To: office-formula@lists.oasis-open.org
Subject: Re: [office-formula] BITAND

On Thu, 2009-12-10 at 08:32 -0500, Patrick Durusau wrote:
> Greetings!
> In BITAND we say:
> > To comply with this specification, an implementation *shall* support 
> > parameters of at least 48 bits (values from 0 to 2^48-1 inclusive); 
> > they *may* support values with more bits.
> >
> Is this meant to be a requirement for *any* conformance to OpenFormula?

"shall" support ... yes


PS: Of course this "To comply with this specification" is unnecessary
everywhere, since by design the specification states what one needs to
comply with.

Andreas J. Guelzow <aguelzow@pyrshep.ca>

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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