Sameness - an abstract approach.

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

...

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.

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

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.

all,

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

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

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-

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

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: ...

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