r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

BrianH
4-Jul-2009
[16072]
You do topological comparison here, not  marking.
Ladislav
4-Jul-2009
[16073x4]
yes, I am actually unable to do marking in Rebol
but, if you want a model, I can write one
do you know how many bits can I use for marking?
(or is it just one bit? - in that case it indeed is a problem)
BrianH
4-Jul-2009
[16077]
Well, my point was that marking isn't enough here, and that this 
kind of comparison (the kind in equal-state?) is needed.
Ladislav
4-Jul-2009
[16078]
so, the question is, how many marking bits are available
BrianH
4-Jul-2009
[16079x3]
Only Carl has that answer. Still reading...
You would have to do something similar to a simplified EQUAL-STATE? 
even in a C version. There will never be enough bits for marking 
because every concurrent instance of your comparison would need its 
own set. Having thread-local done lists would work though.
concurrent instance of your comparison
 -> "concurrently running instance of your comparison function"
Ladislav
4-Jul-2009
[16082]
concurrently running instance of EQUAL? - yes, understood, that would 
be impossible, but such a thing can be made "atomic/protected", can't 
it?
BrianH
4-Jul-2009
[16083]
No.
Ladislav
4-Jul-2009
[16084]
why? RECYCLE and MOLD will be protected, won't they?
BrianH
4-Jul-2009
[16085]
You can make GC single-instance, but not MOLD or EQUAL?. MOLD and 
EQUAL? will be done too often to lock.
Ladislav
4-Jul-2009
[16086]
too often to lock - I would say, that RECYCLE is more likely to be 
"encountered" than MOLD or EQUAL?
BrianH
4-Jul-2009
[16087]
Unlikely - RECYCLE isn't FREE. The whole point to GC is that it isn't 
done that often.
Ladislav
4-Jul-2009
[16088]
yes, but it takes time: the "probability of encountering" is proportional 
to running time as well as to call frequency
BrianH
4-Jul-2009
[16089]
OK, EQUAL-STATE? is too strict in another way: It also considers 
values that precede the series references. I'm going to figure out 
if it will still work if changed to use the level of equivalence 
expected from EQUAL?. Note:
>> equal? next [a a] next [b a]
== true
>> equal? next [a a] next 'b/a
== false
Not sure about that last one - will it be true in R3?
Ladislav
4-Jul-2009
[16090]
yes, re strictness, it will probably be found too strict in a number 
of ways
BrianH
4-Jul-2009
[16091]
What about equal? [a b] 'a/b ?
Ladislav
4-Jul-2009
[16092]
(it was certainly not a prototype of any specific member of the current 
equality coparison hierarchy)
BrianH
4-Jul-2009
[16093]
Are we doing equivalence within any-block! or limiting it to within 
any-path! ?
Ladislav
4-Jul-2009
[16094x3]
re last question: supposedly True
(ie. I would take the any-block variant)
but, you may propose a different alternative, if you don't like it 
for some reason
BrianH
4-Jul-2009
[16097]
One alternative is equality within any-path!, within any-word! and 
within any-string!, but not within any-block!.
Ladislav
4-Jul-2009
[16098]
yes, the only difference is, that I considered any-block! to be the 
counterpart of any-string!, but that is just me
BrianH
4-Jul-2009
[16099]
Another alternative (the current one) is equality within any-word! 
and any-string, but not within any-block! or any-path!.
Ladislav
4-Jul-2009
[16100x2]
I think, that currently the equality within any-string isn't imlemented
sorry for the typos
BrianH
4-Jul-2009
[16102x2]
I consider any-block! and any-string! to correspond as well, but 
the question  is whether EQUAL? should do the same.
You are right about the equality of any-string! - not implemented 
yet.
Ladislav
4-Jul-2009
[16104]
yes, this needs to be decided specifically for the purpose of equality 
comparison
BrianH
4-Jul-2009
[16105]
Remember, EQUAL? is the simplee default for people who don't want 
to worry about things. We have more strictness later down the line, 
buut a little strictness in EQUAL? would help newbies in some cases.
Ladislav
4-Jul-2009
[16106]
a little strictness in EQUAL? - do you mean, that newbies may be 
more comfortable with finer (stricter) or with coarser (less strict) 
version of EQUAL? in this case?
BrianH
4-Jul-2009
[16107x2]
Yeah. It's hard for me to judge, but equivalence within any-block! 
seems confusing to newbies. However, equivalence within any-path! 
seems to be similar to equivalence within any-word!, so we might 
want to implement it.
We should ask Fork - he seems to be the designated newbie advocate 
these days :)
Ladislav
4-Jul-2009
[16109x3]
:-)
ARN (The Association of Rebol Newbies) president
(it is hard for me to understand what he means quite often)
BrianH
4-Jul-2009
[16112]
And vice-versa, in my experience, but he's very intelligent so that's 
not it :(
Ladislav
4-Jul-2009
[16113]
yes, the problem is, that I am used to different terminology
BrianH
4-Jul-2009
[16114]
My problem is that my vocabulary is too big and precise for most 
people to get the subtle distinctions :(
Ladislav
4-Jul-2009
[16115]
I found, that complete newbies are frequently outside of the range 
of my understanding. After discussing a couple of things in the fora, 
they start to become understandable even for me :-)
BrianH
4-Jul-2009
[16116]
Most of Fork's recent complaint about tag! in R3 came down to not 
making the distinction between "join" (JOIN and REJOIN) and "adjoin" 
(AJOIN). If he had been around for the discussion that led to the 
creation of the AJOIN function it woldn't have been a problem :(
Ladislav
4-Jul-2009
[16117]
is seems to be caused by the fact, that I am prepared to assign too 
many possible meanings to their questions to be able to detect what 
they are actually asking
BrianH
4-Jul-2009
[16118x2]
Contextual decoding issues :(
It looks like an algorithm similar to EQUAL-STATE? will work for 
structural equivalence if you get rid of lines 518 and 519. Some 
of the comparisons should be relaxed to the same level as the comparison 
function you are implementing too. I notice that it does topological 
similarity rather than strict structural equivalence :)
Ladislav
4-Jul-2009
[16120x2]
yes, but this algorithm is rather slow for Rebol standards?
hmm, seems I am using different line numbering