- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- Gurulunk, WAZE?!
- Argos: Szeretem az ecetfát
- Brogyi: CTEK akkumulátor töltő és másolatai
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Parci: Milyen mosógépet vegyek?
Új hozzászólás Aktív témák
-
-
cucka
addikt
válasz
bobace
#11982
üzenetére
A mohó algoritmusok úgy működnek, hogy minden egyes iterációban a lokális optimumot választják.
Például ha az a célod, hogy a legrégebbi számlákat kell kiegyenlíteni, akkor a mohó algoritmus minden egyes lépésben kiválasztja a legrégebbi számlát, amit ki tud egyenlíteni (ez a lokális optimum) a meglévő keretből és kiegyenlíti. Elég könnyű belátni, hogy így a végén is optimumhoz jutunk.
Ha viszont az a célod, hogy a lehető legnagyobb összeget kel kiegyenlíteni, akkor a mohó algoritmus minden egyes lépésben kiválasztja a legnagyobb összegű számlát, amit ki tud egyenlíteni (ez a lokális optimum) a meglévő keretből. Szintén elég könnyű belátni, hogy ez összességében nem fog optimális eredményhez vezetni.
Pl. ha a számláid összege 80, 40, 50 és a rendelkezésre álló pénz 100, akkor a mohó algoritmus kiegyenlíti a 80-as számlát és megáll, miközben az optimális a 40 és 50 kiegyenlítése lenne. -
cucka
addikt
válasz
bobace
#11980
üzenetére
Végül is mivel alapvetően prepaid rendszerű a dolog, így mindegy melyik optimumot választanám, mert az egyenleg a mérvadó, ha most marad 20 Ft a számláján mindegy, majd következő alkalommal beszámítja a rendszer.
Pont, hogy ellentmondasz magadnak. Ha az egyenleg a mérvadó, akkor nem mindegy, hogy melyik optimumot választod, hanem pont hogy azt kell, amelyiknél a lehető legnagyobb mértékben csökken a kifizetetlen tartozás. Egyébként szerintem a 3 közül talán ezt a legnehezebb leprogramozni, mert az egyszerű mohó (greedy) algoritmus ilyenkor nem fog optimális eredményt adni.
Egyébként ez tök jó feladat, ha tanulóprojektről van szó és szeretnél fejlődni, akkor javaslom, hogy kódold le mind3 esetet. -
#11979
Sk8erPeter
nagyúr
bobace
#11976
Sk8erPeter
nagyúr
válasz
bobace
#11976
üzenetére
Hát szerintem a "check_mysql" mindent kifejez, csak azt nem, hogy egy lekérdezés eredményét fogjuk megvizsgálni, és mindezt logolni vagy kivágni a képernyőre, ha mondjuk a fejlesztői módon engedélyezve van.
Ilyen névnél egy jó hosszú függvénynév is szerencsésebb, még a check_result_of_query_and_log is jobb.
(vagy mindez camelCase-ben; persze lehet simán checkQueryResult is, vagy mittomén, ízlés dolga, de legyen beszédes)
Egyébként a PDO-t már csak ezért is érdemes használni, mert para esetén képes kivételdobálásra, a kivételeket meg a megfelelő helyeken el lehet kapni, és logolni mindenféle hibát. Plusz saját exception osztályokat is lehet definiálni, amiben alapból benne van a logolás, és még lehetne sorolni.cucka leírta az alapvető problémát.
De a #11977-ben írt okfejtésedben nem látom azt az esetet, ha épp csak másfél kifizetetlen számlányi összeg érkezik be. Ha nem akarsz nagyon átalakítgatni, akkor ezt valahol jelezned kéne, hogy egy adott számla végösszegének hányad része érkezett be eddig, azt' csókolom (mondjuk ezt írtam már korábban is). De tényleg a megrendelőnek kéne felvetned ezt a problémát, hogy na most akkor hogy legyen az elszámolás, nehogy aztán az legyen, hogy dehát ez nem is úgy működik, ahogy én gondoltam (tipikus ilyen rejtett elgondolás a megrendelő részéről, amikor azt hiszi, hogy amit ő gondol, az triviális másnak is, és nyilván ő is úgy gondolta, nincs is más lehetőség). -
cucka
addikt
válasz
bobace
#11977
üzenetére
Ez az a kérdés, amire nem fogsz választ kapni. Például itt a köv. bemenő adat, időrendben:
számlák 180, 50, 53, 90, 108
befizetés 200Namost
- kifzetheted a 180-at. Ez egy optimum, mert a legrégebbi számlát egyenlítetted ki.
- kifizethetsz 50+53+90-et. Ez egy optimum, mert a legtöbb számlát egyenlítetted ki.
- kifizethetsz 90+108-at. Ez is egy optimum, mert így fizetted ki a legnagyobb összeget.Az egy üzleti döntés, hogy a fenti esetekből melyiket választod (és nem csak ez a 3 eset van). Mindhárom megközelítés helyes, de ezt a megrendelővel kell tisztázni, hogy milyen működést szeretne látni a programban.
-
#11975
Sk8erPeter
nagyúr
bobace
#11974
Sk8erPeter
nagyúr
válasz
bobace
#11974
üzenetére
Hát reméltem, hogy ez okozza a legkisebb problémát, amikor pluszban van. De attól még a korábban felvetett probléma létezik, szóval a tartozásából kéne levonni annyit, amennyit kiegyenlített, vagy az az arányos megoldás, amit írtam, ha nem szeretnéd nagyon átvariálni, na az úgy pl. nem túl nehéz.
Ha nem megy a dolog végiggondolása kódolás során, akkor az egészet írd le egy papírra, hogy számolnád ki (ez attól még nem lesz amatőr, sőt, segít a gondolkodásban), gondold át úgy, hogy jó lesz-e, a gondolatmenetből kódot csinálni már talán a kisebb probléma, először jól kell megtervezni.
Egyébként ha már valami "rendszer" van az egész körül, akkor nem ártana azzal együttműködve megírni a kódot, gondolom akkor van valami objektumorientált módja az adatbázis-kezelésnek is (ha már ez a check_mysql() nevű, látszólag nem túl értelmes metódus is van [legalábbis a neve semmiképp sem értelmes, mert nem lehet belőle kitalálni, mit csekkol]).van ez:
while ($row = mysql_fetch_assoc($res2))
szóval a $row['id'] nyilván itt a ciklus következő lépésében fog változni.
Nálad ezen a cikluson belül van még egy másik ciklus, amivel megint egy másik query-t akarsz lefuttatni, de valamit nagyon rosszul csinálsz.
-
#11970
Sk8erPeter
nagyúr
bobace
#11967
Sk8erPeter
nagyúr
válasz
bobace
#11967
üzenetére
Hogy ellenőrzi a szintaktikát, miután már rég lefutott?
Egyáltalán mivel ellenőrzöd? És mi ez a mágikus $system osztály?
A #11965-ben küldött kód attól még ugyanaz, és továbbra is áll, amiket mondtam, hogy a $row['id'] nem változik, satöbbi.
Meg cucka felvetése is jogos, hogy így még mindig nem oldottad meg a feladatot. Legfeljebb a beérkező összegtől függően valamiféle arányt tudnál a kifizetetlen összegekre beállítani, hogy mondjuk a következő kifizetetlen számlának csak a 25%-a van rendezve, a maradék még hátravan, vagy ilyesmi. Mármint a jelenlegi rendszerhez igazodva, ha csak plusz egy mezővel kell kiegészíteni - vagy a paid mezőt átalakítani úgy, hogy csak akkor 1.00, ha teljesen ki van fizetve, addig meg mondjuk decimal number, például 0.25. -
-
cucka
addikt
válasz
bobace
#11965
üzenetére
Két kérdés:
- Pontosan mit akar csinálni ez a program? Ezer sebből vérzik, így nehéz megragadni a problémát.
- a system->check_mysql pontosan mit csinál? Összerakod a query-det mindenféle sql injection ellenőrzés nélkül, majd lefuttatod, az eredményét pedig odaadod a check függvénynek. Ha sql injection történik, akkor a check függvény mit fog csekkolni? -
#11964
Sk8erPeter
nagyúr
bobace
#11963
Sk8erPeter
nagyúr
válasz
bobace
#11963
üzenetére
Egyrészt nem is futtatod a query-t a while-on belül, másrészt mivel itt nem változik a $row['id'], ezért lényegében többször csinálod pontosan ugyanazt, ugyanannál a sornál, vagyis állítod 1-re a paidet, egészen addig, amíg nagyobb az $avabal, mint a $row['amount']. Szóval ez még erősen átgondolásra szorul.
-
Swifty
csendes tag
válasz
bobace
#11700
üzenetére
Szerintem sehogyan...
Főként azért, mert a rewrite arra való, hogy a "csúnya" vagy esetleg nem létező URL-eket átírjuk használhatóra, esetleg SEO friendly-re...
Viszont ha a használhatót szeretnéd megszüntetni, akkor mi fogja lekezelni a lapod???Persze saját magad átírhatod kézzel a kódodban a "csúnya" URL-eket, és működni fognak, de erre nincs automatizált módszer...
-
#11741
Sk8erPeter
nagyúr
bobace
#11739
Sk8erPeter
nagyúr
válasz
bobace
#11739
üzenetére
Hát nem tom, egy CMS is kínál sztem ilyen lehetőséget, úgy tudom, a Drupalban is megvannak erre a megfelelő modulok az Ubercart és Commerce segítségével.
Amúgy bírom az ilyen önismertetőket egy terméknél, amiben eleve az szerepel, hogy "... is the best ..." - ja, persze, a "best".
A saját mércéjük alapján, vagy ki mondta ezt róluk, ki határozza meg, mi a "legjobb"? 
Nekem az ilyesmi valahogy nem szimpi, de ez már OFF. Pl.
Ubercartnál: Ubercart Auction
Commerce-nél: Commerce AuctionSzóval azé' van alternatíva.
-
Soak
veterán
válasz
bobace
#10780
üzenetére
Én ugy csinálnám, hogy az adatbázisból úgy kérném vissza a tételeket, hogy érték szerint növekvő legyen. Majd szépen egyenként összeadogatod őket. Egy array-ban eltárolod azok id-ját amiket összeadsz . Nyilván akkor írod bele amikor már biztos, hogy 100alatt van az össz érték (és mész a következőre). Majd amikor végezett (a következő tétel hozzádása már 100 fölé menne) akkor egyszerrel UPDATE parancsal frissited az adatbázisod (azokat amiket az array-ba írtál)
.
(vagy mindez camelCase-ben; persze lehet simán checkQueryResult is, vagy mittomén, ízlés dolga, de legyen beszédes)
Egyáltalán mivel ellenőrzöd? És mi ez a mágikus $system osztály?
Új hozzászólás Aktív témák
Hirdetés
- ÚJ PS5 Slim - FW 8.40 - Lemezolvasó - Lua Loader - Lua játék - Lapse
- új, bontatlan, iPhone 16E gyárilag kártya-független, apple világgaranciával
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 1TB SSD Radeon Pro 5500M
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 2TB SSD Radeon Pro 5600M 8GB
- MacBook Pro 14" M1 MAX - 32GB / 1TB (2021) - 1 év garancia
- Használt és ÚJ Gamer Monitor Felvásárlás Gyors és Korrekt Ügyintézés!
- LG 45GR95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- Bomba ár! Lenovo ThinkPad T480s - i7-8GEN I 16GB I 256GB I 14" WQHD I HDMI I Cam I W11 I Gari!
- Szinte új, minőségi, állítható ritkítóolló
- Beszámítás! Oculus Rift virtuális valóság szemüveg garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged