Dotaz: java - pole

[salik]

Příloha:

• java.txt (1720 bytů)

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

 

Odpovědi

[salik]

jo a dotaz je ze bch rad vedel proc to nefunguje..hlavne jak vyresit ty sudy a lichy cisla

[oroborus]

Příloha:

• Cisla.java (870 bytů)

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.

[oroborus]

BTW samozrejme, v mojom kode ma byt "public class Cisla" namiesto "public class Hello"

 

( zobralo mi to staru verziu :) )

[Jan Zahornadsky]

A ten průměr bych počítal avg/pocet, ne avg/10 Jinak (snad) OK.

[oroborus]

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

[salik]

dikes

[default]

Přílohy:

• Generator.java (585 bytů)
• Numbers.java (2544 bytů)

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
$ 

[saslik]

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.

[default]

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.

[saslik]

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.

[default]

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.

[saslik]

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.

[default]

No jo no. Chybami se člověk učí.

[Ladicek]

Prý chybami. Jestli by někoho měli vyrazit od zkoušky, tak člověka, který takový problém řeší tím, že si všechny vstupy zapamatuje! BigDecimal je tady spíš vtip

[xkucf03]

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.

[deadmail]

Priemer cisel z intervalu -10 az +10 je tiez z tohto intervalu, ale pri vypocte sa pocita najprv sucet - a ten uz moze prekrocit hranice datoveho typu

[saslik]

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?

[saslik]

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.

[saslik]

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.