Add unassigned localities to best adjacent group

[remidelattre]

As per #18, an inner loop could improve coverage and work within the context of grouping for values other than 0.

• LOOP U over unassigned localities
  • LOOP A over adjacent assigned localities to U
    • Add U to adjacent group that moves the de sum of the group the least distance away from target sum

[JamesBremner]

Average locality deficit -3.68182

Sum -22 to -18, Min. Size 5

946 of 946 localities assigned to 63 groups.

Group size: min 5 av 6.34921 max 15 Group deficit: min -22.3703 av -20.289 max -18.1042

============
84018 -3.020023941 84079 1.108881531 84075 -0.549648069 84072 -6.595199808 84070 -10.40870801 84066 -4.064215212 84150 1.158613508 sum -22.3703
============
04004 -4.701654056 04166 -6.165652354 04230 28.82751951 04189 -1.933016885 04143 -0.90772212 04094 -33.84247635 sum -18.723
============
04124 2.436997072 04157 -7.059854713 04172 -1.435391592 83014 -9.015429534 04176 -2.166478961 83015 -1.734889031 sum -18.975

...

[JamesBremner]

v0.1.0

[JamesBremner]

Updated the algorithm description https://github.com/JamesBremner/so77307162#algorithm

[remidelattre]

This is impressive, you've managed to group every locality ! Can't wait to test this when I get a chance. Thank you :)

[remidelattre]

If you were to try the following parameters : Range -150 to -118 Min. group size 20 How would you input the parameters ? I've been trying this but it crashes.

[JamesBremner]

The range is input using deltas ( as the prompts say, and the same as it was in v0.0 ) not the absolute values.

So:

-118 -32 1

[remidelattre]

Strange, inputting those will crash the app, with min. group size 20. Would copy console but it closed too.

[JamesBremner]

A group size of 20 is bad idea. You will get poor initial coverage, so the adding of unassigned localities will not work very well.

Remember this:

If you have found some input that crashes the application you should open a bug issue.

[remidelattre]

I see. I'm inputting those values because I can compare them to results produced by SA.

[JamesBremner]

I suggest you compare the results from a run with the optimum parameters. Comparing the results of a run using parameters that you know give poor results is hardly a fair comparison.

[remidelattre]

SA is so slow I only have data for specific ranges and values. I thought a fair comparison would be to input the exact same parameters in both apps to see which yields the best coverage.

[JamesBremner]

The algorithms work quite differently. So, naturally, they do best with with different parameters.

[JamesBremner]

A parameter is a way of tuning an algorithm to produce the result that you want. It is not a wish that the algorithm will respect and obey, magically producing the result you want merely because you asked nicely.

This is one of the reasons that time is always an issue when designing algorithms. The algorithm must run fast enough that you can run it multiple times with different parameters to find the optimal combination. If you cannot produce a graph like this

then you will never be able to get the best out of your algorithm

[remidelattre]

Yeah, we'll produce a graph like this eventually. We're storing data for both programs and I will organize it. We have a few months, and it takes about 4 days to get the best out of one SA test. Thank you for the suggestion !

Another idea I have is to make a dynamic map illustrating how the algorithm works overtime !

[remidelattre]

Closing this one as I've got the chance to test it with the latest version :)