Most itt tartok, azt, hogy 0 és 10 közé eshet (0 és 10 is lehet) hogyan tudom megcsinálni, bocs a buta kérdésért...

# include <iostream>
#include<ctime>
using namespace std;
int main()
{

srand((unsigned int)time(NULL)); // véletlen generátor inicializálása
int GURIT[10], TAR[10] = { 0 }, i; // A TAR[] -ban számoljuk, hogy az egyes dobásokból
//mennyi volt

for (i = 0; i<11; i++) //ellenőrzött dobás bekérés
{
GURIT = rand() % 11 + 1;
}
int dbparos = 0;
for (i = 0; i<10; i++) // eredmények megszámlálása
{
switch (GURIT(i))
{
case 1: TAR[0]++; break;
case 2: TAR[1]++; break;
case 3: TAR[2]++; break;
case 4: TAR[3]++; break;
case 5: TAR[4]++; break;
case 6: TAR[5]++; break;
case 7: TAR[6]++; break;
case 8: TAR[7]++; break;
case 9: TAR[8]++; break;
case 10: TAR[9]++; break;
case 11: TAR[10]++; break;
}
if (GURIT(i) % 2 == 0)dbparos++;
}
for (i = 0; i<10; i++) // eredmények kiíratása
cout << "\nA(z) " << i + 1 << "-es dobasok szama:\t" << TAR(i);
cout << endl;
cout << "\nA(z) paros dobasok szama:\t" << dbparos;

cout << endl;
system("pause");
return 0;

Amúgy
GURIT[i] = rand() % 11 + 1;

# include <iostream>
#include<ctime>
using namespace std;
int main()
{
srand((unsigned int)time(NULL)); // véletlen generátor inicializálása
int GURIT[10]; //10 guritas
int TAR[11] = { 0 }; // A TAR[] -ban számoljuk, hogy az egyes dobásokból [0, 10]
int i; //index
int dbparos = 0; //paros dobasok szama
//mennyi volt
for (i = 0; i<10; i++) //ellenőrzött dobás bekérés
{
GURIT[i] = rand() % 11; // [0, 10]
}
for (i = 0; i<10; i++) // eredmények megszámlálása
{
++TAR[GURIT(i)];
if (GURIT(i) % 2 == 0) ++dbparos;
}
for (i = 0; i<10; i++) // eredmények kiíratása
{
cout << "\nA(z) " << i << "-es dobasok szama:\t" << TAR(i);
cout << endl;
}
cout << "\nA(z) paros dobasok szama:\t" << dbparos;
cout << endl;
system("pause");
return 0;
}

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

A kolléga fordítva csinálja. Nem a dobásokat tárolja, hanem hogy melyikből mennyi volt.

Same rules apply!

Valami init kellene annak a randomnak, hogy ne ugyanaz potyogjon belőle mindig.
Amúgy jól elbonyolítottad Te is.
Erre való a map.
Ugye map<int, int>, aztán index operátorral rányomulsz. Mivel van defualt initializaiton a value-ra, ha nem létezett az adott key, és ezt intnél pont 0, ezért nyugodtan lehet indexelni. Másrészt kulcs szerint rendezett, tehát az első elemre, amelyiknél nem 0 a value, megvan a legkisebb generált érték.

Valahogy így:

map<int,int> results;
int num_of_even=0;
srand (time(NULL));
for(int i=0; i<11; results[rand() % 11]++,++i);
for(int i=0; i<11; num_of_even += results[i], i+=2);
auto it = find_if(results.begin(), results.end(), [] (const std::pair<int, int>& v) { return v.second > 0; } );

És kész is. *kezét összecsapja smiley*

Nyilván a dolog még egyszerűbb amúgy, mert a minimum simán results.begin()-ben van a feltöltés után, de jól esett megírni egy lambdát.

[ Szerkesztve ]

Same rules apply!

"Erre való a map"
Hogyne! Mindjárt ágyúval verébre. Így lehet egy nagyon egyszerű, jó esetben pár száz byte-ra leforduló programból több megás lomha bloatware-t csinálni. Sajnos manapság tényleg ez a tendencia, és ez nem kis részben a "mindenre jó" template könyvtáraknak köszönhetö. Semmi funkcionalitású pimfli kis programok akkorák, hogy nem is olyan régen egy op. rendszer kisebb volt. Ide pl. nagyon nem kell a map a maga red-black tree megvalósításával, erősen túllövése a dolognak.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Ez nem a teljesítményről szólt éppen (nyilván erről 10 elemnél nem lehet beszélni), hanem arról, hogy használjuk kihasználjunk olyan működéséket, amik kényelmesek és megkönnyítik a dolgunkat.
Ha gyors kódot akarsz írni, akkor meg static array, ami alapból zero inites, és csinálod rajta ugyanezt.

dobragab: kihasználtam az int zero initjét, amit a static array ugyan tud, de tömb vagy vektor nem. Illetve ha megnézed az utolsó mondatomat, a kulcsok rendezettségét és validálását is ki tudod használni.

A map azért elég jó olyan felhasználásra, amikor a kulcsaid csak az értékkészlet kis részét (<20%) fedik le.

[ Szerkesztve ]

Same rules apply!

Nekem úgy tűnt, hogy a kérdező erre a konkrét feladatra volt kíváncsi, nem pedig az STL rejtelmeire. Szerintem ez számára nem könnyíti meg a dolgot. Annál is inkább, hogy alapvető dolgokkal van problémája (ld. case szerkezet), inkább ezekben kéne segíteni neki. Itt többen, többször elkövetitek azt a hibát (akinek nem inge ne vegye magára), hogy nem a kérdésre válaszoltok, hanem egyfajta összekacsintós bennfentes módon csillogtatjátok a magas szintű tudásotokat, ami a kérdezőnek ugyan nem segít, viszont fellengzőssé és lekezelővé teszi a hozzászólásotokat.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Ha észrevetted, kapott már olyan választ, amilyet te elvársz. EQ megmutatta, hogy ezt igazán C++-osan hogyan illik. Pl. tőlem mindenképpen kapott volna egyszerű választ.

Ajánlom figyelmedbe Stroustrup intelmeit az Újszövetségből. (The C++ Programming Language 4th Edition)

[8] Minimize the use of arrays and C-style strings. C++ standard-library strings (§4.2), arrays (§8.2.4), and vectors (§4.4.1) can often be used to write simpler and more maintainable code compared to the traditional C style. In general, try not to build yourself what has already been provided by the standard library.

[10] Do not assume that something laboriously written in C style (avoiding C++ features such as classes, templates, and exceptions) is more efficient than a shorter alternative (e.g., using standard-library facilities). Often (but of course not always), the opposite is true.

[ Szerkesztve ]

Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.

És ezt szerinted " igazán C++-osan" map-pel "illik" megoldani? Szerintem nem, de hát ízlések és pofonok... Az "Újszövetségben": minimize!=avoid, often!=always, in general!= in all circumstances.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

De ugye nem akarsz kitiltani?

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Bocsi még kezdő vagyok... Csak próbálkozom.... Abban tudnál segíteni még, hogyan kellene a tömböket összeadás, pontosan arra gondolok, hogy mennyi a guritások összege, azt, hogy csinalnád??? Illetve, hogy kiírja a legkisebb dobás sorszámát... Maxindex és minindex értékadással??? Sorry a hülye kérdésekért...

Köszi! A viccben az a jó, hogy csak félig vicc

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

srand(time(NULL)); // véletlen generátor inicializálása
int GURIT[10], TAR[11] = { 0 }, i; // A TAR[] -ban számoljuk, hogy az egyes dobásokból mennyi volt

for (i = 0; i<10; i++) //ellenőrzött dobás bekérés
{
GURIT[i] = rand() % 11 ;
}
int dbparos = 0, guritasok_osszege=0,legkisebb_dobas=GURIT[0],legkisebb_dobas_sorszama=0;
//kezdetben feltetelezed, hogy az elso guritas a legkisebb
for (i = 0; i<10; i++) // eredmények megszámlálása
{
int gi=GURIT[i]; //segedvaltozo, hogy ne kellje mindig kiindexelni az i. guritast (hatekonyabb)
++TAR[gi];
if (gi % 2 == 0)dbparos++;
guritasok_osszege+=gi;
if(gi<legkisebb_dobas){
//a most vizsgalt guritas kisebb, mint az eddig megtalalt legkisebb, most mar ez lesz a legkisebb
legkisebb_dobas=gi;
legkisebb_dobas_sorszama=i;
}
}
for (i = 0; i<11; i++) // eredmények kiíratása
cout << "\nA(z) " << i << "-es dobasok szama:\t" << TAR[i];
cout << endl;
cout << "A paros dobasok szama:\t" << dbparos;
cout << endl;
cout << "A dobasok osszege:\t" << guritasok_osszege;
cout << endl;
cout << "Az (elso) legkisebb dobas erteke:\t" << legkisebb_dobas << "sorszama: " << legkisebb_dobas_sorszama+1;
cout << endl;

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Nem szoktatom én sehogy, de hát a GURIT és TAR neveket nem én adtam, pedig szerintem magyarul vannak. Egyébként fogd fel úgy, hogy komment helyett adtam ilyen neveket. Vagy magyarul kommentezni is főbenjáró bűn?
"jobb helyen hirtelen felindulásból leggépuskáznak érte!" Ilyen helyekre én nem járok.

"A legkisebb dobás és a sorszámának külön eltárolása meg elég béna, ha egy egyszerű tömbindexeléssel elérhető hozzá az adat."
Ezt nem értem. Elmagyaráznád?

[ Szerkesztve ]

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Ezt nem értem. Elmagyaráznád?

legkisebb_dobas nevű változód felesleges, mert GURIT[legkisebb_dobas_sorszama] pontosan ezt adja.

Same rules apply!

Részben igazad van, viszont az if feltételben megspóroltam egy tömb indexelést. Talán ez a megoldás hatékonyabb, és jobban átlátható. A gi-t sem kellett volna bevezetni, de ugyanezért lett az is. Nem tartozik ide, de szoktál assembly kódot debuggolni? Ott látszik, hogy egy tömb indexelés költségesebb mint egy sima változó elérés. Az értékadás pedig csak az if törzsében történik meg, ami feltehetően jóval ritkábban fut le, mint a feltétel kiértékelése.

[ Szerkesztve ]

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Jaja, így keletkezik a bloatware.

Same rules apply!

Persze, nem attól, hogy tömb helyett fölöslegesen map-et használsz, hanem egy szerinted (bár ahogy írtam, szerintem nem egészen) fölöslegesen bevezetett lokális változótól. Nagyon megsértődtél attól a hozzászólásomtól, ugye? Azért annyira ne vedd a szívedre!

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

rand() % 11

(...)
random_device rnd;
uniform_int_distribution dist(0, 10);
for(int i=0; i<11; results[dist(rnd)]++,++i);
(...)

Én is inkább használnék array<int, 10> results{};-t a map helyett. map nem igazán a go-to konténer, ha 0-N indexel a kulcs

Falura jó az. Egyébként közel egyenletes eloszlást is ad.
Map: azt szeretjük benne, hogy zseniális a [] operátora.
Ugyanerre a feladatra, ha mondjuk nem 1-10, hanem 1-100 intervallumban dobunk 10 randomot, már sokkal inkább a map való, mint a vektor.

Same rules apply!

Lehet jó falura, de ugyanannyit kell írni (na jó, a függvény/osztálynevek hosszabbak), ha rendesen használsz <random>-ot.

Map: Nem értek egyet: mivel a map node-okban tárolja az adatot, amiben benne van a kulcs, az érték, és jellemzően 3 pointer (left, right, parent), ezért masszívan több memóriát foglal, mint a vector: Az összes általam ismert 64 bites implementációban 32 byte + sizeof(pair<K,V>) a node méret + allocation overhead. Win x64-en a sizeof 16 bye, tehát 40 byte a blokk, ahol az overhead átlagosan 56 byte (!!), azaz 96 byte. Per node. Ja, és a map-nek kell egy extra node (az end node). Szóval 10 elemhez kell 1056 byte heap memória map-el.

Vector esetében ez N*sizeof(int) + overhead, ami most 10*4+56 = 96, összesen a 10 elemre. 100 elemre ez 9696 vs 449 byte.

Szóval ha a cellák több, mint ~9%-át használod ki, akkor a vector nyer map ellen. És még nem is beszéltünk mennyire cache-friendly a vector, és mennyire cache-ellenséges a map; hogy a vektorban indexelsz, nem keresel.

Azért ha tényleg el kell tárolnod a kulcsot, egy kategóriával szebben áll a map, de még mindig vesztésre áll, nem véletlen van a flat_map a boost-ban (ami gyakorlatilag egy map interfész vector felett).

Kissé off topic, de azért érdekes:
A legkisebb dobás meghatározásakor EQMontoya kifogásolta, hogy fölöslegesen vezettem be a legkisebb_dobas változót, mert tömb indexeléssel is megoldható lett volna. Ez igaz, azonban ahogy írtam, valószínűleg hatékonyabb így, mert a feltétel kiértékelésben megspórolom az egyébként költséges tömb indexelést, ezzel szemben az if törzsben "bevásárolok" egy értékadást. Ha az értékadások össz költsége kisebb mint a tömbindexelések össz költsége, akkor ez megéri (itt most figyelmen kívül hagyom az egyetlen tömb indexelés, és értékadás közötti költségek viszonyát). Mivel a feltétel jóval ritkábban értékelődik igazra, ezért az értékadás is jóval ritkábban lesz végrehajtva. Nos, kiszámoltam, hogy mennyi is az annyi. A konkrét feladatban [0,10] intervallumból generáltunk egyenletes eloszlással egy 10 elemű tömböt. Ekkor nyilván a generált sorozatok eloszlása is egyenletes. Kiszámoltam, hogy a konkrét feladatban mi a várható értéke a feltétel igazra értékelődésének, és 2,55 adódott, bele számolva a legkisebb_dobas kezdő értékadását is. A tömb indexelős megoldással ezzel szemben 10 indexelés adódik. Tehát tényleg hatékonyabb az értékadós megoldás.

„Kétségtelen, hogy nem tudjuk, mit tegyünk, de felkészültek és elszántak vagyunk.” - Olaf Scholz német kancellár

Napi mitírki. Az első C, a második C++. Feltéve, hogy a char 1, az int 4 bájtos.

1.

printf("%d", sizeof('a'));
printf("%d", sizeof(+'a'));

2.

std::cout << sizeof('a');
std::cout << sizeof(+'a');

Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.

1. Undefined behavior A sizeof size_t-t ad vissza, ami egy nem-specifikált méretű unsigned integer vs a %d signed int-et vár. Variadic függvény, nem olyan típust olvas, amit átadsz, goto Launch_nuclear_missiles; "%zu" kell oda

Oké, első language lawyer megjött Igazad van.

3.

printf("%zu", sizeof('a'));
printf("%zu", sizeof(+'a'));

Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.

Akkor fejeljük meg a dolgot egy ilyennel is:
printf("%zu", sizeof("a"));

Same rules apply!

Rendben Rálicitálok.

4.

printf("%zu", sizeof("hello"));
printf("%zu", sizeof("hello"+0));

Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.

Üdv! Írtam egy programot arra, hogy hogyan fog repülni egy ágyúgolyó a kilövés után. A program figyelembe veszi a légellenállást is, elvileg.
Az lenne a gond, hogy a program gyorsan lefut, ha nincs légellenállás... ki hitte volna, az matematikailag könnyebb feladat. A kódot úgy írtam meg, hogy fogtam a dolog fizikáját, és megoldottam a differenciálegyenletet, majd pedig a kapott függvényeket leprogramoztam. A program jól működik, ha nincs légellenállás, szépen megadja a kilövési sebességhez, és a távolsághoz tartozó szöget, és szépen ki is rajzolja, tehát ezzel nincs gond. A légellenállásos egyenletekkel viszont nem tud megbirkózni. 16 percen keresztül számolt, közben 1 GB memóriát elhasznált, és semmi eredmény. Igaz sajnos, csak egy szálon fut a program.
Van valami ötlet esetleg erre a problémára ? Nem tudom linkeljek programkódot ?

A vicces a dologban az, hogy még így is csak közelítek a valósághoz.

[ Szerkesztve ]

PS4

Linkelj kodot.

while (!sleep) sheep++;

[link]

[ Szerkesztve ]

PS4

Nem fogtam fel teljesen a kódot, de ha jól értem a ciklust, csak akkor áll le a program, ha x==s && y==0 állapot áll fenn egyszerre. (legalábbis egymás epszilon sugarú környezetében van)
Valószínűleg ez nem teljesül valamilyen számítási hiba miatt soha.
Az 1g ram pedig azért van, mert mindig eltárolod az eredményt, de a végtelenségig tárolgatsz.
Valamelyik képleted lesz rossz, ennek pillanatok alatt kellene lefutnia.

Erre a részre gondolok:
for (t = 0; 1; t += TIME_STEP)
{
x = get_x(type, v_0, t, alfa, k, m);
y = get_y(type, v_0, t, alfa, k, m);

//A MARGIN szerepe, hogy hova kerüljön a koordináta rendszer, margóként szolgál, és a SIZE adja meg a nagyságát.
draw_x = (int)round(SIZE * (x / s)) + MARGIN;
draw_y = (int)round(fabs(SIZE * (y / max_y) - SIZE)) + MARGIN;

graph_x = (int)round((x / s) * GRAPH);
graph_y = (int)round((y / max_y) * GRAPH);

graph_set(&graph, graph_x, graph_y);
//Itt kapja meg a koordinátákat az .svg fájloknak megfelelő stílusban.
fprintf(f, "%s %d %d ", (t == 0 ? "M" : "L"), draw_x, draw_y);

if (comp(x, s) && comp(y, 0))
{
graph_draw(&graph);
break;
}
}

[ Szerkesztve ]

Same rules apply!