1. & and append(), sequence slicing, shrouding

This is a multiple topic email...

[&  and append()]
I've been meaning to pick a bone about these two operators
for a while now... ;)
take the following fer instance:

sequence num,temp
num = { {1,2,3}, {4,5,6}, {7,8,9} }

temp = num
temp = temp & 0
? temp
{{1,2,3},{4,5,6},{7,8,9},0}
_wrong_
you are "anding" here, (i don't mean: 1 "and" 1 = 1)
(i mean concat'ing here)
and each innermost sequence should get the & effect,
not specifically, and only, the outermost...
imho the use of the & operator here should result in:
{{1,2,3,0},{4,5,6,0},{7,8,9,0}}
why? because the sequence, by definition, is *recursive*

temp = num
temp = append(temp,0)
? temp
{{1,2,3},{4,5,6},{7,8,9},0}
_correct_
you are *appending*, ergo: to the end

temp = num
temp = temp & {10,11,12}
? temp
{{1,2,3},{4,5,6},{7,8,9},10,11,12}
now we get into a little trouble...

temp = num
temp = append(temp,{10,11,12})
? temp
{{1,2,3},{4,5,6},{7,8,9},{10,11,12}}
and once again trouble brews...

the problem is we really need a third operator...
but append can do double duty...
1:append as sequence
2:append as atom
so the last examples can work correctly now...
to wit:
temp = num
temp = temp & {10,11,12}
temp should now be:

temp = num
temp = append(temp,{10,11,12},"s") --"s" = as sequence
temp would then be:
{{1,2,3},{4,5,6},{7,8,9},{10,11,12}}

temp = num
temp = append(temp,{10,11,12},"a") --"a" = as atom
temp would then be:
{{1,2,3},{4,5,6},{7,8,9},10,11,12}

and it would work for 'strings' as well:

sequence names,temp
names = {"Billy ","Bobby ","Bobbie "}

temp = names
temp = temp & "Joe"
temp should now be:
{"Billy Joe","Bobby Joe","Bobbie Joe"}

temp = names
temp = append(temp,"Joe ","s")
temp should now be:
{"Billy ","Bobby ","Bobbie ","Joe "}

temp = names
temp = append(temp,"Joe ","a")
[ well this example is a bit nonsensical...
  but, no more nonsensical than temp = temp & "Joe "
  currently is ]
temp would be:
{"Billy ","Bobby ","Bobbie ",'J','o','e',' '}
[ergo, the same as temp = temp & "Joe " would be currently]

okay okay okayokay...
code would be *severly* broken IF you implemented
the suggestion in this manner.
BUT!
if we allow & to do what it does now, and append()
to do what it does now, and only _added_ an operator
that performed the "recursive &", then, I believe,
the language becomes *more* consistent with it's
refman.
Yes, i can implement a concat() function in my library.
No, it would be slower then a june bug stuck in dried
molasses.  This function/operation, *needs* the speed
that the sequence is all about...
there is a huge difference in between:
1>
function concat(sequence data,object appendage)
   for i=1 to length(data)
        data[i] = data[i] & appendage
   end for
end function
[not the best prototype of this function, admittedly]
2>
data = data && appendage

because #2 can only be implemented by rob to be able
to affect that whole sequence in *one shot*.
and i think && may be a good symbol because it
denotes "double &" or "recursive &" and i think it's
a *bad* symbol because of irv's prior post about
C, jolt and twinkies.
so my vote for naming is concat(), and my vote
for implementation is **native** and #2 would read:
data = concat(data,appendage)

lastly, if this topic has been discussed before,
i don't remember it in the time that i've been on
this listserv (1-2years now?), and i'm sorry
for bringing it back up then.





[sequence slicing]
another request, not a bone to pick :), is in regards
to something in the refman i saw whilst looking up
why my code didn't work... cuz it can't :)

sequences can be sliced:
data = {1,2,3,4,5,6,7,8,9}
data[3..5]={9,9,9}  <or> data[3..5]=9

good so far?
here we go...
blahblah in refman... up to where it starts about 2d arrays...
data ={ {1,2,3},
        {4,5,6},
        {7,8,9}}
data[1] = {1,2,3}
data[1][1] = 1
and then it says something in the refman about how
the sequences aren't "ordered" such that they aren't
balanced... words to that effect...
you can grab a whole row with the data[1]={1,2,3}
command, but there is currently no way to grab a
*column*... well, i believe that
data[1..3][1]
*should* be allowed and should equal {1,4,7}
now, i'm almost positive i havent seen discussion
on this topic, and i have two questions about it:
(and i guess they're directed mostly to rob)
1>*can* this be implemented in EU?
  if it cannot be accomplished in EU without extreme
  migraines lasting into the wee years of adulthood,
  then I understand...
2>if it could be implemented, is there some reason you've
  choosen not to do so?
i'm kinda curious... you haven't mentioned it in any
of your postings whereby you gave a status report
on "EU3" and what is/isnt/has/hasnt been coded yet...
but, yet, you mentioned in refman, a phrase like
"there is _currently_ no way to do this in EU"
and that "currently" stands out like a pandora's
box waiting to kill a curious cat...
and boy, it would sure be used *a lot* and would
sure make things easier...


[shrouding]
irv mentioned that 'we could simply send shrouded .ex
thru email' (semiquote)...
well, alan tu had sent a shrouded file, a while back,
for some program or another that he coded...
and i use netscape mail, and it's pretty good about
most things, but it wasn't real happy with that shrouded
file and all it's smilie faces and char's below ascii32
and above (somewhere near) asciiZ...
so, if your gonna do that, i would strongly recommend
zipping the shrouded file, and sending it via
zipped *attachment*, that way it's for sure not mangled...

(drops a full quarter into the EUbot microeconomy)



take care all--Hawke'

new topic     » topic index » view message » categorize

2. Re: & and append(), sequence slicing, shrouding

I have to disagree with your suggestion that

{{1,2},{3,4}}&5 --> {{1,2,5},{3,4,5}}

I actually like the & operator.  My suggestion would be to optimize s1&{s2}
to be as fast as append(s1,s2), and we wouldn't need the append function at
all.

I do agree with the && suggestion though; in fact I suggested this format
for all binary operators a few months ago:

s1={{a,b},{c,d}}
s2={e,f}

s1&s2:  {{a,b},{c,d},e,f,g}
s1&{s2}:        {{a,b},{c,d},{e,f}}
s1&&s2: {{a,b,e,f},{c,d,e,f}}

s1+s2:  {{a+e,b+e},{c+f,d+f}}
s1++s2: {{a,b}+{e,f},{c,d}+{e,f}} --> {{a+e,b+f},{c+e,d+f}}

This could be expanded to accept +++, etc, with each + adding one level
deeper on which to operate. a command such as:

?{1,2,{{3,4}}}+++{1,2}

would either skip the first two levels and begin operating on the third,
producing:

{1,2,{{4,6}}}

or would cause an error.

A common use for deep operators would be sets nof coordinates.

As for s[1..3][2], I believe it has been suggested before, and I like it;
it would allow sequences to represent true multidimentional fields, as
opposed to lists of lists as they are now, but it seems like it'd be tough
to implement with any efficiency.

        Isaac

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu