Portál AbcLinuxu, 9. května 2025 23:10
Na vstupu je n náhodných čísel z intervalu <-10;10> zjistěte jejich průměrnou hodnotu, součet, součet sudých a lichých čísel
jo a dotaz je ze bch rad vedel proc to nefunguje..hlavne jak vyresit ty sudy a lichy cisla
Hned na zaciatku ma zarazilo, skade beries tu istotu, ze parnych/neparnych cisel
bude polovica celkovych cisel int suda[] = new int[pocet/2];
To je iba statisticky/teoreticky, ale realne sa na to spoliehat nemozes.
BTW samozrejme, v mojom kode ma byt "public class Cisla" namiesto "public class Hello"
( zobralo mi to staru verziu :) )
Jinak (snad) OK.
Ops, to som sa sekol :)
Ono by sa to dalo este efektivnejsie: (parne+neparne)/pocet // vsimol som si to az teraz
a s avg premennou by sa vobec nepracovalo, ani by neexistovala
dikes
Na vstupu je n náhodných čísel
Nechci se do toho plést, ale je-li na vstupu n prvků, pak (staticky či dynamicky alokované) pole není dobrý nápad. Tento problém jde řešit iterativně. Kód v příloze načítá čísla ze standardního vstupu. Každé číslo na novém řádku.
$ javac Generator.java Numbers.java $ java -cp . Generator 2000000 | java -cp . Numbers oddSum : -897333472733 oddCount : 1000023 evenSum : -1471369732372 evenCount : 999977 totalSum : -2368703205105 totalCount : 2000000 oddAvg : -897312.83 evenAvg : -1471403.57 totalAvg : -1184351.60 $
Pouzit pro pocet cisel BigDecimal je hodne spatny napad, za ktery by se asi od zkousky vyhazovalo
Ze by se pocet cisel na vstupu nevesel napr. do long je totiz v tomto vesmiru nepravdepodobne. Vzhledem k tomu, ze BigDecimal je immutable, vznikne ohromne mnozstvi zcela zbytecnych objektu, navic se pro scitani vola metoda, proste bude to tragicky pomale. Pouziti BigDecimal pro soucet ma mozna trochu smysl, ale pro takovouto ulohu je to podle mne rovnez zbytecne, long by asi mohl stacit. Nehodlam to prilis zkoumat, ale ty vypsane vysledky jsou na prvni pohled nesmyslne, takze asi tam nekde bude i vecna chyba.
Tak to se hochu pleteš! Mám tady na starosti aplikaci, která si neporadí se souborem, protože používá java.lang.Integer. S tím, že výpočty jsou pomalé, souhlasím. S věcnou chybou nikoli. Přepočítával jsem alternativním programem.
Spíš bych hledal způsob, jak obejít to dělení. Co se výkonu týče, dva miliony čísel to udělá za 13 sekund. Šlo by to udělat lépe, ale to by nikdo nepochopil. Šlo mi spíš o to ukázat, že když je na vstupu neznámý počet čísel, pole není dost cool. Zkusi si naalokovat pole intů o dvou milionech prvcích. 
No prumer cisel z intervalu -10 az +10 musi byt asi rovnez z tohoto intervalu, takze mam proste podezreni na chybu. Deleni se provadi trikrat, scitani pro kazdy prvek, takze v deleni urcite vykonnostni problem nemuze byt. Naopak je v nesmyslnem vytvoreni nekolika milionu instanci BigDecimal pro pocet cisel na vstupu. long je podstatne vetsi nez integer, takze jako paranoik bych pouzil ten, prece jen integer uz je dneska trochu maly. Neni zadny problem naalokovat pole o dvou milionech integeru, takove pole ma par megabajtu. Samozrejme pri cteni ze stand. vstupu nema smysl delat nejake pole, nicmene pokud by se mela cisla uchovat, tak se tomu stejne neda vyhnout, nebo pouzit nejakou kolekci, coz ale pro cisla do deseti bude ohromne plytvani pameti.
Použil jsem Copy/Paste. Proto je takový šílený.
Průměr nemusí být z intervalu <-10;+10>, protože Generator negeneruje čísla z tohoto intervalu.
Nechtěl jsem udělat state-of-the-art solution. Chtěl jsem jen poukázat na to, že vzhledem k tomu, že nevíme, kolik vstupních dat máme, pole není podle mého názoru dobrý nápad. Lze to řešit iterativně s mnohem menší paměťovou náročností. Nic víc, nic míň.
To, že jsem zvolil nesmyslné datové typy, si plně uvědomuji. O tom žádná. Ale lidé by si měli zvyknout, že zadání pro software má vypadat úplně jinak. Když to dotáhnu podle zadání do extrémů, tak ani ten BigDecimal nestačí.
Nedošlo mi, že se najde nějakej vtipálek, kterej se v tom bude vrtat. Ale to je holt cena za to, že se člověk snaží a obtěžuje se s funkčním příkladem namísto obyčejných chytrých řečí. To je další chyba, kterou jsem udělal. Základní myšlenku ten kód pokrývá a to by mělo stačit.
Zadani ma mozna vypadat jinak (naprikald neni vubec receno jak je vstup realizovan), nicmene ze jde o cisla z intervalu -10 az +10 tam je uvedeno. Jestli to tak Generator nedela, tak to rozhodne neni problem zadani. Ja jsem se generatorem vubec nezabyval, predpokladal jsem, ze dela to co delat ma.
Ja na to reaguju proto, ze jsi sem umistil zdrojak, ktery ma na prvni pohled velmi zavazne nedostatky - BigDeciamal pro cela cisla misto BigInteger (kdyz uz tedy nestaci ten long), BigDecimal jako citac (to je naprosty humus, ktery nema NIKDY pravo na zivot), urceni lichosti udesnym zpusobem delenim nejakych BigDecimal instanci (kdyz uz tak lze pouzit treba BigInteger.testBit). Opravdu bych se nerad v praci v budocnosti setkal s programatorem, ktery pouzije BigDecimal jako citac, protoze to nekde "radil' nejaky odbornik...
Funkci priklad, ktery je chybny, coz si dokonce sam uvedomujes ("To, že jsem zvolil nesmyslné datové typy, si plně uvědomuji"), nema vubec zadny prinos (leda kdybys k nemu pripsal "takto to vypadat nema") a naopak muze nejakeho zacatecnika zmast. Proto mam potrebu uvest takovy "priklad" na pravou miru. Kdybys zustal u "chytych reci" a pouze vysvetlil, proc se ti nelibi pouziti pole, nemel bych proti tomu zadne namitky.
No jo no. Chybami se člověk učí.
Ještě by se to dalo krásně vyřešit pomocí SQL* – vytvořís tabulku, naINSERTuješ čísla a pomocí agregačních funkcí spočítáš výsledek. Standardní vstup a výstup by samozřejmě probíhal pomocí XML.
*) ani na to není potřeba PostgreSQL nebo Oracle, stačí javovská hSQL nebo Derby.
To s mym prispevkem nijak nesouvisi. Ja jsem poukazoval na to, ze pokud ten prumer vysel mimo interval, asi se pocita spatne. To se pozdeji vysvetlilo tak, ze na vstupu byla cisla, ktera neodpovidala zadani, takze ani vysledny prumer nebyl takovy, jak by se podle zadani ocekavalo. A dale na to, ze pro citac poctu cisel na vstupu staci (a je nejvhodnejsi) long, na cemz si dovolim trvat. Stejne tak si myslim, ze v tomto pripade staci long i pro soucet, ale to jsem v prispevku nepsal.
BTW kontrolni otazka - kolik cisel z intervalu -10 az +10 by muselo byt na vstupu, aby se jejich soucet nevesel do promenne typu long?
BTW proc by nikdo nepochopil program scitajici dva miliony cisel za mene nez 13 sekund? Ja spis nechapu program, kteremu to trva tech 13 sekund Samozrejme zalezi na hardwaru, ale asi vis kam mirim.
Promenna by se nemelal jmenovat avg, kdyz se do ni pocita soucet. Muze byt vygenerovano cislo -11, coz je v rozporu se zadanim (vhodnejsi je zde ostatne pouzit java.util.Random). Pouziti absolutni hodnoty je zbytecne, operator % lze pouzivat i pro zaporna cisla.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
14.6.2009 15:15
14.6.2009 15:26
14.6.2009 21:20
16.6.2009 23:25