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

Limitation coming from the "initialize" refinement used with the "Array"

 [1/15] from: gerardcote::sympatico::ca at: 26-Jun-2002 14:48


Hello, As I tried to generate a dynamic line of code to create a way to circumvent the way REBOL interprets the ARRAY notation when used with variable indexes instead of numeric constants (nothing really hard with REBOL), I found some limitation with the initialize refinement as following : It seems only possible to use the same constant (a scalar value or any other datatype seems to be is accepted) as the initial value used by the Array word itself. Here is my example code ( I tried it directly at the concole) : tab_nbr: array/initial [3 2] 0 cells contents are all initialized to the 0 value L: 2 C: 1 tab_nbr/2/1: 10 cell content [2 1] is updated to 10 print tab_nbr/:L/:C I verify that all is OK tab_nbr/:L/:C: 20 But this one doesn't work, so I dynamically generated the real line and asked REBOL to execute it. The wanted expression was : tab_nbr/2/1: 20 and this can be given by join join join join "tab_nbr/" L join "/" C ": " 20 which generates == tab_nbr/2/1: 20 then the "do" word will do it like this. do join join join join "tab_nbr/" L join "/" C ": " 20 But now that I can use real variable indexes with my array, am I supposed to use loops too just to get any cell value initialized with something other than some constant like the series of values : 10, 20 , 30 , 40 50 and 60. Would it not be simpler to have something like this : tab_nbr: array/initial/series [3 2] 10 60 10 where the start, stop and increment values would be respectively 10 60 and 10. IS this already possible in another way that I am not aware of ? While I am at it, I also tried to use the word "reduce" and a to-block conversion instead of the word "do" but it seems that the refered object (tab_nbr) is not in the same context. So is there a way to notify REBOL that we want it to share some valuable information from a context to another one or do we have to define it for the global one, which in this case is not under my control Thanks to all for any clue if any, Gerard

 [2/15] from: ammon:rcslv at: 26-Jun-2002 12:09

Re: Limitation coming from the "initialize" refinement used with the "Ar


Hi, I am not sure just how you wanted to have 'array/initial work, but at first thought you would probably need to redefine 'array or create your own function. On the other hand it looked like you just might want this: a: array [3 2] [10 60 10] But you did say *increment* so I am not sure. ;-) If you literally did want an incremented value, then yes you will probably need to use loops. But you might want to create your own generic function to do it if you like incremented arrays. ;-) I thought that I had some light to shed on *contexts* but it appears that my light has faded. ;-( I would play with different combinations of 'compose and 'bind to try to find what I was looking for. I have done some bind stuff, but ended up writing my own version of bind to get what I was looking for... HTH Ammon On Wednesday 26 June 2002 06:48 pm, you wrote:

 [3/15] from: tomc:darkwing:uoregon at: 26-Jun-2002 18:30


thats nice Gerard a bit prettier do rejoin['tab_nbr "/" l "/" c ": " 20] On Wed, 26 Jun 2002, Gerard Cote wrote:
> Hello, > As I tried to generate a dynamic line of code to create a way to circumvent
<<quoted lines omitted: 23>>
> any cell value initialized with something other than some constant like the > series of values : 10, 20 , 30 , 40 50 and 60.
I think yes

 [4/15] from: lmecir:mbox:vol:cz at: 27-Jun-2002 8:49


Hi Gerard, instead of tab_nbr/:L/:C: 20 which doesn't work you can use: 1) change at at tab_nbr L C 20 2) change at tab_nbr/:L C 20 3) poke tab_nbr/:L C 20 I do not suggest you to use string conversion, because it doesn't preserve the context information. If you insist on doing it your way, you should use blocks instead of strings as follows: do reduce [to set-path! reduce ['tab-nbr L C] 20] ----- Original Message ----- From: "Gerard Cote" Hello, As I tried to generate a dynamic line of code to create a way to circumvent the way REBOL interprets the ARRAY notation when used with variable indexes instead of numeric constants (nothing really hard with REBOL), I found some limitation with the initialize refinement as following : It seems only possible to use the same constant (a scalar value or any other datatype seems to be is accepted) as the initial value used by the Array word itself. Here is my example code ( I tried it directly at the concole) : tab_nbr: array/initial [3 2] 0 cells contents are all initialized to the 0 value L: 2 C: 1 tab_nbr/2/1: 10 cell content [2 1] is updated to 10 print tab_nbr/:L/:C I verify that all is OK tab_nbr/:L/:C: 20 But this one doesn't work, so I dynamically generated the real line and asked REBOL to execute it. The wanted expression was : tab_nbr/2/1: 20 and this can be given by join join join join "tab_nbr/" L join "/" C ": " 20 which generates == tab_nbr/2/1: 20 then the "do" word will do it like this. do join join join join "tab_nbr/" L join "/" C ": " 20 But now that I can use real variable indexes with my array, am I supposed to use loops too just to get any cell value initialized with something other than some constant like the series of values : 10, 20 , 30 , 40 50 and 60. Would it not be simpler to have something like this : tab_nbr: array/initial/series [3 2] 10 60 10 where the start, stop and increment values would be respectively 10 60 and 10. IS this already possible in another way that I am not aware of ? While I am at it, I also tried to use the word "reduce" and a to-block conversion instead of the word "do" but it seems that the refered object (tab_nbr) is not in the same context. So is there a way to notify REBOL that we want it to share some valuable information from a context to another one or do we have to define it for the global one, which in this case is not under my control Thanks to all for any clue if any, Gerard

 [5/15] from: ingo:2b1 at: 27-Jun-2002 9:16


Hi Gerard, Gerard Cote wrote:
> Hello,
<...>
> Here is my example code ( I tried it directly at the concole) : > tab_nbr: array/initial [3 2] 0 cells contents are all initialized to
<<quoted lines omitted: 11>>
> join join join join "tab_nbr/" L join "/" C ": " 20 > which generates > "tab_nbr/2/1: 20" then the "do" word will do it like this.
There are a lot of ways to make this work, but sometimes it pays to think about what arrays really are: blocks of blocks, so the most elegant solution (IMO) is to use change at tab_nbr/:L C 20 And, btw, it is _much_ faster:
>> profiler/test [do join join join join "tab_nbr/" L join "/" C ": "
20] 1000000 == [0:01:07.580636]
>> profiler/test [change at tab_nbr/:L C 20] 1000000
== [0:00:02.855449] <...>
> While I am at it, I also tried to use the word "reduce" and a to-block > conversion instead of the word "do" but it seems that the refered object > (tab_nbr) is not in the same context. > > So is there a way to notify REBOL that we want it to share some valuable > information from a context to another one or do we have to define it for the > global one, which in this case is not under my control
Yup, it's 'bind.
>> reduce bind to-block join join join join "tab_nbr/" L join "/" C ":
30 'tab_nbr == [[30 0]]
>> tab_nbr
== [[0 0] [30 0] [0 0]] 'bind has two paramters, the block you want to run in a differrent context than its default, and a word from the context you want it to run in. I hope that helps, Ingo -- To unsubscribe from this list, please send an email to [rebol-request--rebol--com] with unsubscribe" in the

 [6/15] from: joel::neely::fedex::com at: 27-Jun-2002 7:46

Re: Limitation coming from the "initialize" refinement used withthe "Arr


Hi, Gerard, Gerard Cote wrote:
> Hello, > > As I tried to generate a dynamic line of code to create a way > to circumvent the way REBOL interprets the ARRAY notation when > used with variable indexes instead of numeric constants... >
Having beat my head against that particular brick wall, may I suggest living with it, instead of circumventing it! ;-) See samples below, which show a much faster (and easier to read IMHO) version. I'll address the initialization issue at the end.
> ...(nothing really hard with REBOL), I found some limitation with > the initialize refinement as following : It seems only possible
<<quoted lines omitted: 8>>
> print tab_nbr/:L/:C > tab_nbr/:L/:C: 20
As you observed, this is not valid REBOL syntax...
> do join join join join "tab_nbr/" L join "/" C ": " 20 >
...and that is entirely too complicated (especially for a language that is supposed to be designed for humans instead of programmers! ;-) By adding one level of indirection, we can revive the notion of place that allows (almost!) simple syntax again, and does wonders for performance. Let's build a little function that times the use of the above scheme: 8<---- table0: array/initial [3 2] 0 tally0: func [n [integer!] /local t row col] [ t: now/time/precise table0: array/initial [3 2] 0 row: col: 1 loop n [ do join join join join join "table0/" row "/" col ": " 1 + table0/:row/:col row: row // 3 + 1 col: col // 2 + 1 ] t: now/time/precise - t print mold table0 print t ] 8<---- The little trick with ROW and COL inside the loop just makes them sweep through the collection of paired values 1,1 2,2 3,1 1,2 2,1 3,2 so that all combinations occur equally frequently (and there's a minimum of index manipulation overhead relative to the actual work of incrementing the array value at the specified row and column, which is what we really want to time). Notice that all of the occurrences of JOIN can come at the front of that expression, since you're just constructing a string from a collection of values that can be stated one after the other. That said, this cries out for a single REJOIN expression (only the inside of the loop changes): 8<---- tally0a: func [n [integer!] /local t row col] [ t: now/time/precise table0: array/initial [3 2] 0 row: col: 1 loop n [ do rejoin [ "table0/" row "/" col ": " 1 + table0/:row/:col + 1 ] row: row // 3 + 1 col: col // 2 + 1 ] t: now/time/precise - t print mold table0 print t ] 8<---- Even so, this requires a great deal of block and string flogging; a new block is constructed per pass through the loop, which is then turned into a string, which is LOADed and then DOne. We can get better performance by flushing all of that string flogging: 8<---- tally0b: func [n [integer!] /local t row col path] [ t: now/time/precise table0: array/initial [3 2] 0 row: col: 1 loop n [ path: compose [table0 (row) (col)] do compose [(to-set-path path) 1 + (to-path path)] row: row // 3 + 1 col: col // 2 + 1 ] t: now/time/precise - t print mold table0 print t ] 8<---- Finally (the end is in sight! ;-) let's get back to the suggestion about adding a level of indirection. As you know, we can't alter a number in REBOL, but if we know "where" it is we can get to that place and put a different number "there". Instead of
>> array/initial [3 2] 0
== [[0 0] [0 0] [0 0]] (which give us a 3-by-2 structure of integers) let's build the pseudo-array as
>> array/initial [3 2 1] 0
== [[[0] [0]] [[0] [0]] [[0] [0]]] so that we now have a 3-by-2 structure of *containers* whose content can be accessed and replaced easily. This strategy gives us the following design for our tallying test: 8<---- table1: array/initial [3 2 1] 0 tally1: func [n [integer!] /local t row col] [ t: now/time/precise table1: array/initial [3 2 1] 0 row: col: 1 loop n [ change table1/:row/:col 1 + table1/:row/:col/1 row: row // 3 + 1 col: col // 2 + 1 ] t: now/time/precise - t print mold table1 print t ] 8<---- Finally, for comparison purposes, here's one that just does the looping and index management, without any "array" manipulation. It's time provides a baseline to be deducted from all of the other versions if we really want fair comparisons: 8<---- tallyx: func [n [integer!] /local t row col] [ t: now/time/precise row: col: 1 loop n [ row: row // 3 + 1 col: col // 2 + 1 ] t: now/time/precise - t print mold table1 print t ] 8<---- The punch line of all this is the times; using N of 120000 we get [[20000 20000] [20000 20000] [20000 20000]] for the TALLY0* series and [[[20000] [20000]] [[20000] [20000]] [[20000] [20000]]] for TALLY1. The times for two runs each are: tally0 0:01:03.88 0:01:04.09 tally0a 0:00:35.26 0:00:35.15 tally0b 0:00:17.68 0:00:17.52 tally1 0:00:06.27 0:00:06.09 tallyx 0:00:02.03 0:00:02.03 Averaging the two times for each, deducting the baseline from TALLYX, and normalizing to TALLY1, we get relative times of: tally0 14.9 tally0a 8.0 tally0b 3.8 tally1 1.0 (rounded to 1 fractional digit -- we shouldn't assume more precision with such short run times). In *very* rough terms, replace the run of JOINs with a single REJOIN cuts out about half of the time, going to a COMPOSEd block instead of a constructed string cuts about half of the remaining time, and going to an additional level of structure cuts a third to a fourth of the remaining time.
> But now that I can use real variable indexes with my array, am I > supposed to use loops too just to get any cell value initialized > with something other than some constant like the series of values: > 10, 20 , 30 , 40 50 and 60. >
Yes. But it can be done simply, in several ways (keeping with the three-level structure for sake of illustration). One brute-force approach would be to create the series of numbers and copy chunks into the table: rawdata: copy [] for i 10 60 10 [append/only rawdata reduce [i]] table: copy [] loop 3 [append/only table copy/part rawdata 2 rawdata: skip rawdata 2] table which gives == [[[10] [20]] [[30] [40]] [[50] [60]]] and several variations thereof. But let's take advantage of REBOL's nice management of containers (blocks) instead: table: array/initial [3 2 1] 0 counter: 0 foreach row table [foreach col row [change col counter: counter + 10]] table which also gives == [[[10] [20]] [[30] [40]] [[50] [60]]] without so much effort.
> Would it not be simpler to have something like this : > > tab_nbr: array/initial/series [3 2] 10 60 10 where the start, > stop and increment values would be respectively 10 60 and 10. >
Using either of the above strategies, you could write such a thing yourself quite easily. (Notice the redundancy between saying that you have [3 2] for the shape of the structure and saying that the initialization data runs from 10 to 60 in steps of 10. I'll drop that redundancy in the sample.) array-series: func [ dims [block!] lo [integer!] by [integer!] /local stripe ][ lo: lo - by do stripe: func [blk [block!]] [ either 1 = length? blk [ change blk lo: lo + by ][ foreach subblk blk [stripe subblk] ] blk ] array/initial append dims 1 0 ] which behaves as:
>> array-series [3 2] 10 10
== [[[10] [20]] [[30] [40]] [[50] [60]]]
>> array-series [2 3 2] 5 5
== [[[[5] [10]] [[15] [20]] [[25] [30]]] [[[35] [40]] [[45] [50]] [[55] [60]]]] This is such a special-case initialization, and so easy to write, that I suggest it should be a user-written function, rather than being added to the core language. Hope this helps! -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [7/15] from: joel:neely:fedex at: 27-Jun-2002 11:30

Re: Limitation coming from the "initialize" refinement usedwiththe "Arra


Hi, again, Gerard... One more thing I forgot earlier... Joel Neely wrote:
> 8<---- > table1: array/initial [3 2 1] 0
<<quoted lines omitted: 12>>
> ] > 8<----
There's an additional improvement to be had by replacing the line: change table1/:row/:col 1 + table1/:row/:col/1 with the equivalent table1/:row/:col/1: 1 + table1/:row/:col/1 (improving both performance and notational consistency!) With this container-based scheme, one can always access an elementary data value with arrayname/...path.../1 and change the contained value with arrayname/...path.../1: expressionfornewvalue where, of course, the ...path... part can contain literals and get-words as apprpriate. Making a new version (tally1a) with this last change and rerunning the benchmarks (this time using an average of five runs of half-a-million cycles each -- on a faster computer ;-) we get these stats version strategy avg time ratio lo/med/hi times ------- -------- -------- ----- -------------------- tally0 join 35.3388 19.71 35.311 35.331 35.37 tally0a rejoin 21.2766 11.55 21.25 21.271 21.301 tally0b compose 11.4544 5.84 11.426 11.447 11.486 tally1 change 3.453 1.20 3.435 3.455 3.465 tally1a path 3.1106 1 3.104 3.105 3.124 tallyx baseline 1.388 0 1.382 1.392 1.392 -jn-

 [8/15] from: joel::neely::fedex::com at: 27-Jun-2002 11:29


One more time, folks... ;-) Incorporating the proposals from various emails, I've re-run the benchmarks (quickly... caveat lector) with the result that using explicit paths on nested containers still is the fastest, e.g. array/:i/:j/1: 1 + array/:i/:j No time to be tidy, but here are the stats... strategy average ratio ------- ------- -------- joins 14.1602 19.75 rejoin 8.4542 11.47 compose 4.6046 5.88 at...at 1.5824 1.49 change at 1.482 1.35 change sub 1.372 1.19 poke path 1.314 1.10 path sub 1.2418 1 baseline 0.5528 0 -jn-

 [9/15] from: joel::neely::fedex::com at: 27-Jun-2002 11:15

Re: Limitation coming from the "initialize" refinement usedwith the "Arr


Hi, Ladislav, Ladislav Mecir wrote:
> Hi Gerard, > > instead of > > tab_nbr/:L/:C: 20 > > which doesn't work you can use: > > 1) > change at at tab_nbr L C 20 >
Perhaps change at first at tab_nbr L C 20 is what you meant??? As in
>> table0
== [[0 0] [0 0] [0 0]]
>> at at table0 1 1
== [[0 0] [0 0] [0 0]]
>> at first at table0 1 1
== [0 0]
>> change at first at table0 1 1 17
== [0]
>> table0
== [[17 0] [0 0] [0 0]] -jn-

 [10/15] from: gerardcote:sympatico:ca at: 27-Jun-2002 13:08

Re: Limitation coming from the "initialize" refinement used with the "Ar


Hello Tom,
> Tom Conlin wrote : > > a bit prettier > do rejoin['tab_nbr "/" l "/" c ": " 20] >
You're almost right but a small glitch appeared in your version. The final one should be : do rejoin["tab_nbr/" L "/" C ": " 20] instead of my original one :
> > join join join join "tab_nbr/" L join "/" C ": " 20 > > which generates > > "tab_nbr/2/1: 20" then the "do" word will do it like this. > > > > do join join join join "tab_nbr/" L join "/" C ": " 20 > >
Thanks for the "cue". As you can see below, even if I knew the effect of the reduce word - when used alone, I didn't think to use it, at least in the form you submitted me - that is with the combined "rejoin" word. And the worst here is that when confronted with this face-to-face encounter I quickly told myself : Wow! It could have been great if the "join" word had been used with so many parameters as I had under the hand. I simply missed it but be sure that next time I'll try harder !!! But as I have grabbed your attention for a moment, can I submit you another question which I also asked myself when confronted with this other coding example I tried a couple of days ago while submitting it to a friend of mine who want to start in REBOL - don't worry about the apparent difficulty level for this intro to REBOL because he is already doing professional coding in other programming languages and I was effectively comparing many ways to do the same thing - assignment (multiple ones in this case) : The original try was : set [ 'n1 'n2 'total 'diff ] [ 15 25 n1 + n2 n2 - n1] <-- the error is pointing n1 as having no value print [n1 n2 somme diff] while trying to eval n1 + n2 The expected result was : 15 25 40 10 but I had to rearrange it according to one of these alternatives to get the expected result : a) set [ 'n1 'n2 ] [ 15 25 ] set 'somme n1 + n2 set 'diff n2 - n1 b) set [ 'n1 'n2 ] [ 15 25 ] set ['somme 'diff ] reduce [ n1 + n2 n2 - n1 ] c) set [ 'n1 'n2 ] [ 15 25 ] set ['somme 'diff ] compose [ (n1 + n2) (n2 - n1) ] And the related question : Is there is a way for REBOL to assign many variables simultaneously (that is in a pseudo-parallel form on the same line instead of serializing them by putting them on many successive lines) like I was able to do in the Lisp language with the LET (for parallel assignment) and LET* (for serial assignment) statements. I know this is just a purist question for academicians but I'd like to know if this is possible or not with REBOL as it is now Thanks, Gerard.

 [11/15] from: gerardcote:sympatico:ca at: 27-Jun-2002 14:51

Re: Limitation coming from the "initialize" refinement usedwith the "Arr


Joel and Ladislav Wrote :
> Hi, Ladislav, > Ladislav Mecir wrote:
<<quoted lines omitted: 23>>
> >> table0 > == [[17 0] [0 0] [0 0]]
Thanks Joel and Ladislav, this is something I will explore as it is probably faster than my actual way of doing things. Regards, Gerard

 [12/15] from: joel:neely:fedex at: 27-Jun-2002 17:15


Hi, Gerard, Gerard Cote wrote:
> The original try was : > > set [ 'n1 'n2 'total 'diff ] [ 15 25 n1 + n2 n2 - n1] > >> set [n1 n2] [15 25]
== [15 25]
>> set [tot dif] reduce [n2 + n1 n2 - n1]
== [40 10] gets your expected result:
>> print [n1 n2 tot dif]
15 25 40 10 - If the first argument to SET is a block, the words are already "protected" from evaluation, and therefore don't need to be lit-words. - If both arguments to SET are blocks, the second block contains the corresponding values for the words; therefore REDUCE is needed in the second SET to cause the evaluation of the expressions, to produce a two-element block. Unreduced, that block contains six words! Being able to play around with unevaluated blocks is one of the more powerful features of REBOL:
>> w0: [a b]
== [a b]
>> print mold w0
[a b]
>> print w0
** Script Error: a has no value ** Near: a b
>> v0: [15 25]
== [15 25]
>> length? v0
== 2
>> v1: [b + a b - a]
== [b + a b - a]
>> length? v1
== 6
>> w1: [t d]
== [t d]
>> set w0 v0 set w1 v1 print [a b t d]
15 25 b +
>> set w0 v0 set w1 reduce v1 print [a b t d]
15 25 40 10 - Before we can REDUCE (evaluate the expressions in) the block V1 all of the words in that block must be defined/set. That's why two SETs are needed for the example at hand.
> And the related question : Is there is a way for REBOL to assign > many variables simultaneously (that is in a pseudo-parallel form > on the same line instead of serializing them by putting them on > many successive lines) like I was able to do in the Lisp language > with the LET (for parallel assignment) and LET* (for serial > assignment) statements. >
Sure. If you give SET two arguments, the first a block of words and the second a block of values (both blocks of the same length), all of the words will be set to the corresponding values. In the context of your question, SET is parallel and *not* serial, otherwise e.g., the following trick to swap two values would not work properly.
>> x: 13
== 13
>> y: 42
== 42
>> set [x y] reduce [y x]
== [42 13]
>> print [x y]
42 13 The gotcha is that your original attempt would have to have been written as set [n1 n2 total diff] reduce [15 25 n1 + n2 n2 - n1] to get the effect you wanted, where the reduce [15 25 n1 + n2 n2 - n1] part is a subexpression that must be evaluated *before* the SET is done, because the *result* of REDUCE *is* the second argument to SET. That evaluation would use the values of N1 and N2 as of the time of the REDUCE (prior to evaluation of SET on two block args). As written (nearly), your example can be evaluated, but it doesn't do what you expected:
>> unset [n1 n2 total diff] >> set [n1 n2 total diff] [15 25 n1 + n2 n2 - n1]
== [15 25 n1 + n2 n2 - n1]
>> print [n1 n2 total diff]
15 25 n1 + The second argument to SET contained eight elements: two integers and six words; N1 and N2 were set to the two integers, while TOTAL and DIFF were set to the first two of the words. Hope this helps! -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [13/15] from: tomc::darkwing::uoregon::edu at: 27-Jun-2002 19:21

Re: Limitation coming from the "initialize" refinement used with the "Ar


hi again for your second question an answer that will undoubtably be improved opon is:
>> unset [n1 n2 total diff] >> set['n1 'n2 'total 'diff] compose[15 25 (does [n1 + n2]) (does [n2 - n1])]
== [15 25 func [][n1 + n2] func [][n2 - n1]]
>> print [n1 n2 total diff]
15 25 40 10
>>
for the first part- though there are far better solutions than the one I offered I am not seeing a glitch. (REBOL/Core 2.5.0.3.1 on w98)
>> a: array/initial [3 2] 0
== [[0 0] [0 0] [0 0]]
>> r: 2 c: 1 d: 0
== 0
>> print a/:r/:c
0
>> do rejoin['a "/" r "/" c ": " 10]
== [10 0]
>> print a/:r/:c
10
>> a
== [[0 0] [10 0] [0 0]]
>> for i 1 3 1[for j 1 2 1[do rejoin['a "/" i "/" j ": " d: d + 10]]]
== [50 60]
>> a
== [[10 20] [30 40] [50 60]] On Thu, 27 Jun 2002, Gerard Cote wrote:

 [14/15] from: lmecir:mbox:vol:cz at: 28-Jun-2002 11:39

Re: Limitation coming from the "initialize" refinement usedwith the "Arr


Hi Joel, thanks for correcting me -L ----- Original Message ----- From: "Joel Neely" Hi, Ladislav, Ladislav Mecir wrote:
> Hi Gerard, > > instead of > > tab_nbr/:L/:C: 20 > > which doesn't work you can use: > > 1) > change at at tab_nbr L C 20 >
Perhaps change at first at tab_nbr L C 20 is what you meant??? As in
>> table0
== [[0 0] [0 0] [0 0]]
>> at at table0 1 1
== [[0 0] [0 0] [0 0]]
>> at first at table0 1 1
== [0 0]
>> change at first at table0 1 1 17
== [0]
>> table0
== [[17 0] [0 0] [0 0]] -jn-

 [15/15] from: gerardcote:sympatico:ca at: 28-Jun-2002 12:06

Re: Limitation coming from the "initialize" refinement used with the "Ar


Hello Tom,
> for your second question an answer that will undoubtably be improved opon > is: > > >> set['n1 'n2 'total 'diff] compose[15 25 (does [n1 + n2]) (does [n2 - n1])] > == [15 25 func [][n1 + n2] func [][n2 - n1]]
Thanks again for this fresh view of another way of defining a short function - this is very concise and this is the solution that approaches the most my original way of doing things (on a syntax basis) even you defined 2 functions that must be evaluated each time they are used instead of getting 2 values directly. I only hope the execution time is not a way too long when compared to other approaches. This will surely be very useful to me in a near future ...
> > for the first part- > though there are far better solutions than the one I offered > I am not seeing a glitch. (REBOL/Core 2.5.0.3.1 on w98) > > >> do rejoin['a "/" r "/" c ": " 10] > == [10 0] > >> print a/:r/:c
Tom, you were absolutely right - your answer is really a functional one. Sorry for my confusion about the way I interpreted your original suggestion. I was faulty and your version was really OK. I simply thought you were bad by writing ' tab_nbr (that is a lit-word) instead of my own string "tab_nbr/" and so I have been fooled when I substituted your original work for a modified one before really testing it. This is only after testing MY OWN modification that nothing more was operating. However I didn't realize that I was the author of the glitch I reported publicly as yours. Sorry about that. You did well to tell me back that you were right because this learned me 2 other things : a) Don't take for granted that my own view is the only way to go - even if I really demonstrate that everything is well-founded on my part (and fairly that was not the case here) ; b) Don't criticize too quickly other's work even if I think I am right - especially in a public exchange - something that in the present case I unfortunaltely did and I sincerely regret it but it's a little late now. Sorry again for my blunder and I publicly ask you to excuse me for this uncalled-for attitude, even if it was lead in part by some misconception from me. I'll remember the lesson and please continue to reply to my questions as you did before. I learned a lots since my last to questions - frankly more than I thought I would ... (I was once a victim of such a non voluntary discredit from an inexperienced student and this really put me in a severe situation in front of an entire class - I really don't know how I didn't catch this lesson better than I did. Hope this will not cause you any other prejudice to you since it is entirely my fault). Regards, Gerard

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