banner rotatie (logaritmisch afnemend)

[killercow]

Ik ben m'n banner roulatie scriptjes nog wat aan het optimaliseren, en ben ook wat andere opties aan uitvogelen.

Mijn probleem is als volgt.

Ik heb een lijstje banners.
Deze banners worden omstebeurt op een locatie getoond.
Nu hebben de banners een prioriteit. De banner met de hoogste prio (0) krijgt meer views dan de banners met de laagste prio bijvoorbeeld (4)

Het aantal banners in een pool kan vreselijk verschillen. meestal is het er maar een, maar soms zijn het er 30.

Het aantal impressies dat granted is, is natuurlijk afhankelijk van het totaal aantal reeds gegeven impressies.

Stel dat er 100 impressies te verdelen zijn, dan wil ik bijvoorbeeld logaritmisch de bovenste 90, de 2e 9, de 3e .9 views geven.

Nu moet het logaritmische getal aanpasbaar zijn. Log10 is leuk, maar niet echt nuttig, het verschil is VEEL te groot tussen de eerste en laatste.

Omdat het met decimale log getallen allemaal wel heel erg veel floating point getallen op gaat leveren is het niet echt een optie om "gewoon" decimale machten enzo te gaan gebruiken.

Zijn er andere wiskundige functies (die snel in sql gevoerd kunnen worden) die beter te versprijden zijn, en die minder fp berekeningen uitlokken?

Ik heb al even rond zitten neuzen naar hyperbole functies, maar die zijn ook kanp zwaar.

[WEBsel]

Anders gebruik je e (~ 2,71), dat schijnt wel een natuurlijke waarde te zijn.

[Infinitive]

Kan je de reeks niet van te voren uitrekenen, dan lijkt me performance niet zo'n probleem?

[Verwijderd]

killercow schreef op dinsdag 18 juli 2006 @ 12:05:

Kun je niet een extra veld toevoegen en die als waarde gebruiken?
30 banners. (bijvoorbeeld schaal (30x10= 300)

banner1 - 270 (=90% kans)
banner2 - 280 (=3,33% kans)
banner 3 - 285 (=1,6% kans)
etc.

en dan met een simpele sql en between en rnd ofzo de juiste banner te voorschijn halen.
Alleen bij het toevoegen/updaten/verwijderen van je banners moet je iets slims bedenken.

[ Voor 7% gewijzigd door Verwijderd op 18-07-2006 17:51 ]

[Pyrus]

en anders van logaritmische rekenregels gebruik maken, als je met een willekeurige macht wil werken:
^xlog(y) = ^zlog(y)/^zlog(x)

[killercow]

Zal eens even testen wat dit terug geeft.

Het lastigste is dat het aantal views wat een banner moet krijgen dus afhankelijk is A, de locatie/prioriteit in de lijst, en B het totaal aantal views wat er geweest is.

Bij 1 view, moet alleen de banner met de hoogste pri banner een view krijgen, maar zodra hij over 10 views totaal komt, springt komt de 2e banner ook aan op 1 view. welke hij dan dus krijgt.

Als het aantal reeds gegeven views van het aantal aangewezen views aftrekt kunt je zo dus zien welke banner er een view nodig heeft.

Probleem is dus dat dit voor alle banners in de pool ELKE view gedaan moet worden. (en dus zwaar is, en dus het liefst alleen met INts mag rekenen)

[Verwijderd]

Waarom doe je het niet probabilistisch?

Geef elke banner een bepaald kanspercentage om te verschijnen (bij 4 banners bijvoorbeeld 70, 20, 8, 2, of wat jij wilt).

Als er een banner getoond moet worden genereer je een willekeurig getal tussen 0 en 100 en kiest de bijbehorende banner.

Het is eenvoudig, snel te berekenen (percentages en ranges kunnen voorgecalculeerd worden), en bij grote aantallen pageviews is het resultaat nagenoeg niet te onderscheiden van view-voor-view de banner berekenen.

[Verwijderd]

Verwijderd schreef op dinsdag 18 juli 2006 @ 14:57:
Waarom doe je het niet probabilistisch?

Idd, zoiets bedoelde ik ook. Alleen moet je de kansen cumulatief opslaan, omdat je anders meerdere banners als resultaat zou kunnen krijgen.

[RobIII]

Verwijderd schreef op dinsdag 18 juli 2006 @ 17:54:
... omdat je anders meerdere banners als resultaat zou kunnen krijgen.

edit:
euh... hier stond onzin.

^ Het moet inderdaad "cumulatief" opgeslagen worden, maar dat is alles.

Tabelletje voor de banners:

SQL:

CREATE TABLE [dbo].[banner] (
    [id] [int] IDENTITY (1, 1) NOT NULL PRIMARY KEY,
    [campaign] [int] NOT NULL ,
    [image] [varchar] (50) NOT NULL ,
    [probability] [int] NOT NULL 
)

Dan een indexje op campaign en "probability" gooien...die hebben we straks wel nodig...

SQL:

CREATE  INDEX [IX_banner] ON [dbo].[banner]([campaign], [probability]) 

De query:

SQL:

SELECT TOP 1 banner.id, banner.image
FROM banner
WHERE banner.campaign = 1
    AND banner.probability >= rand()*100
ORDER BY banner.probability

Dan tabelletje vullen:

ID	Campaign	Image	Probability
1	1	Campaign1BannerA.gif	2
2	1	Campaign1BannerB.gif	10
3	1	Campaign1BannerC.gif	90
4	1	Campaign1BannerD.gif	100
5	2	Campaign2BannerA.gif	10
6	2	Campaign2BannerB.gif	100

Geeft volgens mij 2% kans op BannerA, 8% (10-2) kans op BannerB, 80% (90-10) kans op BannerC en 10% (100-90) kans op BannerD (voor Campagne 1).

Voor campagne 2 geldt dat je 10% kans hebt op A en 90% (100-10) op B.

Het veldje "probability" is qua naam wellicht wat ongelukkig gekozen, want dat is de "kans-vorig record" ofzo
Uiteraard kun je van dit veldje ook een float maken. Dat scheelt weer een cast op je rand en dan kun je je "probability" uitdrukken op een schaal van 0 tot 1 i.p.v. 0 tot 100 Stom natuurlijk, waarom zou je uberhaupt casten. >= 73 werkt even goed als >= 73.4727826

Vind 'm eig'k wel creatief

Dan nog iets met aantal views eromheen knutselen et voila.

[ Voor 187% gewijzigd door RobIII op 18-07-2006 18:57 ]

[killercow]

Lol

Dat was nou precies wat ik ook bedacht had vanmiddag.

In plaats van de "positie" in de lijst op te slaan, sla ik gewoon 2 getallen op, een boven en ondergrens.

tussen de 0 en 100 bereken ik dan een random getal, en pik de banner waarvan de boven en ondergrens om het getrokken getal staan eruit.

De getallen zijn natuurlijk prima logarithmisch te berekenen.

Thanks allemaal, vaak helpt hem om gewoon een en anders uit te leggen aan je zelf en anderen, en dan komt iedereen eigenlijk op t zelfde idee.

Het aantal views wordt volledig irrelevant, als het maar random genoeg is. Statistisch gezien zou elke banner genoeg views moeten krijgen, en anders, tjah pech, moeten ze zelf maar een server komen brengen die al die logs gaat uitrekenen elke view.

[RobIII]

killercow schreef op dinsdag 18 juli 2006 @ 20:29:
In plaats van de "positie" in de lijst op te slaan, sla ik gewoon 2 getallen op, een boven en ondergrens.

1 getal is voldoende (zie voorbeeld)

[killercow]

RobIII schreef op dinsdag 18 juli 2006 @ 21:52:
[...]

1 getal is voldoende (zie voorbeeld)

I know,
Ik ga ff testen wat er sneller is, 2 losse indices, of inderdaad eentje met een sort. (zal wel van m'n db afhangen, veel banners per pool = waarschijnlijk 2 banners, 1 banner per pool, 1 index)