Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

reduce/deep

 [1/17] from: maarten::vrijheid::net at: 17-Oct-2003 11:49


Hi, I have been triggered by Robert and Cyphre to think about reduce/deep. I think I can do this by recursively traversing a block and its subblocks and reducing them on the mezzanine level. Anybody interested and having feature requests for this? --Maarten

 [2/17] from: AJMartin:orcon at: 24-Dec-2003 22:41


Maarten wrote:
> I think I can do this by recursively traversing a block and its subblocks
and reducing them on the mezzanine level. Anybody interested and having feature requests for this? I'm assuming that this would work on tree structured blocks, not blocks that are are recursively 'insert-ed into each other? Andrew J Martin Grail Jedi ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [3/17] from: maarten:vrijheid at: 17-Oct-2003 13:20


> I'm assuming that this would work on tree structured blocks, not
blocks
> that > are are recursively 'insert-ed into each other? >
Isn't a tree structure recursively built? This should work: Reduce/deep [ now 10 [ now ]] Reduce/deep [ now [ now [ now ]]] --Maarten

 [4/17] from: lmecir:mbox:vol:cz at: 17-Oct-2003 16:55


Hi Andrew, you wrote:
> I'm assuming that this would work on tree structured blocks, not blocks that > are are recursively 'insert-ed into each other? > > Andrew J Martin > Grail Jedi
actually, even cyclic (or recursive, whatever you prefer) blocks can be handled as I have proven in http://www.fm.vslib.cz/~ladislav/rebol/identity.html#section-24 , but the usefulness of such structures is questionable. Anyway, if you need such a construct, it is a matter of minutes for me. -L

 [5/17] from: maarten:vrijheid at: 17-Oct-2003 17:38


Hi Ladislav, Don't take away my hobby project ;-) I assume you'd traverse the block structure recursively using tail-func with the block and the last position that was evaluated? --Maarten

 [6/17] from: lmecir:mbox:vol:cz at: 17-Oct-2003 18:15


Hi Maarten,
> Don't take away my hobby project ;-) > I assume you'd traverse the block structure recursively using tail-func > with the block and the last position that was evaluated? > > --Maarten
I am not sure we understand each other. I think, that Andrew meant cyclic blocks like a: [1] insert/only a a I wouldn't use tail-func probably, but you are close. -L

 [7/17] from: antonr:iinet:au at: 18-Oct-2003 16:08


You can handle cyclic blocks, that is, blocks with contain themselves at some point. You just maintain a list of visited blocks. If you run into one that has already been visited (in the list already) then don't process it (that would lead to infinite loop). If not already visited, add it to the list and the process it. All the containers could be supported this way; blocks, lists, objects, parens. Anyway, for reduce/deep I suppose you would just do blocks... Anton.

 [8/17] from: robert:muench:robertmuench at: 18-Oct-2003 16:38


On Sat, 18 Oct 2003 16:08:00 +1000, Anton Rolls <[antonr--iinet--net--au]> wrote:
> You just maintain a list of visited blocks.
How do you this? I think you will need something like Ladislav's "equal" function, right? Or how can you check if two blocks are really the same (not only identical). Robert

 [9/17] from: maarten:vrijheid at: 18-Oct-2003 17:29


OK, so I won't do cyclic references immediately. --Maarten

 [10/17] from: antonr:iinet:au at: 20-Oct-2003 12:33


Use SAME? a: b: [123] same? a b ;== true Anton.

 [11/17] from: robert:muench:robertmuench at: 21-Oct-2003 21:56


On Mon, 20 Oct 2003 12:33:29 +1000, Anton Rolls <[antonr--iinet--net--au]> wrote:
> Use SAME? > > a: b: [123] > same? a b > ;== true
Hi, ahhh forgot about this one. Rebol just has to many words to remember ;-) But this doesn't seem to work for nested blocks:
>> a: [a 1 b 2]
== [a 1 b 2]
>> b: [a 1 b 2]
== [a 1 b 2]
>> same? a b
== false
>> d: reduce [a b]
== [[a 1 b 2] [a 1 b 2]]
>> e: reduce [a b]
== [[a 1 b 2] [a 1 b 2]]
>> same? d e
== false So I tink for nested structures we would need something like a same?/deep. Robert

 [12/17] from: ingo:2b1 at: 21-Oct-2003 22:33


Robert M. Münch wrote:
> On Mon, 20 Oct 2003 12:33:29 +1000, Anton Rolls <[antonr--iinet--net--au]> > wrote:
<<quoted lines omitted: 19>>
> So I tink for nested structures we would need something like a same?/deep. > Robert
But it _works_ those two blocks are not the same ...
>> append d 1
== [[a 1 b 2] [a 1 b 2] 1]
>> e
== [[a 1 b 2] [a 1 b 2]] on the other hand ...
>> same? d/1 e/1
== true
>> append d/1 1
== [a 1 b 2 1]
>> d
== [[a 1 b 2 1] [a 1 b 2] 1]
>> e
== [[a 1 b 2 1] [a 1 b 2]] Kind regards, Ingo

 [13/17] from: joel:neely:fedex at: 21-Oct-2003 15:39


Hi, Robert, Robert M. Münch wrote:
> Hi, ahhh forgot about this one. Rebol just has to many words to remember > ;-) But this doesn't seem to work for nested blocks: >
Sure it does!
>>>d: reduce [a b] >>
<<quoted lines omitted: 5>>
>> > == false
Consider a simpler, analogous set of evaluations:
>> a: b: "xyz" == "xyz" >> same? a b == true
<<quoted lines omitted: 4>>
>> same? c d == false >> equal? c d == true
or even *more* simpler (pardon the grammar! ;-)
>> p: "12" == "12" >> q: "12" == "12" >> same? p/1 q/1 == true >> same? p/2 q/2 == true >> same? p q == false >> equal? p q == true
These all illustrate the difference between SAME? and EQUAL? in that it is entirely possible to have two different series values whose corresponding elements are the same. In my first example above, as in your original post, two different REDUCE expressions over two different blocks will not produce THE SAME block, even if the content of those two blocks are the same. However the blocks are equal. My second example breaks it down even further. Two different appearances in the input of "12" correspond to two different strings, even though the corresponding characters in those strings are equal (and same, being immutable). Likewise, two different appearances of [a b] result in the creation of two different blocks, even though the corresponding words in those blocks are the same. Therefore, when we reduce those distinct but equal blocks, we get distinct but equal resulting blocks. -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Enron Accountingg in a Nutshell: 1c=$0.01=($0.10)**2=(10c)**2=100c=$1

 [14/17] from: rebol:techscribe at: 21-Oct-2003 21:44


Hi Robert.
>> b: a: [a 1 b 2]
== [a 1 b 2]
>> same? a b
== true
>> a: b: "xyz"
== "xyz"
>> d: c: reduce [a b]
== ["xyz" "xyz"]
>> same? d c
== true Robert M. Münch wrote:

 [15/17] from: maximo:meteorstudios at: 22-Oct-2003 9:41


sorry if I come in late in this discussion, I didn't have time to properly follow it. so it could be that what I post here is redundant to some previous post, but maybe not... quoting elan:
> Hi Robert. > >> b: a: [a 1 b 2]
<<quoted lines omitted: 5>>
> >> d: c: reduce [a b] > == ["xyz" "xyz"]
but you assigned d and c to the same block... why should they be different. I think what you wanted to show was b: a: "xyz" c: reduce [a b] same? first c second c ==true here, even if we reduced a block which has words assigned to the same string, both still reduce to the same string. Its like having a list with the same pointer twice. proof: insert first c "abc" probe c ==["abcxyz" "abcxyz"] since they are the same string, adding to first one will reflect in the second reference too.
> >> same? d c > == true
<<quoted lines omitted: 5>>
> >>>same? d e > >== false
the above is not the same block if you append to the block d, then it will not be reflected in block e. continuing above code: append d [test block] probe d ==[[a 1 b 2] [a 1 b 2] test block] probe e ==[[a 1 b 2] [a 1 b 2]] this is why same? returns false, d and e aren't the same block.
> >So I tink for nested structures we would need something like > a same?/deep. > >Robert
when doing same?, same?/deep is actually implicit. you cannot have two same outer blocks if their content is different. for example, I am always the same person. even if two persons look at me, they still see the same person. where as if I had a twin, they looking at each twin (altough looking exactly the same) is not the same person. Thus if two persons are looking at the same person, they will implicitely look at the same eyes, clothes, etc. so: ((same?/deep block ) <> (same? block)) is impossible! looking at the above example, I think equivalent? is really what you'd like, no? this would return true if all items within two blocks contained the same data (but possibly not the same data pointers). same <> equivalent if you want to know if two different blocks are equivalent, the = operator does dig deeply. a: [a [1 [2]] [3 [4]]] b: [a [1 [2]] [3 [4]]] same? a b ==false a = b ==true a: [a [1 [2]] [3 [4]]] b: [a [1 [2]] [3 [5]]] same? a b ==false a = b ==false in conclusion, it might be that what you want is really a same?/content which would return true if all elements of a block are the same, but does not check if the block itself is the same. In that case, using /deep refinement for same might be misleading, because other functions which use /deep, usually consider the outer-most block as part of what it has to process. Just adding my (possibly redundant) comments to the topic ;-) cheers! -MAx

 [16/17] from: robert:muench:robertmuench at: 22-Oct-2003 20:17


On Tue, 21 Oct 2003 15:39:57 -0500, Joel Neely <[joel--neely--fedex--com]> wrote:
> Consider a simpler, analogous set of evaluations: > >> a: b: "xyz" == "xyz"
<<quoted lines omitted: 15>>
> it is entirely possible to have two different series values whose > corresponding elements are the same.
Hi, yes I got it now. Even I find this a tricky pitfall...
> In my first example above, > as in your original post, two different REDUCE expressions over two > different blocks will not produce THE SAME block, even if the content > of those two blocks are the same. However the blocks are equal.
The problem I had(!) was that I thought that reduce [a b c] needs the [...] because I want to specify a list/block of values, more like a syntactic need. That is has a semantic meaning as well (create new block around those values) wasn't that obvious to me. I used 'reduce to get back a block of values but, yes, it's a new block... Robert

 [17/17] from: robert:muench:robertmuench at: 22-Oct-2003 20:17


On Tue, 21 Oct 2003 22:33:11 +0200, Ingo Hohmann <[ingo--2b1--de]> wrote:
> But it _works_ those two blocks are not the same ... > > >> append d 1 > == [[a 1 b 2] [a 1 b 2] 1] > >> e > == [[a 1 b 2] [a 1 b 2]]
Hi, hmmm... the help for reduce reads: Evaluates an expression or block expressions and returns the result. This means that reduce [...] will create a new block, which is the container for the result. Even the experssions inside the block don't give you a hint, that a new block is created. 'same? takes the (new created) cotainer block into account as well.
> on the other hand ... > >> same? d/1 e/1
<<quoted lines omitted: 5>>
> >> e > == [[a 1 b 2 1] [a 1 b 2]]
If we only had a script that would plot a graph of such relations... BTW: Do we have an inverse 'same? perhaps 'like-me? which lists all words where foreach hit like-me? me [(true = same? me hit) = true] always holds? -- Robert M. Münch Management & IT Freelancer Mobile: +49 (177) 245 2802 http://www.robertmuench.de

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