Subject: 48 bits?
Greetings! I have a question about the requirement to support up to 48 bits. A note under BITAND reads: > This specification requires support for at least up to 48 bits. This > is because most implementations use IEEE 754's 64-bit (“double”) > representations for numbers. These have 53-bit mantissas, but there > seemed to be little need to handle exactly 53 bits, and requiring > exactly that support might cause implementation issues without user > need. However, there are many applications where 48 bits of support > are useful. Implementations that use 32-bit number representations can > implement this function with a more limited domain, but they will not > be compliant with this specification. This seemed reasonable, since > users will want to know what range of numbers they can count on, and > this was the largest range that was both useful and relatively easy to > implement. > I can't speak to the "need" to handle exactly 53 bits but why create a variation from IEEE 754's 64-bit representation for numbers? Apparently that is used by a large number of implementations and so saying something different simply creates yet another variance for implementers to be aware of. I suppose this is a more generalized concern about standards but it seems to me that when writing a standard, which one expects to be followed as a standard, then to the extent possible we should follow other standards whenever possible. To put it another way, re-defining (or in tis case, deviating from) standardized values mitigates against the usefulness of standards. Hope everyone is having a great day! Patrick -- Patrick Durusau firstname.lastname@example.org Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)