On Thursday, 5 April 2001, at 9:9,
Kurt W Hirchert <[log in to unmask]> wrote:
> At 07:18 AM 4/5/2001 -0400, Dan Nagle wrote:
> >"how many bytes" is a tricky issue because bit_size() applies to
> >integers only, it's actually defined in terms of the processor model
> >of integers.
> In other words, BIT_SIZE doesn't necessarily return the bit size of an
> integer!  It returns a property of the values it can represent, not a
> property of its storage representation.  If some of the bits in the
> representation contribute less than a bit's worth of information to the
> value represented, BIT_SIZE will likely be less than the actual bit
> size.  I know of no implementation where this is true, but I can give some
> examples of the way in which it could happen:
Maybe the standard allows that, but don't think it happens that way.
 For instance:
the NEC SX-5 BIT_SIZE(1) gives 64 - the storage representation size.
HUGE(1) gives 9007199254740991  or (2**53) -1
This is related to the IEEE real representation minus exponent bits.
In C you can override and insist that all 64 bits be available, but not in
F90.
Cray had something similar: 64 bit storage/48 bit values
BIT_SIZE returns the storage size, not the max usable bits for an integer value.
Cheers,
        Len
--
[log in to unmask]:+61 3 9669 8109: CSIRO/Bureau of Meteorology
      High Performance Computing and Communications Centre
      24th floor, 150 Lonsdale St., Melbourne 3000, Victoria, AUSTRALIA