a preferential semi-random sort

[witeowl]

OK, let's say that I have a list of 40 items with details (age, name, etc). I can sort them by a specific feature, like age, or I can randomize them. Here, though, is what I'd like to do: I'd like to semi-randomize them with a preference for putting those with a specific feature towards the top. I can see a couple ways to do this, but I'm hoping that someone out there has a brilliant idea they'll share.

Here are the approaches I have.

Approach 1:
- randomize the list
- look through the list line by line and move any item with x feature up a number of lines (probably a random number within a range)

Approach 2:
- sort the list by random
- sort the list by (has x feature) and (doesn't have x feature)
- look through the list line by line and do a soft shuffle by moving every item up or down a random number (within a range) of lines

That's all I've got. They both have their obvious disadvantages and would result in very different lists (the first may leave "preferred" individuals very close to the bottom, and the second would surely start with all preferred individuals before moving on). Of the two, I think I like the first better, simply because I plan on having users select up to two "prefer x" options.

Anyway, I'd love to hear your genius.

[dunbarx]

I am confused.

In your "semi-random" sort, does that mean that if, say, you sorted by name, and also by an age range above 50, that most of those above 50 would appear at the top, but that you still want to bury a few random unfortunate souls down at the bottom? When you sort by two criteria, are they both semi-random, or only one? Can you provide a short list with an example? Otherwise, your method of sprinkling within a random range near the top seems sound.

Or maybe someone else just gets it.

Craig Newman

[witeowl]

Yeah, I know I'm looking for something a bit odd, and I'm surely not explaining it well. Let's go with a list of 40 items. 10 of those meet the target criteria and the rest do not. I'd want the mix to look something like this (all else being random):

MEETS
no
MEETS
MEETS
no
no
MEETS
no
no
no
MEETS
no
MEETS
MEETS
no
no
no
MEETS
no
no
MEETS
no
no
no
no
MEETS
no
no
no
no
no
no
no
no
no
no
no
no
no
no

I want the other criteria (should someone select both criteria) to look similar. Those who meet both criteria may naturally fall even closer to the top, but I don't want that to happen intentionally. In other words, both over 50 and handsome shouldn't necessarily be preferred more than just 50 or just handsome, though it might happen that way as just a side effect. It wouldn't be a big deal if it did.

Thanks.

[dunbarx]

I see.

Is there a slightly higher density in the first 25% than in the second 25%?

Anyway, there are many ways to do this, all simple, all fun to write. The methods can vary all over the place. I tried a simple brute force way. With a field containing your data, in a button script put:

Code: Select all

on mouseup
   put fld "yourField" into temp
   sort temp
   get lineOffSet("bbb",temp)
   put line 1 to it of temp into pool
   put line (it + 1) to the number of lines of temp of temp into accum
   repeat with y = it down to 1
      put return & line y of pool after line random(10) of accum
      delete line y of pool 
   end repeat
   answer accum
end mouseup

Check out the scatter, and also see if the results go down far enough.

[witeowl]

Looks very interesting, thanks. I've been playing with sorting the haves and have-nots into bags and using a random number to determine whether to pull from the haves bag or the have-nots bag. But I like this and will play with this as well. Thanks.

On a side note, thanks also for teaching me something new (to me) and very useful: "down to". I have some old code to rewrite.

[dunbarx]

Hi.

"Down to" is an essential variation. When deleting lines from a list, as I did, the line order will fail almost immediately if you try to do it from the top down. The counter will crash into the updated data, and all heck will break loose. counting from the bottom always keeps the counter in sync with the remaining lines and their original order.

There are other instances where this is essential, and some where it is merely useful. But critical from a dynamically counted list that is being depleted.

Craig Newman

[witeowl]

No, I totally get what it was doing; that's why I was excited to learn of its existence. In the past, I created a second tIndex counter and manually did "subtract 1 from tIndex" in each loop repeat. Not horrible, but obviously unnecessary.