> paying' ads
> more show than 'low paying' (or free) ads.
> This is one idea:
> When this table is dumped into an application array, a position in the
> array is
> given for each ad for each dollar (or part) it has.
> .01 is 1 position.
> $1 is 1 position.
> $1.01 is 2 positions.
> This is rather simple and works well for small amounts of ads, but when
> you get
> a lot, it fails.
> ex: 99 ads at .01 and 1 ad at $5 will equal an array of 104 items. The big
> paying ad has a greater chance of being seen in relation to any other
> ad, but is
> buried under all the low paying ads.
A variation on this would be to have an array of structs like this:
ads[n] [min]
[max]
[ad_stuff]
Where min and max are the minimum and maximum values where your random
number will "hit" (for random number n, display this ad if min<=n<=max).
Then you can do a binary or smart search, which will be pretty fast.
Cache the result for 15 or 30 (or 5) seconds in the application scope,
and you'll avoid having to do the search (the slow bit) too often (just
a simple time compare).
> Another idea is to have sub arrays for each price grouping. In this
> example, the
> chances of a $5 text ad coming up is far greater than a $1 ad and if a
> $5 comes
> up, then it'll be one of several $5 ads. This may work and I'm building
> it now.
> Critique?
Without knowing how you plan on "weighting" the dollar values, I can't
comment too much.
However, you could do something similar to what I've listed above.
Another idea might be instead of min/max wieghting (by probability) you
create an actual hard number of displays per "cycle" where a cycle
includes all the assigned displays of all ads. That is, instead of a
min and max, you have a displaycount, and you decrement it every time
that ad is displayed. When it hits 0, remove the array row. When the
array is empty, refresh it.
--BenD
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
