Re: ptr conversions and values
- From: kuyper@xxxxxxxxxx
- Date: 13 Oct 2005 10:28:55 -0700
S.Tobias wrote:
> [order of quotes slightly rearranged]
> kuyper@xxxxxxxxxx wrote:
> > S.Tobias wrote:
....
> >> Making values of different types equivalent means nothing more
> >> that joining them in pairs.
> >
> > Joining them in pairs is called mapping, not equivalence.
> >
> Whatever. My choice of words was poor. I called them "equivalent"
> as I could not call them "equal"; later I found "corresponding"
> was a better word.
You make it sound as if "mapping" and "equivalence" are similar
concepts, and your choice of the wrong one of the two represents a
minor mistake. You can establish a mapping between members of any two
sets, whatsoever. The existence of the mapping doesn't make them in any
sense equivalent; it doesn't imply they are even remotely similar. I
can define a mapping that connects the letter J to a specific orange
currently residing in a grocery store in the city of Minsk. That
doesn't mean there's any significant similarity between "J" and that
particular organge.
....
> What I cannot comprehend is how you can accept that a complex type
> and a corresponding array, or an imaginary and a corresponding real,
> can have the "same meaning", and a pointer and an integer can't.
The real and imaginary parts of a complex number are themselves real
numbers. Therefore, the real part and imaginary parts of a double
precision complex number can have the same representation as a double.
There's no sense in which a memory location and an integer are the same
thing.
....
> >> How you make those pairs is pretty arbitrary.
> >
> > Not true: if you're pairing together inequivalent values, the fact that
> > you chose to pair them together doesn't make the representations of
> > those values equivalent.
> >
> Of course most such pairings would not be sensible. In my
> generalization I was trying to develop a widest possible
> interpretation while still keeping things consistent, and see how far
> it could go (if there were two interpretations, there could be N).
> The problem is which values are to be considered equivalent, and
> that _may_ be arbitrary to some extent.
It's completely arbitrary. There's no possibile mapping which is ruled
out.
> [snip]
> > A mapping from bit patterns to memory locations is fundamentally
> > different from a mapping from bit patterns to integer values.
>
> How is this "fundamental difference" different from mapping to
> complex types and to corresponding arrays?
Because a memory location is a place where you can store a
representation of a value, while an integer is a number. The real part
of a complex number IS a real number, and the same is true of it's
imaginary part. There's an absolute identity between those things,
whereas any connection between memory locations and integers is a part
of the definition of the system containing those memory locations; it
is not an identity, it's a mapping. For instance, integers can be added
to each other. What would it mean to add memory locations? You can
store values in memory locations. The concept of storing a 61 in the
integer 3 is meaningless.
> ... I don't do anything
> substantially different that the Standard does: I attach additional
> meaning to an integer and treat it as a pointer that points at the
> location of an i'th byte in a char array that occupies the whole
> memory. I couple an integer and a pointer when they "point" at the
> same location. How is it different from what the Standard does:
> it attaches a meaning of a complex number to an array of two reals,
> and joins it with a complex type that expresses the same value.
The difference is that the real and imaginary parts of a complex number
are themselves real numbers, so it's meaningful to say that they are
represented in the same fashion as a real number. Integers and memory
locations are not the same thing, so it's not meaningful to say that
they are represented in the same way.
> >I think you're asserting that there's a unique
> > mapping from integers to memory locations that should be used to define
> > what it means when you say that the representation of an integer type
> > is equivalent to the representation of a pointer type.
> I don't say it's unique, but that this one is sensible.
You seem to be implying that it's more sensible than any of the
alternatives. If so, that makes it unique. However, even if you're
merely claiming that it's one of a few million equally sensible
alternatives, that doesn't change the fact that you're treating this
mapping as if it makes things mapped to a given element of the target
set equivalent to the elements of the target set; and that's just not
the case.
> > The true connection is through values, not conversions.
> I assume you think of integers here. Thanks, you're the first
> person to acknowledge this openly.
No, I'm also thinking of pointers. The value of a pointer is the
location at which it points.
....
> I agree with all that mostly. Only I still can't understand
> why "pointers are equivalent when they convert into each other"
> should be better than "when they point at the same location".
I never said that it was.
....
> >a complex value must have the same representation as an array
> > of two elements of the corresponding real types, and therefore cannot
> > have padding bytes between them. But how does that justify saying "No"
> > to my statement that the components of the complex type are the only
> > parts that are required to have the same representation as the
> > corresponding real type?
....
> In the first place my "No" meant that the requirement of same
> representation was stronger than one just for the components.
Since my statement was not in conflict with that fact, the word "No"
was not justified.
> Secondly, I object to your way of reasoning. You cannot talk about
> components of complex types, because you don't know it until you
> make the said requirement (it's similar to using the results of a
> theorem in order to prove that theorem). Mathematically complex
> values may be defined as pairs of real values, but this does not
> necessarily need to be reflected in the representation of complex
> types; they can be split into components *because* they have the same
> representation as a corresponding array (which does have components).
If a given object represents a complex number, there's a mathematically
clear and precise meaning to the real component of that number. You
could talk about the value of the real component of that number even if
the standard mandated a polar representation of complex numbers. You
don't need to know that he standard mandates that the components be
explicitly represented, in order to identify what they are. The real
component of complex number represented by a radius=1.0 and an
angle=45.0 degrees is 0.5*sqrt(2.0), even though the object containing
the representation of that number doesn't contain 0.5*sqrt(2.0).
What the standard says about the representation of complex numbers
means that if the mathematical value of the real component of a complex
number is 3.0, then the first sizeof(double) bytes of the
representation of that complex number must contain bits that would, if
interpreted as a double, represent the same exact value, 3.0. It's that
fact which prevents a polar representation. Key point: 3.0, referring
to the value of the real part of a complex number, is exactly the same
value as 3.0, referring to the value represented by a double.
The "third memory location after the start of memory" is NOT the same
thing as the integer 3. They are quite different things that can be
mapped together. That mapping doesn't make them equivalent, and it is
therefore incapable of making it meaningful to say that they have the
same representation.
.
- Follow-Ups:
- Re: ptr conversions and values
- From: S.Tobias
- Re: ptr conversions and values
- References:
- Re: ptr conversions and values
- From: S.Tobias
- Re: ptr conversions and values
- Prev by Date: Re: Argument of free() should be const void*
- Next by Date: Re: Argument of free() should be const void*
- Previous by thread: Re: ptr conversions and values
- Next by thread: Re: ptr conversions and values
- Index(es):
Relevant Pages
|
Loading
