1. RE: Is subscripting a slice useful
Derek Parnell wrote:
>
>
> posted by: Derek Parnell <ddparnell at bigpond.com>
>
> Pete Lomax wrote:
>
> [snip]
>
> > This is all possible, but you should at least by now understand why
> > *I* don't consider it an improvement to the lovely, elegant language
> > we all know and love.
> >
> > If the majority want this, so be it, I've had my say.
>
> I must agree with Pete (a rare thing I suspect). The concept of
> 'vertical'
> slicing needs a new syntax altogether, if we need to have it at all in
> the language.
>
> Currently the "[n..m]" notation in an expression is saying ...
>
> "create a new sequence, and build it from elements 'n' to 'm'
> inclusively"
>
> But vertical slicing implies that we don't want to use all of each
> element
> but just a subset of each element. So the difference in semantics
> (sub-element verses full element) needs to be reflected in the syntax.
> Something like "[n..m : x..y]" maybe. This is saying - build a new
> sequence from elements 'n' to 'm', but for each element just use
> sub-elements 'x' to 'y'. In other words, the syntax "[n..m]" could
> be thought of as shorthand for "[n..m:1..$]"
>
> A = { {1,2,3}, {4,5,6}, {7,8,9}, {10,11,12} }
>
> Thus A[2..3 : 2] would give {5,8}
> and A[2..3 : 2..3] would give {{5,6}, {8,9}}
>
> --
> Derek Parnell
> Melbourne, Australia
Readability is more important than compactness of code.
I agree that implementing vertical slicing in that manor would be
significantly detrimental to the readability of euphoria source code.
I would like to see a restricted form of vertical slicing though.
The restriction would be that there can be no more than one slice in any
given reference.
s[1..$][x] , or s[x][1..$][y][z] would be ok
but not s[1..$][1..3][x]
Sure it might be convenient, but it becomes more trouble to decipher it,
than it is to just write it out the hard way in the first place.
Granted that former example is quite simple, but there would have to be
a limit, and the most logical limit is 1. Eu's limit is already 1.
Chris Bensler
Code is Alchemy
2. RE: Is subscripting a slice useful
> Sure it might be convenient, but it becomes more trouble to decipher it,
> than it is to just write it out the hard way in the first place.
Speaking of, didn't Lomax.Pete already provide a sufficiently efficient
function for this? Anyway, here's some code that does it simply:
--start vertical slicing code here
function randomWord()
sequence words
words =
{"One","Two","Three","Four","Five","Six","Seven","Eight","Nine","Ten","absolute","basketball","crazy",
"delirious","effective","fixated","governing","hill","indigo","justified","Klingon","lemon","manners",
"neophyte","opposed","perfect","quagmire","rooster","safety","terror","umbrella","vibrate","wanton",
"xylophone","yellow","zebra"}
return words[rand(length(words))]
end function
function dbSequence()
integer x, recs
sequence allRecs
x = rand(10) + 10 -- between 11 and 20 fields per record
recs = rand(90) + 10 -- between 11 and 100 records
allRecs = repeat({},recs)
for t=1 to recs do
for u=1 to x do
allRecs[t] = append(allRecs[t],randomWord())
end for
end for
return allRecs
end function
function getColumn(atom which, sequence what)
sequence result
result = {}
if which > 0 and integer(which) then
for t=1 to length(what) do
if which <= length(what[t]) then
result = append(result, what[t][which])
else
-- an error, but what to do about it?
-- for now, return empty sequence
result = append(result,"")
end if
end for
end if
return result
end function
sequence x, mySequence
mySequence = dbSequence() -- a db sequence is one with consistent lengths
-- for all elements of the db
x = getColumn(1, mySequence) -- getColumn #1 of all "records" in mySequence
puts(1,"All items in column 1:\n")
?x
?1/0
--end vertical slicing code here
I guess it would be better to call the function
verts() -- for VERTical Slice
eh? Plus, it's shorter. :)
Then it becomes
x = verts(1,mySequence)
vs.
x = mySequence[1..$][1] -- or however you would do it... :/
both of which are the same length, so no time difference to the developer,
which is the most important consideration of all! :)
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
3. RE: Is subscripting a slice useful
Chris Bensler wrote:
>
>
> Derek Parnell wrote:
> >
> >
> > posted by: Derek Parnell <ddparnell at bigpond.com>
> >
> > Pete Lomax wrote:
> >
> > [snip]
> >
> > > This is all possible, but you should at least by now understand why
> > > *I* don't consider it an improvement to the lovely, elegant language
> > > we all know and love.
> > >
> > > If the majority want this, so be it, I've had my say.
> >
> > I must agree with Pete (a rare thing I suspect). The concept of
> > 'vertical'
> > slicing needs a new syntax altogether, if we need to have it at all in
> > the language.
> >
> > Currently the "[n..m]" notation in an expression is saying ...
> >
> > "create a new sequence, and build it from elements 'n' to 'm'
> > inclusively"
> >
> > But vertical slicing implies that we don't want to use all of each
> > element
> > but just a subset of each element. So the difference in semantics
> > (sub-element verses full element) needs to be reflected in the syntax.
> > Something like "[n..m : x..y]" maybe. This is saying - build a new
> > sequence from elements 'n' to 'm', but for each element just use
> > sub-elements 'x' to 'y'. In other words, the syntax "[n..m]" could
> > be thought of as shorthand for "[n..m:1..$]"
> >
> > A = { {1,2,3}, {4,5,6}, {7,8,9}, {10,11,12} }
> >
> > Thus A[2..3 : 2] would give {5,8}
> > and A[2..3 : 2..3] would give {{5,6}, {8,9}}
> >
> > --
> > Derek Parnell
> > Melbourne, Australia
>
> Readability is more important than compactness of code.
I agree, and that has been a consistent stance of mine too.
Did I suggest otherwise? On the other hand, verbose code does
not automatically imply readability either - see COBOL for
numerous examples!
> I agree that implementing vertical slicing in that manor
Which manner? My code above or the examples that Christian provided?
> would be significantly detrimental to the readability of euphoria
> source code.
This is the nature of 'operators' in programming languages. They are
small and sometimes ambiguous, especially when first encountered. I hinted
that vertical slice operators may not be needed as they can be acheived
quite easily using functions, and I'm not sure if there would be significant
performance benefits if they were built into the language.
--
Derek Parnell
Melbourne, Australia
4. RE: Is subscripting a slice useful
<snip>
> > Readability is more important than compactness of code.
>
> I agree, and that has been a consistent stance of mine too.
> Did I suggest otherwise? On the other hand, verbose code does
> not automatically imply readability either - see COBOL for
> numerous examples!
I just was establishing my perspective.
And yes, verbose code is not readable either. A balance must be found.
>
> > I agree that implementing vertical slicing in that manor
>
> Which manner? My code above or the examples that Christian provided?
>
The one which allows the user to create multidimensional slices. From
what I can tell both proposals lend to that.
> > would be significantly detrimental to the readability of euphoria
> > source code.
>
> This is the nature of 'operators' in programming languages. They are
> small and sometimes ambiguous, especially when first encountered. I
> hinted
> that vertical slice operators may not be needed as they can be acheived
> quite easily using functions, and I'm not sure if there would be
> significant
> performance benefits if they were built into the language.
I'm generally satisfied to use a function instead. But passing a slice
of a sequence to a function that manipulates it, creates copies.
I think vertical slicing could provide a noticable speed gain.
Pulling a 1st level column from a dimmed sequence is quite common.
Chris Bensler
Code is Alchemy
