Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^6: Better mousetrap (getting top N values from list X)

by BrowserUk (Patriarch)
on Feb 04, 2005 at 00:04 UTC ( #427875=note: print w/replies, xml ) Need Help??


in reply to Re^5: Better mousetrap (getting top N values from list X)
in thread Better mousetrap (getting top N values from list X)

Okay. I see what you are saying now. The slice across the return from sort generates a lazy list.

So the code:

my @data = getdata( 100000 ); my @topN = ( sort( @data ) )[ 1 .. 10 ]; undef( @data ); for my $top ( @topN ) { ## << COrrect per 427878 ## do something with $top }

Passes the whole list of data to sort, (which takes a copy of it in case we modify or discard it) and returns an iterator which gets bound to @top, so that each time we access the next element of @top in the for loop, the iterator is called via the magic of tieing, and the copy of the 100,000 elements that we passed to sort gets scanned to produce the next of our 5 return values.

Lazy huh?!


Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^7: Better mousetrap (getting top N values from list X)
by sleepingsquirrel (Hermit) on Feb 04, 2005 at 00:15 UTC
    Essentially. Although I think you probably meant...
    for my $top ( @topN ) { ## do something with $top }


    -- All code is 100% tested and functional unless otherwise noted.

      Corrected. Thanks.

      You do see the contradiction though?

      For an algorithm that produces a subset m of a set N, duplicating N so that you can produce the subset lazily always consumes more storage--not to mention the overhead of tieing the iterator, retaining it's state etc.

      <soapbox>

      That's one of my bug bears with FP. They claim it produces proveably correct code by avoiding side effects, or putting things into variables and so forth, but what they gloss over is that you still retain state, you just put it all on the either the program stack or continuation stack or some other internal stack where the programmer cannot see it, or test it or verify it. Or control it.

      Until they find a way to prove that the FP interpreter or compiler (usually written in C!) cannot corrupt it's own stack, every other claim of proveability is built on sand.

      </soapbox>


      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
        Until they find a way to prove that the FP interpreter or compiler (usually written in C!) cannot corrupt it's own stack, every other claim of proveability is built on sand.
        Sure, if the compiler has a bug, you're screwed. But how is that any different than the non FP case? It would be heaven-on-earth if we only had to worry about compiler bugs. Just compare how many bugs you find in you're own code, versus bugs in perl. There's a good reason why there are fewer bugs in a compiler than other code written in that language. Because more people use the compiler in more different ways. And most FP compilers (common lisps, haskell, ocaml, etc.) are self-hosted if for no other reason then it shows the compilier writers are willing to eat their own dog food.


        -- All code is 100% tested and functional unless otherwise noted.
          A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2022-10-07 10:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My preferred way to holiday/vacation is:











    Results (29 votes). Check out past polls.

    Notices?