[LiivaneLord]

Keegi teab mingit lihtsat programmeerimiskeelt, millega saaks teha suurema hulga kalkulatsioone ning millele saaks ette sööta mingi faili või andmebaasi, mille baasil neid kalkulatsioone teha? Apache + mysql + php pole just kiireimate killast, vaid 7 kalkulatsioonimassiivi sekundis ja prose 30%.

Tegevus toimub siis selliselt, et on eelsisestatud andmed, mille põhjal neid kalkulatsioone tehakse. Programm peab võtma sealt need andmed, korrutama ja liitma vajalikud numbrid ning siis salvestama tulemuse failisse või andmebaasi.

Programm peaks suutma teha palju kalkulatsioone ja töötama arvuti taustaprotsessina. Seega võiks vähe või enda poolt valitud prioriteediga kasutada arvuti ressursse.

[2ndalpha]

Sul jääb tõenäoliselt ketas pudelikaelaks.
Kas teed pärast iga baasi sisestamist commiti või kasutad transaktsioone?

[jnt]

No c/c++ peaks kindlasti mõnna olema selliste asjade tegemiseks, kuid pigem on pudelikaelaks tõesti ketas. Ja siis ei anna keele vahetus ka mingit võitu.

[priitr]

C++ ja OTL näiteks?
Andmete ja ülesande kirjeldus oleks muidugi abiks...

[LiivaneLord]

[Redikate]

Andmebaas on indexeeritud õigesti? Äkki sa timed oma skripti osad ära ja vaatad mis asjad aeglased on? Mina panustaks, et reaalne arvutamine ei võta võrreldes andmebaasi päringute jms'ga üldse aega.

[priitr]

[2korda2]

[LiivaneLord]

priitr, skript loob 1-48-st numbrist ligi 12 miljonit erinevat kombinatsiooni. Andmebaasis on pea 1100 rida, igas reas 8 veergu, mis sisaldab vastavalt reale täpselt samasuguseid numbreid. Kui skript koostab iga järgneva numbrite rea, siis loendab, palju neid andmebaasis kattuvad. Seejärel liidab kõikide 1100 rea tulemused kokku ja salvestab tulemuse. See on põhiline tegevus.

[Redikate]

Kui see pole sul mingi ülisalajane projekt, siis võiksid anda oma skirpti ning andmebaasi schema. Paar testi kirjet ei teeks ka paha. Oluliselt lihtsam oleks aidata ja kaasa mõelda kui me näeme mis kood on ning mis täpselt toimub.

[priitr]

[ranel]

scicos?

[LiivaneLord]

Et andmebaasi lugemiskordasid vähendada, tõin andmebaasist loetavad andmed ühe korraga välja muutujaga $sql_numbrid, aga kasu sellest praktiliselt ei olnud. Varem oli see käsk kõige madalama FOR loop sees.

süsteemimäng_viking tabeli päringu võtan hiljem vahelt ära vist, suht ebavajalik antud hetkel. Asja mõte oli ka süsteemipileteid kalkuleerida, aga see tulemuste hulk läheks miljarditesse sel juhul.

[2korda2]

[napoleon]

Natuke teemast mööda, kuid siiski kasulik soovitus - ära kasuta sql-s ei tabeli ega veeru nimedes täpitähti, sellest võib hiljem hulk peavalu olla, kui andmeid ühest süsteemist teise tahad tõsta.

Aga kirjelda lähemalt, mis on ülesandepüstitus. Võimalik, et asjale saab läheneda ka kavalamalt kui brute-force meetodil kõiki kombinatsioone genereerides.
Põgusalt peale vaadates tundub, et võibolla on siin mõistlikum lähenemine alustada hoopis loosimistest mitte numbrite huupi genereerimisest kuna mõtet on genereerida vaid kombinatsioone, kus vähemalt kolm numbrit pihta läheb.

[LiivaneLord]

2korda2, võidusummad konkreetsete kombinatsioonide taga ei oma siin tähtsust, see väänab statistikat. Seetõttu on igal piletil oma väärtus. Teoreetiliselt võib see väärtus olla ka lihtsalt 1, 2 ja 3, aga seda siis kõigil piletitel, et tulemuses kajastuks statistika, mitte tegelikkus.

napoleon, nojah, aga mida see kolm numbrit eriti annab. Tulemusse tuleb see kirjutada niikuinii. Iseküsimus muidugi, kas määrata mingi alampiir, millest alates see andmebaasi salvestatakse.

[napoleon]

LiivaneLord, annab küll. Huupi genereerides tähendab kolm täiendavat numbrit 103776 korda rohkem kombinatsioone. Kaheksast numbrit kolm saad valida vaid 112 erineval moel.... aga antud juhul on variante veel vähem, kuna kolme numbri korral tohib neist ainult üks lisanumber olla. Seda muidugi eeldusel, et saan õigesti aru ja sind huvitavad vaid kombinatsioonid, mis vähemalt 2+1 pihta saavad.

[Desmond5]

[Ohohh]

Kui kiiresti see for tsüklite ahel "tühjalt" töötab, kui selle esimese select päringu asendad staatilise massiiviga ja insert'i välja kommenteerid?

Põhimõtteliselt see, mida priitr ütles, loe kõik andmed enne sisse ja pärast tulemuse saab ilmselt batchide kaupa kiiremini salvestada, kui rida-rea haaval.

[LiivaneLord]

Ohohh, njah, tundubki, et enamus auru läheb selle koodi jooksutamiseks, mitte andmebaasi kirjutamiseks.

See R tundus üsna huvitav tarkvara. Võiks täitsa proovida. Tegin mõned dumpuser testid ära ning tundub igati loogiliselt toimivad, peab leiutama, kuidas andmeid sellele ette sööta jne.

Uurin ...

[DoS]

Tegin huvi pärast C's katsetuse ja ei ole sel brute-forcel ka midagi häda, kui natuke teistmoodi läheneda:

[kpihus]

Offtopic:
Lihtsalt infotks, et statistiliselt lähenedes tulevasi tõenäolisi võidukombinatsioone välja ei arvuta. Miks ?
1) Ühe või teise palli tõenäosus sõltub pallide kaalust ja juhuslikusest. Pallid on väga täpselt kaalutud ja tava inimeste mõistes võime öelda et nad on sama kaaluga, ning juhuslikust statistiliselt ette ei ennuste
2) Võimalike kombinatsioone on 12,5 miljonit, tänaseks on loosimisi olnud ca 1000, see on liiga väike algmaterjal mingit sisulist statistikat teha
3) palle vahetatakse 2 korda aastas, seega mõistliku statistika saaksid sa ainult viimase poolaasta tulemuste peale, mis vähendab sinu statistika kasumlikust veelgi.

Aga silmaringi laiendamise mõttes säärast programmi kirjutada pole muiduig paha mõte.

[LiivaneLord]

Pole just kõige kenam lahendus, aga teeb asja ära.

[andrusny]

Ei tea kuidas sul algne programm tehtud oli, kuid arvan, et kiirus ei saanud nii väike kül php tõttu olla, arvata sa püüdsid peale iga tehet käia andmebaasis ja tulemust salvestada, kuna sa JS seda teha ei oska läks asi tunduvalt paremaks, lugesid kõik andmed välja tegid korraga kõik arvutused ära ja salvestasid vajaliku tagasi, saidki kiirema tulemuse. Võimalik, et eksin, kuid nii tundub.

[LiivaneLord]

andrusny, tegin varem prooviks selle, et jätsin kogu selle andmebaasi kirjutamise sealt viimasest tsüklist ära ehk alles jäi lihtsalt läbi kalkuleerimine, aga see ei muutnud mitte midagi.