Mailing List Archive: 49091 messages

# Puzzle with FIND and SELECT

### [1/37] from: joel:neely:fedex at: 7-Feb-2003 6:27

Here's a console transcript, unedited except for the blank line I've inserted between consecutive expressions/results for readability:
>> numbers
== [1 2 3 4 5]
>> find numbers 3
== none
>> select numbers 3
== none
>> foreach num numbers [print [num tab num = 3]]
1 false 2 false 3 true 4 false 5 false
>> foreach num numbers [print [num tab same? num 3]]
1 false 2 false 3 true 4 false 5 false I'll post separately the solution to this little mystery, to allow some pondering time for anyone who's interested in working it out uncontaminated by the solution. -jn-

### [2/37] from: lmecir:mbox:vol:cz at: 7-Feb-2003 15:02

Hi, ----- Original Message ----- From: "Joel Neely"
> Here's a console transcript, unedited except for the blank line I've > inserted between consecutive expressions/results for readability:
<<quoted lines omitted: 16>>
> 4 false > 5 false
I bet that you didn't mean the "solution" below, which looks like the most trivial answer: context [ i: 0 nbrs: [ [1 2 3 4 5] [1 2 3 4 5] [] [] ] set 'numbers does [first skip nbrs i: i + 1 // 4] ]

### [3/37] from: g:santilli:tiscalinet:it at: 7-Feb-2003 15:27

Hi Joel, On Friday, February 7, 2003, 1:27:29 PM, you wrote: JN> Here's a console transcript, unedited except for the blank line I've JN> inserted between consecutive expressions/results for readability: I'll give an hint: nothing is what it looks like. :-) Also, my solution only works with the old non-betas, so unless there's another solution for the latest versions that I don't know of, I think it's better for you to not go mad trying to solve it on them. ;-) I'll post my solution later, too. Joel, could you post yours just after you see mine? Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

### [4/37] from: rotenca:telvia:it at: 7-Feb-2003 15:14

Hi, Joel The solution is down: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . numbers: reduce [1 2 to-decimal "3" 4 5] some variants: numbers: reduce [1 2 to-word "3" 4 5] numbers: reduce [1 2 to-path "3" 4 5] numbers: reduce [1 2 to-url "3" 4 5] numbers: reduce [1 2 to-email "3" 4 5] --- Ciao Romano

### [5/37] from: rgombert:essentiel at: 7-Feb-2003 15:59

Here is a way :
>> numbers: head insert at [1 2 4 5] 3 to-decimal 3
== [1 2 3 4 5] that gives :
>> numbers
== [1 2 3 4 5]
>> find numbers 3
== none
>> select numbers 3
== none
>> foreach num numbers [print [num tab num = 3]]
1 false 2 false 3 true 4 false 5 false
>> foreach num numbers [print [num tab same? num 3]]
1 false 2 false 3 true 4 false 5 false Renaud GOMBERT -------------------------------- www.essentiel.net N° SIRET : 418 620 159 N° MdA : G316527 NAF/APE : 923A

### [6/37] from: joel:neely:fedex at: 7-Feb-2003 9:45

Hi, Gabriele, I'll be glad to post soon; I don't want to drag this out too long. -jn- Gabriele Santilli wrote:
> I'll give an hint: nothing is what it looks like. :-) > > Also, my solution only works with the old non-betas... >
Since I usually stay out of beta-land, I don't know whether that's an issue. I'll post soon, and someone can let us know. -- ---------------------------------------------------------------------- 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.

### [7/37] from: joel:neely:fedex at: 7-Feb-2003 9:42

>> type? :numbers
== block! -jn- Ladislav Mecir wrote:
> > I bet that you didn't mean the "solution" below, which looks like > the most trivial answer: >
... -- ---------------------------------------------------------------------- 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.

### [8/37] from: g:santilli:tiscalinet:it at: 7-Feb-2003 16:55

Hi Romano, On Friday, February 7, 2003, 3:14:09 PM, you wrote: [Don't read below if you don't have your answer] RPT> Hi, Joel RPT> The solution is down: RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> . RPT> numbers: reduce [1 2 to-decimal "3" 4 5] Oh, didn't think of this. So there's a way (and an easy way too :) for the betas. My solution:
>> system/version
== 1.2.1.3.1
>> word: to-word "3"
== 3
>> path: to-path reduce [word]
== 3
>> set word 3
== 3
>> numbers: [1 2 3 4 5]
== [1 2 3 4 5]
>> poke numbers 3 :path
== [1 2 3 4 5]
>> find numbers 3
== none
>> select numbers 3
== none
>> foreach num numbers [print [num tab num = 3]]
1 false 2 false 3 true 4 false 5 false
>> foreach num numbers [print [num tab same? num 3]]
1 false 2 false 3 true 4 false 5 false Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

### [9/37] from: joel:neely:fedex at: 7-Feb-2003 10:02

Hi, Renaud and Romano, (Sorry, Gabriele... the feline has exited the flexible container! ;-) You guys get the right result, but work way too hard! numbers: [1 2 3.0 4 5] is all it takes. Gabriele, is that your solution, or should I now show a draft REP? -jn- Renaud GOMBERT wrote:
> Here is a way : > > >> numbers: head insert at [1 2 4 5] 3 to-decimal 3 > == [1 2 3 4 5] >
-- ---------------------------------------------------------------------- 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.

### [10/37] from: rotenca:telvia:it at: 7-Feb-2003 18:30

Hi all, don't you think that this is a bug?
>> same? to-decimal 3 to-integer 3
== true --- Ciao Romano

### [11/37] from: christian:ensel:gmx at: 7-Feb-2003 19:13

Hello Joel, without any knowledge on replies to this puzzle - how's about the following solution ? Probably not quite what you had in mind, but it's producing exactly your output: numbers: function [] [call] [ call: [0] change call call/1 + 1 either find [1 4 5] call/1 [ [1 2 3 4 5] ] [ [] ] ] Which gives ...
>> numbers
== [1 2 3 4 5]
>> find numbers 3
== none
>> select numbers 3
== none
>> foreach num numbers [print [num tab num = 3]]
1 false 2 false 3 true 4 false 5 false
>> foreach num numbers [print [num tab same? num 3]]
1 false 2 false 3 true 4 false 5 false ;-)) Cheers, Christian -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

### [12/37] from: joel:neely:fedex at: 7-Feb-2003 12:34

Hi, Romano, Yes, although without access to the design specs I can't say whether it is a design bug or an implementation bug. Romano Paolo Tenca wrote:
> don't you think that this is a bug? > > >> same? to-decimal 3 to-integer 3 > == true >
Furthermore... I now believe that the following is a misfeature:
>> print 3.0
3 With any "subtype" of ANY-STRING! (for example) the format of the external syntax/representation suffices to allow the user to tell *at*a*glance* the type of a value: "this is a string" {this is another string} <this type="tag" confidence="obviously"> %no/doubt/a/file and so on. I propose that the same should be true for DECIMAL! versus INTEGER! values, with a radix point guaranteed in the result of FORM or MOLD or any other such conversion of DECIMAL! values, so that (e.g.) print 3.0 would output 3. or 3.0 (I really don't care which, as long as the radix point is there). -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.

### [13/37] from: rgombert:essentiel at: 7-Feb-2003 20:21

it seem that rebol say "same" when two values refer to the same object (place in memory) or, if they are "atomic" values such as numbers or chars if they are equal considering their value.
>> a: #"4" >> same? a #"4"
== true
>> same? :a #"4"
== true
>> b: 3 >> same? b 3
== true
>> same? :b 3
== true
>> same? 95 + 5 200 / 2
== true
>> txt: "foo" >> list: reduce [100 "foo" txt] >> same? list/1 100.0
== true
>> same? list/2 "foo"
== false
>> same? list/2 txt
== false
>> same? list/3 "foo"
== false
>> same? list/3 txt
== true So when 'same? have to examine objects that it is not relevant to compare by their location in memory they are compared by their value. For "ideal" objects such as numbers, they effectively are the same if their value is, wherether they could be ;-) Renaud GOMBERT -------------------------------- www.essentiel.net

### [14/37] from: greggirwin:mindspring at: 7-Feb-2003 18:33

Hi Joel, JN> With any "subtype" of ANY-STRING! (for example) the format of the JN> external syntax/representation suffices to allow the user to tell JN> *at*a*glance* the type of a value: Maybe we should make a list for them. money! values have problems displaying the correct result with print when the actual value is correct...now where is that old note on it... -- Gregg

### [15/37] from: lmecir:mbox:vol:cz at: 8-Feb-2003 8:08

Hi Romano, ----- Original Message ----- From: "Romano Paolo Tenca"
> Hi all, > > don't you think that this is a bug? > > >> same? to-decimal 3 to-integer 3 > == true
According to my results on sameness, (in http://www.rebolforces.com/~ladislav/evaluation.html ), this way of comparing things isn't the true identity in Rebol. I think, that a naturally designed Rebol identity would be better. -L Praetera censeo, the crashes of SAME? are untolerable.

### [16/37] from: rotenca:telvia:it at: 8-Feb-2003 16:03

Hi, Joel JN> With any "subtype" of ANY-STRING! (for example) the format of the JN> external syntax/representation suffices to allow the user to tell JN> *at*a*glance* the type of a value: this is not true: probe any-string? probe to-email "3" probe any-string? probe to-url "3" --- Ciao Romano

### [17/37] from: rotenca:telvia:it at: 8-Feb-2003 17:11

Hi Ladislav, about "absolute sameness", i think that these cases are different: x: [1 1] same? x/1 x/2 two values in two different position in a block i can discern them with something like: change x 3 same? x/1 x/2 x: 1 same? x x the same value in the same position of the block of the global context --- Ciao Romano

### [18/37] from: joel:neely:fedex at: 8-Feb-2003 11:08

Hi, Romano, Romano Paolo Tenca wrote:
> this is not true: > > probe any-string? probe to-email "3" > probe any-string? probe to-url "3" >
Point taken; I should have stated myself more clearly. I was referring to the syntax used to write literal values. The sub-expression "3" in the above is clearly a STRING! value, and it was necessary to have REBOL do some additional evaluation to create a value that breaks the normal syntax rules. (The same thing applies for e.g. TO-WORD .) The newly-introduced notation for literal LOGIC! and NONE! values (or rather the need for such) reinforces my view that the external representation of "literal" values should make clear the types of those values. Thanks for clarifying! -jn-

### [19/37] from: lmecir:mbox:vol:cz at: 9-Feb-2003 1:44

Hi Romano, ----- Original Message ----- From: "Romano Paolo Tenca"
> about "absolute sameness", i think that these cases are different: > x: [1 1]
<<quoted lines omitted: 3>>
> change x 3 > same? x/1 x/2
(...) About "absolute sameness": 1) My goal was to find a "natural" definition of identity in Rebol. 2) You are free to write your own definition if you like, but I am pretty sure, that you will have big problems with the "absolute sameness". The reason is simple: my definition is the finest equivalence you can define in Rebol, therefore any definition you can write either cannot be finer then mine, or it cannot be an equivalence. No sameness that isn't an equivalence can be natural, neither I think, that any coarser equivalence is a true identity. Ciao -L

### [20/37] from: rotenca::telvia::it at: 9-Feb-2003 12:19

> 2) You are free to write your own definition if you like, but I am pretty > sure, that you will have big problems with the "absolute sameness". The
<<quoted lines omitted: 3>>
> can be natural, neither I think, that any coarser equivalence is a true > identity.
I want to say that the finest equivalence is not the finest sameness one can detect inside the limits of rebol language. The finest sameness happens when the evaluation process get exactly the same value in the same series. An equivalence that find the finest sameness should get the unevaluated args and check that the evaluation process ends to the same value in the same series. I do not know if this is "natural". --- Ciao Romano

### [21/37] from: lmecir:mbox:vol:cz at: 9-Feb-2003 20:10

Hi Romano, ----- Original Message ----- From: "Romano Paolo Tenca" ...
> The finest sameness happens when > the evaluation process get exactly the same value in the same series. > An equivalence that find the finest sameness should get the unevaluated
args
> and check that the evaluation process ends to the same value in the same > series. > > I do not know if this is "natural".
I am not sure it is a "definition". How is that supposed to work? Would you like to have a function e.g. ABSOLUTELY-SAME? Ciao -L

### [22/37] from: rotenca:telvia:it at: 10-Feb-2003 11:34

> I am not sure it is a "definition". How is that supposed to work? Would you > like to have a function e.g. ABSOLUTELY-SAME?
I do not know. The problem is that rebol code does not give enough reflexive information. But i know that every rebol value is in a block at a given position. Beyond its attributes, it has a block position. Literal values, for example, have never the same block position: same? "a" "a" same? 1 1 should result both false. Only if same? receive pointers to value the two values can be truly the same: y: x: [[]] same? x y same? x/1 y/1 do reduce ['same? x x] The actual implementations of same?, with some values, keep in consideration memory storage, with other values ignore it. If i am not wrong, same? keep in consideration memory storage only with mutable value and ignore it with immutable value:
>> same? [] []
== false
>> same? 1 1
== true So i think that same? gives the correct result only for mutable values. Your version of same? does not exhibit a different behaviour, because function arguments are pointers in case of mutable values and copies in case of immutable values. --- Ciao Romano

### [23/37] from: lmecir:mbox:vol:cz at: 10-Feb-2003 14:35

Well, Romano, ----- Original Message ----- From: "Romano Paolo Tenca"
> But i know that every rebol value is in a block at a given position.
This is *very* questionable as a definition...
> Beyond > its attributes, it has a block position.
Again, I am not sure I understand: a: make block! 2 append/only a b: [1] append/only a b Is there one value B included twice in A or not?
> Literal values, for example, have never the same block position: > > same? "a" "a" > same? 1 1 > > should result both false.
See above...
> Only if same? receive pointers to value the two values can be truly the same: > y: x: [[]] > same? x y > same? x/1 y/1 > do reduce ['same? x x]
Neither this looks as a definition, the "pointer" notion is undefined. My POV is, that you didn't define (at least until now) any sameness, and, moreover, there are inconsistencies in your specifications. If you had a function like ABSOLUTELY-SAME? what would be the result of: absolutely-same? 1 + 2 2 + 1 and why? Ciao -L

### [24/37] from: joel:neely:fedex at: 10-Feb-2003 7:33

Hi, Romano, Metaphysics, anyone? ;-) Romano Paolo Tenca wrote:
> But i know that every rebol value is in a block at a given position. > Beyond its attributes, it has a block position. > Literal values, for example, have never the same block position: > > same? "a" "a" > same? 1 1 > > should result both false. >
Which raises the following questions IMHO: - Why? If "same" means "indistinguishable by any means (within the language)" then aren't all occurrences of e.g. 1 the "same"? - Why do we need SAME? at all? One use is to distinguish mutable values so that one can determine in advance whether a change via one "access path" will affect what is visible via another? That said, are there others? Does this imply that immutable values of the same type (see below) which are equal are indistinguishable? - Do we need more state into the semantic model? Even if we accept the notion that "every REBOL value is in a block...", some blocks are inaccessible (e.g. blocks resulting from the load/eval/print cycle at the console). This already means that we can't take any arbitrary expression and wrap it in a function without the risk of changing its semantics, as in the classic REBOL-newbie koan:
>> repeat i 10 [append [] i]
== [1 2 3 4 5 6 7 8 9 10]
>> foo: func [n [integer!]] [repeat i n [append [] i]] >> foo 5
== [1 2 3 4 5]
>> foo 5
== [1 2 3 4 5 1 2 3 4 5] - Are we cracking an egg with a sledgehammer? I started this thread with a puzzle that cost me more time than I care to admit when it came up in debugging a small script. In a nutshell, the issue was
>> foo: [1 2 3.0 4 5] == [1 2 3 4 5] >> find foo 3 == none >> equal? foo/3 3 == true >> same? foo/3 3 == true
And my proposed solution is that a DECIMAL! value and an INTEGER! value should never be SAME? (even if EQUAL!) because they *are* distinguishable by some means in the language (TYPE? of each). Since RT apparently has chosen TYPE? to be a discriminator for FIND and SELECT it should be relevant to SAME? at least AFAIAC.
> So i think that same? gives the correct result only for mutable > values. >
All of these (my) comments are dangerous, being about what REBOL should do in the opinion of (at least one of) its users, and not about what REBOL was intended to do in the opinion of its creator. It would be nice to hear from Carl about the original intent behind some of these things. -jn-

### [25/37] from: lmecir:mbox:vol:cz at: 10-Feb-2003 16:22

Hi Joel, ----- Original Message ----- From: "Joel Neely"
> Romano Paolo Tenca wrote: > >
<<quoted lines omitted: 50>>
> behind some of these things. > -jn-
I suggest you to send this to the feedback. Regards -L

### [26/37] from: g:santilli:tiscalinet:it at: 10-Feb-2003 15:38

Hi Joel, On Monday, February 10, 2003, 2:33:40 PM, you wrote: JN> >> foo: [1 2 3.0 4 5] == [1 2 3 4 5] JN> >> find foo 3 == none IMHO this is a bug since FIND is based on EQUAL? and not SAME?:
>> b: ["one" "two" "three"]
== ["one" "two" "three"]
>> find b "two"
== ["two" "three"]
>> equal? b/2 "two"
== true
>> same? b/2 "two"
== false JN> >> same? foo/3 3 == true and this is a bug too since they are obviously not the same value (I'd vote for SAME? to always return false for immutable values, so that we can consider its semantics to be "Return true if two values are the same value"). JN> It would be nice to hear from Carl about the original intent JN> behind some of these things. I agree, but the only way is to send it to feedback I think. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

### [27/37] from: lmecir:mbox:vol:cz at: 10-Feb-2003 17:23

Hi Joel, ...
> - Why do we need SAME? at all? One use is to distinguish mutable > values so that one can determine in advance whether a change via > one "access path" will affect what is visible via another?
SAME? is not useful for this purpose. The reason is as follows: you can find two values that clearly aren't the same, like e.g. a: [1 2] b: next a A and B are Relatives in the above sense and a mutation of A can affect B even though A and B are neither same nor equal. For the cases like above the RELATIVES? equivalence (in http://www.rebolforces.com/~ladislav/evaluation.html ) is better suited.
> That > said, are there others?
See the applications of the IDENTICAL? function (in http://www.rebolforces.com/~ladislav/evaluation.html ).
> Does this imply that immutable values > of the same type (see below) which are equal are indistinguishable?
This is a proven thing for me (in http://www.rebolforces.com/~ladislav/evaluation.html ).
> - Do we need more state into the semantic model? Even if we accept > the notion that "every REBOL value is in a block...", some blocks
<<quoted lines omitted: 9>>
> >> foo 5 > == [1 2 3 4 5 1 2 3 4 5]
Moreover, even if we could wrap any expression in a function/block/whatever, how can we guarantee, that any value will be in a one and only one block and not more, and that it will be at exactly one position of the block?
> And my proposed solution is that a DECIMAL! value and an INTEGER! > value should never be SAME? (even if EQUAL!) because they *are* > distinguishable by some means in the language (TYPE? of each). > > Since RT apparently has chosen TYPE? to be a discriminator for > FIND and SELECT it should be relevant to SAME? at least AFAIAC.
... Agreed. Regards -L

### [28/37] from: joel:neely:fedex at: 10-Feb-2003 10:56

> ... > > - Why do we need SAME? at all? One use is to distinguish mutable
<<quoted lines omitted: 4>>
> a: [1 2] > b: next a
I didn't mean that SAME? was the whole answer, but that it can be used to obtain the answer. To use your example:
>> a: [1 2] == [1 2] >> b: next a == [2]
as you point out...
>> same? a b == false
but...
which is all I meant. -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.

### [29/37] from: lmecir:mbox:vol:cz at: 10-Feb-2003 18:24

Hi Gabriele, ----- Original Message ----- From: "Gabriele Santilli" ...
> (I'd vote for SAME? to always return false for immutable values, > so that we can consider its semantics to be "Return true if two > values are the same value").
This would be very unlucky, any meaningful sameness must be reflexive IMO. Ciao -L

### [30/37] from: lmecir:mbox:vol:cz at: 10-Feb-2003 18:46

Hi Joel, not that I want to be picky, but: ----- Original Message ----- From: "Joel Neely"
> I didn't mean that SAME? was the whole answer, but that it can be > used to obtain the answer. To use your example:
<<quoted lines omitted: 6>>
> which is all I meant. > -jn-
In this case, but there are different cases, where the things get more complicated, e.g. words, series, etc. Regards -L

### [31/37] from: g:santilli:tiscalinet:it at: 10-Feb-2003 19:34

Hi Ladislav, On Monday, February 10, 2003, 6:24:23 PM, you wrote: LM> This would be very unlucky, any meaningful sameness must be reflexive IMO. If you are passing it THE SAME value, then it is reflexive, of course. But if you are not, then there's no breaking the rule. So if: same? a a means actually passing two different values, I don't see it breaking the reflexive rule. If they are the same value, instead, then it would be correct to return TRUE. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

### [32/37] from: lmecir:mbox:vol:cz at: 10-Feb-2003 22:42

Hi Gabriele, ----- Original Message ----- From: "Gabriele Santilli" ...
> If you are passing it THE SAME value, then it is reflexive, of > course. But if you are not, then there's no breaking the rule. So
<<quoted lines omitted: 3>>
> breaking the reflexive rule. If they are the same value, instead, > then it would be correct to return TRUE.
Nevertheless, you aren't able to supply any value B such that your GSAME? would return TRUE, am I right? gsame? 1 b That means, that the GSAME? isn't reflexive for the integer 1 as I see it. Regards -L

### [33/37] from: g:santilli:tiscalinet:it at: 11-Feb-2003 2:02

Hi Ladislav, On Monday, February 10, 2003, 10:42:56 PM, you wrote: LM> Nevertheless, you aren't able to supply any value B such that your GSAME? LM> would return TRUE, am I right? If REBOL is implemented as I think it is, then you are right. LM> That means, that the GSAME? isn't reflexive for the integer 1 as I see it. That's because the implementation does not allow to have two integer 1 s. But from the point of view of the definition of GSAME?, it is reflexive. A relation "r" defined in the set S is reflexive is for each a in S you have a r a; this does not mean that you have to have a r a' too for some a', even if that a' on the surface looks like being the same as a. The usefulness of a function like GSAME? would be that of giving us more information of what EQUAL? gives. Currently it does so only partially, because it only works for mutable types; or, maybe our interpretation of REBOL's current implementation is wrong and all "1"s are actually the same (but I doubt it, in particular I doubt that 1 is the same as 1.0 as the current SAME? reports). Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

### [34/37] from: lmecir:mbox:vol:cz at: 11-Feb-2003 7:34

Hi Gabriele, ----- Original Message ----- From: "Gabriele Santilli"
> If REBOL is implemented as I think it is, then you are right.
...
> That's because the implementation does not allow to have two > "integer 1"s.
...
> or, maybe > our interpretation of REBOL's current implementation is wrong and > all "1"s are actually the same (but I doubt it, in particular I > doubt that 1 is the same as 1.0 as the current SAME? reports). > > Regards, > Gabriele.
1 and 1.0 clearly cannot be identical, because they have different types, i.e. it is easy for us to discern them. The trouble with your definition of sameness is, that it looks implementation dependent . I used "" in the previous sentence to underline the fact, that you don't know the implementation (exactly as myself), yet you are making assumptions about it. That means, that your assumptions are incorrect for some possible implementations. On the contrary, I think, that a proper definition shouldn't make any assumptions about the implementation, i.e. it should be correct for any compatible implementation. Ciao -L

### [35/37] from: lmecir:mbox:vol:cz at: 11-Feb-2003 10:52

Hi all, as Joel showed, FIND uses a different comparing method than SAME? or EQUAL?. Here is a definition of an (almost)equivalence compatible with FIND: find-equivalent?: function [ {are A and B equivalent for FIND?} a [any-type!] b [any-type!] ] [block] [ block: make block! 2 insert/only block get/any 'a insert/only tail block get/any 'b equal? index? find block get/any 'b 1 ] As expected, we get: find-equivalent? 3 3.0 ; == false I call this an (almost) equivalence, because FIND crashes Rebol like e.g.: a: [] insert/only a a b: [] insert/only b b find-equivalent? a b CRASH! Moreover, this isn't the only equivalence FIND can generate. FIND/CASE generates a different equivalence, which more closely resembles the == function. Regards -L

### [36/37] from: g:santilli:tiscalinet:it at: 11-Feb-2003 12:30

Hi Ladislav, On Tuesday, February 11, 2003, 7:34:34 AM, you wrote: LM> The trouble with your definition of sameness is, that it looks LM> "implementation dependent". Exactly, unless you define by design that immutable values can never be the same. LM> On the contrary, I think, that a proper definition shouldn't make any LM> assumptions about the implementation, i.e. it should be correct for any LM> compatible implementation. To be able to know if it is, we would need to know what SAME? was supposed to do in the design. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

### [37/37] from: lmecir:mbox:vol:cz at: 11-Feb-2003 17:16

Hi, ...
> LM> On the contrary, I think, that a proper definition shouldn't make any > LM> assumptions about the implementation, i.e. it should be correct for any
<<quoted lines omitted: 3>>
> Regards, > Gabriele.
I think, that I am not the only one saying, that even without SAME? we could define an IDENTICAL? function having the necessary properties. We would just have to work harder. Ciao -L

Notes
• Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted