Sameness - an abstract approach.
[1/13] from: lmecir::mbox::vol::cz at: 13-Feb-2003 15:21
Hi Romano and all,
> I should like to know how you (and the official doc) interpret this point.
> Perhaps all this stuff is not clear to me.
It may be necessary to understand "the nature" of the values to be able to
understand the sameness (or the equality).
What are Rebol integers?
================
We may admit, that the following sentence is true: "Rebol integers may
reside in computer memory". (Any objections?)
Although the above sentence looks too primitive to be useful, it allows us
to draw a surprising conclusion:
1) We know, that the computer memory is an abstraction these days - see
notions like: "logical memory", "virtual memory".
2) Since the computer memory is an abstracttion, it surely isn't able to
contain physical things, that is why Rebol integers are abstractions too.
What is an abstraction?
==================
I think, that an abstraction is a property, that some physical things have
in common. Let's suppose, that two computer registers represent a number 1.
We may say, that the number 1 is the property, that these registers have in
common - namely the fact, that they both represent the same number - number
1.
Now we can ask another question: are Rebol integers the mathematical
integers? They have got a lot in common, because mathematical integers are
abstractions exactly as Rebol integers. Nevertheless, there is at least one
property, that Rebol integers have, which isn't observable for mathematical
integers: there is a maximal Rebol integer.
Do Rebol integers have a colour?
=======================
Some physical things representing Rebol integers may be red, but that
doesn't mean, that all physical things able to represent Rebol integers are
red. Therefore I think, that Rebol integers don't have a colour property.
There is no need to ask Rebol designer to find out.
Do Rebol integers have a position?
========================
As an example take a block:
b: [1]
You may say, that the integer value 1 contained in the block B has got a
position 1. Even though you have got the right to say so, I have got the
right to ask:
Is the position a property of Rebol integers?
==============================
These answers came to my mind:
1) The position is a property of Rebol integers.
2) The position isn't a property of Rebol integers.
3) It is undecidable, whether the position is a property of Rebol integers.
4) There is only one man, who can and must be enforced decide, whether the
position is a property of Rebol integers and before he decides, no answer
can be given.
Which answer is correct?
=================
Let's use an experiment to find out. First, we can prepare a block C having
the length 2 as follows:
c: [1 1]
Now, let's have a function F defined as follows:
f: func [i [integer!]] body
I didn't specify the BODY of F, but somebody clever might try to surprise us
all. The documentation states (cited freely, any objections?): "we can
supply an integer value to the function F as its argument". Let's ask
another question:
Can F tell, whether it obtained the number 1 with the position 1 in C or the
number 1 with the position 2 in C?
==========================================================================
I think, that we all agree, that the function F cannot tell. (any
surprises?) This means, that if we can take the above cited information for
granted, we must come to the conclusion, that "Rebol integers don't have a
position", otherwise the position should have been known to F as the
property of the integer value supplied as the argument. If this is true,
how come, that we can tell, that "number 1 is at the position 1 in C"?
===============================================
Because that is the property of C.
Summary:
there is only one Rebol integer number 1 not having any position at all,
while we can have many positions referring to it.
Regards
-L
[2/13] from: g:santilli:tiscalinet:it at: 13-Feb-2003 19:25
Hi Ladislav,
On Thursday, February 13, 2003, 3:21:45 PM, you wrote:
LM> there is only one Rebol integer number 1 not having any position at all,
Your conclusion is not correct. You can conclude that integers do
not have a position, but you cannot say that there is only one
1
. Both possibilities are valid, i.e. it is possible that there
is only one "1", and it is possible that there are multiple "1"s.
Imagine I give you a piece of paper; it is white and has the size
of 5 cm by 5 cm. Now you give it back to you, and I give back to
you a piece of paper that is white and has the size of 5 cm by 5
cm, and I ask to you: "is this THE SAME piece of paper I gave you
earlier?". Can you answer this question? If after that I give you
two pieces of paper that are both white and have the size of 5 cm
by 5 cm and I ask you: "are these two THE SAME piece of paper?",
what would your answer be?
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[3/13] from: joel:neely:fedex at: 13-Feb-2003 13:23
Hi, Ladislav,
OK, this time Plato would have been proud! ;-)
I'd only like to add one bit of gilding to your lilly...
Ladislav Mecir wrote:
...
> Which answer is correct?
> >
<<quoted lines omitted: 16>>
> should have been known to F as the property of the integer value
> supplied as the argument...
Here I'd add that there's yet another possibility, which is that if
I attempt to evaluate
f 2 - 1
we'd have to confront the issue of whether the on-the-fly instance
of 1 resulting from the subexpression 2 - 1 "has a position" or not,
or "has a position" of a different kind than C/1 and C/2, etc.
Ergo by Occam we exclude "position" as a property of integer values,
along with "age", "mode of creation" (result of expression evaluation,
literally inserted in the source, converted from string as a result
of input, etc.)
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
Atlanta, Ga. - Scientists at the Centers for Disease Control today
confirmed that hoof-and-mouth disease cannot be spread by Microsoft's
Outlook email application, believed to be the first time the program
has ever failed to propagate a major virus.
[4/13] from: rotenca:telvia:it at: 13-Feb-2003 20:51
Hi Ladislav,
> there is only one Rebol integer number 1 not having any position at all,
> while we can have many positions referring to it.
Now i understand well your point of view. Thanks for the explanation.
You are lucky! If integer were mutable, I could change all the 1 of your code
in 2 with a simple:
x: 1
change x 2
:-)
But memory say another tale about number storage, and i am sure that:
x: [1 1]
change x/1 2
will result in
x: [2 1]
But you are lucky, change should not work on scalar.
But i can at least say that there are same? scalar value more same? than
others?
For this look at my new puzzles.
---
Ciao
Romano
[5/13] from: joel:neely:fedex at: 13-Feb-2003 14:45
Hi, Romano,
See below...
Romano Paolo Tenca wrote:
> Hi Ladislav,
> > there is only one Rebol integer number 1 not having any position at
<<quoted lines omitted: 5>>
> change x 2
> :-)
You're dangerously close to scoring bonus points on the "Hacker Test"
located at
http://www-users.cs.york.ac.uk/~susan/joke/hacker.htm
which gauges how long/much one has been programming. The following
are the relevant questions:
0015 Ever change the value of 4?
0016 ... Unintentionally?
0017 ... In a language other than Fortran?
I wonder how many of us still know how it was done in Fortran?
;-)
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
Atlanta, Ga. - Scientists at the Centers for Disease Control today
confirmed that hoof-and-mouth disease cannot be spread by Microsoft's
Outlook email application, believed to be the first time the program
has ever failed to propagate a major virus.
[6/13] from: lmecir:mbox:vol:cz at: 13-Feb-2003 22:29
Hi Gabriele,
> LM> there is only one Rebol integer number 1 not having any position at
all,
> Your conclusion is not correct. You can conclude that integers do
> not have a position, but you cannot say that there is only one
> "1". Both possibilities are valid, i.e. it is possible that there
> is only one "1", and it is possible that there are multiple "1"s.
yes, you are clever and you really found a gap in my reasoning. I can bridge
the gap at the cost of some bandwidth.
I think, that it is acceptable to you, that Rebol integers are abstractions.
As I stated, I think, that abstractions are properties, that some physical
things have in common. What if we use a name A for an abstraction and a name
B for an abstraction and find out, that there is no difference between
abstraction called A and abstraction called B? I can tell, that A is a
property that some physical things have in common. As long as A doesn't
differ from B, I can conclude, that B is a property, that the same physical
things have in common as in the case of A, i.e. A and B are different names
for one abstraction.
Let's try to compare the abstraction we can call the first number 1 from the
block C and the abstraction we can call the second number 1 from the block
C. If there were any difference between them, we could have supplied them to
the function F one after another and the function F should get them as
different and find out which was which. That isn't the case as we both
agree, q.e.d.
Regards
-L
[7/13] from: g:santilli:tiscalinet:it at: 14-Feb-2003 1:17
Hi Ladislav,
On Thursday, February 13, 2003, 10:29:59 PM, you wrote:
LM> the function F one after another and the function F should get them as
LM> different and find out which was which. That isn't the case as we both
LM> agree, q.e.d.
This is fine as long as the two "1"s are takes separately. I.e. it
is like in my previous email when I gave you two
indistinguishable
pieces of paper not at the same time. They
look the same piece of paper to you, because you have no mean to
make a distinction (supposing you are not allowed to change them).
But if I give them to you at the same time, even if you cannot
discern a piece from the other you can say that you have two
different pieces of paper (and the distinction is, for example,
the hand that holds them --- one is on the left, the other in on
the right).
This can be applied to the "1"s above; if you have two of them at
the same time, it is possible that they are like the two pieces of
paper: interchangeable but not the same. (If I was going to
implement a REBOL interpreter, I would do it so that any two "1"s
would actually be different data structures in different memory
locations --- even if they are equal in content and so totally
interchangeable; this does not mean that REBOL has to be this way,
but it means that this is a possible way.)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[8/13] from: lmecir:mbox:vol:cz at: 14-Feb-2003 13:15
Hi Gabriele,
...
> (If I was going to
> implement a REBOL interpreter, I would do it so that any two "1"s
<<quoted lines omitted: 4>>
> Regards,
> Gabriele.
You already may have noticed, that the difference between our POV's is mainly a terminological
problem. You think, that an integer is what you implement it to be, while the most useful
terminology uses abstractions to hide some implementation details. A terminology using
implementation details is always more complicated, while its stability is questionable
- if you changed the implementation, you would have to use a different terminology even
if the implementations were compatible.
Rebol documentation uses abstractions instead of implementation details. I am aware of
one implementation detail in the documentation: "... For example, a TRUE would be returned
if two strings ... (occupy the same location in memory)." I intentionally omitted the
... parts, that can be called a "definition in circle". This definition is so much incomplete,
that it isn't a definition. That is why I thought, that Rebol deserved a more useful
definition.
Regards
-L
[9/13] from: joel:neely:fedex at: 14-Feb-2003 7:47
Hi, Gabriele,
Ah, but bits aren't atoms...
Gabriele Santilli wrote:
> But if I give them to you at the same time, even if you cannot
> discern a piece from the other you can say that you have two
<<quoted lines omitted: 4>>
> the same time, it is possible that they are like the two pieces of
> paper: interchangeable but not the same...
More to the point, if I hand you two "indistinguishable" pieces of
paper at the same time, you *can* distinguish them (e.g. by which
hand holds each one of them). However, you're distinguishing them
by physical location, which works for atoms and not for bits. If
your two hands simultaneously hold two otherwise indistinguishable
objects, you know that they necessarily have distinct histories,
even if you don't know the details (e.g. where they came from).
This is not true of bits. If "register A" of a CPU holds the same
value as "register B", that fact alone does not compell us to
conclude that those two values "came from different places" in any
particularly meaningful sense. OTOH "call by reference" means that
you/CPU are given not the value but access to a container holding
the value; now you/CPU can tell whether there are one or two hands.
But now the discussion is about hands and not pieces of paper!
If we allow you the use of a marker or scissors, you can also mutate
at least one of the pieces of paper so that that you'll be able to
distinguish them if you give them back to me and I subsequently hand
them to you one at a time. But if they are made of some hypothetical
super-teflon that resists all attempts to mark/cut them (or you're in
the home for people who worry too much about the subject of this email,
and you are denied the use of markers and sharp things ;-) then you
won't be able to mutate them to facilitate future distinction.
To push the analogy further (faithfully, I hope), suppose I give you
two photographs/photocopies showing indistinguishable images of a
piece of paper (call by value). Now the fact that you are holding
two copies isn't sufficient to distinguish between two copies of the
same piece of paper vs. one copy each of two identical pieces of
paper. Further, if you modify one of the copies and hand them back
to me, when I subsequently give you another photograph/-copy, you
won't be able to tell whether it is:
- the unmodified copy from before,
- another (fresh) copy of the same (original) piece of paper,
- another (fresh) copy of *one* *of* the original *two* pieces,
- a copy of a newly-minted piece of paper made just like the others,
- a second-generation copy of any the above (if my copier is of
sufficiently-high quality ;-)
- or other variation we haven't the time to address right now.
Metaphors share the property with gunpower, electricity, and nuclear
reactions: they are all very powerful, with terrible consequences for
misuse. When we push metaphors between atoms and bits too far, we
may simply be limiting our imaginations by what we expect from every-
day experience; this is a dangerous as going to another country for
the first time and interpreting everything that is done/said in terms
of the customs with which one grew up.
What's worse is that there's another layer here: the metaphors
between electrons and bits! There really are no "integers" inside a
computer, but rather patterns of electrical activity that we have
arranged to use "as if" they were (a finite subset of) integers.
I'm not trying to be cute or clever or pedantic here; I'm trying to
put the burden of interpretation where it belongs -- back on us!
Let me give two quick examples of why I think this is an important
point:
1) In the early days of "structured programming" (and, sad to say,
with some folks who haven't progressed conceptually past the
late 60s or early 70s ;-) there were some who scorned the value
of such concepts as if-then-else, while-do, etc. by saying
But inside the computer those all become GOTOs anyway!
My reply is
Nothing inside the computer is "go"ing anywhere, except
possibly electrons. All that's happening is that the
contents of a register called the "program counter" are
being changed in some way other than by adding one!
The point is that there is a circular relationship between our
metaphors and our machines; earlier computers were designed on
earlier conceptual models (metaphors), but programming those
primitive machines inspired us to think up more sophisticated
metaphors, which in turn the design and construction of more
sophisticated machines, etc... Progress is made by creating
new metaphors when the old ones create limitations.
The metaphor that there's a "point of control" which moves about
as the program "executes" may be OK for beginning programmers
(or it may *not* ;-) but sticking with that metaphor too long
makes it unnecessarily difficult to deal with concurrency,
distributed computation, declarative programming (e.g. Prolog,
Erlang, etc.), and even recursion. "Evaluation of expressions"
is a much nicer metaphor!
2) Imagine with me about a new CPU, the PowerHextium, which uses
ternary qubits (or some other equally esoteric) representation
of data values. The micro vesion of the PowerHextium has a
33-bit address space; all addresses with a leading zero contain
a "pure" representation of an ideal integer (e.g. with no
superposition) and that half of memory is write-protected. So
for example memory address 0000...0001 contains a pure "one".
The PowerHexium is able to do arithmetic on addresses, so that
adding 0000...0001 to 0000...0101 gives 0000...0110 for example.
This is useful for performance because the circuitry is able to
add addresses a few femtoseconds faster than adding (potentially
superposed 33-qubit) values. Also, the PowerHexium throws an
"address overflow" exception if adding addresses carries into
the high-order bit (when the second bits of the addresses are
of equal values). We could then carry out *ALL* arithmetic of
current 32-bit microprocessors on the PowerHexium usinn only
address operations.
The punch line, of course, is that we are working with things
that represent "true integers" and can manipulate those values
that represent the "true integers" without ever modifying (or
even accessing) the "true integers" themselves. (Of course, we
can simulate the PowerHexium with a current-generation microCPU
by dropping the high bit, changing all code that manipulates
addresses to manipulating 32-bit integers, etc. But then we're
just evaluating our REBOL expression using the box on my desk!
;-)
Metaph(or|ys)ically yours,
-jn-
[10/13] from: g:santilli:tiscalinet:it at: 14-Feb-2003 15:17
Hi Ladislav,
On Friday, February 14, 2003, 1:15:58 PM, you wrote:
LM> You already may have noticed, that the difference between our
LM> POV's is mainly a terminological problem. You think, that an
LM> integer is what you implement it to be, while the most useful
LM> terminology uses abstractions to hide some implementation
LM> details.
That's fine, but since there's no way to decide if two equal
integers are the same or not (i.e. there are two possible abstract
definitions), I don't see anything wrong in deciding that they are
not the same; there's nothing wrong in deciding that they are the
same either, I just prefer the former because personally find it
more "natural" (i.e. think of the two pieces of paper).
That said, I think there's really no point in continuing to argue
on an arbitrary question like this, I think I have bored all the
people here much enough. :-)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[11/13] from: g:santilli:tiscalinet:it at: 14-Feb-2003 19:41
Hi Joel,
On Friday, February 14, 2003, 2:47:37 PM, you wrote:
JN> Ah, but bits aren't atoms...
I think my point was not clear enough.
I simply claim that both definitions are valid definitions. I
prefer one of them because it looks more natural to me. I have
nothing against the other one, as it is just another possibility.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[12/13] from: brett:codeconscious at: 15-Feb-2003 13:12
> .....I think I have bored all the
> people here much enough. :-)
No not at all. All the messages in the thread have been interesting. Not
just for their points directly, but how they were made and how persuasive
those points, in and of themselves, can be. Also, such discussions are
practically useful in my opinion, because they encourage in readers fresh
thoughts and valuable insights.
Still, I agree with the spirit of your comment, a lot has been said :^)
Regards,
Brett
[13/13] from: lmecir:mbox:vol:cz at: 15-Feb-2003 8:35
Hi Gabriele,
> I think I have bored all the
> people here much enough. :-)
yes, it is likely, that *we* have bored. Nevertheless, there is something
principially wrong with your "paper metaphor". It shouldn't be left floating
around without an answer.
As concisely as I am able:
...
> it
> is like in my previous email when I gave you two
<<quoted lines omitted: 6>>
> the hand that holds them --- one is on the left, the other in on
> the right).
If you gives me twice a piece of paper at different times, I may not be able
to say, that I received two pieces. IOW, I may not be able to discern two
pieces of paper. This is the correct part of your metaphor.
The incorrect part is, that you are saying, that if I find out, that two
papers are indiscernible (which means, that nobody can discern them), I am
in the same situation. Actually, I am not. I can sign a document, that you
gave me just one piece of paper, because it is not possible to hold one
piece in my right hand and the other in my left hand. If that were possible,
then even I would be able to discern the pieces, which wasn't the case.
Regards
-L
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted