Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Perldocs for Schwartzian transforms?

Reply
Thread Tools

Perldocs for Schwartzian transforms?

 
 
jl_post@hotmail.com
Guest
Posts: n/a
 
      12-09-2005
Dear Perl Community,

Are there any perldocs that cover Schwartzian transforms?

I tried:

perldoc -q Schwartz

and also searched for "Schwartz" in "perldoc perltoc" but couldn't find
any mention of them.

I did, however, find a mention in:

perldoc perlfaq4

(which I found again with "perldoc -f sort") but it only briefly
touches upon the Schwartzian transform. I was wondering if there are
any perldocs that might explain it in more detail.

Thanks for any responses.

-- Jean-Luc

 
Reply With Quote
 
 
 
 
Jürgen Exner
Guest
Posts: n/a
 
      12-09-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Are there any perldocs that cover Schwartzian transforms?

[...]
> touches upon the Schwartzian transform. I was wondering if there are
> any perldocs that might explain it in more detail.


None that I am aware of (which doesn't mean there aren;t any), but there are
numerous articles on Google.

jue


 
Reply With Quote
 
 
 
 
A. Sinan Unur
Guest
Posts: n/a
 
      12-09-2005
"(E-Mail Removed)" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) oups.com:

> Dear Perl Community,
>
> Are there any perldocs that cover Schwartzian transforms?
>
> I tried:
>
> perldoc -q Schwartz
>
> and also searched for "Schwartz" in "perldoc perltoc" but couldn't find
> any mention of them.
>
> I did, however, find a mention in:
>
> perldoc perlfaq4
>
> (which I found again with "perldoc -f sort") but


ITYM perldoc -q sort

> I was wondering if there are
> any perldocs that might explain it in more detail.


Does it have to be in perldoc?

A simple Google search yields the following links in the first few results:

<URL:http://www.stonehenge.com/merlyn/UnixReview/col06.html>

<URL:http://en.wikipedia.org/wiki/Schwartzian_Transform>

<URL:http://perl.plover.com/yak/hw1/samples/slide004.html>

I am assuming you have already done this search, and looked at the
documents above.

Sinan
 
Reply With Quote
 
Tim Heaney
Guest
Posts: n/a
 
      12-09-2005
"(E-Mail Removed)" <(E-Mail Removed)> writes:
>
> Are there any perldocs that cover Schwartzian transforms?


I like Mark Jason Dominus's explanation at

http://perl.plover.com/TPC/1998/Hard...zian_Transform

That's not a perldoc, exactly, but I hope it helps!

Tim
 
Reply With Quote
 
jl_post@hotmail.com
Guest
Posts: n/a
 
      12-11-2005
> "(E-Mail Removed)" <(E-Mail Removed)> wrote in
> >
> > Are there any perldocs that cover Schwartzian transforms?
> >
> > I was wondering if there are
> > any perldocs that might explain it in more detail.


A. Sinan Unur replied:
>
> Does it have to be in perldoc?


It would be nice if there was a perldoc explanation.

The reason I prefer the perldocs is because I always encourage those
newer to Perl to use the perldocs to look up anything they don't know
how to use. Don't know what a function does? Look it up with "perldoc
-f function". Don't know how to use a module? Look it up with
"perldoc Module". Want to know how to do a specific thing in Perl?
Try "perldoc -q keyword" or search for it in "perldoc perl" and
"perldoc perltoc".

I've found that I sometimes have to explain my code at times,
otherwise other people will copy it into their own Perl programs not
really understanding what it means. For example, I once used the
following code in my own program:

use File::Find;
find(\&wanted, @directories_to_seach);
sub wanted
{
...
}

This was taken right out of "perldoc File::Find". Well, the program
worked so well that it was "picked apart" by another programmer.
Unfortunately, since he didn't quite understand what the File::Find
module did (he thought he did), he used it where he really meant to use
opendir() and readdir() instead.

He complained that the code was doing things to files he didn't
specify, not realizing that File::Find operates on all files
*recursively* -- which, after several minutes of interrogation (it's
often difficult to understand other people when they don't clearly
explain what they want), I discovered was exactly what he didn't want.

Therefore, I've taken to adding comments like:

# The following three lines of code were lifted
# right out of "perldoc File::Find":

before any code that, for the most part, I didn't write myself. That
way any maintainer (which could conceivably be me, in a few years) can
look up its purpose and use without having to resort to guessing.
(Unfortunately, there will always be people who remain confused because
they ignore the help written in the comments, but I think that's more
the maintainer's problem than the original code writer's.)

So if I ever wanted to write a Schwartian Transform to sort files by
file size, I might write something like this:

# The following line of code uses a Schwartzian
# Transform to sort the files by file size (read
# "perldoc perlfaq4" to learn more about
# Schwartzian Transforms):
@sorted = map { $_->[0] }
sort { $a->[1] <=> $b->[1] }
map { [ $_, -s $_ ] } @files;

Without the comment, a person who has never seen a Schwartzian
Transform before would have to study the code very hard to figure out
that the files are being sorted by size, and he/she would still have no
clue why I did it in such a seemingly strange way. He/She would have
no idea what to search for, even if he/she did think to look up that
construct on the web or in the perldocs.

I tell people who write Perl code (or any code, really) to ask
themselves: "If a maintainer reads the block of code I have just
written, will he/she have a difficult time understanding what I wrote
and what it's supposed to do, assuming they don't know my thought
process beforehand? If so, I should either simplify the code (so that
what the code does is clear to those who don't necessarily know my
intentions) or, if that's not possible, explain my intentions and what
the code is supposed to do right above the block of code in the form of
a comment (which will make it easier to maintain and distinguish any
bugs that creep in there by future maintainers). So many times I have
seen code that looks like could be a bug -- but I'm not sure if it is
or not because I have no way of knowing what the code is *supposed* to
be doing.

So I encourage people to use the perldocs and to reference them in
their code whenever appropriate. Granted, referencing a web page can
also work, but in my experience a good web page may not be around
several years later when a piece of code is being maintained. In
addition, I trust explanations and code in the perldocs more than I do
on just any web page. For these reasons, I prefer referencing perldoc
documentation over web pages.

That isn't to say that the web page explanations aren't good. The
wikipedia link is good, as many people are encouraged to look up things
there anyway, and I just might cite that next time I use a Schwartzian
Transform.

I also happen to think that if good Perl programmers are expected to
know of a particular construct (like the Schwartzian Transform), then
it should be explained in the perldocs. I constantly tell new Perl
programmers that they should always favor the Perl community's
convention of doing things (over some other language's convention) even
if it goes against what their first programming language teacher told
them (for example, always using prototypes, despite what their
professor said, is not always a good idea in Perl -- just ask Tom
Christiansen).

So if they can't find any mention of a way of doing something in the
perldocs, then they should either not use it, or explain it clearly in
the form of comments. Even if it is in the perldocs and still looks
strange, they should at least give a perldoc reference so that any
decent maintainer (who cannot reasonably be expected to understand
every construct he/she encounters) can look it up and have help
understanding the code.

Sorry... this post turned out longer than I intended.

But anyway, thanks to everyone who provided the links. I can always
reference the Wikipedia article, and be reasonably certain that it will
still be around when a future maintainer needs it to be.

-- Jean-Luc Romano

 
Reply With Quote
 
A. Sinan Unur
Guest
Posts: n/a
 
      12-11-2005
"(E-Mail Removed)" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) oups.com:

>> "(E-Mail Removed)" <(E-Mail Removed)> wrote in
>> >
>> > Are there any perldocs that cover Schwartzian transforms?
>> >
>> > I was wondering if there are
>> > any perldocs that might explain it in more detail.

>
> A. Sinan Unur replied:
>>
>> Does it have to be in perldoc?

>
> It would be nice if there was a perldoc explanation.
>
> The reason I prefer the perldocs is because I always encourage
> those newer to Perl to use the perldocs to look up anything they
> don't know how to use.


<snip>

Does every single programming technique, algorithm, and idiom have to be
in perldoc?

> # The following line of code uses a Schwartzian
> # Transform to sort the files by file size (read
> # "perldoc perlfaq4" to learn more about
> # Schwartzian Transforms):


What's wrong with Randal's original article in Unix Review (which also
appeared in print, in case you are worried about links disappearing)?

<URL:http://www.stonehenge.com/merlyn/UnixReview/col06.html>

> So I encourage people to use the perldocs and to reference them in
> their code whenever appropriate.


OK.

> I trust explanations and code in the perldocs more than I do
> on just any web page.


Well, the link above is not just any web page. Have you ever wondered
where the "Schwartz" in "Schwartzian Transform" comes from?

> I also happen to think that if good Perl programmers are expected to
> know of a particular construct (like the Schwartzian Transform), then
> it should be explained in the perldocs.


Are you volunteering to write a new FAQ entry? That would be a valuable
contribution indeed.

Or, maybe, you could use Uri Guttman's excellent Sort::Maker to
construct the sort routine, and get the description of the Schwartzian
Transform (along with some others) for free.

Sinan
--
A. Sinan Unur <(E-Mail Removed)>
(reverse each component and remove .invalid for email address)

comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/cl...uidelines.html

 
Reply With Quote
 
jl_post@hotmail.com
Guest
Posts: n/a
 
      12-11-2005
> >> "(E-Mail Removed)" <(E-Mail Removed)> wrote:
> >
> > The reason I prefer the perldocs is because I always encourage
> > those newer to Perl to use the perldocs to look up anything they
> > don't know how to use.


> A. Sinan Unur replied:
>
> Does every single programming technique, algorithm, and idiom have to be
> in perldoc?


No. Anything that you would expect a decent Perl
programmer/maintainer to know doesn't have to be documented. (Of
course, we could get into long debates as to what constitutes a
"decent" Perl programmer and what he/she is expected to know, but I
tend to consider that such a person is one who is familiar with almost
all of the concepts in O'Reilly's "Learning Perl".)

As for other programming techniques, algorithms, and idioms that are
not immediately apparent to a maintainer, they don't have to be in
perldocs as long as they are either explained in the form of comments
(or accompanying documentation), or they are written along with a
reference pointing to information needed to understand the code.

Consider the code you see in "perldoc -m Math::BigInt". Looking
through the code, I see the following comments:

# GCD -- Euclids algorithm, variant C (Knuth Vol 3, pg 341 ff)

and

# multiply two numbers -- stolen from Knuth Vol 2 pg 233

Personally, I think these are great comments because they explain
exactly where the code was derived from. In my opinion, it's not
reasonable that a decent Perl coder could understand the intention of
all the code in Math::BigInt without outside help, so it's good to know
that a reference point is provided in case I decide I need more
information to help me. In case I ever I have to track down a bug
somewhere in the Math::BigInt module (and it has happened on one
occasion), I won't have to guess as to what the right operation,
calculation, or behavior is meant to be; I can just look it up in the
references given. Granted, the comments assume that a copy of that
book will be available, but it's better than no comment at all.

Consider this example: 0n page 233 of a certain administrator's
handbook which I won't name here, I saw the following (unexplained)
line of code:

map { $String{$StringIndex{$_}} = $_; } ( keys( %StringIndex ) );

What is it doing, exactly? First of all, we can tell that the code is
not very well written, otherwise map() wouldn't have been used in void
context (foreach would have been a better choice). In addition, "use
strict" and "use warnings" weren't used (there's no way for you to know
just by looking at this one line of code; I just know because I saw the
full script).

It took me about five minutes to study this one line of code before
I realized what it was doing. It was basically doing the same thing as
the following line of code:

%String = reverse %StringIndex;

Now, which line of code is easier to understand and comprehend? For
me, the second one is. I must admit, however, that the second line is
only easier for me because I learned about it in the O'Reilly "Learning
Perl" book. If I hadn't, the line calling reverse() might make no
sense to me. I might have preferred the following lines instead:

while (($k,$v) = each %StringIndex)
{
$String{$v} = $k;
}

or even:

$String{ $StringIndex{$_} } = $_ foreach keys %StringIndex;

But whichever way I choose, there is a reasonable chance that a
maintainer will not know what I meant, and the line looks no more
comprehensible than the first map() example. (It's my opinion that
they should know about the reverse() example since that's covered in
"Learning Perl", but that's not always the case, unfortunately.)
Therefore, I don't think it's a bad idea to include a comment like:

# Create a hash that's the reverse of %StringIndex
# (so that the keys are not values and vice-versa):
%String = reverse %StringIndex;

Even if that comment were used on the map() line of code above, it
would significantly help the maintainer understand what is going on.


> What's wrong with Randal's original article in Unix Review (which also
> appeared in print, in case you are worried about links disappearing)?


Absolutely nothing is wrong. I never said it was a bad review and
I'm not opposed to citing it. I just favor perldocs because they are
available even when a user has no internet connection (or is at the
moment having trouble with it) and will never be a stale link (even if
an article appeared in print). In my opinion, perldocs are just
usually easier to use, and I've found that the more you require of
maintainers to jump through hoops to get information, the less likely
they are to do so (even if the link is valid and good).


> Are you volunteering to write a new FAQ entry? That would be a valuable
> contribution indeed.


To be honest, I haven't thought about that until you mentioned it.
I suppose that's something I could try. How would I go abuot doing it?
(I briefly searched Google and the perldocs and the closest thing I
could find to submitting a perldoc was in "perldoc Net::libnetFAQ"
which says to mail contributions to g barr at pobox dot com. If I'm
missing a crucial page or something, let me know.)

About my opinion (which says that code not immediately
understandable to a decent programmer should always be accompanied by
documentation (or at least a reference) that explains the intent of the
code): I've discussed this opinion of mine at length with several
programmers throughout the years and so far none of them share my
opinion (some think it might be a good idea, however). So if you
disagree with my opinion, know that you are in the majority. However,
this remains my personal opinion and I find that the more I practice it
in my code, the more maintainers understand my code and benefit from
it.

Anyway, thanks for your input, Sinan.

-- Jean-Luc

 
Reply With Quote
 
John Bokma
Guest
Posts: n/a
 
      12-11-2005
"(E-Mail Removed)" <(E-Mail Removed)> wrote:

> Consider this example: 0n page 233 of a certain administrator's
> handbook which I won't name here, I saw the following (unexplained)
> line of code:
>
> map { $String{$StringIndex{$_}} = $_; } ( keys( %StringIndex ) );
>
> What is it doing, exactly? First of all, we can tell that the code is
> not very well written, otherwise map() wouldn't have been used in void
> context (foreach would have been a better choice).


IIRC map in void context has been optimized. (Note: I do not say the above
piece of code is good or bad).

Remember, ages ago it was bad to write: for ( 1 .. 10_000_000 )

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
I ploink googlegroups.com

 
Reply With Quote
 
A. Sinan Unur
Guest
Posts: n/a
 
      12-12-2005
"(E-Mail Removed)" <(E-Mail Removed)> wrote in
news:(E-Mail Removed) oups.com:

> About my opinion (which says that code not immediately
> understandable to a decent programmer should always be accompanied by
> documentation (or at least a reference) that explains the intent of
> the code):


I think you are cheating a little here. Your actual stated opinion seems
to me that everything that you might ever want to reference should be
included in the standard Perl documentation. That is where I am a little
baffled by your arguments. No one can argue with the proposition that
when you do something clever, you should put something that explains
where that came from.

> As for other programming techniques, algorithms, and idioms that are
> not immediately apparent to a maintainer, they don't have to be in
> perldocs as long as they are either explained in the form of comments


I really don't understand you, I am afraid. Do you propose that what
gets included in the standard Perl distribution should depend on what
programmers put in their comments?

> (or accompanying documentation), or they are written along with a
> reference pointing to information needed to understand the code.
>
> Consider the code you see in "perldoc -m Math::BigInt". Looking
> through the code, I see the following comments:
>
> # GCD -- Euclids algorithm, variant C (Knuth Vol 3, pg 341 ff)


So, in the case of Schwartzian transform, it should be fine to reference
Randal's original article, and move on, instead of insisting that
Schwartzian transform should be explained in the standard Perl
documentation.

That's the point I am trying to make. You seem to want to go off on
tangents about dimwit programmers who cannot figure out File::Find, or
map in void context, or comments. The issues you raise are all valid,
but irrelevant to the question I asked. For the record, that question
was: "Does the explanation of the "Schwartzian Transform" -- a general
algorithm -- need to be included with Perl?"

Aaaanyway, I am probably becoming too pedantic, so I'll stop now.

Sinan
--
A. Sinan Unur <(E-Mail Removed)>
(reverse each component and remove .invalid for email address)

comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/cl...uidelines.html

 
Reply With Quote
 
robic0
Guest
Posts: n/a
 
      12-12-2005
On 11 Dec 2005 22:52:07 GMT, John Bokma <(E-Mail Removed)> wrote:

>"(E-Mail Removed)" <(E-Mail Removed)> wrote:
>
>> Consider this example: 0n page 233 of a certain administrator's
>> handbook which I won't name here, I saw the following (unexplained)
>> line of code:
>>
>> map { $String{$StringIndex{$_}} = $_; } ( keys( %StringIndex ) );
>>
>> What is it doing, exactly? First of all, we can tell that the code is
>> not very well written, otherwise map() wouldn't have been used in void
>> context (foreach would have been a better choice).

>
>IIRC map in void context has been optimized. (Note: I do not say the above
>piece of code is good or bad).
>
>Remember, ages ago it was bad to write: for ( 1 .. 10_000_000 )


What does for(1..$somevariable) actually mean? Is it short for some
C construct? Why is Perl so****in much of a child of a prostitute
whore anyway? Who holds the tribal knowledge of this piece of ****
jackoff, incomplete, language anyway? A language allowing dll
interfaces to the os that supposedly legitimizes it. What a real
honest piece of **** Perl is !!! I saw a C program running yesterday,
did the same thing as a module on Cpan. The C program ran 100 times
faster with better results/reliability.

Explain how Perl is something good to me.......>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Schwartzian transform for tuple in list David Di Biase Python 5 09-25-2008 06:10 AM
Numerical sort (Schwartzian xform) Jorge Perl Misc 16 09-08-2006 03:59 AM
Schwartzian Transform built-in to Perl 6? William James Perl Misc 0 08-28-2005 12:14 PM
search perldocs against each word in a string ioneabu@yahoo.com Perl Misc 0 02-16-2005 04:29 AM
best way to search perldocs wana Perl Misc 7 09-27-2004 11:55 PM



Advertisments