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