[pw/bug] Bestelkosten berekenen doet vreemd

[Mentalist]

Ik ben er vrij zeker van dat dit een bug is, maar heel misschien doe ik ook wel iets geks.

Ik heb een wenslijst met het volgende:

2x pricewatch: Corsair CMSO8GX3M1A1333C9
1x pricewatch: Crucial m4 CT064M4SSD2 64GB

Dan ga ik naar bestelkosten berekenen. Dan is dit mijn top 5 suggesties:

1* MyCom Score: 4 € 192,14
Toon prijslijst (overige winkels: Afuture)
2 Zercom Computers Score: 3.5 € 193,45
Toon prijslijst
1* Azerty Score: 4 € 193,67
Toon prijslijst (overige winkels: Dynabyte B.V.)
1 PIXmania.com Score: 3 € 194,13
Toon prijslijst (overige winkels: Afuture)
1* 4Launch Score: 4 € 194,95
Toon prijslijst (overige winkels: Afuture)

Een heel logische optie ontbreekt echter: alles bij afuture bestellen. Dat kost maar één cent extra vergeleken met de eerste optie waarbij de SSD van MyCom komt en het geheugen van afuture.

Zet ik "Maximum aantal shops" op 1 en druk nogmaals op bereken, dan krijg ik de afuture optie wèl. Zet ik "Maximum aantal shops" hierna weer op 4 (of 2, of 3..), dan krijg ik weer dezelfde lijst met voor alles maximaal 1 shop. De opties met meerdere shops zijn uit de lijst verdwenen.

[ACM]

't Feit dat Afuture in eerste instantie niet verschijnt is geen bug. Maar wellicht wel wat onduidelijk gedrag

Daar is het blijkbaar zo dat de goedkoopste mogelijkheid voor Afuture is om een van de producten bij Afuture te halen en de andere bij MyCom. Maar dat is uiteraard precies dezelfde combinatie als die er al staat voor MyCom.

Dat daarna bij het terugzetten van 'Maximum aantal shops' het gedrag lijkt te veranderen komt omdat door die eerst op 1 te zetten, daardoor ook de optie 'Minimum aantal producten eerste shop' automatisch op 2 werd gezet. En toen je daarna die andere optie weer op 2/3/4 zette, werd dat niet meer automatisch teruggezet.

Kortom, het is allemaal precies zoals ik de boel ooit bedoeld had, maar komt uiteraard in dit geval vrij ongunstig uit omdat de Afuture-optie an sich best een interessante is. Maar de goedkoopste mogelijkheid met Afuture stond er al bij bij MyCom, waardoor heel Afuture nu uit de zichtbare combinaties viel.

't Is uiteraard wel een enorm randgeval, als de prijs van MyCom 1 cent hoger of Afuture 1 cent lager was geweest, had die "alles bij Afuture"-optie er wel bijgestaan. Helaas is het niet heel triviaal hier wat aan te doen, ik zit ook niet meer goed genoeg in die code om zo uit mijn hoofd te kunnen zeggen of we wel weten welke andere combinaties van die winkels er zijn.

Als dat wel zo is, zouden we uiteraard de eerstvolgende combinatie neer kunnen zetten als blijkt dat de voorste(n) al via andere winkels getoond zijn. Maar dat heeft wel tot gevolg dat dan eventueel ook de MyCom-variant als Afuture-variant zou worden getoond en daarna een duurdere MyCom-variant verschijnt (hoewel ze waarschijnlijk op shopid gesorteerd zijn, dus MyCom komt dan in dit specifieke geval eerst).

[Mentalist]

ACM schreef op vrijdag 17 februari 2012 @ 08:05:
't Feit dat Afuture in eerste instantie niet verschijnt is geen bug. Maar wellicht wel wat onduidelijk gedrag

Daar is het blijkbaar zo dat de goedkoopste mogelijkheid voor Afuture is om een van de producten bij Afuture te halen en de andere bij MyCom. Maar dat is uiteraard precies dezelfde combinatie als die er al staat voor MyCom.

Ah, nu begrijp ik de gedachte.

Alleen, alles bij afuture kopen vs. afuture+mycom zijn naar mijn mening wel significant verschillende opties.

Ik krijg ook (veel) duurdere opties van andere shops te zien, dus het lijkt me dan eigenlijk wel gewenst om ook de prijzen van een kleiner aantal shops in dezelfde lijst ertussen te zetten.

Ik denk dat ik namelijk niet de enige ben die liever bij 1 winkel ipv. 2 koopt (of 2 ipv. 3, etc) wanneer het verschil bijvoorbeeld maar een eurootje is. In dit geval is het zelfs maar een cent. Daarvoor doe ik de moeite van een extra iDeal-betaling niet eens.

Plus het is gewoon minder gedoe om meer bij dezelfde shop te bestellen. Als de verschillen oplopen ga ik natuurlijk wel spreiden, en juist voor dat verschil is de "bestelkosten berekenen" optie handig.

Dan kan ik natuurlijk het "maximum aantal shops" aanpassen, maar dan moet ik 4 lijsten (1 shop, 2 shops, 3 shops, 4 shops) onthouden en met elkaar vergelijken, wat niet handig is. En ik wil best bij meerdere shops bestellen, maar alleen als het prijsverschil de moeite is.

Dat daarna bij het terugzetten van 'Maximum aantal shops' het gedrag lijkt te veranderen komt omdat door die eerst op 1 te zetten, daardoor ook de optie 'Minimum aantal producten eerste shop' automatisch op 2 werd gezet. En toen je daarna die andere optie weer op 2/3/4 zette, werd dat niet meer automatisch teruggezet.

Zou het dan niet handig zijn om die optie niet automatisch op 2 te zetten in de eerste plaats? Het was voor mij iig totaal niet duidelijk. Als ik één optie verander verwacht ik eigenlijk niet dat andere opties automagisch meeveranderen.

[ACM]

W3ird_N3rd schreef op donderdag 23 februari 2012 @ 01:05:
Ik denk dat ik namelijk niet de enige bent die liever bij 1 winkel ipv. 2 koopt (of 2 ipv. 3, etc)

Dat is sowieso al het uitgangspunt van het systeem. Maar de huidige code is niet in staat daadwerkelijk beslissingen te nemen en/of voorbeeldmandjes te vergelijken anders dan op prijs. 't Enige wat ie doet is per winkel de goedkoopste combinatie van productaanschaffingen per (deel)winkelmandje te berekenen binnen de gegeven randvoorwaarden; dus maximaal bij 2 winkels zo goedkoop mogelijk.
En daarbij berekent ie voor elke winkel die uberhaupt (een deel van) de gewenste producten kan leveren de goedkoopste mix, waarbij de code niet in staat is te kijken naar andere winkel-combinaties en/of naar combinaties die wellicht iets duurder zijn maar "gunstiger".
Zodra ieder van die goedkoopste mixes per winkel is bepaald worden ze op een hoop geveegd en teruggegeven naar de gebruiker; en daarbij valt dus dan die dubbele combinatie (winkel A + B vs winkel B + A) weg.

En ik wil best bij meerdere shops bestellen, maar alleen als het prijsverschil de moeite is.

Wellicht kunnen we die notie ook nog als variabele toevoegen, dat je dus kan opgeven hoeveel extra het goedkoper moet zijn voor je de moeite neemt om bij twee winkels te bestellen. Ik gok dat een bedrag van ergens tussen de 1 en 5% de moeite waard begint te worden.

Zou het dan niet handig zijn om die optie niet automatisch op 2 te zetten in de eerste plaats? Het was voor mij iig totaal niet duidelijk. Als ik één optie verander verwacht ik eigenlijk niet dat andere opties automagisch meeveranderen.

Mja, hij wordt daar alleen maar opgezet omdat het onmogelijk is om met minder dan 2 producten voor de eerste winkel bij in totaal 1 winkel 2 producten te kopen In dit geval lijkt het wat zinloos, maar het is ook een bescherming om het algoritme niet te veel werk te laten doen, voor grotere aantallen producten neemt de rekentijd namelijk significant toe naarmate die parameter ruimer ingesteld wordt.

[Mentalist]

ACM schreef op donderdag 23 februari 2012 @ 08:13:
[...]

Dat is sowieso al het uitgangspunt van het systeem. Maar de huidige code is niet in staat daadwerkelijk beslissingen te nemen en/of voorbeeldmandjes te vergelijken anders dan op prijs. 't Enige wat ie doet is per winkel de goedkoopste combinatie van productaanschaffingen per (deel)winkelmandje te berekenen binnen de gegeven randvoorwaarden; dus maximaal bij 2 winkels zo goedkoop mogelijk.
En daarbij berekent ie voor elke winkel die uberhaupt (een deel van) de gewenste producten kan leveren de goedkoopste mix, waarbij de code niet in staat is te kijken naar andere winkel-combinaties en/of naar combinaties die wellicht iets duurder zijn maar "gunstiger".
Zodra ieder van die goedkoopste mixes per winkel is bepaald worden ze op een hoop geveegd en teruggegeven naar de gebruiker; en daarbij valt dus dan die dubbele combinatie (winkel A + B vs winkel B + A) weg.

Ah, technisch dingetje dus.

Technisch gezien is de oplossing dan om de hele rekensom met het maximaal aantal shops op zowel 1, 2, 3 als 4 te draaien en daarna de dubbele weer weg te gooien. Maar dat zal (gok ik) een behoorlijke extra load opleveren dus begrijp dan ook wel weer dat dat niet zo aantrekkelijk is.

[...]

Wellicht kunnen we die notie ook nog als variabele toevoegen, dat je dus kan opgeven hoeveel extra het goedkoper moet zijn voor je de moeite neemt om bij twee winkels te bestellen. Ik gok dat een bedrag van ergens tussen de 1 en 5% de moeite waard begint te worden.

Dat zou handig zijn idd.

[...]

Mja, hij wordt daar alleen maar opgezet omdat het onmogelijk is om met minder dan 2 producten voor de eerste winkel bij in totaal 1 winkel 2 producten te kopen In dit geval lijkt het wat zinloos, maar het is ook een bescherming om het algoritme niet te veel werk te laten doen, voor grotere aantallen producten neemt de rekentijd namelijk significant toe naarmate die parameter ruimer ingesteld wordt.

Ideetje: op de server alleen die efficiente waarde gebruiken, maar in het form gewoon weer de oude instelling teruggeven. Dan gebruik je intern wel die waarde maar hoef je de instelling die de user in het form ziet niet te veranderen. Het heeft toch geen invloed op het eindresultaat.