Re: Cohen's paper on byte order

From: Brian Gladman (brg@gladman.plus.com)
Date: 04/02/03 

From: "Brian Gladman" <brg@gladman.plus.com>
Date: Wed, 2 Apr 2003 00:56:08 +0100

"David Hopwood" <david.hopwood@zetnet.co.uk> wrote in message
news:3E89BF0E.15C63B24@zetnet.co.uk...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Brian Gladman wrote:
> > "Roger Schlafly" <rogersc@mindspring.com> wrote:
> > > "Brian Gladman" <brg@gladman.plus.com> wrote
> > > > However my point is a more general one - namely that it is wrong to
> > > > assume that strings of bits necessarily represent integers.
>
> That was never assumed by anyone in this thread, AFAICS.

This was assumed in suggesting that the early evaluation of a bit stream
representing a big-endian number could not be evaluated unless the bit
length of the complete representation was known in advance. I pointed out
that a fractional numeric representation did not have this limitation.

> > > Once you load a string of bits into a computer register, then there
> > > is an implied numeric equivalent, and hence a least-significant
> > > and MS bit. Maybe somewhere there is a CPU with a register
> > > of just bits, where the CPU can only AND, OR, XOR, and
> > > maybe other bit operations. But all the ones I know let you
> > > ADD, and hence define an integer meaning. (Except that CPUs
> > > have floating point registers, with only a floating point meaning.)
> >
> > I agree that there might be a numeric interpretation of a non-numeric
bit
> > string on a particular machine but this is irrelevant if the bit string
does
> > not represent a number.
>
> It is certainly relevant. You seem to be confusing what a collection of
> octet values represents (which could be any type at all), with how it is
> modelled in the specification of a machine architecture or of a protocol.

General purpose machines offer several different semantic models for data
objects, it being up to the programmer to choose instructions whose
semantics match those of the objects that they are manipulating. If they
are not manipulating some entities that a machine is capable of processing
then the way that the machine handles such entities is irrelevant for their
purposes.

> Regardless of which type is being represented, in order to describe how
octet
> values relate to abstract values in that type, there *must* be a canonical
> model for the possible values of an octet, and this model should be
universally
> agreed on.

I agree that for each distinct semantic object that a processor is designed
to handle, there must be a mapping of this object to the bits within the
machine. As far as I am aware there is no universal agreement on what
these mappings should be.

> In fact, it is agreed on: the model that everyone uses is the integers
0..255
> inclusive. This *directly* corresponds to something that you can store in
a
> 8-bit processor register, in a memory location of an octet-addressable
> architecture, in a binary file, transmit over an Internet (or OSI)
protocol,
> etc. A 8-bit string, OTOH, cannot be stored or transmitted in these ways
without
> first choosing a bit order.
>
> > Most computer systems have instructions designed to interpret bit
strings
> > with several different semantics, it being up to the programmer to apply
> > only those insructions for which the semantics match those of the
objects
> > that they are manipulating.
> >
> > > So it is usually necessary how a bit string might be an integer,
> > > since any implementation is going to make it an integer (or
> > > integers) anyway.
> >
> > Not so - I have a many implementations in which bytes do not have any
valid
> > numeric interpretations. The most numerous of these use bytes to
represent
> > finite field elements in GF(256).
>
> What is the type of the abstraction function associated with this
representation?
> The answer is "{0..255} -> GF(2^8)". That is, an abstraction function of
type
> {0..255} -> GF(2^8) is sufficient, on its own, to specify how the field
elements
> are represented in terms of octets; a function of type {0,1}^8 -> GF(2^8)
would
> not be.

I use "finite_field_element -> set_of_8_named_bits".

As you know from previous debates, this is not the same as the abstraction
you use.

We can go over this again if you wish but I don't see much point in doing
so.

   Brian Gladman

Relevant Pages

  • Re: Unicode question
    ... Obviously not for the representation in memory;-) ... They fit your approach to string handling. ... character encoding, or in the average or precise display width of the ... Since UTF-16 chars can be 2 or 4 bytes, one has to be always alert ...
    (borland.public.delphi.non-technical)
  • Re: Strings and bindary data
    ... String to another file, are those files guaranteed to be identical? ... No. Strings are designed to hold textual data, and that /always/ is subject to ... beyond what is in its representation. ... representation -- that's to say a mapping from abstract characters (or ...
    (comp.lang.java.programmer)
  • Re: Why (0.09+0.01-0.1) is not equal to 0.09+0.01-0.1 ?
    ... However less precision would suffice, since 17 digits would uniquely identify an IEEE double precision binary representation. ... Function D2BAs String ... You can use the VBA Decimal data type to carry 28 figures, but you have to be careful to avoid truncation in type conversions and to avoid overflow or underflow since the Decimal data type has fixed precision with no scientific notation. ...
    (microsoft.public.excel)
  • Re: Schrodingers Equation
    ... string and how they are connected elastically to their neighbors. ... understand the motion of the string in terms of the motions of the ... An alternative representation is as the collective ... the wave on string can be abstracted as a single pendulum. ...
    (sci.physics.research)
  • Re: newbie - integer variable with leading zero for os.makedirs
    ... >string from ascii to integer, but loses the first zero padding. ... The same binary number (judging by the decimal representation (488) that's being printed). ... as '750' so the conversion from string to binary integer succeeds and gives the value 750. ...
    (comp.lang.python)
Loading