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
Hi, Ladislav,
Ingenious! But let me add the following large hint:
>> 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
Hi, Ladislav
> 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
Hi, Ladislav,
Ladislav Mecir wrote:
> ...
> > - 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...
>> same? head a head b == true
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