[pricewatch] winkelmandje niet zo slim...

[_Thanatos_]

Ik heb nu aan stel producten in m'n mandje liggen, 7 om precies te zijn. Maar als ik de bestelkosten laat berekenen, dan gebeurd dat eigenlijk op de minst slimme manier als je het mij vraagt. Wat het ding lijkt te doen is, hij kijkt van ieder product afzonderlijk waar het het goedkoopste is en telt daarvan de prijs+verzendkosten bij het totaal op.

Wat ik liever zou zien is dat ie ook kijkt naar de verzendkosten. Stel ik heb product A - €150 met €10 verzendkosten. Dan product B van €100 en €7,50 verzendkosten. Het winkelmandje houdt gewoon deze waarden aan, zelfs als product B bij de leverancier van product A gekocht kan worden, voor €105. Dat zou immers goedkoper zijn.

Het komt er dus op neer dat je nog steeds zelf moet gaan uitvogelen wat waar nog goedkoper is, rekening houdend met de verzendkosten. Zo kwam mijn setje dus volgens de PW uit op €995, terwijl met wat schuiven met leveranciers, ik uitkwam op €971,50.

Ik hoop dat het een beetje duidelijk is

[dawuss]

Hier is al eens eerder over gediscussieerd. Het kan inderdaad veel slimmer, maar dan moet het met brute-force en dat trekt te zwaar op de servers.

[Eskimootje]

Programmeer technisch is het niet op te lossen dwz. all1 maar brute force alle mogelijkheden uitproberen zou de beste oplossing tot gevolg hebben en dat kost te veel CPU tijd. Je zult het dus idd zelf moeten controleren, helaas. Volgens mij kan het winkelmandje wel enkele opties aangeven of heb ik dat maar gedroomd

[Hielko]

Het zou misschien ook wel client-side met javascript kunnen, maar misschien dat een devver daar wat nuttigers over kan zeggen

[Femme]

Het winkelmandje houdt wel degelijk rekening met verzendkosten.

[dawuss]

Hielko schreef op 11 May 2003 @ 16:24:
Het zou misschien ook wel client-side met javascript kunnen, maar misschien dat een devver daar wat nuttigers over kan zeggen

daar had ik nog niet eens over nagedacht

Moet dan wel uit te zetten zijn voor trage pc's.

[_Thanatos_]

Brute force lijkt me wat overdreven, je hoeft immers enkel de producten in het wineklmandje te controleren tegen de leveranciers in het winkelmandje. Dus in mijn geval 49 combinaties maximaal en gemiddeld dus 25 combinaties bij 7 producten.

Femme: niet hoe ik het uitgelegd heb dus

[Verwijderd]

Femme schreef op 11 mei 2003 @ 16:29:
Het winkelmandje houdt wel degelijk rekening met verzendkosten.

TS bedoelt dat als er 2 artikelen zijn, en leverancier A het ene artikel goedkoper heeft, en B het andere, dat het soms toch voordeliger kan zijn om beide producten bij dezelfde leverancier te bestellen, om zo te besparen op verzendkosten.

Basically komt het erop neer dat je bij het vergelijken van prijzen niet meer de bezorgkosten moet meerekenen als de leverancier al eerder in het boodschappenlijstje stond.

Maar voor het beste resultaat moet je dan ook nog eens uitgaan van elk van de leveranciers, en elk van de producten, en dus moeten de berekeningen meerdere keren uitbevoerd worden.
En dan nog kan het voorkomen dat een leverancier die van geen enkel product de laagste prijs had, en toch het goedkoopst kan zijn doordat deze (vrijwel) alle producten kan leveren.

Maar er is dus wel degelijk een behoorlijk aantal berekeningen nodig om de laagste prijs te kunnen garanderen. De vraag is of het de moeite waard is om zoiets te gaan programmeren.

[T.T.]

Maar er is dus wel degelijk een behoorlijk aantal berekeningen nodig om de laagste prijs te kunnen garanderen. De vraag is of het de moeite waard is om zoiets te gaan programmeren.

Je kan het altijd in /14 vragen of iemand java(script) oplossing ervoor wil maken. Als het goed werkt, wordt de pricewatch nog een stuk krachtiger. Je geeft dan alleen maar op welke onderdelen je wilt en je bent klaar

[Eskimootje]

_Thanatos_ schreef op 11 May 2003 @ 16:31:
Brute force lijkt me wat overdreven, je hoeft immers enkel de producten in het wineklmandje te controleren tegen de leveranciers in het winkelmandje. Dus in mijn geval 49 combinaties maximaal en gemiddeld dus 25 combinaties bij 7 producten.

Femme: niet hoe ik het uitgelegd heb dus

Ok je hebt 9 produkten allen bij 9 verschillende winkels te koop dan heb je
9*8*7*6*5*4*3*2*1 mogelijkheden veel plezier met rekenen (362880) komt er 1 produkt bij zit je al op 10 keer zoveel oftewel neit te doen.

[Sybr_E-N]

T.T. schreef op 11 May 2003 @ 16:50:
[...]

Je kan het altijd in /14 vragen of iemand java(script) oplossing ervoor wil maken. Als het goed werkt, wordt de pricewatch nog een stuk krachtiger. Je geeft dan alleen maar op welke onderdelen je wilt en je bent klaar

Voor de duidelijkheid: Java hoort in /14, en JavaScript hoort in /13.

[Hielko]

Het probleem is vast wel efficienter op te lossen door gebruik te maken van een wat slimmer algoritme. En als je dit clientside laat doen dan is het ook niet zo erg als het wat tijd kost, in een paar seconden kan je heel wat vergelijkingen doen op een 3GHz Pentium 4

De vraag is alleen hoe goed het client side is aan te pakken aangezien je natuurlijk niet elke keer de complete pricewatch database naar de client kan sturen.

[odysseus]

Hielko schreef op 11 May 2003 @ 16:59:
Het probleem is vast wel efficienter op te lossen door gebruik te maken van een wat slimmer algoritme. En als je dit clientside laat doen dan is het ook niet zo erg als het wat tijd kost, in een paar seconden kan je heel wat vergelijkingen doen op een 3GHz Pentium 4

De vraag is alleen hoe goed het client side is aan te pakken aangezien je natuurlijk niet elke keer de complete pricewatch database naar de client kan sturen.

In eerste instantie heb je genoeg aan de lijst met producten in combinatie met de lijst met winkels die aan die producten gekoppeld zijn. Als je die gegevens hebt kun je heel eenvoudig alle mogelijke combinaties gaan uitrekenen.

* odysseus zou daar wel een browser met een efficiënte javascript-implementatie voor gebruiken...dat kan ook nogal schelen in snelheid .

[Wouter Tinus]

Verwijderd schreef op 11 May 2003 @ 16:40:TS bedoelt dat als er 2 artikelen zijn, en leverancier A het ene artikel goedkoper heeft, en B het andere, dat het soms toch voordeliger kan zijn om beide producten bij dezelfde leverancier te bestellen, om zo te besparen op verzendkosten.

Basically komt het erop neer dat je bij het vergelijken van prijzen niet meer de bezorgkosten moet meerekenen als de leverancier al eerder in het boodschappenlijstje stond.

Maar voor het beste resultaat moet je dan ook nog eens uitgaan van elk van de leveranciers, en elk van de producten, en dus moeten de berekeningen meerdere keren uitbevoerd worden.
En dan nog kan het voorkomen dat een leverancier die van geen enkel product de laagste prijs had, en toch het goedkoopst kan zijn doordat deze (vrijwel) alle producten kan leveren.

Maar er is dus wel degelijk een behoorlijk aantal berekeningen nodig om de laagste prijs te kunnen garanderen. De vraag is of het de moeite waard is om zoiets te gaan programmeren.

En denk je dat Femme niet kan lezen ofzo? Er wordt wel degelijk rekening gehouden met het feit dat de verzendkosten niet meer meegeteld hoeven worden als er al een ander product bij die leverancier is gekozen. Het enige waar nog een beetje mee getweaked kan worden is welke leverancier als "basis" wordt genomen (standaard degene met de meeste producten in het assoriment), maar om voor dat miezerige bedrag een 10 keer zo grote serverload te gaan veroorzaken is niet de moeite waard. In de vorige thread hierover gaf de pricewatch 2247 euro als prijs en bleek het met handmatige tweaks terug te brengen tot 2242, 0,2% besparing, jeuh .

Zie deze thread: [rml][ suggestie] uitbreiding op pricewatch[/rml]

[ Voor 10% gewijzigd door Wouter Tinus op 11-05-2003 19:35 ]