Trap representations in the absence of padding bits
- From: Spiros Bousbouras <spibou@xxxxxxxxx>
- Date: Sun, 7 Jun 2009 13:29:24 -0700 (PDT)
I'm changing the title of the thread to something more appropriate.
On 28 May, 11:21, James Kuyper <jameskuy...@xxxxxxxxxxx> wrote:
Spiros Bousbouras wrote:
On 26 May, 23:18, jameskuyper <jameskuy...@xxxxxxxxxxx> wrote:
And as I said previously, even with my interpretation,If so, it fails to do so. Specifying the maximum and minimum
paragraph 1 still needs to explain how the values of individual
bits combine to give the total value. ...
representable values is insufficient to determine the combination
algorithm (though the obvious one is probably the simplest).
The combination algorithm *is* mentioned. It says "pure binary
representation".
That's why I said "if so"; I did not consider that the condition of that
if was actually met.
I don't understand you , what condition ?
... From this it follows immediately
that the range of values is from 0 to 2**N-1 and there's no
reason to mention it explicitly in paragraph 1 of 6.2.6.2
I would agree with that conclusion, were it not for the
already-established exceptions allowed by the definition of the term
"trap representation". It is still a binary representation if every
non-trap representation is interpreted as binary. The fact that trap
representations are not interpreted at all doesn't change that.
Footnote 40 which provides the definition for "pure binary
notation" does not mention trap representations. If you could
get trap representations for unsigned integers in the absence of
padding bits the definition of "pure binary notation" would not
be satisfied.
According to your interpretation what is the significance of
"pure binary representation" ?
Its significance is probably exactly the same as what you believe it to
be, for any representation not identified by the implementation as a
trap representation. My interpretation differs from yours only in that I
believe that requirement for "pure binary representation" has no
significance for trap representations.
[...]
My reasoning is not that no mention of trap representation is needed in
order to make them applicable. My reasoning is that a single mention of
trap representations, as is already present in the standard, is
sufficient to render them relevant in all contexts for which that
mention applies, and that there is no need to redundantly mention trap
representations in later clauses of the standard.
Which later clauses? We are mainly disagreeing on the
interpretation of paragraph 2 of 6.2.6.2 which does mention trap
representations.
Note by the way the first sentence of footnote 45: "Some
combinations of padding bits might generate trap
representations, for example, if one padding bit is a parity
bit". This refers to signed integers and is identical to the
first sentence of footnote 44 which refers to unsigned integers.
All they had to do to support your interpretation would be to
modify footnote 45 so that it read "... of padding or value bits
....". But they didn't.
Here's another example: let's say you have written a C programme
which does not use any of the date functions. Do you think that
it might behave differently if it happens to be running on
Friday the 13th ? I expect not. But why not ? After all the
standard doesn't exclude the possibility.
The difference is that trap representations are in fact defined; special
handling of Friday the 13th is not.
Is it important that they are defined rather than simply mentioned?
After all , Friday the 13th doesn't need to be defined , everyone
knows what it means. In any case the point of the example is that
there is nothing in the standard to suggest that trap
representations are relevant in the absence of padding bits (and
when the sign bit is 0 in the case of signed integers) in much the
same way that there is nothing to suggest that Friday the 13th is
relevant.
[...]
However, that section
only describes the values that the bits represent; it does not
address whether or not the bit pattern represents a valid
value.
If it's a trap representation then the bits do not represent any
value. Don't you find it contradictory to say that the bits
represent value but the pattern does not ?
No. So I guess that defines our differences.
It seems to be a central point.
And your argument sounds to me as saying that if you happen to
have a 10 dollar bill and a 20 dollar bill you might not be
allowed to use them together to buy 30 dollars worth of goods.
Thank you for that answer, because it fits my argument well. If I have
one quarter, two dimes, and five pennies, it's often the case that I am
not allowed to use them together to buy 50 cents of goods (think vending
machines). That strikes me as a very good analogy for the way that the
possibility of trap representations can foul up what otherwise seems
like airtight logic.
You are legally allowed to use them regardless of whether a vending
machine will accept them. You wouldn't expect it would be illegal
unless there was a law saying so.
--
- LOL
- Non-sequitur. Your response is irrational and does not constitute
an argument in favor of Lisp or against Java.
From http://tinyurl.com/spiros-quote-1.
- Follow-Ups:
- Re: Trap representations in the absence of padding bits
- From: Tim Rentsch
- Re: Trap representations in the absence of padding bits
- From: James Kuyper
- Re: Trap representations in the absence of padding bits
- Prev by Date: A novel approach to creating templates in C
- Next by Date: Optimization questions
- Previous by thread: A novel approach to creating templates in C
- Next by thread: Re: Trap representations in the absence of padding bits
- Index(es):
Relevant Pages
|
Loading
