[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2327) Bit OperationFunctions Inadequately Defined
[ http://tools.oasis-open.org/issues/browse/OFFICE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17905#action_17905 ]
Dennis Hamilton commented on OFFICE-2327:
-----------------------------------------
Exactly. All of those questions and more.
SOME THOUGHTS
I suspect that we should make this be defined for some range of positive precise integers from 0 to 2^kbits-1, where kbits is an ambient property (but so 2^kbits-1 is a precise integer).
It would seem to follow the pattern that there are no constraints other than 0 to 2^kbits-1 be a precisely represented range. I am thinking that the result is mathematically equivalent to mod 2^kbits, shifting left 1 place is equvalent to multipying by 2 mod 2^k, shifting right one place is floor(n/2) and that's it.
The nice thing about staying away from negative numbers in how the function is defined is that these are always safe because there is no sign extension to worry about and shifting left and right each introduce 0 for the vacated positions. I would not forbid implementation-defined behavior for those cases, but I suspect there is no commonly-agree implementation.
USER DISCOVERY AND CONTROL
Sticking to a postive precise integer range, we can discover what kbits is (start with 1 and shift left until it disappears or goes negative or does anything else curious, like no longer being a precise integer. (I was thinking about doing a numCheck-like spreadsheet just to demonstrate that can be done reliably.)
My sense is that different implementations may not have the same value for k although k=48 seems to be achievable most of the time there are some implementations where that may be a stretch.
Question 1: Is requiring that k be at least 48 too demanding?
Question 2: If not, is it going too far to allow it to vary above 48?
It is possible to force kbits=48 behavior (or any smaller value) when kbits is at least 48, but folks would need to remember to mask their results with BITAND after left shifts. It is also possible to inspect for at kbits being at least some desired number and forcing an error otherwise.
ARE WE IN AN INTEROPERABILITY BALL-PARK WITH THESE PROVISIONS?
I have no axe to grind with regard to the value of kbits, I just want to make sure that the functions are well-specified in terms of what case they are defined for.
> Bit Operation Functions Inadequately Defined
> --------------------------------------------
>
> Key: OFFICE-2327
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-2327
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Bug
> Components: OpenFormula
> Affects Versions: ODF 1.2 Part 2 CD 1
> Environment: This issue applies to OpenFormula drafts through OpenDocument-part2-draft17-editor-revision.odt
> Reporter: Dennis Hamilton
> Assignee: Dennis Hamilton
> Fix For: ODF 1.2 Part 2 CD 2
>
>
> [This topic has been discussed on the list and perhaps on calls. This issue and its sub-issues bring management of the various issues to JIRA.]
> The Bit Operations Functions do not precisely establish the sequence of bits that correspond to a given Integer parameter value and the Integer result. Although this is conventional it needs to be described precisely so that the effect of "left" and "right" shifting is understood, including the loss of bits to the left and right, and the introduction of 0 bits on the right and left.
> The means by which the number of bits is specified/known needs to be addressed both with respect to what an OpenFormula-hosting specification might constrain and how implementtion-defined support might be specified, including absence of support for the set of Bit Operation functions..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]