Lotto szam generalas

Programozás - kezdő

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

  • 28149 megtekintés

"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

( balazsasd | 2012. 03. 29., cs – 10:43 )

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

( Quain | 2012. 03. 29., cs – 10:56 )

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 :-)

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

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"

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

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

( sunmao v | 2012. 03. 29., cs – 11:41 )


    	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));

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.

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<String> list) {  
       // code to do sonething with 'list'  
    }  
    ...  
    List<String> al = new ArrayList<String>();  
    doSomething(al);  
    List<String> ll = new LinkedList<String>();  
    doSomething(ll);  
    List<String> s = new Stack<String>();  
    doSomething(s);  
    List<String> v = new Vector<String>();  
    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.

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

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

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

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.

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

( Finder | 2012. 03. 29., cs – 17:30 )

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

( selli | 2012. 03. 29., cs – 17:59 )

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()) ) );
}

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 ;)

( dash | 2012. 03. 29., cs – 20:21 )

http://code.google.com/p/java-programozas/source/browse/src/fejezet08/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet08/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet11/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet13/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet13/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet13/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet13/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet13/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet19/%…
http://code.google.com/p/java-programozas/source/browse/src/fejezet19/%…

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/

( Nextra | 2012. 03. 29., cs – 22:55 )

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. *_*

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

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

( sebist v | 2012. 03. 29., cs – 23:48 )


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

( uid_2516 | 2012. 03. 30., p – 15:25 )

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


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

( zeller | 2012. 03. 30., p – 15:29 )

Ú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

( Nyizsa v | 2012. 03. 30., p – 22:39 )

É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

( szemet | 2012. 04. 03., k – 07:01 )

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


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

( apal v | 2012. 04. 21., szo – 23:38 )


#!/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'

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.

( Jason v | 2012. 04. 23., h – 18:41 )

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

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.