48 bits?

[Patrick Durusau <patrick@durusau.net>]

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
patrick@durusau.net
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)