Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Re: Perl Internals: Hashes

by demerphq (Chancellor)
on Apr 14, 2004 at 22:41 UTC ( #345235=note: print w/ replies, xml ) Need Help??


in reply to Re: Perl Internals: Hashes
in thread Perl Internals: Hashes

Regarding C) No. Definately not (IMO anyway). Did the fact that I implemented 2-3 trees (aka red-black trees) in perl rob me of understanding 2-3 trees? Did it with huffman compression? Did it with LZW compression? Treaps? No no, perl frees you from all the BS junk and allows you to narrow down quickly on the algorithm at hand. It may not be as efficient as the same thing coded in C, but its the same algotihm and thus will perform just the same way.


---
demerphq

    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi



Comment on Re: Re: Perl Internals: Hashes
Download Code
Re: Re: Re: Perl Internals: Hashes
by flyingmoose (Priest) on Apr 14, 2004 at 23:00 UTC
    Definitely yes -- if you are avoiding the intracies of pointer manipulation. True that trees as such can be aided by higher level languages, but there is nuance and skill learned in finer manipulation (though it be drudgery) that will allow you to perform far greater things in other languages when Perl is not always available.

    Don't do your data structures work in Perl if you want to really get something from the class. If you are just trying to avoid drudgery, well yeah, Perl helps. But do it ground up at least once, and you'll come out a changed developer.

      Well, I learned and programmed in a lot of other languages before I came to Perl so Im aware of the differences. Pascal in particular... *shiver* But anyway, I dont know that I agree with your last point. Personally amongst the first thing I do with a new language is write certain data structure implementations. Try 2-3 trees in VB. Blech. :-) Perl has a natural slant and thus some algorithms work nicely in Perl, others go against the grain as it were and are actually far less efficient than they should be. But aside from that if you learn an algorithm in a language like perl then you probably havent had to deal with as much language and representation specific gunk so you have probably learned the core ideas better. So when you go to implement in another language you're more free of language specific distractions and can concentrate on figuring out how to implement the core behaviour, not the equivelent of the other implementation you wrote.

      For instance

      sub build_huffman_tree { my $input=shift; my %count; $count{$_}++ for split //,$input; my @list=map { [ $_, $count{$_} ] } keys %count; while (@list>1) { @list=sort {$a->[1] <=> $b->[1]} @list; my ($x,$y)=splice @list,0,2; push @list,[[$x,$y],$x->[1]+$y->[1]]; } return wantarray ? @list : $list[0]; }

      The equivelent code in almost any other language would be much larger, and would do no better, and IMO signifigantly worse at illustrating the ideas behind Huffman encoding. Optimising this so that it only calls sort once for instance only detract from the core idea of the algorithm.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi


        You are preaching to the choir here in terms of what to use in real-life projects. I was discussing not jumping to Perl in a datastructures class, where the goal is to attain the intracy and Zen. Ah well, we might as well agree that we aren't communicating on this point.

        An example I often feel held back in Perl is that only offers hashes, lists, and scalars. Yes, it has objects, but it lacks structures, and hence that keeps one from implementing many data structures in their natural form. I also find it's rather broken when implementing things that feel like tables. Why? Again, the lack of records and the need to use objects.

        The case for not having C-like structs is defintely an area where efficiency will burn you. While Huffman-trees, LZW encoding, and simple graphs can do nicely, you start to lose edge when passing lots of data around, and you also lose the grasp on having to "rewire" graphs due to the seeming niceness of memory management. Yeah, references and objects are ok, but still ugly and less pure, IMHO, especially when learning what a datastructures class is meant to teach you.

        So that's really the crux of it. Datastructures is in part about datastructures, but as a student of programming, it's also an EXCELLENT time to assess how well you can manipulate pointers. C is unforgiving, but that builds vast discipline. Screwing up and getting a seg fault builds programmer disciple far more than just getting a GIGO error. Sort of like how the appreciation assembler gave me for not confusing int 13h with int 33h (yes, kids, you can make your printer go haywire in the middle of the night while trying to code a silly maze program!).

        Keep in mind I am talking about *learning* and *datastructures*, not neccessarily *using* and *algorithms*.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://345235]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2014-12-26 07:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (168 votes), past polls