From: Robert Klemme <shortcutter@...>
Date: 2011-06-28T21:21:08+09:00
Subject: Re: How to order a hash based on its keys?

Hi,

unfortunately I don't have time to follow up in detail just now.

On Sat, Jun 25, 2011 at 7:31 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 2011/6/24 Robert Klemme <shortcutter@googlemail.com>:
>>> I was not able to do it with a loop, neither writing the algorithm in
>>> a paper, I always got bad statistical results.
>>
>> That was certainly not an effect of the recursion.  You probably
>> accidentally added another issue.
>
> Yes, and still I'm looking for the introduced bug :)

:-)

>>> Results:
>>> -------------------------------------------------------------------
>>> server-1:     50000         0         0       0         0
>>> server-2-A:         0  28488  16302  5210         0
>>> server-2-B:         0    7226  12245 30529        0
>>> server-2-C:         0  14286  21453 14261        0
>>> server-3:            0         0         0        0 50000
>>> ---------------------------------------------------------------------
>>
>> Would that be sufficient statistical enough for you?
>> https://gist.github.com/1040631
>
> Yes :)
>
> However, I've compared efficience (with 100.000 iterations):
>
> Mine:
> --------
> INFO: Time elapsed     : 0.9837 seconds
> INFO: Resolution speed : 101656.6751 resolutions/second
>
> Yours:
> ---------
> INFO: Time elapsed     : 2.5718 seconds
> INFO: Resolution speed : 38883.8211 resolutions/second
>
> :)
>
> Of course my code is much more ugly.

Can you post the exact testing code in a gist?

>>> Right. I'm trying to improve that. However take into account that my
>>> code does not need to create an instance. Instead it will be a class
>>> method (or a module method like DNS::srv_randomize), so I cannot use
>>> attributes (or I should not).
>>
>> Well, that's not exactly true: your code creates an Array (stored in
>> ordered_targets) so you could as well create another object.
>
> Yes, but it's just an Array allocation (using [] rather than
> Array.new, which is much faster).

Probably true.

>> Weight 0 generally means "do not use".  Basically you change the
>> algorithm to also include items whose weight is 0.  I am not sure I
>> would add that complexity.  If someone uses weight 0 then he may
>> actually do that on purpose.  If not then it's a bug and should be
>> flagged accordingly (e.g. by raising an exception).  Also: this will
>> also change weight of all other elements, because the probabilities
>> are skewed.  I'd rather provide proper weights as inputs and avoid
>> illegal weights.
>
> DNS SRV are explained in RFC 2782, and entries with weight 0 don't
> mean "do not use", but "rarely select it at the first choice":

Even then I would leave special treatment of this out of class
WorkQueue (in my code) because that is something specific to the use
case at hand.  I'd probably adjust weights before handing instances
over to the WorkQueue (e.g. multiply with 100 and set to 1 if still
0).

> http://tools.ietf.org/html/rfc2782:

> Note also that the selection mechanism is detalied in the last paragraph.

I'll leave that for later.

>>> Really thanks a lot for your interest. It's very helpful.
>>
>> Good!  These kinds of discussions are the ones I like being around.
>> Everybody learns something along the way.
>
> Sure ;)
>
> Thanks a lot again.

You're welcome!

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/