Re: Schwartzian Transform
On Thu, Mar 22, 2001 at 11:13:47PM -0500, John Porter wrote:
Brent Dax wrote:
Someone else showed a very ugly syntax with an anonymous
hash, and I was out to prove there was a prettier way to do it.
Do we want prettier? Or do we want more useful?
Perl is not exactly known for its pretty syntax.
If you have to explicitly specify both the forward and inverse transforms,
then it isn't very useful -- it's nothing more then map/sort/map. OTOH, if
you only have to specify the forward mapping, it becomes more useful. Thus,
I think the best syntax is
tsort({xform}, {compare}, @list), where the {}s are anon blocks or curried
expressions (same thing) and xform specifies the forward mapping (IE (lc
^_)) and compare specifies the comparator (IE (^_ cmp ^_)).
This would always (do the equiv to) create a LoL in the inner map, sort on
the -[0] elem, and extract the -[1] elem. Thus, it might not be as
effecent as a hand-crafted schwartzian, but will be at least as efficent as
a naieve straight sort (except in pathalogical cases, like tsort((^_),
(^_=^_), @list)).
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
i have to put my 2 cents in...
after reading all the discussion so far about the Schwartz,
i feel that map{} sort map{} is perfect in it's syntax.
if you code and understand Perl (i've seen situations where
these aren't always both happening at the time) and knowingly
use the building block functions, sort and map, to create an
abstraction like the Schwartzian transform, then why do you
need to come up with special syntax or use a Sort::Module, as
it was suggested, to achieve just the same thing. my point
is that i wonder if it's useful for Perl or people who write
Perl, to bundle a map and sort function into some special
schwartzian syntax, is the goal just to abstract another layer
above the transform itself? why not just keep using map{} sort
map {}, if it's a well understand concept?
monty
James Mastros wrote:
On Thu, Mar 22, 2001 at 11:13:47PM -0500, John Porter wrote:
Brent Dax wrote:
Someone else showed a very ugly syntax with an anonymous
hash, and I was out to prove there was a prettier way to do it.
Do we want prettier? Or do we want more useful?
Perl is not exactly known for its pretty syntax.
If you have to explicitly specify both the forward and inverse transforms,
then it isn't very useful -- it's nothing more then map/sort/map. OTOH, if
you only have to specify the forward mapping, it becomes more useful. Thus,
I think the best syntax is
tsort({xform}, {compare}, @list), where the {}s are anon blocks or curried
expressions (same thing) and xform specifies the forward mapping (IE (lc
^_)) and compare specifies the comparator (IE (^_ cmp ^_)).
This would always (do the equiv to) create a LoL in the inner map, sort on
the -[0] elem, and extract the -[1] elem. Thus, it might not be as
effecent as a hand-crafted schwartzian, but will be at least as efficent as
a naieve straight sort (except in pathalogical cases, like tsort((^_),
(^_=^_), @list)).
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
--
Mark Koopman
Software Engineer
WebSideStory, Inc
10182 Telesis Court
San Diego CA 92121
858.546.1182.##.318
858.546.0480.fax
perl -e '
eval(lc(join("",
map ({chr}(q(
49877273766940
80827378843973
32767986693280
69827639463932
39883673434341
))=~/../g;'
Re: Distributive - and indirect slices
On Mon, Mar 19, 2001 at 08:30:31AM -0800, Peter Scott wrote: Seen http://dev.perl.org/rfc/82.pod? I hadn't. I'm surprised it didn't give the PDL people screaming fits. But no, I wouldn't do it like that. It has: @b = (1,2,3); @c = (2,4,6); @d = @b * @c; # Returns (2,8,18) Where I would have @d = (2,4,6,4,8,12,6,12,18); However, this isn't great language design; it's applying a specific solution to a specific problem. Better is to solve the general problem, and have all operators overloadable even on non-objects, so the user can define how this sort of thing works. -- I want you to know that I create nice things like this because it pleases the Author of my story. If this bothers you, then your notion of Authorship needs some revision. But you can use perl anyway. :-) - Larry Wall
Re: Distributive - and indirect slices
Simon Cozens wrote: Better is to solve the general problem, and have all operators overloadable even on non-objects, so the user can define how this sort of thing works. Even better is to let the user have access to the real objects by which "non-objects", i.e. normal variables, are implemented. That is, to remove the "non-object"-ness of normal variables. (I'm not disagreeing with Simon, just twisting the idea a little.) -- John Porter
Re: Distributive - and indirect slices
Simon Cozens wrote: On Mon, Mar 19, 2001 at 08:30:31AM -0800, Peter Scott wrote: Seen http://dev.perl.org/rfc/82.pod? I hadn't. I'm surprised it didn't give the PDL people screaming fits. But no, I wouldn't do it like that. It has: @b = (1,2,3); @c = (2,4,6); @d = @b * @c; # Returns (2,8,18) Where I would have @d = (2,4,6,4,8,12,6,12,18); The first example above is called the scalar product of two vectors in APL, and can be generalised for all arithmetic operators. The second example is called the outer or cross-product of two vectors. However, this isn't great language design; it's applying a specific solution to a specific problem. Better is to solve the general problem, and have all operators overloadable even on non-objects, so the user can define how this sort of thing works. Precisely. The operators for arrays (lists) should be defined orthogonally and completely in a mathematically consistent manner to be of general purpose use. Here is one example of such a definition, freely adapted from the APL syntax: 1. scalar array operators: @a ? @b For any numerical operator '?', two compatible arrays can be combined with that operator producing a new array as follows: @r = @a ? @b where $r[i] = $a[i] ? $b[i] complexity: if @a and @b are not the same length, the shorter is extended with the appropriate scalar value, i.e. 0 for additive and 1 for multiplicative operators. example: @a = (1,2,3); @b = (2,4,6); @r = @a + @b; # @r = (3,6,9) As well, mixed array and scalar operands are allowed: @a + 10 produces (11,12,13) 20 - @b produces (18,16,14) 2. reduction: ?/@a Reduction introduces the new diglyphs that end in '/', and are preceded by a numerical operator, i.e. +/ -/ */ // Any numerical array can be reduced to a scalar value over a given numerical operator '?' as follows: $r = ?/@a where $r = $a[0] ? $a[1] ? $a[2] ... example: @a = (2,4,6); $r = */@a; # $r = 36 3. inner product: @a ?/! @b Inner product introduces the new triglyphs with '/' as the middle character, and surrounded by numerical operator, i.e. +/* */- -/* -/- etc. For any numerical operators '?' and '!', two compatible arrays can be combined with those operators producing a scalar inner product, as follows: $r = @a ?/! @b where $r = ?/ (@a ! @b) i.e. $r = ($a[0] ! $b[0]) ? ($a[1] ! $b[1]) ? ... example: @a = (1,2,3); @b = (2,4,6); $r = @a +/* @b; # @r = +/(2,8,18) = 28 4. outer product: @a @? @b Outer product introduces the new diglyphs that start with '@', and end with a numerical operator, i.e. @+ @- @* @/ For any numerical operator '?', any two arrays can be combined into the cross-product with those operators producing a new array containing the outer product. Each row of the outer product is concatenated to the next to produce the result, best illustrated by the following example: @a = (1,2,3); @b = (2,4,6); @r = @a @* @b; @r = (2,4,6), (4,8,12), (6,12,18) = (2,4,6,4,8,12,6,12,18) Of course, there are probably syntactic nightmares in introducing the diglyphs and triglyphs mentioned above into perl. -- Rick Welykochy || Praxis Services Pty Limited
