in reply to RFC - Tie::Hash::Ranked

With the exception of Get_Rank, your new functionality is just implementing order statistics on top of Tie::Hash::Sorted. If one has access to the sorted array, it would seem easier to me to extract the elements directly than download another module, install it, and figure out the API.

But having the functions within the module already would tip the convienence factor the other way. So I would be in favor of including them in your current API for Tie::Hash::Sorted. I expect the methods would be simple to implement and would result in little code bloat.

If you do choose to breakout into a new module, I would recommend a more expressive name like Tie::Hash::RankStatistics. <update> In the area of new methods, I think a median method would be useful: return the middle element, with a well-defined convention for even numbers of hash elements.

-Mark

Replies are listed 'Best First'.
Re^2: RFC - Tie::Hash::Ranked
by Limbic~Region (Chancellor) on Oct 12, 2004 at 15:47 UTC
    kvale,
    is just implementing order statistics on top of

    I am not sure I have described the methods properly nor am I opposed to just adding the functionality to Tie::Hash::Sorted. The rationale for breaking them out is because they would dramatically change the way the hash behaved. Basically it would only be giving you a window of the hash. So if the hash had 50 keys but you had set Top_X to 10, looping over the keys of the hash would only loop 10 times. Additionally, having direct access to the underlying array will give wrong unexpected results. This is due to the way the optimizations have been added in. Resorting (and hence array creation) is only done when necessary.

    Thanks for the idea about a median method. I am not sure about the name suggestion since I think we may be talking past each other.

    Cheers - L~R

[reply]

In Section Meditations