Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: A mini-language for sequences (part 1)

by dragonchild (Archbishop)
on Nov 05, 2004 at 18:41 UTC ( #405580=note: print w/replies, xml ) Need Help??


in reply to A mini-language for sequences (part 1)

If something like this isn't on CPAN, you should seriously consider putting it on there, along with this meditation as the POD. Excellent work! ++

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

  • Comment on Re: A mini-language for sequences (part 1)

Replies are listed 'Best First'.
Re^2: A mini-language for sequences (part 1)
by stvn (Monsignor) on Nov 05, 2004 at 19:00 UTC
    If something like this isn't on CPAN, you should seriously consider putting it on there

    I second that, although I would suggest better naming conventions. I am not a fan of abbreviations, and especially ones that are so similar and potentially confusing to the eye (i.e. - seq, spec).

    -stvn
Re^2: A mini-language for sequences (part 1)
by brian_d_foy (Abbot) on Nov 19, 2004 at 18:09 UTC

    CPAN already has Set::CrossProduct, Object::Iterate, and Tie::Cycle. I think those three modules cover just about everything discussed in the node, and anything they don't I can add.

    --
    brian d foy <bdfoy@cpan.org>
      brian, thanks for the pointers!
      CPAN already has Set::CrossProduct, Object::Iterate, and Tie::Cycle. I think those three modules cover just about everything discussed in the node, and anything they don't I can add.
      While the overlap of my meditation's sequences and your modules is large, I would like to point out some philosophical differences between our approaches. (These aren't pros or cons – just differences.)
      1. The sets that sequences represent are implicit. This lets them be defined on the fly so that, for example, you can efficiently take the Cartesian products of arbitrary sequences (that themselves may the products of sequences). This also lets you work (space efficiently) with sequences whose lengths cannot be known until they are exhausted. However, the lengths of sequences cannot be known until they are exhausted.
      2. You can observe the cyclical wrap-around point of a sequence. This lets the wrap-around be used as a trigger for other events, such as terminating a parallel merge operation or advancing the next most-significant sequence in a series of sequences.
      3. I think that it's easier to build up a chain of operations with sequences than with the collection of CPAN modules. For example, it seems like you must forego the space-saving benefits of iterators to take the product of an earlier product, which discourages the use of products in computational chains.
      4. Nevertheless, I think that the CPAN modules are probably more practical for the functionality where our libraries overlap. My sequences are first and foremost meditative material. In their present form, they aren't suited for production use.
      If you're looking to add features, it would be nice if Set::CrossProduct could take the product of arbitrary iterators.   :)

      Cheers,
      Tom

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (3)
As of 2019-09-15 10:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The room is dark, and your next move is ...












    Results (180 votes). Check out past polls.

    Notices?