Home > Archive > Fortran > January 2006 > Re: Kind of NOT integer constant
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Kind of NOT integer constant
|
|
|
| "James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:U6Gof.297632$zb5.74566@bgtnsc04-news.ops.worldnet.att.net...
> Effectively, this model defines an integer object to consist
> of bits in sequence numbered from right to left from 0 to z-1 .
> This model is valid only in the context of the use of such
> an object as the argument or result of one of the bit manipulation
> procedures. In all other contexts, the model defined for an integer
> in 13.7.1 applies. In particular, whereas the models are identical for
> {bit z-1}= 0, they do not correspond for {bit z-1}= 1 and the
> interpretation of bits in such objects is processor dependent.
>
> Since in your example, the leftmost bit of the result is not zero,
> the value, interpreted as an integer, is allowed to be processor
> dependent.
But nevertheless, as far as the NOT operation is concerned,
all bits of the integer word are treated equally.
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| robin wrote:
(snip regarding bitwise operations)
[color=darkred]
> But nevertheless, as far as the NOT operation is concerned,
> all bits of the integer word are treated equally.
In addition, changing the width requires treatment as an integer
value, not as a group of bits, which requires sign extension for
ones and twos complement value, and moving the sign for sign
magnitude. (Most likely there are no sign magnitude machines
running modern Fortran compilers.)
-- glen
| |
| James Giles 2006-01-10, 4:11 am |
| glen herrmannsfeldt wrote:
> robin wrote:
....
>
> In addition, changing the width requires treatment as an integer
> value, not as a group of bits, which requires sign extension for
> ones and twos complement value, and moving the sign for sign
> magnitude. (Most likely there are no sign magnitude machines
> running modern Fortran compilers.)
Quote that requirement from the standard. Otherwise, it's
merely "quality of implementation".
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard E Maine 2006-01-10, 4:11 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> glen herrmannsfeldt wrote:
>
> Quote that requirement from the standard. Otherwise, it's
> merely "quality of implementation".
I'll ignore the low-level details about the bits - that is part of the
internal representation, which is certainly not in the standard.
However, for the "requires treatment as an integer value" part, which I
take as the central statement here (the rest just being elaboration of
how such treatment might look in particular cases), I'll cite (all from
f2003, section 7.4.1.3, "Interpretation of intrinsic assignments")...
Well, it is tempting to cite the whole section, but snippets of
particular interest include
The first sentence is a broad summary: "Execution of an intrinsic
assignment statement causes, in effect, the evaluation of the expression
expr and all expressions within variable (7.1.8), the possible
conversion of expr to the type and type parameters of variable (Table
7.9), and the definition of variable with the resulting value."
There are also some bits that make it pretty explicit that things must
be done in this order (or have the same effect). The sentence "The
evaluation of expressions within variable shall neither affect nor be
affected by the evaluation of expr." is close to being relevant, but not
quite, as we aren't talking about expressions within it (though I think
I might recall an interp request about generalizing that wording, but it
wasn't directly for this question, so that's probably a side trip).
The relevant line from Table 7.9 says that for an integer variable, the
"Value assigned" (that's the exact column heading from the table) is
"INT(expr, KIND=KIND(variable))" (that's the exact table entry). See
13.7.53 to discover that if A is of type integer, the result value of
INT(A) is A.
That all seems pretty explicit to me.
Note that none of the values in question are outside of the range of any
of the kinds of integers in question in the actual implementation. That
one might posit an integer kind with severely limited range (perhaps
not including any negative values) is a different question, since none
of the actual kinds involved here had such a property in the actual
implementations in question.
Of course, one can make pedantic arguments to the effect that it is a
quality of implementation issue to expect that a compiler can compile
any program in excess of the compiler's size limit of, say, 1 line. But
I don't find that a particularly useful observation in practice.
Notably, I would be surprised if the vendors of any of the actual
compilers that I claim to be nonconforming here would try to drag out a
point quite that pedantic as their defense.
I suppose they might be more likely to try the "defense" that the
standard only requires that they support a single kind of integer, and
so any other inds that they do are an "extension" that dosn't have to
play by the standard's rules. I've seen vendors try lines like that
(notably to explain why they think they can get by without doing quad
complex as part of quad real), but as I've mentiond here before, I don't
think such defenses actually hold together completely.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| James Giles 2006-01-10, 4:11 am |
| Richard E Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
....
Quote that requirement from the standard. Otherwise, it's[color=darkred]
[... lots of references about assignment ...]
Since the result of NOT has no standard meaning as an
expression of the same type and KIND as the argument to
NOT and therefore the expression itself has no standardized
interpretation, the assignment can work any way the
implementor likes. All the quotes about how assignment
works depend on the expression having a value within the
standard's scope. This expression doesn't. The program
already has no standard interpretation. If the implementor
choose to halt with an error message, or merely treat the
thing as a collection of bits, that still conforms to the standard:
since the standard specifies no meaning at all. A program
that relies on any *specific* behavior is a non-conforming
program. The implementation may do as it likes with
those. This has always been true. It will likely remain true
whether we like it or not.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard E Maine 2006-01-10, 4:11 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> Since the result of NOT has no standard meaning as an
> expression of the same type and KIND as the argument to
> NOT...
I disagree with that premise (and thus everything that follows from it),
but we already went through that one and apparently aren't going to
agree on it, so further rehashing of the argument seems pointless.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Jan Vorbrüggen 2006-01-10, 4:11 am |
| > Since the result of NOT has no standard meaning as an
> expression of the same type and KIND as the argument to
> NOT and therefore the expression itself has no standardized
> interpretation, the assignment can work any way the
> implementor likes. All the quotes about how assignment
> works depend on the expression having a value within the
> standard's scope. This expression doesn't. The program
> already has no standard interpretation.
Hmmm. Let me try to focus the discussion, if I can. It appears to me
we were discussing whether the following program
Integer(4) :: I, J
Integer(8) :: M, N
I = 0
M = NOT (I)
J = NOT (I)
N = J
Print M, N
End
- with kind=4 being default integer kind, for clarity and simplicity -
should give as output
-1 -1
or may be allowed to print
4294967296 -1
Was that the point of discussion? If not 8-|, you've lost me.
IMO, this is not a question of what NOT does. It is a question of whether
the seemingly equivalent sequence of steps that define M and N above are
indeed equivalent, or not as evinced in some DEC-heritage compilers.
Jan
| |
| Mr Hrundi V Bakshi 2006-01-10, 4:11 am |
|
"Jan Vorbrüggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:421fibF1g3l1mU1@individual.net...
>
> Hmmm. Let me try to focus the discussion, if I can. It appears to me
> we were discussing whether the following program
>
> Integer(4) :: I, J
> Integer(8) :: M, N
>
> I = 0
>
> M = NOT (I)
>
> J = NOT (I)
> N = J
>
> Print M, N
>
> End
>
> - with kind=4 being default integer kind, for clarity and simplicity -
>
> should give as output
>
> -1 -1
>
> or may be allowed to print
>
> 4294967296 -1
>
> Was that the point of discussion? If not 8-|, you've lost me.
>
> IMO, this is not a question of what NOT does. It is a question of whether
> the seemingly equivalent sequence of steps that define M and N above are
> indeed equivalent, or not as evinced in some DEC-heritage compilers.
>
> Jan
Are all Huns/Krauts as dumb and insensitive as you? Seems so, as is known.
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| Jan Vorbrüggen wrote:
[color=darkred]
> Hmmm. Let me try to focus the discussion, if I can. It appears to me
> we were discussing whether the following program
> Integer(4) :: I, J
> Integer(8) :: M, N
> I = 0
> M = NOT (I)
> J = NOT (I)
> N = J
> Print M, N
> End
> - with kind=4 being default integer kind, for clarity and simplicity -
> should give as output
> -1 -1
With the added restriction of a twos complement binary machine.
> or may be allowed to print
> 4294967296 -1
Nit: off by one.
> Was that the point of discussion? If not 8-|, you've lost me.
I believe that was the point.
> IMO, this is not a question of what NOT does. It is a question of whether
> the seemingly equivalent sequence of steps that define M and N above are
> indeed equivalent, or not as evinced in some DEC-heritage compilers.
Note in addition, at least as of the draft F2003 standard version that
I have available, arithmetic is allowed in any radix greater than one.
I believe, though, that the bit manipulation functions would still be
expected to work in that case, for some maximum number of bits.
Before the ANSI standard, C allowed for decimal arithmetic, but as of
ANSI only twos complement, ones complement and sign magnitude binary
are allowed. There is always the "AS IF" rule, though.
On any machine the two values printed by your program should be the
same. They may be negative zero on a ones complement machine, though,
or large and negative on a ones complement machine.
It is likely within the standard that the high bit is ignored in
such operations.
-- glen
| |
| Jan Vorbrüggen 2006-01-10, 4:11 am |
| > With the added restriction of a twos complement binary machine.
Yes, for these particular results.
> Nit: off by one.
Sorry, just copy&pasted 2^32 from the calculator, and forgot the -1.
> I believe that was the point.
Good.
> On any machine the two values printed by your program should be the
> same. They may be negative zero on a ones complement machine, though,
> or large and negative on a ones complement machine.
Yes - that was the point I was trying to make.
Jan
PS: It's two o'clock in Pa ena at the moment...reminds me of my student
days...well, nowadays one can't tell whether people are where their computers
are 8-)...
| |
| Richard E Maine 2006-01-10, 4:11 am |
| Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:
> Hmmm. Let me try to focus the discussion, if I can. It appears to me
> we were discussing whether the following program
[elided]
> should give as output
>
> -1 -1
>
> or may be allowed to print
>
> 4294967296 -1
>
> Was that the point of discussion?
Close. I might say essentially. However, do note that I don't think
anyone has alleged that the -1 -1 output is required; the value -1
assumes a particular representation that is not required by the standard
(even though it happens to be almost universal on current machines).
I maintain that the two values printed are required to be the same, but
that the standard does not specify what the exact value is. The -1 -1
meets the requirement of being the same (and is what I'd expect on
current machines); the other one doesn't.
> IMO, this is not a question of what NOT does. It is a question of whether
> the seemingly equivalent sequence of steps that define M and N above are
> indeed equivalent, or not as evinced in some DEC-heritage compilers.
I agree with you on that. That's why I say that the values are required
to be the same - because I claim that the standard says these two
sequences of steps are equivalent, by the definition of assignment
statements.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Jan Vorbrüggen 2006-01-10, 4:11 am |
| > Close. I might say essentially. However, do note that I don't think
> anyone has alleged that the -1 -1 output is required; the value -1
> assumes a particular representation that is not required by the standard
> (even though it happens to be almost universal on current machines).
Sure - I wanted to produce a relevant example, and not burden it with
disclaimers about representations et al. unnecessarily.
> I agree with you on that. That's why I say that the values are required
> to be the same - because I claim that the standard says these two
> sequences of steps are equivalent, by the definition of assignment
> statements.
In this context - those intrinsics could be made more orthogonal if they
had an optional KIND argument as others have, wouldn't you think so?
Jan
| |
| Richard E Maine 2006-01-10, 4:11 am |
| Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:
> In this context - those intrinsics could be made more orthogonal if they
> had an optional KIND argument as others have, wouldn't you think so?
I don't think so. There is a pattern to the intrinsics that have KIND
arguments. Basically, they are ones where there is no inherently
"correct" kind for the result; you actually need the KIND argument to
get the appropriate functionality. Some are transformational intrinsics.
Others are inquiry intrinsics.
But for the bit intrinsics, there is an inherently "correct" kind for
the result - the same kind as the argument. I would say that adding a
KIND argument would actually be illogical in that it would conflate two
unrelated operations - the operation named by the intrinsic plus the bit
extension/deletion/whatever.
If you want an operation like int(not(something),kind=some_kind), then
that capability already exists, either in that form, or in the form of
the asignment statements in question. Note that this is very different
from most of the intrinsics that have KIND arguments; they *NEED* the
kind argument. If your array has a size too large to express in a
default integer, then you need to do something in the size intrinsic
itself - you can't take the result of size(array) and then transform it.
If, on the other hand, you want something like a sign extension
transformational operator, well that's possibly a fine thing to have
(hmm...), but it seems to me that it is a separate operator in its own
right, rather than something that should be conflated with all the other
bit operators. I have a vision of someone writing, for example,
ior(a,0,kind=some_kind) as a strange spelling for sign extension.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Richard E Maine 2006-01-10, 4:11 am |
| Joost <jv244@cam.ac.uk> wrote:
> Richard E Maine wrote:
>
> Well, I would be curious to know how many codes 'out there' are
> actually doing the wrong thing with cmplx ....
Ah, yes. I neglected CMPLX in my overgeneralization. CMPLX is a
historical oddity. To my knowledge, the only reason for its current
behavior is compatibility with existing codes. I decline to get into
speculations about how many codes might be affected, or about whether it
was or was not a good idea to stick with compatibility. I find myself in
considerable sympathy with the idea that Giles has mentioned - of
creating a new intrinsic (the name COMPLEX certainly does come to mind
as pretty obvious), which does it "right", thus giving a "right" version
without breaking existing codes. Of course, then there is the
possibility that some existing codes are already broken...
And, back to the original point, note that although there are some cases
where the "correct" kind for cmplx is "obvious" (even if the standard
dictates a "wrong" kind), there are other cases such as cmplx(integer,
integer), where there is no "obvious" answer; those cases "need" the
option for a kind argument.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| James Giles 2006-01-10, 4:11 am |
| Jan Vorbrüggen wrote:
....
> Hmmm. Let me try to focus the discussion, if I can. It appears to me
> we were discussing whether the following program
>
> Integer(4) :: I, J
> Integer(8) :: M, N
>
> I = 0
>
> M = NOT (I)
>
> J = NOT (I)
> N = J
>
> Print M, N
>
> End
>
> - with kind=4 being default integer kind, for clarity and simplicity -
>
> should give as output
>
> -1 -1
>
> or may be allowed to print
>
> 4294967296 -1
>
> Was that the point of discussion? If not 8-|, you've lost me.
You are making an assumption not justified by the standard
document: that the result of a processor defined feature
must correspond to *your* mental model of what should
happen. The output could be 1397311310 (which is 4hSIGN
if your compiler still supports hollerith). The fact remains that
the *STANDARD* does not define the behavior of the program.
It quite explicitly doesn't. It goes out of its way to deny that the
above has standardized meaning. (j3/04-007 May2004, 293:5-6)
Now, *you* know what bits you expect NOT to leave set, and
*I* know what bits I expect NOT to leave set, and we both
know what those bits would mean as integers on various hardware
and/or software platforms. But, as much as we may desire it, the
*standard* doesn't require the bits to mean that, or to remain
unchanged when cast back from the bit-model to the integer-
model, or to work the same way each time it's used, or any
of those things.
Now, as I've already pointed out, the standard *could* have
specified more clearly what is intended. It could have said,
for example, that each INTEGER KIND supported by a processor
must be either signed magnitude, one's complement, or two's
complement and that correspondence between the bit-model
and the integer-model (the standard would have to mention all
three) for each argument KIND must be consistent with the
representation of the KIND in question. This would have
been difficult since the standard is written informally, but it
could have been done without *too* much bother. The standard
doesn't specify that though, it says that if the top bit is set
as the result of a bit operation, the interpretation of bits in such
objects is processor dependent. (The standard does actually
say "bits" not "bit", if the top bit is set the interpretation of
*all* the bits of the result are processor dependent.)
Which means that the programmer can't depend on anything
- not from the standard anyway. There's always "quality of
implementation" arguments to encourage an implementor to do
as you want. In that respect, the two behaviors mentioned
in this thread are *both* standard compliant (and I'd actually
prefer the one that most people claim is not conforming).
Now there's a reason to continue to point things like this
out: the standard does not formally define the language.
Hence there's an awful lot of situations where people,
even on the committee, assume meaning that isn't actually
specified. This means that various implementors do
different things (all in coformance with the informal
wording of the document) that others strongly (and
almost certainly incorrectly) believe to be non-standard.
The bottom line is that if you really want the standard to
say a particular thing, you should write it so that it does
in fact say that particular thing. You should not afterwords
resort to subtle word games trying to force an interpretation
that you just happen to like.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard E Maine 2006-01-10, 4:11 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
[elided]
> Which means that the programmer can't depend on anything
> - not from the standard anyway. There's always "quality of
> implementation" arguments to encourage an implementor to do
> as you want. In that respect, the two behaviors mentioned
> in this thread are *both* standard compliant (and I'd actually
> prefer the one that most people claim is not conforming).
I continue to disagree with this point. I maintain that the standard
*DOES* specify the two results to be the same - that it doesn't sepcify
the particular value, but that it does specify that, whatever value it
is, it is the same in both cases.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| James Giles 2006-01-10, 4:11 am |
| Richard E Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
>
> [elided]
>
> I continue to disagree with this point. I maintain that the standard
> *DOES* specify the two results to be the same - that it doesn't
> sepcify the particular value, but that it does specify that, whatever
> value it is, it is the same in both cases.
Unfortunately you quote nothing from the standard to support
your belief. Beliefs are not normative. The words in black-and-
white in the document are. Since the standard does not provide
a formal specification, it's already hard enough to interpret without
having to factor in the beliefs of other readers (whether they're
members of the committee, former members, or just interested
others). I don't care to have to second guess your beleifs to
discover the meaning of any part of the document. And,
I'm pretty sure there are both users and implementors of
Fortran that aren't even aware of your existence, much less
what your beliefs are. They shouldn't be compelled to conform
to your beliefs.
All the linguistic gymnastics you care to engage in won't change
the wording of the standard.. You could, maybe, get the committee
to clarify the meaning by changing the document. You could, more
likely, get the committee to issue an official interp (I don't like that
possibility since the gist of interps are seldom integrated into the
standard document, so the document itself still appears unclear).
But without either, the actual words of the document don't support
your position.
Not only that, but you are being inconsistent. With respect to
other issues in dispute, you have often (vociferously) maintained
that the lack of concensus implies increased leeway to implementors.
Here, you are arguing the opposite.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard E Maine 2006-01-10, 4:11 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> Richard E Maine wrote:
>
> Unfortunately you quote nothing from the standard to support
> your belief.
I did before. I decline to repeat or further defend them. One might, of
course, disagree with my interpretation of the quoted words. That's
rather a different matter from quoting "nothing". If you really think I
quoted nothing, or perhaps that my quotes were so irrelevant as to
effectively constitute nothing, well, I decline to defend that
meta-argument either.
The only reason I have futher posted on this point at all is in response
to claims that were not even labeled as opinions or interpretations, but
as absolutes. Had you said words to the effect that your interpretation
of the standard is ...whatever..., or that you disagree with my
interpretation for whatever reason, I'd have not followed up at all.
What little value my beliefs or interpretations might have is, of
course, quite questionable. Perhaps yours are better. I can quite accept
that. There have certainly been cases before, where I have changed my
mind about beliefs or interpretations that I had been quite confident
in. It will probably happen again in the future. (I sure hope so,
because I know I'm not right about everything, so if I never again
change my mind, that must mean I've closed it.)
It is, however, my most emphatic belief that, above all, it is important
to distinguish opinions from facts. If you think that your statements on
the subject are facts, in contrast to mine are just opinions, then I
guess we disagree on a *VERY* fundamental level. I do agree that mine
are opinions/interpretations.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| James Giles 2006-01-10, 4:11 am |
| Richard E Maine wrote:
....
> The only reason I have futher posted on this point at all is in
> response to claims that were not even labeled as opinions or
> interpretations, but as absolutes. Had you said words to the effect
> that your interpretation of the standard is ...whatever..., or that
> you disagree with my interpretation for whatever reason, I'd have not
> followed up at all.
Oh, I see. You're one of those that believes in redundant
verbage in all things. I saw no such qualifications on your
arguments (but I wasn't looking for them), but you insist
that I must give such qualifications. For future instances:
If I don't quote references, then what I say is my opinion.
If you don't quote references, nothing you say will be
interprerted as anything more than your opinion. If *GOD*
doesn't quote references, anything he says will be interpreted
as "only" his opinion. That's to be *universally* applied to *all*
usenet discussions. No exceptions. Thart always *has* been
my rule for interpretation of usenet content. I won't change.
Auxilliary rule: if the reference given is not normative and/or
mentions no objective way of independent verification, then
even the reference is only an opinion.
Anyone that consistently insists on disclaimers is implying
that any of his own articles that don't contain such discalimers
are absolutes. I don't agree. But then, that's just my opinion.
Now, to make sure the thread contains at least *some*
on-topic content: let's test your belief that processor dependent
behavior *must* be consistent. Let S1 and S2 be single precision
REAL, and D1 and D2 be double precision REAL. In the
statement:
D1 = D2 - S1*S2
need the processor consistently use a single precision product
first, then convert to double and subtract? Is the processor required
to use extended precision multiply *every* time? Is it at least required
to use the *same* rule in selecting intermediate precision every time?
The answer, as discussed in this forum many times, is "no" to each
question. Implementations are not required to be consistent in their
definitions of processor defined behaviors.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| Richard E Maine wrote:
(snip)
> And, back to the original point, note that although there are some cases
> where the "correct" kind for cmplx is "obvious" (even if the standard
> dictates a "wrong" kind), there are other cases such as cmplx(integer,
> integer), where there is no "obvious" answer; those cases "need" the
> option for a kind argument.
I might suggest that this is again combining operations, the combining
of two numbers to make a complex value, and the conversion of them from
fixed to floating point.
(For comparison purposes, PL/I allows complex fixed point values, and
uses separate functions for the different conversions. It would, then,
be COMPLEX(FLOAT(I),FLOAT(J)) or FLOAT(COMPLEX(I,J)).)
-- glen
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| Richard E Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
> [elided]
[color=darkred]
> I continue to disagree with this point. I maintain that the standard
> *DOES* specify the two results to be the same - that it doesn't sepcify
> the particular value, but that it does specify that, whatever value it
> is, it is the same in both cases.
After reading a version of the standard, I might believe that it
could leave whatever value happens to be in that bit, without
changing it, or even a bit from some other register. It should, then,
do that in both cases, which might mean that they have different values.
Even so, the operation would be the same for both.
-- glen
| |
| James Giles 2006-01-10, 4:11 am |
| glen herrmannsfeldt wrote:
....
> After reading a version of the standard, I might believe that it
> could leave whatever value happens to be in that bit, without
> changing it, or even a bit from some other register. It should, then,
> do that in both cases, which might mean that they have different
> values. Even so, the operation would be the same for both.
Yes, the actual example behaviors in described in this thread
*are* self-consistent. They are just consistent in different
ways. This observation is independent of the fact that,
as I've already pointed out, implementations are not
required to be self-consistent with respect to processor-
defined behaviors.
A processor that does NOT(0) as a default precision operation
(and returns -1, which is not required even on two's complement
platforms) followed by an assignment will give -1 as the value of
both the default precision left-hand side and the extended
precision left-hand side. An implementation that generates
an extended precision result for *all* bit operations, because
it recognizes that the meaning of leaving the top bit set is
not defined in default precision, will yield a large positive reult
(for a 32-bit default precision machine it will generate 32
set bits right adjusted in the extended precision result). This
will then be assigned, using the usual rules that implemenations
have of disregarding bits to the left of the size of the integer
destination, as either -1 or (2^32)-1 depending on whether
the variable on the left of the assignment is default precision
or extended precision. Either implementation is internally
consistent and standard conforming.
There is no rule in the standard that require all intermediates
of an integer expression to be default precision, or the same
precision, or indeed for the intermediate precision to be consistently
chosen. That's rather why I chose a similar example involving
REALs to demonstrate that consistent processor-defined
behavior is not required by the standard: it's the same thing
as may happen in the INTEGER case under discussion: the
processor if free to choose different intermediate precisions
even though the results are *computationally* different.
For implementations that aren't two's complement, or are not
32-bits for the default INTEGER KIND, the values of the
example may differ, but the concepts are about the same.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Jan Vorbrüggen 2006-01-10, 4:11 am |
| > I don't think so. There is a pattern to the intrinsics that have KIND
> arguments. Basically, they are ones where there is no inherently
> "correct" kind for the result; you actually need the KIND argument to
> get the appropriate functionality.
Ah yes. I must admit to not having had a proper mental model of intrinsics
with and without KIND arguments, and was hoping to get one from you - which
you very kindly provided 8-|...
> If, on the other hand, you want something like a sign extension
> transformational operator, well that's possibly a fine thing to have
> (hmm...), but it seems to me that it is a separate operator in its own
> right, rather than something that should be conflated with all the other
> bit operators. I have a vision of someone writing, for example,
> ior(a,0,kind=some_kind) as a strange spelling for sign extension.
Actually, you can get the sign extension now by simple assignment. what
doesn't exist as such is zero-fill extension. But doing a sequence of L
ARGE = 0 and an appropiate MVBITS from SMALL to LARGE would fit that bill
- so thanks, but no.
Jan
| |
| Jan Vorbrüggen 2006-01-10, 4:11 am |
| James,
why don't you read the follow-up discussion before answering? About
95% of your response - I removed the initial word "diatribe" I had
used - concerns the particular result of NOT that I used for illustrative
purposes in my post, not the central point of the discussion (if there
is one). Subsequent discussion had, at the time you replied, already made
clear that the point is the two numbers should be the same, not their
actual value.
Jan
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| James Giles wrote:
(snip)
> Yes, the actual example behaviors in described in this thread
> *are* self-consistent. They are just consistent in different
> ways. This observation is independent of the fact that,
> as I've already pointed out, implementations are not
> required to be self-consistent with respect to processor-
> defined behaviors.
> A processor that does NOT(0) as a default precision operation
> (and returns -1, which is not required even on two's complement
> platforms) followed by an assignment will give -1 as the value of
> both the default precision left-hand side and the extended
> precision left-hand side. An implementation that generates
> an extended precision result for *all* bit operations, because
> it recognizes that the meaning of leaving the top bit set is
> not defined in default precision, will yield a large positive reult
> (for a 32-bit default precision machine it will generate 32
> set bits right adjusted in the extended precision result).
In the version that I have, Sept. 2002, it specifically says that
the result of the logical operations have the same "result
characteristics" as the first operand. For the two operand functions,
such as IOR and IAND both are specifically required to have the same KIND.
> This
> will then be assigned, using the usual rules that implemenations
> have of disregarding bits to the left of the size of the integer
> destination, as either -1 or (2^32)-1 depending on whether
> the variable on the left of the assignment is default precision
> or extended precision. Either implementation is internally
> consistent and standard conforming.
Consistent, but it seems to me not standard conforming.
> There is no rule in the standard that require all intermediates
> of an integer expression to be default precision, or the same
> precision, or indeed for the intermediate precision to be consistently
> chosen. That's rather why I chose a similar example involving
> REALs to demonstrate that consistent processor-defined
> behavior is not required by the standard: it's the same thing
> as may happen in the INTEGER case under discussion: the
> processor if free to choose different intermediate precisions
> even though the results are *computationally* different.
I did start a discussion some time ago on the result of REAL
multiplication. Many machines will tend to generate a double precision
product, and may or may not truncate it before it is assigned or used in
other operations.
> For implementations that aren't two's complement, or are not
> 32-bits for the default INTEGER KIND, the values of the
> example may differ, but the concepts are about the same.
>
Also, in 7.1.8 it says:
"The declared type of an expression in which a function reference
appears does not affect, and is not affected by, the evaluation
of the actual arguments of the function."
Also, 7.1.4.2 explains the result KIND of expressions using intrinsic
operators.
-- glen
| |
| James Giles 2006-01-10, 4:11 am |
| glen herrmannsfeldt wrote:
....
> In the version that I have, Sept. 2002, it specifically says that
> the result of the logical operations have the same "result
> characteristics" as the first operand. For the two operand functions,
> such as IOR and IAND both are specifically required to have the same
> KIND.
The same is said of the multiply operation applied to REAL
arguments. Yet the consensus is that processors are permitted
to carry additional intermediate precision. In any case, the
operations NOT, IAND, IOR, and so on (the bit intrinsics)
don't necessaarily have values of the same KIND as their
operands - any result withthe top bit set have processor-
dependent interpretations. All the more reason for
implementations to use extended precision intermediates
(or behave as-if such intermediartes were used).
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Paul Van Delst 2006-01-10, 4:11 am |
| Richard E Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
>
>
>
>
> I did before.
For those of us still trying to nut out the original argument/question, the Standard
reference was:
> Richard E Maine wrote:
[snip][color=darkred]
[..and snip]
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
| |
| James Giles 2006-01-10, 4:11 am |
| Paul Van Delst wrote:[color=darkred]
> For those of us still trying to nut out the original
> argument/question, the Standard reference was:
>
> [snip]
And, the definition of assignment is still irrelevant unless
you assume things not required by the standard: that the
result of NOT necessarily has a value that can be
represented in default precision, that the processor is
not permitted to carry extra precision in an INTEGER
expression, etc. The standard does not require the same
result on two consecutive assignments to default precision
variables, much less to destinations of differing KINDs.
If a bit-wise operation yields a result with the top bit
set, the processor is permitted to replace that result
with a copy of the CPU clock. That's certainly not a
likely implementation, but the *standard* allows the
implementor to decide. (That's the point of the exercise:
to teach the concept that the *standard* often does
not specify what people assume. After all 2+2 needn't
ever be 4 either, much less must it always be 4. Again,
not getting that right is an unlikely implementation, but
the standard leaves it up to the implementor.)
And, you still don't address the issue that the possiible
results usually mentioned *both* yeild "the same result"
for different definitions of "the same result". Say the
definition of "the same result" when bit-wise operations
are involved is: right justify each value in a register that's
large enough to hold all the bits and XOR them, they're the
same if the XOR is zero. In that case, yielding -1 as the
answer in both assignments is definitely not "the same result".
For bit-wise operations, this is probably a better definition
of "the same result" than numerical equality. It's certainly an
acceptable definition of what is, after all, not a requirement
within the standard anyway.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Dan Nagle 2006-01-10, 4:11 am |
| Hello,
James Giles wrote:
<snip>
> And, the definition of assignment is still irrelevant unless
> you assume things not required by the standard: that the
> result of NOT necessarily has a value that can be
> represented in default precision,
The result of not() can be represented by a default integer
if the argument is a default integer, because the standard
states that the result characteristics of not() are
the same as those of its argument.
> that the processor is
> not permitted to carry extra precision in an INTEGER
> expression, etc.
Extra precision is not an issue, because the standard
defines not() to be a bit-by-bit operation.
<snip the rest>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| James Giles 2006-01-10, 4:11 am |
| Dan Nagle wrote:
> James Giles wrote:
>
> <snip>
>
>
> The result of not() can be represented by a default integer
> if the argument is a default integer, because the standard
> states that the result characteristics of not() are
> the same as those of its argument.
*IF* the result is defined at all, which it isn't (necessarily)
if the top bit is set.
>
> Extra precision is not an issue, because the standard
> defines not() to be a bit-by-bit operation.
What does that have to do with the size of the
register/word/temporary or other storage used
as the intermediate repository of those bits? Are
you saying that *because* it's a bit operation, a
larger register is *prohibited*?
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Dan Nagle 2006-01-10, 4:11 am |
| Hello,
One more swing at this, then I quit.
James Giles wrote:
> Dan Nagle wrote:
<snip>
> *IF* the result is defined at all, which it isn't (necessarily)
> if the top bit is set.
The result is bit-wise defined. It's interpretation may not be,
if the sign bit is set.
> What does that have to do with the size of the
> register/word/temporary or other storage used
> as the intermediate repository of those bits?
Huh?
> Are
> you saying that *because* it's a bit operation, a
> larger register is *prohibited*?
Huh?
The result type, kind and bits are defined.
It may be computed by having trained rats banging the disk drive,
or whatever magic the processor chooses.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
|
| "James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:v13vf.225962$qk4.186645@bgtnsc05-news.ops.worldnet.att.net...
> glen herrmannsfeldt wrote:
> ...
>
> Yes, the actual example behaviors in described in this thread
> *are* self-consistent. They are just consistent in different
> ways. This observation is independent of the fact that,
> as I've already pointed out, implementations are not
> required to be self-consistent with respect to processor-
> defined behaviors.
>
> A processor that does NOT(0) as a default precision operation
> (and returns -1, which is not required even on two's complement
> platforms) followed by an assignment will give -1 as the value of
> both the default precision left-hand side and the extended
> precision left-hand side. An implementation that generates
> an extended precision result for *all* bit operations, because
> it recognizes that the meaning of leaving the top bit set is
> not defined in default precision, will yield a large positive reult
> (for a 32-bit default precision machine it will generate 32
> set bits right adjusted in the extended precision result). This
> will then be assigned, using the usual rules that implemenations
> have of disregarding bits to the left of the size of the integer
> destination, as either -1 or (2^32)-1 depending on whether
> the variable on the left of the assignment is default precision
> or extended precision. Either implementation is internally
> consistent and standard conforming.
I wonder what would happen if NOT(3) were used as an
argument. That would not mesh well with the corresponding
dummy argument defined as a default integer.
Ellis Phillipa\s & Lahey state that the result of NOT
as the same kind as the argument.
Also for all the bit manuipulation intrinsics.
Your interpretation looks odd when it comes to
ISHFTC.
| |
|
| "James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:_S5vf.415668$zb5.104319@bgtnsc04-news.ops.worldnet.att.net...
> glen herrmannsfeldt wrote:
> ...
>
> The same is said of the multiply operation applied to REAL
> arguments. Yet the consensus is that processors are permitted
> to carry additional intermediate precision. In any case, the
> operations NOT, IAND, IOR, and so on (the bit intrinsics)
> don't necessaarily have values of the same KIND as their
> operands - any result withthe top bit set have processor-
> dependent interpretations.
Processor-dependent interpretations they may have,
but a change of kind they cannot have.
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| James Giles wrote:
(snip)
> If a bit-wise operation yields a result with the top bit
> set, the processor is permitted to replace that result
> with a copy of the CPU clock. That's certainly not a
> likely implementation, but the *standard* allows the
> implementor to decide. (That's the point of the exercise:
> to teach the concept that the *standard* often does
> not specify what people assume. After all 2+2 needn't
> ever be 4 either, much less must it always be 4. Again,
> not getting that right is an unlikely implementation, but
> the standard leaves it up to the implementor.)
That might be true, but if it is I would say that the
value of NOT better not have the sign bit set. See below.
> And, you still don't address the issue that the possiible
> results usually mentioned *both* yeild "the same result"
> for different definitions of "the same result". Say the
> definition of "the same result" when bit-wise operations
> are involved is: right justify each value in a register that's
> large enough to hold all the bits and XOR them, they're the
> same if the XOR is zero. In that case, yielding -1 as the
> answer in both assignments is definitely not "the same result".
> For bit-wise operations, this is probably a better definition
> of "the same result" than numerical equality. It's certainly an
> acceptable definition of what is, after all, not a requirement
> within the standard anyway.
The result of NOT or XOR, which may or may not have the sign
bit set, is considered to have the same size as its
argument, is converted to a different KIND. It is required to
be an INTEGER type. The conversion should be done the same as
any other function returning an INTEGER.
Reading 13.3 and 13.4 again, I believe that all BIT_SIZE() bits
must be given the proper value. If an implementation can't
generate the right result for the high bit, it must return
a smaller value for BIT_SIZE, such as 31 on a 32 bit machine.
It it does sometimes return a value with the sign bit set, it must
properly accept such arguments. That is, NOT(NOT(I)) should be
legal. If an implementation can't properly generate the sign bit
in a logical operation, it would, as a quality of implementation issue,
be best to always return that bit as zero. The description in 13.3
applied only to the argument and value for the bit manipulation
functions. For all other operations, which I believe includes
assignment and KIND changes, the 13.4 model is used.
Note that the standard doesn't require INTEGER to use binary arithmetic,
though functions such as NOT will likely be very slow on machines that
don't use binary. It seems that any base larger than 1 is allowed.
BIT_SIZE presumably returns a value small enough that it can properly
compute the result.
-- glen
| |
| Richard Maine 2006-01-10, 4:11 am |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> It it does sometimes return a value with the sign bit set, it must
> properly accept such arguments. That is, NOT(NOT(I)) should be
> legal.
I forgot to mention something vaguely along this line. If one takes the
interpretation that pretty much anything can happen if the sign bit is
set, then I guess I don't see how any invocation of NOT() can ever be
counted on to do anything useful. After all, either the sign bit is set
either in the argument value or in the return value.
This isn't the interpretation I take, but it seems to me a conclusion to
be reached if one does go down that path.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| James Giles 2006-01-10, 4:11 am |
| Dan Nagle wrote:
> Hello,
>
> One more swing at this, then I quit.
>
> James Giles wrote:
>
> <snip>
>
>
> The result is bit-wise defined. It's interpretation may not be,
> if the sign bit is set.
And the interpretation is processor dependent. The
processor may do *anything* it likes.
> The result type, kind and bits are defined.
> It may be computed by having trained rats banging the disk drive,
> or whatever magic the processor chooses.
So, the same as with REAL operations, the processor may
carry *extra* bits if it chooses beyond those in the model
for the type and KIND. And, what the *bits* mean (and even
wbether they remain unchanged) is *explicitly* up to the
processor!
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| James Giles 2006-01-10, 4:11 am |
| robin wrote:
....
> Processor-dependent interpretations they may have,
> but a change of kind they cannot have.
That's not what the concensuss is regarding the *same*
question when REAL arithmetic is involved. The produst
of two REALs may be a double (or even more extended)
value.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| James Giles 2006-01-10, 4:11 am |
| robin wrote:
....
> I wonder what would happen if NOT(3) were used as an
> argument. That would not mesh well with the corresponding
> dummy argument defined as a default integer.
>
> Ellis Phillipa\s & Lahey state that the result of NOT
> as the same kind as the argument.
> Also for all the bit manuipulation intrinsics.
> Your interpretation looks odd when it comes to
> ISHFTC.
You are confusing semantics and pragmatics. The type
and KIND associated with he object may be defined, and
representation may be anything has the same *or*more*
precision.
NOT (3) proceeds the same as any application of NOT().
The values of 3 is (presumably) in range and not negative,
therefore its integer model corresponds without ambiguity
to a value of the bit model. NOT() then complements the
value which, in this case, leaves the righmost bit set. That
value of the bit model doesn't have a *standard* correspomding
value in the integer model and the processor is *expicilty*
allowed by the standard to do anything it likes with that
result. In the case I'd prefer, it keeps the whole result
with sufficient precision not to lose any information (possibly
using a larger register, or otherwise keeping track of the
situation) and then applies the next operation as-if to that
larger integer field.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| James Giles 2006-01-10, 4:11 am |
| glen herrmannsfeldt wrote:
> James Giles wrote:
>
> The result of NOT or XOR, which may or may not have the sign
> bit set, is considered to have the same size as its
> argument, is converted to a different KIND. [...]
I said nothing about *conversion* to a different KIND. I was
giving a sequence of semantic operations (operational semantics
can even be formalized). There was no conversion involved.
I placed the resuklt of the NOT operations iinto registers long
enough to hold either KIND (right justified) and XORed them.
No conversion was done. INTEGER semantics was not even
referenced nor is it relevant. This is all withion the processor's
range of choices: since *anything* the porcessor wants to do
is valid "procedor defined" behavior.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| James Giles 2006-01-10, 4:11 am |
| Richard Maine wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>
> I forgot to mention something vaguely along this line. If one takes
> the interpretation that pretty much anything can happen if the sign
> bit is set, then I guess I don't see how any invocation of NOT() can
> ever be counted on to do anything useful. After all, either the sign
> bit is set either in the argument value or in the return value.
There are lots of things that you can't count on based solely on the
standard. 2+2 == 4? Can you actually *count* on integer add
to do anything useful? Not based only on the standard. The processor
is given wide latitude. That, as I keep saying, is my point in this
thread..Maybe you think the standard allows too much latitude
(I do). Maybe you think the standard *should* require 2+2 == 4
(I do).
Yes, I believe (eye-roll emoticon for having to put in a redundant
disclaimer) the standard doesn't reqiure NOT(NOT(I)) to necessarily
do anything useful. It's one of the places where the standard gives
implementors wide latitude. Maybe too wide.
Maybe the problem is that people are  by the idiosyncratic
way that the standard actually does very clearly define some things
and doesn't at all define others that are closely related. INTEGER
divide is fully and clearly defined. No other intrinsic arithmetic operator
is defined at all. The bit intrinsics are clearly and fiully defined as
long
as the rightmost bit doesn't get set, if it does then all bets are off.
The standard relies heavily on the implementations to do something
"reasonable" in these cases. In most cases, the "reasonable" thing
is obvious. In other cases, people may completely disagree over
what "obvious" thing is most reasonable. On a 32-bit machine,
should (2147483647+2147483645)/2 be 2147483646, or should
it be -2, or should it generate an error message and stop? Are there
other "obvious" choices?
In the case of the bit intrinsics, I believe (eye-roll emoticon again)
both of the results given at the start of this thread are perfectly
reasonable "obvious" choices. They only differ if mixed-KIND
expressions are involved (otherwise the two work identically).
I prefer the one most people claim (incorrectly, I believe (eye-roll))
is not permitted by the standard.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard Maine 2006-01-10, 4:11 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> There are lots of things that you can't count on based solely on the
> standard. 2+2 == 4? Can you actually *count* on integer add
> to do anything useful? Not based only on the standard.
I've seen it argued otherwise (and by people other than yourself), but
my position is that the standard does require 2+2 to equal 4 (ok, unless
it overflows because 4 is too big a number or some such thing, or it
this is too complicated an expression, but those points are getting
pretty picky).
That's different from 2.0+2.0=4.0. Floating point numbers involve
approximations. And while I don't know of any real compilers likely to
get that one "wrong", 2.0e20+2.0e20 is quite a different matter.
I see no leeway in the standard for approximations in integer
arithmetic... until you get into things like overflow. Once you have
overflowed, then yes, you have a nonstandard program and all bets are
off.
Ok, I admit the abstract possibility of the compiler implementing 2+2 as
a "mathematically equivalent" expression that is computationally
different because it overflows (that's the only way I can think of to
get a computational difference in a mathematically equivalent integer
operation). So in a completely pedantic sense, I agree. But I happen to
consider the case of 2.0+2.0 a more real (pun not intended) issue. I've
actually seen people write code to defend against approximations in that
one. I doubt it was necessary, but I've seen it done; probably based on
a misremembered problem long ago (this was code from the late 60's,
written by someone who recalled problems from earlier than that).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| James Giles 2006-01-10, 4:11 am |
| Richard Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
>
>
> I've seen it argued otherwise (and by people other than yourself), but
> my position is that the standard does require 2+2 to equal 4 (ok,
> unless it overflows because 4 is too big a number or some such thing,
> or it this is too complicated an expression, but those points are
> getting pretty picky).
I'd like to agree, because that's what I think the standard
*should* say. But I don't believe it does anywhere. Have
you a normative reference. Either in the standard or in an
interp?
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard Maine 2006-01-10, 4:11 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> Richard Maine wrote:
>
> I'd like to agree, because that's what I think the standard
> *should* say. But I don't believe it does anywhere. Have
> you a normative reference. Either in the standard or in an
> interp?
Not off-hand. I *have* heard the question asked in a committee meeting.
I *think* (but won't swear to) I recall a conclusion that went something
along the line of saying that it was "obvious" (for some definition of
that term), perhaps arguing that English words in the standard have
their English meaning except where the standard specifies a particular
technical meaning of the word. I'm sure (but don't feel like checking
the citation) that there is something saying that the + operation is
addition, but I'm very sure that the standard does not define what the
word "addition" means, considering it to be a normal English word. The
only cases that the standard qualifies are those where it doesn't
strictly mean exactly the same thing as the English word - as in
floating point, where one has to throw in a qualification about
approximations.
I don't think it made a formal interp, because I think the conclusion
was that it wasn't worth the bother to do one (even an interp that
"everyone" agrees on takes a lot of time to put through the formal
process - time that isn't free could otherwise be spent on other
things). I think this was one of those "this isn't actually an issue, so
lets get rid of it and do useful work" things. There have been others;
I've brought up a few myself and ended up accepting that they were
points that nobody got wrong or was going to get wrong, so they weren't
worth the trouble to fix (the fixes being difficult).
The standard also doesn't define what "is" is. But it does define what
"shall" is. :-)
My recollection could be faulty on the details, I'll admit.
P.S. Yes, writing the standard in some kind of formalism other than
English might avoid such questions, but it won't happen for the basic
reason that nobody will do it. I, for example, don't know any of those
formalisms well enough to do such a thing. To my knowledge, neither does
anyone else on the committee or likely to get on the committee. So if it
were to be done, it would have to be by some different committee (which,
of course, some people would say was a good idea anyway. :-)).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Dick Hendrickson 2006-01-10, 4:11 am |
|
James Giles wrote:
> Richard Maine wrote:
>
>
>
> I'd like to agree, because that's what I think the standard
> *should* say. But I don't believe it does anywhere. Have
> you a normative reference. Either in the standard or in an
> interp?
>
This might seem a little odd, but how about 1.7.6, under
text conventions, where it says
"Boldface words are used in the text where they are first
defined with a specialized meaning."
I don't see anything in chapter 7 that has "addition" or
"+" in bold face. So, I'd assume they have their normal
English language meaning.
I deliberately didn't put any smilies above because I'm
actually serious. There's no reason to think that integer
arithmetic is odd; if there were, the standard would have
described how the oddities work. So, 1+1 = 2! I almost
wrote 2 + 2 = 4! But, that would have needed a ;) .
Dick Hendrickson
| |
| James Giles 2006-01-10, 4:11 am |
| Dick Hendrickson wrote:
....
> I don't see anything in chapter 7 that has "addition" or
> "+" in bold face. So, I'd assume they have their normal
> English language meaning.
Well, it could also be argueud that in a programming language
context, the usual English definition of "addition" is "the processor's
addition instruction(s)". Certainly for REALs, the definition
of "addition" pretty much can't be "the mathematical sum
of the operands". Unless integer addition is explicitly defined
separately from real addition, whatever conclusion you come
to should be consistent for both? Or is it not required for the
standard to be consistent in the same way that I believe that
processor's are not required to be consistent? If the standard's
use of even the informally used English words is not required
to be consistent, doesn't that make the language even less
well defined?
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard Maine 2006-01-10, 4:11 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> Certainly for REALs, the definition
> of "addition" pretty much can't be "the mathematical sum
> of the operands".
I believe that is the definition of "addition" for reals, but that the
result of any operation giving a real includes an approximation. That is
to say
x = 2.0 + 2.0
doesn't mean that x is assigned the sum (addition, if you will) of 2.0
and 2.0. Instead it means that x is assigned an approximation to that
sum. I still think that the addition referred to is the mathematical
operation of addition, but that the computational result differs from
that mathematical one.
There are many places where the word "approximation" is explicitly used.
I'm actually in favor of a proposal I've heard to get rid of most of
those places and replace them by a single statement covering them all.
That would solve the problem of forgetting to put it in some places,
which has happened and resulted in people on J3 asking (rhetorically)
whether compilers were required to compute exact results for some
intrinsic functions where it "obviously" wasn't possible (things like
trig functions, though I forget exactly which ones).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| James Giles 2006-01-10, 4:11 am |
| Richard Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
>
>
> I believe that is the definition of "addition" for reals, but that the
> result of any operation giving a real includes an approximation. That
> is to say
>
> x = 2.0 + 2.0
>
> doesn't mean that x is assigned the sum (addition, if you will) of 2.0
> and 2.0. Instead it means that x is assigned an approximation to that
> sum. I still think that the addition referred to is the mathematical
> operation of addition, but that the computational result differs from
> that mathematical one.
The places describing addition as an operatior don't use the word
"approximation" (well, I can't find it on quick perusal). Even if it were
used, unless it was explicitly said *separately* for REALs, the word
would imply that integer arithmetic was an approximatrion: that the
computational result could differ from the mathematical one. If, without
the word "approximation", the defrinition of REAL addition is assumed
to allow the computational result to differ from the mathematical
result, isn't that the same for INTEGER add? Why not?
***
To get back on topic. On a 32-bit platform, is the processor
allowed to generate 2147483646 as the answer for (2147483647+
2147483645)/2, or must it not? If it's allowed, then is the processor
permited to carry extra precision on the intermediates? Or do you
think it got the answer by magic?
Suppose that i, j, and k are all 32-bit default integers, and li is
an extended precision integer (64-bit say). On most 32-bit
machiines, if I write:
i = 2147483647
j = 2147483645
k = i+j
print *,k
the answer printed is -4 (or an overflow message). Suppose the example
was:
i = 2147483647
j = 2147483645
li = i+j
print *, li, (i+j)/2
Is the processor prohibited from printing
4294967292 2147483646
even if the answer for the second value *is* permtted?
If the processor *is* permitted to carry extra intermediate precision,
how is this different from the case where NOT is involved. The value
of i+j has the 32nd bit set. The type and KIND of i+j is default
INTEGER. Is the compiler that uses extra precision for arithmetic
expressions prohibited from doing the same for bit-wise operations?
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard Maine 2006-01-10, 4:11 am |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> The places describing addition as an operatior don't use the word
> "approximation" (well, I can't find it on quick perusal).
Wouldn't surprise me. I mentioned the word being left out several
places.
> Even if it were
> used, unless it was explicitly said *separately* for REALs
Yes, it should be said separately for reals. As I said, I think it
should be said (elsewhere) that *ALL* real operations give
approximations, and that this was a property of real (not integer). I'm
confident that is the intent and that its omission is a wording
infelicity.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| James Giles 2006-01-10, 4:11 am |
| Richard Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
....
>
> Yes, it should be said separately for reals. As I said, I think it
> should be said (elsewhere) that *ALL* real operations give
> approximations, and that this was a property of real (not integer).
> I'm confident that is the intent and that its omission is a wording
> infelicity.
Well, I'm not. In fact, I'm pretty sure it is not a mere omission.
This is the specific issue that, 20 years or so ago, originally
interested me in looking carefully into the standard. My immediate
supervisor was our representative on the committee, and
mentioned this very issue: that two plus two wasn't required,
by the language standard, to be four. No, he wasn't talking
about REALs, though for those as well the standard made
no such requirement. Apparently it occasionally came up
in conversation among committee members: *should* the
standard require that two plus two be four? The reply from
other members was never that the standard already did so.
The answer was that it might take more effort than it's
worth - and after all what implementation would get something
that obvious wrong? (Of course, I know, and they knew, that
the issue was more general. Should there be minimum requirements
on the range of representable integers and should arithmetic
operations within that range be required to be exact? That's
the real issue and they all knew it.)
Now, I've mentioned this issue many times in this forum and
others over the years. And other people have brought it up
too. Today, for the first time ever, someone with plausible
credentials made the *certain* claim that the standard *does*
require two plus two to be four (and all the rest of it). That
makes Jan 6 2006 a memorable day. Unfortunately, it
rather smacks of revisionism. If you can't fix the document
interpret it differently than those that wrote it?
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| James Giles wrote:
> robin wrote:
[color=darkred]
> That's not what the concensuss is regarding the *same*
> question when REAL arithmetic is involved. The produst
> of two REALs may be a double (or even more extended)
> value.
The standard allows for approximate values for REALs.
I don't know if it is really legal for a double or extended result,
but many do it anyway.
-- glen
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| James Giles wrote:
(snip)
> NOT (3) proceeds the same as any application of NOT().
> The values of 3 is (presumably) in range and not negative,
> therefore its integer model corresponds without ambiguity
> to a value of the bit model. NOT() then complements the
> value which, in this case, leaves the righmost bit set. That
> value of the bit model doesn't have a *standard* correspomding
> value in the integer model and the processor is *expicilty*
> allowed by the standard to do anything it likes with that
> result. In the case I'd prefer, it keeps the whole result
> with sufficient precision not to lose any information (possibly
> using a larger register, or otherwise keeping track of the
> situation) and then applies the next operation as-if to that
> larger integer field.
If BIT_SIZE(3) is 32 then it must keep 32 bits worth of result,
including the sign bit. If an implementation can't guarantee
2**32 unique values then BIT_SIZE(3) must be less than 32.
The standard makes no claim as to the value as a signed integer
in the case that the sign bit is set, but it does require
2**BIT_SIZE(3) unique values.
Consider a decimal machine. The value of an INTEGER result from
NOT with the sign bit clear must be the usual binary value of
such bits. If the sign bit is set, it can be any other value,
but it must have the right properties if used in later bitwise
operations. The standard explicitly allows any radix greater
than one.
-- glen
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| James Giles wrote:
(snip)
> And the interpretation is processor dependent. The
> processor may do *anything* it likes.
Well, we know it can at least use ones complement or sign magnitude,
both of which will give different INTEGER values. It can also use
a radix other than two, which may require other values. It might
be that some ones complement or sign magnitude machines don't allow
the negative zero as a valid bit pattern. On those machines I would
say that BIT_SIZE() must be one less than one might expect.
(snip)
> So, the same as with REAL operations, the processor may
> carry *extra* bits if it chooses beyond those in the model
> for the type and KIND. And, what the *bits* mean (and even
> wbether they remain unchanged) is *explicitly* up to the
> processor!
Well, pretty much any rounding or imperfect approximation is allowed
for REAL. Too much precision, and so unexpected results, seems to be
a side effect of allowing that.
-- glen
| |
| James Giles 2006-01-10, 4:11 am |
| Combining two subthreads:
glen herrmannsfeldt wrote:
> James Giles wrote:
>
>
> If BIT_SIZE(3) is 32 then it must keep 32 bits worth of result,
> including the sign bit. If an implementation can't guarantee
> 2**32 unique values then BIT_SIZE(3) must be less than 32.
Yes, but there's nothing to prevent it from keeping those
32 bits in a register or storage location that's bigger.than
32 bits. If BIT_SIZE(3) is 32, then the processor must
be able to guarantee *at least* 2**32 values in the
intermediate calculations. It can decide, based on the
next operation that's applied to the result, whether any
extra precision it carries is meaningful or relevant.
> Consider a decimal machine. The value of an INTEGER result from
> NOT with the sign bit clear must be the usual binary value of
> such bits. If the sign bit is set, it can be any other value,
> but it must have the right properties if used in later bitwise
> operations. The standard explicitly allows any radix greater
> than one.
As far as I can tell, this provides even more justification
for my claim that the processor may do as it likes. It's even
harder to determine the "obvious" or "right" thing to do when
the argument is negative or the result has the right-most bit set
if the radix is not 2. For example, as far as I can tell, if the
radix is 10, the value but be converted to binary before
the bit-wise operations are performed. That is, AND(127,73)
is 73, not 23 (which is what you get if you AND the 4-bit
decimal digits together in some decimal representations).
This means that an implementation that keeps the intermediate
in binary form until it decides what the next operation is will
be a useful optimization.
glen herrmannsfeldt wrote:
> James Giles wrote:
>
>
>
> The standard allows for approximate values for REALs.
>
> I don't know if it is really legal for a double or extended result,
> but many do it anyway.
It's been discussed many times. I've objected, but been in the
minority. The majority view is that it really *is* legal for the
processor to carry more precision on the intermediates than
the presision of the operands. I can't find normative refutation
of that view. So, I assume the same is true for integer arithmetic
and bit-wise operations: they can carry more intermediate precision
than their operands. I can't find a normative refutation for that
view either.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| James Giles wrote:
(snip)
> It's been discussed many times. I've objected, but been in the
> minority. The majority view is that it really *is* legal for the
> processor to carry more precision on the intermediates than
> the presision of the operands. I can't find normative refutation
> of that view. So, I assume the same is true for integer arithmetic
> and bit-wise operations: they can carry more intermediate precision
> than their operands. I can't find a normative refutation for that
> view either.
Well, the real problem with floating point is when it is not
consistent, which happens pretty often. But consider the
integer case of a multiply being assigned to a variable twice
as big as the operands. Is it legal to keep the double length
product (as generated by many processors)?
-- glen
| |
| Ron Shepard 2006-01-10, 4:11 am |
| In article
<R3Wvf.430887$zb5.213181@bgtnsc04-news.ops.worldnet.att.net>,
"James Giles" <jamesgiles@worldnet.att.net> wrote:
> It's been discussed many times. I've objected, but been in the
> minority. The majority view is that it really *is* legal for the
> processor to carry more precision on the intermediates than
> the presision of the operands. I can't find normative refutation
> of that view. So, I assume the same is true for integer arithmetic
> and bit-wise operations: they can carry more intermediate precision
> than their operands. I can't find a normative refutation for that
> view either.
What about an expression such as ISHIFTC(NOT(0),BIT_SIZE(0))? If
the intermediate results of NOT(0) are extended beyond the number of
bits in the default integer, then this expression could have any
value at all. I think the result should be the same as NOT(0), but
that is only true if the intermediate result of NOT(0) has exactly
the same size as its argument.
$.02 -Ron Shepard
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| Ron Shepard wrote:
> In article
> <R3Wvf.430887$zb5.213181@bgtnsc04-news.ops.worldnet.att.net>,
> "James Giles" <jamesgiles@worldnet.att.net> wrote:
(snip)
[color=darkred]
> What about an expression such as ISHIFTC(NOT(0),BIT_SIZE(0))? If
> the intermediate results of NOT(0) are extended beyond the number of
> bits in the default integer, then this expression could have any
> value at all. I think the result should be the same as NOT(0), but
> that is only true if the intermediate result of NOT(0) has exactly
> the same size as its argument.
As operands to other functions, I don't believe it can be extended,
and this is one more reason that it can't.
To add in my question from my last post, how about
ISHIFTC(I*I,BIT_SIZE(I))
Where the product is generated at twice BIT_SIZE(I)
-- glen
| |
| James Giles 2006-01-10, 4:11 am |
| Ron Shepard wrote:
....
> What about an expression such as ISHIFTC(NOT(0),BIT_SIZE(0))? If
> the intermediate results of NOT(0) are extended beyond the number of
> bits in the default integer, then this expression could have any
> value at all. I think the result should be the same as NOT(0), but
> that is only true if the intermediate result of NOT(0) has exactly
> the same size as its argument.
The definition of ISHFTC is in terms of model numbers and is
specific (provided the top bit isn't set). So, the operation could
very easily be carried out in an extended register. And the result
could be left in that register. And yes, the answer is the same as
NOT(0). That's the problem?
I think you're blurring the distinction between semantics and
pragmatics again. Yes, the operation of ISHFTC on a longer
than necessary registion requires extra steps. But, the semantics
require that. It obvously can't be done with a "longword circular
shift instruction". Notwithstanding, it *can* be performed in
a long register and left there pending subsequent operations.
In fact, that's what I've been saying all along should be done
with NOT itself: you don't load the value into the register
and complement the whole thing, you only complement the
bits in the model for the argument KIND. That's the semantics
of NOT.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| James Giles 2006-01-10, 4:11 am |
| glen herrmannsfeldt wrote:
....
> Well, the real problem with floating point is when it is not
> consistent, which happens pretty often. But consider the
> integer case of a multiply being assigned to a variable twice
> as big as the operands. Is it legal to keep the double length
> product (as generated by many processors)?
It's legal unless you can find a normative reference that
prohibits it. You are certainly allowed to do so with
REALs (as is frequently asserted in this forum) and the
wording is the same for REALs and INTEGERs.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| James Giles wrote:
> Ron Shepard wrote:
Are you confusing ISHIFT and ISHFTC? ISHFTC is a circular shift,
often called a rotate. In the case of NOT(0), which by the standard
has the same BIT_SIZE as 0. The result of ISHFTC(I, BIT_SIZE(I))
should equal I for any I. Things become more interesting with
ISHIFT, though, which is what I originally thought you were asking.
[color=darkred]
> The definition of ISHFTC is in terms of model numbers and is
> specific (provided the top bit isn't set). So, the operation could
> very easily be carried out in an extended register. And the result
> could be left in that register. And yes, the answer is the same as
> NOT(0). That's the problem?
ISHFTC allows a third argument, the number of bits contributing
to the circular shift, less than or equal to BIT_SIZE, and defaulting
to BIT_SIZE. If a bit can't properly contribute to the shift,
it can't be including in BIT_SIZE. The special consideration of
the high bit only comes when considering it using the numerical model
in 13.4. When used directly as an operand of another logical
instruction, and assuming a legal shift value, there should be no
need for special consideration of the sign bit.
> I think you're blurring the distinction between semantics and
> pragmatics again. Yes, the operation of ISHFTC on a longer
> than necessary registion requires extra steps. But, the semantics
> require that. It obvously can't be done with a "longword circular
> shift instruction". Notwithstanding, it *can* be performed in
> a long register and left there pending subsequent operations.
> In fact, that's what I've been saying all along should be done
> with NOT itself: you don't load the value into the register
> and complement the whole thing, you only complement the
> bits in the model for the argument KIND. That's the semantics
> of NOT.
Most likely a combination of shift instructions and OR instruction.
Note that on most machines neither ISHIFT nor ISHFTC can be done
with a single hardware instruction, as most restrict the shift amount
to be less than BIT_SIZE, a restriction that C has in its << and >>
operators. The 8086 allows shifts up to 255, reduced in later models.
S/360 and S/370 allow up to 63 on either 32 bit or 64 bit shifts.
-- glen
| |
| Jan Vorbrüggen 2006-01-10, 4:11 am |
| > Suppose the example
> was:
>
> i = 2147483647
> j = 2147483645
> li = i+j
> print *, li, (i+j)/2
>
> Is the processor prohibited from printing
>
> 4294967292 2147483646
>
> even if the answer for the second value *is* permtted?
If the answer for the second value were permitted, I would _require_,
for consistency, the first value you show. However, I think in this
example the second value is not permitted: the expression i+j is
evaluated with a result the same kind as i and j, which for this being
a 32-bit integer will lead to overflow. If you had written
li = INT (i, kind = KIND (li)) + INT (j, kind = KIND (li))
things would be different.
Jan
| |
| Jan Vorbrüggen 2006-01-10, 4:11 am |
| > Well, pretty much any rounding or imperfect approximation is allowed
> for REAL. Too much precision, and so unexpected results, seems to be
> a side effect of allowing that.
OTOH, standardizing inquiry functions about data representations, including
floating-point data, and in the process defining model numbers and all that,
together with the type promotion rules in expressions and assignments, leads
to an expectation that all this actually means somehing useful. And useful
in this context, for me, means that the compiled code obeys the restrictions
that result from these definitions and rules. Now, a compiler optimization
where I tell it that it may violate some of these restrictions if it deems
them expedient in the interest of faster code is fine with me, as long as I
need to give it explicitly and the documentation tells me that (and preferen-
tially which of) those restrictions might be violated. Indeed, this is just
what xlf, for instance, does - when you give one of those options, it actually
prints a message to say that some of the expected semantics might change.
Jan
| |
| James Giles 2006-01-31, 7:02 pm |
| Jan Vorbrüggen wrote:
....
>
> If the answer for the second value were permitted, I would _require_,
> for consistency, the first value you show. However, I think in this
> example the second value is not permitted: the expression i+j is
> evaluated with a result the same kind as i and j, which for this being
> a 32-bit integer will lead to overflow. [...]
There is no concept of overflow in the standard document.
An implementation is not required to detect, report, or
"wrap" values on overflow. It *IS* permitted that it carry
extra precision for the intermediate calculations of an
integer expression. Otherwise, I would say, for consistency,
that the corresponding floating point example would *have*
to overflow:
dble_var = huge(0.0) + huge(0.0)
And we all know that the standard does *not* require that
to overflow.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
|
|
|
|
|