Lotto szam generalas

 ( heroes83 | 2012. március 29., csütörtök - 10:39 )

Sziasztok!

Lotto programot szeretnék írni, de megakadtam annál a problémánál, hogy a szám generálásánál ne legyenek azonosak, azaz csak 1x szerepeljen egy generált szám.

A példa kedvéért 5-ös lotto, ugye van 90 szám és 5 db generált szám, tehát a generált számok ne legyenek azonosak. (amúgy java nyelven csinálnám Math.random-al generálok számokat)

Hogy tudnám ezt a szám azonosságot kiiktatni?

köszönöm

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

http://hup.hu/node/93935

Hogy ne kelljen végigböngészni, a legegyszerűbb megoldás talán ez:
http://hup.hu/node/93935#comment-1140924

"Hogy ne kelljen végigböngészni, a legegyszerűbb megoldás talán ez:
http://hup.hu/node/93935#comment-1140924"

Egyszerűnek egyszerű, csak hibás, mert nem egyforma a kihúzott számok eloszlása, az 1-es kb. 2,5x nagyobb valószínűséggel húzódik ki, mint a 90-es, s ez a valószínűségi görbe szép egyenes... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Tévedsz.
szerk: azért futtattam egy tesztet, hátha elírtam valamit - 1000000 sorsolásból 55426-ban lett 1-es és 55324-ben 90-es...

Ok, megnéztem ismét, és tévedtem... :D

Sikerült kimérnem a random.nextInt()%i és a random.nextInt(i) jellegű véletlenszám generálás közötti különbséget, ami a hivatkozott szálban is előkerült. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Bevallom én is Javaban teszteltem. %i-s módszer tényleg kerülendő...

Ha sikerül a generálás, és azt is tudod hogy melyik héten kell megtenni, azonnal szólj.

Dióhéjban:
10: egy Listába tedd bele a számokat (1-90), utána:
20: random szám 0 és a Lista elemszáma-1 között.
30: Ami kijött, vedd ki a Listából (a random számot indexként felhasználva)
40: ha kell még szám: goto 20 :-)

megoldódott, köszönöm

1 és 100 közötti prím számok kiírását végző programot írtam, melynek az igazi munkát végző része a következő:

for (int i=1; i < 100; i++){
boolean prime = true;
for (int j=2; j < i; j++){
if(i%j==0){
prime=false;
break;
}
}
if (prime){
System.out.println(i);
}
}

A kérdésem az, hogy a második for ciklus esetén a j-nek miért nem lehet adni 1-es értéket, miért kell 2-ről indítani?

köszönöm

Mert az 1 minden számnak osztója.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

inkabb csinalj egy int+boolean memberu osztalyt, es csak ahol true a prime booleanod a szamhoz, csak ott nezd meg, hogy oszthato-e, ne az osszes szamot n-ig, sokkal kevesebb muvelet is, meg sokkal kozelebb is all egy normalis java kod kinezetehez

a j=1 inditoval a j=2 helyett szemantikailag hibas lenne a kodod a mindig 0 dolog miatt, azert kell 2-tol inditanod, hogy valid eredmenyt kapj, ne pedig mindig rogton a for elejen legyen egy teljesult if 0-d, ami azonnal tori a ciklust, igy minden szamod ki lesz iratva, mert 1-gyel osztahto, igy "prim mar nem lehet"

Továbbá elég lenne a tartomány négyzetgyökének egészrészéig vizsgálni, hiszen ha valaminek van a négyzetgyöknél nagyobb osztója, akkor annak van egy négyzetgyöknél kisebb párja is.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

igen, de hozzateszem, hogy azt se sqrt-vel tegyuk, mert az nagyon muveletigenyes mar onmagaban is, inkabb legyen ra egy valtozo (a: ameddig megyunk), es megnezzuk mindig az elejen, hogy (a*a kisebb= i) (i.-ediknel tartunk), es ha igen, akkor ++a;

meg eleve haladhatnank kettesevel 3-tol folfele 2-t belove mar az elejen, na de ez most mindegy

És szerinted mennyivel lesz gyorsabb egy fastsqrt algoritmusnál az a sok-sok szorzás?
----
Hülye pelikán

Semmivel... szerintem valamit csúnyán elnézhetett...
A szorzásos megoldást egyetlen esetben használtam: amikor FPGA-n kellett megvalósítani a dolgot. Normál procikon értelmetlen.

A kisebb jelet cseréld &lt;-re, a > jelet pedig &gt;-re.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

köszönöm

További gondok adódtak:

A lottó program esetén olyan lehetőséget szeretnék még beállítani, ahol a legenerált 5 darab számot addig addig generálja, amíg el nem találja az öt darab előre definiált lottó számot.

Arra gondoltam, hogy while ciklussal (true) futtatom a programot, amíg nincs 5 darab találat, ha megvan az egyezés, akkor break a ciklusból. A kérdés, hogy tudnám összehasonlítani a generált 5 darab számot az előre definiált 5 darab számmal?

köszönöm

A számok (az előre megadott, és a sorsolt is) legyenek sorba rendezve. Ekkor az elsőt az elsővel, a másodikat a másodikkal, ... kell összehasonlítani. Ha tömbben tárolod őket, akkor for ciklussal végig nézed az elemeket.

-----
A kockás zakók és a mellészabások tekintetében kérdezze meg úri szabóját.

Ket lista, contains() az osszes generalt szamra az elso listaban, az elso false-nal kiugrasz az ellenorzociklusbol es mehet tovabb a kereses, ha az osszes szam true lett, akkor kiugrunk a generalasbol, "You WIN" szoveg kiirasa, System.exit(0);
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Akkor már inkább Collections.shuffle(List<?> list) és 5 elemet kiveszel?

De nekem is ez tetszik leginkább:
http://hup.hu/node/93935#comment-1140924
___________________________
http://lorem.hu
Az emberi tudás mindenkié!

    	ArrayList<Integer> nums = new ArrayList<Integer>();

    	for (int i = 0; i < 90; i++)
    	   nums.add(i+1);
    	
    	
    	Collections.shuffle(nums);
    	
    	for (int i = 0; i < 5; i++)
    		System.out.println(nums.get(i));

tipusnak nem interfeszt irni kifejezetten rossz dolog, tessek leszokni rola.

Gondoltam én is, hogy megírom, de nem akartam kekeckedni, de szerintem annál nagyobb hiba az Collections Framework nem ismerete.
-
Könyvajánló: Java fejtörők

Nyugodtan lehet kekeckedni, ha a kekeckedés építő jellegű annak nagyon örülök, mert tudok belőle tanulni. :)
Szóval leírnád kérlek, hogy miben nyilvánul meg a Collections Framework nem ismerete?

Abból gondoltam, és lehet, hogy tévesen, hogy a feladat az volt, hogy 5 darab egyedi számot kell előállítani. Ezen számok tárolására nem a List a legalkalmasabb, ugyanis a Set pont azt garantálja, hogy 1 elem csak 1x szerepelhet benne, tehát Set-el a megoldás 3 sor, mint ahogy lentebb írtam. Listet választva, vagy vissza kell ellenőrizgetni, hogy már benne van-e, vagy a te megoldásodat kell választani, ami -127 és +128 közötti számok esetén még nem is "olyan nagy" probléma, hiszen wrapper cacheben lesznek a számok, és csak referenciát tárolsz rájuk, de ennél kissebb/nagyobb szám esetén minden eszám egy újabb példány lesz a memóriában, amiből aztán felhasználsz 5öt.
-
Könyvajánló: Java fejtörők

Teljesen, jogos köszönöm a figyelmeztetést.

Ettől függetlenül én úgy tudom, hogy az a legfontosabb, hogy metódusoknál a formális paramétereknél és a visszatérési értéknél(ha van) használjunk interfészt. Amit értek is hiszen a metódust nem érdekli, hogy amit kap az például LinkedList vagy ArrayList a lényeg, hogy List legyen. Illetve így a függvény egyik ágában visszatérhetek LinkedList-el a másikban pedig ArrayList-el.

Viszont, ha így explicit megadom, hogy én egy ArrayList-et akarok használni a metóduson belül, akkor ez miért kifejezetten rossz dolog? Azon kívül, hogy List-el elegánsabb lenne, illetve, hogy ha később mégis LinkedList-et szeretnék használni, akkor kevesebb helyen kelljen megváltoztatnom.

pont ezert rossz, amit leirtal :)

en meg finalnak is szoktam tenni oket, ha tudom, hogy nem valtozok (akar metoduson belul is).

Rendben, akkor jól sejtettem.

Közben hátha valakinek még jól jön, egy kis szemléltetés:


And it is. Here's a real-life example:

    public void doSomething(List list) {  
       // code to do sonething with 'list'  
    }  
    ...  
    List al = new ArrayList();  
    doSomething(al);  
    List ll = new LinkedList();  
    doSomething(ll);  
    List s = new Stack();  
    doSomething(s);  
    List v = new Vector();  
    doSomething(v);  


I've just written a method that works with 4 different classes (and probably many more), simply because instead of defining its parameter as a class, I defined it as an interface; and because I did that, it'll work with any class that implements List (or, in the above case, List).


And when you define a field (eg, 'al' above), if you define it using the interface type, you can change your mind later. Assuming that all my methods are written to take Lists, rather than ArrayLists, I can change the above definition to:
List al = new AttributeList();
and everything will continue to work just fine.

ez majdnem jo pelda, csak raw tipust hasznalni is rooonda. raadasul van egy nagyon erdekes mellekhatasa annak, plusz pontert meg lehet nezni a JLS-ben. :)

Én had! Én had! Én tudom mi a mellékhatás! Az, hogy Eclipse-be aláhúzza sárgával... :DD

majdnem :D

Elmondod mi a mellékhatás? :)

Random randomGenerator = new Random();
Set<Integer> nums = HashSet<Integer>();
while (nums.size() <= 5) nums.add(randomGenerator.nextInt(90) + 1);

-
Könyvajánló: Java fejtörők

Mivel a cél az, hogy legyen 5 különböző szám, tehát addig a feladat nem megoldott, amíg nincs meg az 5 szám, és amíg a generálandó számok száma kevesebb mint a range amiből generálni kell ez nem egy végtelen ciklus, hiszen egyszer készen lesz vele, pontosan akkor, amikor megvan az 5 szám. Vagy egyéb implementációban ha nem sikerül véges X idő alatt előállítani a számokat, akkor beéri a program 4gyel is? Én még nem láttam olyan lottósorsolást, ahol bemondták, hogy sajnos mivel nem sikerült 1 nap alatt sem 5 számot sorsolni, ma csak 4essel lehet nyerni. Egyébként nyilván extrém körülmények között lehet ezt egy szálba tenni, amit kilő az ember amikor akarja, de továbbra is fenntartom, amíg szélesebb elemszámbol kell keskenyebbet csinálni sosem lesz végtelen ciklus.
-
Könyvajánló: Java fejtörők

Range: 1, 2

Feladat: a kiválasztott szám értéke legyen 1

Ha randommal választasz a két szám közül, nem történhet meg, hogy a random "örökké (végtelen ciklusba keveredve)" a 2-est szállítja?


"ez nem egy végtelen ciklus, hiszen egyszer készen lesz vele, pontosan akkor, amikor megvan az 5 szám"

A te értelmezésed szerint a program akkor lesz kész ha a random az 1-est adja vissza, de az is megtörténhet, hogy ez sosem történik meg... :)

Viszont annak, hogy a végtelen ciklusnak mi a valószínűsége azt nem tudom, pedig elvileg tudnom kéne....
Az első választásnál 50% esélyem van, hogy a jót adja vissza a random függyvény, viszont a 4635254332. választásnál is 50% esélyem van ugyanerre. Mivel az előző választások nincsenek hatással a jelenlegire.
Tehát ha minden egyes próbálkozásnál 50% esélyem van arra, hogy eltalálom a jót és a végtelen ciklus feltétele az, hogy MINDIG a rosszat válasszam aminek az esélye szintén mindig 50%, akkor az a végtelen ciklusra az esélyem....

Ah belekavarodtam, valaki segítsen!

Mivel a Java beszámítja az aktuális időt a seed értékébe, ami alapján generálja a psuedo-random szekvenciát, kötve hiszem, hogy véges sok idő alatt ne lenne megoldás a problémádra.

Amit utólag írtál bele, arról annyit, hogy ez egy elmélet, aminek nincs köze a Java (és a többi) random generálásához, a már említett ok miatt.
-
Könyvajánló: Java fejtörők

Anelkul, hogy vegiggondolnam, vagy matematikailag bizonyitanam, a hrgy84 sejtes: minel nagyobb egy range, annal kisebb a valoszinusege annak, hogy ugyanaz a szam jon ki 2x egymas utan.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ha a range r elemű, akkor a valószínűsége egy értéknek éppen 1/r, már ha jól értem a felvetésed. A következőre ugyanannak az esélye szintén 1/r, így szerintem az egymásutániság valószínűsége 1/r^2. Persze tévedhetek, nem gondoltam túl mélyen végig.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tévedsz is, méghozzá egy elég alapvető dologban. Az nem volt feltétel, hogy egy konkrét szám ismétlődéséről van szó, tehát az első valószínűség 1: egy számot mindenképpen sikerül kihúznunk. Vagy máshonnan nézve: valóban 1/r^2 a valószínűség, de ez r-szer.
----
Hülye pelikán

Jogos, szóval 1/r. :) A sejtőnek ettől még igaza van. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Aztan egyszer majd elcsodalkozol, hogy nem akar leallni a programod, pedig maskor megvolt akar 100 ms alatt...

Mint ahogy biztos azon is csodálkozna, ha lakásából véletlenül az összes oxigénmolekula kipattogna az ajtón, kint is maradna percekig - ő meg megfulladna. ;) A véletlenekre egy igazi mérnök nem alapozhat: remélem neked van oxigén palackod a közelben!

(persze itt ebben a konkrét példában tényleg van jobb megoldás is, szóval ezt csak úgy általánosságban mondom....)

Magamat tudnám idézni, amíg a range nagyobb, mint a generálandó darabszám, és a generált random számba beszámít az aktuális idő, előbb utóbb lefut. Lehet, hogy 100 ms, lehet, hogy 10 év, de _nem végtelen_. Az pedig már az üzleti logika része, hogy mennyi idő a releváns a feladatra. Az 5ös lottóban _mindig_ 5 számot sorsolnak!!! Amíg ez az üzleti modell, jöhettek nekem a matematikai valószínűségi számításaitokkal, 5 rohad szám kell. Ha az üzleti logika mást diktál, és a jelen feladat nem specifikált mást, akkor lehet vele játszani, lehet másik szálba rakni, lehet a while-ba más ellenőrzést is beletenni, stb.,stb., a konkrét feladatra ez egy jó megoldás. A példa amire reflektáltam pedig szintén hibás, mert ha 9999999999 * 10^999999-on számból kell 2-őt kiválasztani, akkor nem lesz annyi ram a gépbe, amibe a List elfér :).
-
Könyvajánló: Java fejtörők

Hibás feltételezés. Attól, hogy változik a seed, még nem feltétlenül nem fogod ugyanazokat a számokat kapni akár folyamatosan.

Mégegyszer: mivel van _változó_ az egyenletben, véges sok időn belül garantáltan bekövetkezik az esemény, hogy már nem ugyanazt a számot adja vissza, tehát nem _végtelen_ a ciklus. Sajnos ennél szájbarágósabban már nem tudom leírni.
-
Könyvajánló: Java fejtörők

Akkor mégegyszer: ezt NEM feltételezheted, mert ha megtiltod a generátornak, hogy ugyanazt a számot adja folyamatosan, akkor már nem is lenne random szám generátor...

Nem tiltom meg a generátornak, hogy ugyanazt számolja ki nem erről van szó, csak arról, hogy a matematikai valószínűsége sokkal nagyobb annak, hogy egyszer vége lesz a ciklusnak, mint annak, hogy nem.
-
Könyvajánló: Java fejtörők

Persze, de nem lehetetlen, hogy nem lesz vége. ;)

Az sem lehetetlen, hogy ennek a szalnak sosem lesz vege...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

ennek a szalnak ket lehetseges felso korlatja van:

1) a db storage kapacitasa
2) trey turokepessege

hamarabb elfogyasnal en utobbira tippelnek

Nem látom, hogy trey-t miért zavarná.

Nem a szal, a db novekedese.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Szerintem gyorsabban novekszik a tarolhato db meret, mint a szal, de majd meglatjuk... :)

Ugy ertettem, egy bizonyos szint felett trey-t zavarni fogja a db meret novekedese, sokkal elobb, minthogy elernenk a technikai korlatokat. Nala alacsonyabb a treshold :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Fog egy 90 elemű tömböt, feltölti tomb(i)=i. Aztán fog random 0<k<(92-h) véletlen számot generál, megnézi a tömb k. elemének az értékét - az lesz a h. számú lottószám. Ez után a tömb utolsó elemének az értékét beteszi a k. pozícióba. Eztán h-t megnöveli egyel, és jöhet a következő random érték generálása.

seq 90 | bogosort -n | head -n 5

"Like" :D
--
RowCol

Ne vedd el azoknak az embereknek a munkáját, akik a JVM-et tweak-elik, hogy ne fusson ki a memóriából egy ilyen program.
Köszi.

--------------------------------------
Unix isn't dead. It just smells funny.

LOL :D


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kicsit feljavítva:

seq 90 | sort -R | head -n5 | sort -n

:)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

És tényleg... :D
--
Coding for fun. ;)

Natív bash megoldás:

seq -f '%02g' 90 | shuf | head -n 5 | sort | xargs echo

--
Coding for fun. ;)

Lényegében ezt írtam, csak felesleges - szerintem nem szép - a vezető nullák használata. A sort -n kapcsolója numerikusan rendez.

Na jó, nem írom tovább, közben javítottál rajta, így nem látszik, mire is írtam, amit. :) Az érdem persze antiemes kollégáé. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Rövidebben:

seq 90 | shuf -n 5 | sort -n

--
Coding for fun. ;)

Ez a legjobb eddig. A shuf parancsot nem ismertem, de tetszik. Jellemzően fentebb meg objektumorientált módon estek neki, csak tudnám, miért.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mert javaban kell a megoldás, és nem shellben? :)

Hm... tényleg. Javaban már nem is lehet kihagyni az objektumorientáltságot?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem! Ott ezért főbelövés jár! :) Egyszer láttam egy srácot aki Java-ban kihagyta az objektumorientáltságot. EGYSZER...

Bár egy ideje tudjuk, hogy egy embernek mégis ki lehet hagyni az objektumorientáltságot még akár Java-ban is... :)

Ki lehet, elvileg teljes programokat írhatsz egyetlen osztályban, csak statikus metódusokat használva. Csak aztán azt próbáld meg karban tartani.

Gondolom Java-t tanul az illető, aki indított. És ez egy teljesen jó tanuló példa. Ez csak a vicc szál. nyilván ebből sok java nem származik :)

--------------------------------------
Unix isn't dead. It just smells funny.

Viszont működik. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ötletes.

antiemes kolléga az ötletgazda. :D :D Csak picit továbbjátszottuk. :D
--
Coding for fun. ;)

shuf -i 1-90 -n 5 |sort -n

Csak én csodálkozom az ilyen kérdéseken?

vmi ilyesmi: (vegtelen ciklus kizart)


List< Integer> numbers = new ArrayList< Integer>();
for ( int i=1; i<=90; i++ ) {
numbers.add(i);
}

for ( int i=1; i<=5; i++ ) {
System.out.println( numbers.remove( (int)(Math.random() * numbers.size()) ) );
}

uh. :)

Még nagyon kezdő vagyok, de ebben az esetben mi garantálja, hogy nem lesz szám ismétlés?

elso loop: berakunk 90 szamot egy List-be
masodik loop: kiveszunk 5 db-ot, mivel 2x nem tudsz kivenni valamit kizar az ismetles, akar mind a 90 szamot kivehetet ismetles/sebesseg romlas nelkul ...

ugyan az a model mint az igazi lotto huzas, egy uveg golyoba beraksz 90 szamot, majd csinos lany kihuz neked 5 db ot :) csak a lany-t remove nak hivjak ;)

ekezet classname-ben :( (input/output stringben meg kell is, hogy meg legyen oldva, de mar fajlnevben is meredek, nem hogy valtozonevben es vegkepp osztalynevben)

Ha a nyelv megengedi, pont magyarhonban ne használnánk ki? ;)

És még az indiai kódereket szidják hogy rossz a hozzáállásuk...

Ugyan, örülj hogy nem rovásírással van. (juteszembe, nemrég fordították le a bibliát rovásírásra)

Kinek?

ez egy igen jó kérdés

Klingont is "használják", ezt miért ne?

+ https://en.wikipedia.org/wiki/ISO,_SIL,_and_BCP_language_codes_for_constructed_languages
ezek egy részére még pl a biblia is le van fordítva, annyi erőt feccölnek bele emberek.

Sok sikert nekik az életben. De jobb időtöltés, mint a háború.

Mindenkinek más a kihívás :)

Van latin wikipédia. Szerinted?
----
Hülye pelikán

Négy évig tanultam latint és egy kicsiny ógörögöt is mellé. Nagy hasznát vettem eddig az életben.

Nem tudom, mennyire volt itt irónia, én két évig tanultam latint, és annyit értem el vele, hogy tudok latin közmondásokat (bár abból is egyre kevesebbet), illetve a lorem ipsumról ránézésre megmondtam, hogy halandzsa.
----
Hülye pelikán

Nálunk még a javadoc -ban is tilos magyar szavakat használni, nemhogy ékezet mindenhol, feláll a szőr a hátamon. Onnantól kezdve hogy nem magadnak írtad (nem, mert fent van a neten), kifejezetten taszító, hogy nem nemzetközileg olvasható a kód.

--
http://neurogadget.com/

10 dim n(5)
20 for i=1 to 5
30 A=int(rnd(0)*90)+1
40 for j=1 to i
40 if n(j)=A then goto 30
50 next j
60 n(i)=A
80 next i
90 for i 1 to 5
100 print n(i);
110 next i

run

Háát most nem tudom kipróbálni, de valami ilyennek működnie kéne. *_*

A for ciklusból kiugrani egyezéskor, majd azt újra elkezdeni... Van benne valami undorító.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Minek fusson el végig?

Valahogy olyasmi jár a fejemben, mintha a Commodore BASIC-ben nem lett volna kötelező kiírni a next után a változónevet. Tehát nem kizárt, hogy stack-en tárolt, akkor meg az efféle kiugrás elég szerencsétlen. Tegyük hozzá, egy érzésről beszélek, nem néztem meg az implementációt. Különben is ZX Spectrum-om volt a daliás időkben. :D


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jahogy csak erről az implementációról van szó. Amúgy hasznos, hogy ha megvan az eredmény, akkor kiszállunk a ciklusból (Prog 1, buborékrendezés :)).

Valoban stack-kel dolgozott. Lenyomta a stackbe a for utasitas cimet asszem, a next pedig a stack tetejen tarolt cimre ugrott (ami elvben ugye a for utasitas volt). Namost ha valaki kozben bizgatta a stacket, es utana nem allitotta vissza a SP-t, abbol igen finom dolgok sultek ki.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal


System.out.println(13);
System.out.println(51);
System.out.println(71);
System.out.println(73);
System.out.println(84);

Huh... :D


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vagy inkább ez: http://xkcd.com/221/

sirok

errol ez jut eszembe
http://beust.com/weblog/2011/06/15/sleep-sort/

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Aranyos. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ha már volt itt shell megoldás is, akkor lehet R is.

sort(sample(1:90, 5, replace=FALSE))

Újabb házi... legalább a google-t tanulnád meg használni :-P Csináld úgy, hogy addig generálsz új számot, amíg öt különböző nem lesz :-D

Én kinyomtattam a számokat 1-től 90-ig, és a kislányom (1 éves múlt, de valószínűleg idősebbel is működik) húzott 5 db-ot. Garantáltan nem lesz egyezés.
Egyébként ez annyira generikus algoritmus, hogy a 46-90 közti számokat kivéve az edényből, majd 6-szor iterálva hatoslottóra is tökéletes megoldást nyújt.

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

19:43:15| <ggergelz> http://pastebin.com/aAPWvMGC

----------------
Lvl86 Troll - Think Wishfully™

neeeeee meg a vegen valaki komolyan veszi :D

hat, ezen jot rohogtem

ez mi a franc?!?!

Humornak hívják, barátom... ;)
--
Coding for fun. ;)

az a szerecsenjatek.hu-s hivatkozás megzavart...

a megoldás megszületett (itt alant), ha javába át tudod forgatni.

és nézd végig, hogy mi a volt eddig a statisztikai valószínüsége annak, hogy ugyanazt az öt|négy|három számot húzták ki a jegyzett heteken:
http://www.lottotipp.hu/List/Numbers.aspx (1957-2012 aktual).

Hogy legyen valami érdekes is:

Könnyű kiszámolni hány szelvényt kell kitölteni, hogy biztos legyen 5-ösünk. Az általános eset (biztos legyen n-es találat) viszont nagyon nehéz probléma. (érdemes rajta önállóan is gondolkodni, hogy ezt átérezzük;)

A probléma neve angolul - az érdeklődőknek - egyszerűen: "Lottery problem"

És aki kíváncsi hány szelvényt kell kitölteni az 5-ös lottón, hogy biztos legyen 2-es találata: http://www.math.uiuc.edu/~z-furedi/PUBS/furedi_lotto.pdf

A programozás csúcsa a lottó nyeremény generálása lenne. :)

Nap tüzében, holdárnyékban

10 INPUT "Mennyi az eheti lotto fonyeremeny?";N
20 PRINT:PRINT "On NYERT! A nyeremenye";N;" Ft!"
25 PRINT
30 IF N > 500000 THEN GOTO 60
40 PRINT "Kerem faradjon a legkozelebbi lottozoba, hogy atvehesse!"
50 GOTO 90
60 PRINT "Kerem faradjon a legkozelebbi lottozoba, hogy felvehessuk az adatait a kifizeteshez!"
90 END

--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Brávó, szép munka!

Már csak az a kérdés, hogy e heti vagy eheti? :)

:-) Csak sajna most mar nem tudom fixalni...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

:O Ezer bocsánat, kitörölném, ha lehetne. :(

#!/bin/bash

wget -q http://www.szerencsejatek.hu/otoslotto -O - | \
tr -d '\015' | \
awk '{ if ( $1=="<ul" && $2=="class=\"nums\">" ) k=1; else if ( k ) { print $1;k++; } if ( k==6 ) k=0; }' | \
sed -e 's|<li>||g' -e 's|</li>||g'

Így is lehet, de ha már futtatod az awk-t, miért nem abban intézel mindent? Minek a tr meg a sed? Az igaz, hogy nekem is így jut hamarabb eszembe. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezen kívül, mivel nem használ bash specifikus dolgot, elég lenne a /bin/sh, ha meg valamiért bash kell, akkor célszerűbb a

#!/usr/bin/env bash

használata. Mert pölö nálam a /bin/bash nincs FreeBSD-n, viszont van /usr/local/bin/bash, amit az env megtalál.

En ki szoktam symlinkelni a /bin/bash ala is, mert a scriptek 95%-a ott keresi.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igazad van, de ettől még jobb, ha a script van jól megírva és nem a rendszered kell a scripthez igazítanod.

Na igen. Bar sokszor ez az env-ezes is felesleges overhead, mert hat mi biztositja, hogy az env ott van, ahol? Egyaltalan, hogy ott van-e. Aztan meg ez is csak plusz egy felesleges processz inditas.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Szerintem több rendszeren van az env a /usr/bin alatt, mint bash a /bin alatt, tehát általánosabb megoldásnak tűnik. Viszont nem kötelező. :-)

Processek. Kipróbáltam egy scriptet több verzióban, a script faék egyszerűségű, kiírja a processtree-t:

simán, nincs semmilyen #!
bash(10151)───bash(10336)───pstree(10337)

#!/bin/bash
bash(10151)───tt(10344)───pstree(10345)

#!/usr/bin/env bash
bash(10151)───bash(10350)───pstree(10351)

Nincs felesleges process, azonos a számuk.

De, csak az env exec() -cel inditja a hivatkozott shell-t, igy valojaban az o PID-jevel fut tovabb a cucc. Ettol meg processz felloves tortenik.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Elmondanám, hogy a lottószám generátorotok rossz, mert nem nyertem a hétvégén.
:-)

Várj, félreértetted. Lottószámot generált, csak nem azt, amit most húztak ki. Ha elég időt vársz, 1 valószínűséggel ez is fog szerepelni (ami persze nem jelent garantáltat), csak mindig tedd fel.
----
Hülye pelikán

Ott a smiley, ne vedd komolyan :)

Mivel feltételeztem a végtelen sok lottóhúzást, sejthetted, hogy nem vettem komolyan :)
----
Hülye pelikán

Csak akkor lenne igazad, ha végtelen sok lottóhúzás lenne. De ennek elég kicsi az esélye, figyelembe véve, hogy év vége előtt eljön a világvége :)

Mivel a maják nem vették figyelembe a julianus->gergely átállást és a szökőéveket, jelenleg majdnem egy évvel a maja naptár előtt vagyunk, ergo a világnak már tavaly óta vége. Csak szólok.

Ha én ezt tudom, ma be se jövök dolgozni...

BTW az továbbra is igaz, hogy annak 1 a valószínűsége, hogy nem lesz végtelen sok lottóhúzás, így annak nem lehet 1 a valószínűsége, hogy bizonyos számsort mindenképpen kihúznak.

A majak igenis figyelembe vettek a szokoeveket, nem veletlenul olyan a kis kor felepitese, amilyen. Tessen utanaolvasni a temanak.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Gergely pápa által kidobott 10 napot is figyelembe vették? Akkor ideje a majákat megkérdeznem a jövő heti lottószámokért.
Ja, Jézus mikor született? Krisztus után egyben vagy Krisztus után nullában?
Érted.

Lovon fordítva ülés esete... NEM kellett figyelembe venniük - ugyanis nem azt írták le, hogy "2012.12.12" (vagy bármi), hanem azt, hogy a naptárukban kezelt egy nagy egység befejeződik x kisebb egység elteltével, ami z még kisebb egységből áll, ami... összesen soksok földi napot jelent. Mivel a naptárukat csillagászati események alapján lehet az időben pozicionálni, és megmondani, hogy az a soksok földi nap a ma használt akármelyik naptárban hol ér véget. A kieső/berakott napokat ebben a körben kell figyelembe venni.

hurrá, akkor még nem haltunk meg.

Én is izgultam...

valld be, titokban te is reménykedtél, hogy igen...

"ergo a világnak már tavaly óta vége. "

http://hu.wikipedia.org/wiki/Kital%C3%A1lt_k%C3%B6z%C3%A9pkor

Ha ez igaz, akkor még előtte vagyunk ~300 évvel. :)

heh, ezt én nem mertem belinkelni :)

Ki nyert? :)

A Szerencsejáték Zrt. :-D