OK, umesto 1 treba da izadje neki ERR.... Posto to bas i nije definisano. Verovatno je neko pisao precicu, pa stavio da je x^0=1, nevezano za x, a propustio specijalan slucaj x=0.

Jeste bug, svi se slazu. A koliki - pa ocigledno da, ako stoji od 2006-te i nije neki. Koliko cesto mislis da je neko naleteo na njega, tj. da je zasmetao? Nije stepenovanje na nulu cesta primena u onome za sta vecina koristi spreadsheet.

To se ne mora tretirati kao greška. U aritmetici kardinalnih i ordinalnih brojeva zaista važi .

No, slažem se da nad argumentima realnog tipa treba to da bude greška.

Ja ne znam kako rade tabelarni programi. Ako se tip određuje na osnovu onoga što je ukucano, a postoji i celobrojni tip, onda ovo ima smisla. Sa druge strane, ako je 0.0^0.0 definisano, onda račun definitivno ne valja.

Dobio sam da =0.0^0.0 daje 1, što je svakako greška.

A šta ćemo sa bagom u IEEE 754 standardu, koji nažalost proizvođači procesora poštuju?

Nedeljko, nije matematička greška. Funkcija POWER(x,y) je u OpenOffice.orgu definisana po OpenFormula specifikaciji i tačnije određena u samom OOo. Ta funkcija se u (0,0) ne poklapa sa matematičkom funkcijom stepenovanja, ali to nije matematički već čisto praktični problem.

Pa, znaš šta, oni mogu da definišu funkciju POWER tako da bude POWER(2,3)=76, ali to je greška. Ne možeš koristiti standardne termine za neke leve stvari.

Realan stepen nije definisan u koordinatnom početku zbog neprekidnosti. Celobrojni domen je druga stvar.

"Šta mi nindže sad da radimo?!"

Jel ti baš često stepenuješ na nulti u spreadsheetovima pa je ovaj bug toliko dramatičan, ne kontam?

Ok, da crtam. Fora sa spreadsheet aplikacijama je da ti mozes da radis automatizaciju nekih matematickih operacija, grubo receno mozes da od skalara pravis vektore i matrice po nekom sablonu i onda da vrsis neke operacije nad svim tim (ovo je samo jedna varijanta primene). U mom konkretnom slucaju je u pitanju inzenjerska primena - ja koristim ovakve aplikacije da ubrzam proracune. Nije pitanje da li dizem nulu na nulti stepen, nego sto neko gura OO kao industrijski standard i kao alternativu MSO, a ovamo ne krpi bugove ovakvog kalibra. Ja se onda pitam kakvih sve tu bugova ima, koji su krupni a niko ih nije uocio.

Pitanje je upravo na mestu, ako ti je matematicki model za proracune takav da moze da digne nulu na nula a nije limitran na cele brojeve onda ti je model neispravan ili nedorecen, a ako je u pitanju ceo broj onda je rezultat ispravan. Ja stvarno ne vidim bug ovde, jedino sto bi eventualno mogli da urade je da dodaju treci opcioni parametar u POWER da definisu odziv na 0,0 a za to bi prvo morao da se promeni openformula standard.

Nedeljko spreadsheet nije striktni matematicki alat, generalno ne razlikuje float i int (int je samo ispis floata sa odsecenim decimalama ;)) tako da je njemu 0.0^0.0 isto sto i 0^0. Ne mozes bas traziti dlaku u jajetu naspram matematicke teorije, moras se prilagoditi ogranicenjima te alatke, u suprotnom tu su matlab i slicni. Sama specifikacija formule dozvoljava ovaj rezultat a OOo se odlucio na opciju koja vraca 1, po meni ispravno jer dozvoljava modele sa celobrojnim vrednostima ali prebacuje odgovornost na tebe, u krajnjem slucaju ako ti ovo predstavlja operativni problem mozes da napravis svoju MYPOWER() funkciju koja ce pokriti tvoj scenario.

Koliko se sjećam, mi smo u školi učli da je 0^0=1. Ne znam da li su se u međuvremenu pravila promijenila, ali i Google Calculator takođe misli tako:

Vidim da i Scilab tako računa...

Niko ne reče šta ćemo sa dugogodišnjim bagom u IEEE 754 standardu.

Hej Hej pa OpenOffice je open source, je li tako?

Onda moram da vam dam cuveni OSS savet: use the source... :-)

A sto se IEEE 754 tice i deljenja sa nulom koje daje pozitivnu beskonacnost, to nije nikakav bag vec je deo specifikacije.

i python i bc i octave i perl neko pomenu i scilab , aj nek neko vidi sta se na windowsima desava
a sta excel radi u tom slucaju?

ne znam kako rade pomenuti softveri , ali bi svakome trebalo da bude poznato kako se ponasa IEEE754
http://docs.sun.com/source/806-3568/ncg_goldberg.html

Excel daje 0^0=#NUM, ali Calculator daje 0^0=1.

Wolfram Alpha (Mathematica): neodređeno

Svako svoju politiku vodi...

Najbolje definisati sopstvenu funkciju da ispisuje ono što želiš.

_{[Ovu poruku je menjao Not now, John! dana 11.09.2010. u 08:58 GMT+1]}

Pa, ja sam i rekao da je IEEE 754 bag, tj. greška u specifikaciji. Delenje nulom daje beskonačnost znaka deljenika. Besmislica.

Probajte 0/0 da vidimo koliko specifikacija ima smisla. Mislim da C/C++ kompajleri jednostavno poštuju FPU rezultate, a da se FPU projektuje po IEEE 754 specifikaciji.

Neko svratio na http://en.wikipedia.org/wiki/E...tiation#Zero_to_the_zero_power ? IEEE 754 preporučuje dodefinisanje 0 na 0 kao 1. I u fortranu se poštuje IEEE 754 (isprobao sa Gfortranom i Ifortom), tako da…



…ovo ni najmanje ne pije vodu. (Bar ovoliko sam morao da napišem, pošto sam prethodno obrisao nekoliko sarkastičnih rečenica, zato što mi se podigne želudac kad čujem za tabelarce u inženjerskim primenama.)

Nisam baš matematičar, ali me baš zanima koji bi tu rezultat trebalo (po tebi) da bude umesto +beskonačno?

ERR

+Inf se dobija tek kada funkciju 1/x redefinišemo da bude neprekidna na [0, Inf). Ali tada množenje više nije njen inverz (Inf * 0 != x), mislim da Nedeljku to najviše smeta.

Ako ćemo po logici, meni je sasvim logično da 1/0 bude +beskonačno, jer 0 u 1 može da stane beskonačno puta . Odnosno, što više smanjujemo delilac koji teži nuli, to i rezultati više teži ka beskonačnosti. Tako da kada delilac postane nula, sasvim je logično i da rezultat postane beskonačno.

1/(-1)=-1
1/(-1/2)=-2
...
1/(-1/n)=-n
...

Zašto onda da ne bude .

U kompleksnoj aritmetici postoji samo jedna beskonačnost i tamo jeste , ali u realnoj aritmetici postoje dve beskonačnosti suprotnog znaka, tako da je nemoguće opredeliti se za jednu od njih, a ne napraviti prekidnu funkciju.

Pravilno bi bilo da bude .

Šta uopšte očekujete od OpenOffice.org-a kad se mikroprocecori prave po takvim šarlatanskim specifikacijama?

Specifikacija uopste nije sarlatanska - razlog za takvo ponasanje je kako ne bi dolazilo do zaustavljanja programa i generisanja greske. Sva ostala resenja nisu pogodna za reprezentaciju realnim brojevima (cemu IEEE754 sluzi).

http://standards.ieee.org/reading/ieee/interp/754-1985.html

Iskreno i ja nisam znao kako da zapocnem odgovor na tvoj komentar iz slicnih razloga. Za posledjnih 4-5 godina rada sam video toliko razlicitih nacina rada u elektro struci, masinskoj i tehnoloskoj. Neki nacini odradjivanja proracuna koje sam video su bili bizarni (blago receno), drugi su bili krajnje nefleksibilni a bilo je dosta onih OK.Ti OK su radjeni u spreadsheetu. Moje iskustvo je sledece: spreadsheet aplikacije su sjajne sto se tice interoperabilnosti - kada razne struke razmenjuju podatke, pri cemu se neki proracuni koriste u dve ili vise struka (tipican primer elektro i masinska struka: dimenzionisanje dizel-elektricnog agregata). Jos bolja fora: softverska interoperabilnost - mogucnost koriscenja i Excela i Calca za rad na jednom fajlu. E ovaj konkretan problem moze da zezne stvar: u Excelu je 0^0 greska, u Calcu je 1.

_{[Ovu poruku je menjao Sir_Oliver dana 11.09.2010. u 21:41 GMT+1]}

kad sam ja studirao 0/0 je bio nedef. izraz ali ko zna sve se menja i imaju razne teorije. A odakle je x^0=1 za x nije 0 dolazi od razlomka x^n/x^m=x^(n-m)

Ne menja se nista.

Vec postoje razlike u tretiranju brojeva za razlicite primene... IEEE 754 format sluzi za skladistenje realnih brojeva sa pokretnim zarezom, i namenjen je za inzenjerske aplikacije.

Odluke u vezi deljenja sa nulom su jednostavno tu zbog prirode aplikacije IEEE 754 formata - odluceno je da deljenje sa nulom daje beskonacnost kako ne bi dolazilo da okidanja gresaka u programima, to je samo prakticni kompromis.

Ako se trazi neka apsolutna "matematicka tacnost" treba reci da bi se za postizanje te tacnosti kompletno izaslo van granica IEEE 754 formata, tj. samih realnih brojeva.

>>(Bar ovoliko sam morao da napišem, pošto sam prethodno obrisao nekoliko sarkastičnih rečenica, zato što mi se podigne želudac kad čujem za tabelarce u inženjerskim primenama.)


a u cemu je problem sa inzenjerskim proracunima u Excelu?




Da se razumemo, ceo MS Office kao paket je nedoradjen, i taj fking Excel ima jedan mnogo chudan bug, kada krenes da snimis file on ti izbacice nesto tipa Out of resurce...ili tako neka nebuloza <-valjda sto u file nakrcam x macroa, tablea, chuda loodila....ali mi nije jasno zasto ti se podigne zeludac?

Vidiš, više stotina miliona ljudi širom sveda koristi taj Excel i normalno sačuvaju svoju tablicu. Valjda zato što, citiram, ne "nakrcaju macroe, tablea, chuda loodila" već koriste softver za ono za šta je i namenjen.

Specifikacija je itekako šarlatanska, jer proizvodi besmislene rezultate. Na primer, ako je takvo da je (naravno, u računarskoj aritmetici), onda je , što je besmislen rezultat.

Matematičari nisu bez razloga smislili takva pravila, već je utvrđeno da je tako najbolje, najpraktičnije iz raznih razloga. E, sad su se našli IEEE 754 inženjeri pametni da ne valja to o čemu su pre njih promislili mnogo veći umovi od njih tokom čitavih vekova. Da, matematika se kao i sve ostale discipline rukovodi praktičnim razlozima.

Ko da je galet@world pisao specifikaciju.

Bolje je da računar lepo izbaci NaN i prizna da ne zna rezultat, pa da probamo da dobijemo rezultat na neki drugi način, nego da izbacuje besmislene rezultate, pa da samim tim rezultati uvek budu neupotrebljivi, jer nikada ne znamo da li su dobri. Bolje je ne dobiti rezultat, nego dobiti besmislen rezultat. Ko to ne shvata, ne vredi mu objašnjavati.

Sarlatanska je za matematicare, a za inzenjere je odgovarajuca.

A IEEE754 je standard koji su pisali inzenjeri za inzenjere... sta da ti kazem, drzi se Mathematica-e.



Tacno, ko ne shvata - u slucaju tvog citata: matematiku, a u slucaju mog odgovora: inzenjering.

Nego da, Nedeljko... ako vec niste, ti i tvoji matematicari lepo napravite MEEE format za zapis realnih brojeva... pa onda mozete da se obratite CPU vendorima :)

MEEE 754 kako to dobro zvuci... E, ako vec pravite format - zamenite cifre sa slovima, da bude MEEE MEEE za MEEE754

>>Vidiš, više stotina miliona ljudi širom sveda koristi taj Excel i normalno sačuvaju svoju tablicu. Valjda zato što, citiram, ne "nakrcaju macroe, tablea, chuda loodila" već koriste softver za ono za šta je i namenjen.


vidish, ti macroi, tabele, chuda loodila, nisu rndom upucani u x Excel file, vec se koriste pri proracunu....dakle, taj Excel je prilicno slab kada se pristojno opetereti. A za 2*2 je calc.exe a ne Excel.



pri tome ne vidim zasto sw nije namenje svemu ovome gore....poenta je da Excel ima taj glupavi bug, a negde sam nasao da je to u vezi sa razlicitim scale view vise sheetova (!!)

http://www.google.com/search?h...&aql=&oq=&gs_rfai=

http://www.excelforum.com/exce...rces-to-display-completly.html

Ivane, ti očigledno ne razumeš matematiku, pa samim tim ni način njene primene. Sa takvim tvojim nadobudnim stavom ti oko toga ne mogu pomoći. Sprdaš u nedostatku argumenata. A ako ne razumeš zašto je bolje ne dobiti rezultat nego dobiti pogrešan (ne približan, već besmislen) rezultat, onda nisi ni neki inženjer.

Ispravno je zato sto bi davanje greske strahovito produzilo izvrsenje proracuna sa nizovima / u petljama, zato sto bi moralo pre bilo kakvog racunanja u nizu / petlji da se proverava da li se deli nulom.

To je, u vreme donosenja IEEE754 standarda imalo daleko veci prioritet nego tacnost koja nije potrebna u vecini ostalih aplikacija inzenjeringa, osim u aplikacijama koje imaju dodir sa delovima vise matematike.

Kome je potrebna kompletna tacnost - IEEE754 format nije za nejga.

Nije to nikakva nadobudnost, nego inzenjerska realnost - nesto sa cime se matematicari obicno ne susrecu u svom poslu, pa im to izgleda kao besmislica.

Zahvaljujem što si počeo ozbiljno i argumentovano da pišeš. Tako i treba. Dovoljno te cenim da smatram da ti drugo ne pristoji.

Vidiš, kada imaš dva programa A i B, koji su namenjeni istoj svrsi, pri čemu A ili izbaci tačan rezultat ili ga ne izbaci uopšte (ili prizna da je glup), ali nikada ne izbacuje pogrešne rezultate, dok program B ponekad izbacuje pogrešne rezultate, onda

U rezultate programa A se možeš pouzdati, jer kada ih dobiješ, siguran si da su dobri.
Rezultati programa B su uvek neupotrebljivi, jer nikad ne znaš da li su dobri.

Samim tim, program A je ponekad upotrebljiv, jer kada izbaci rezultate, znaš da su dobri, a program B je uvek neupotrebljiv, jer nikad ne znaš na čemu si.

Računarska aritmetika u pokretnom zarezu treba da bude napravljena za dobijanje približnih rezultata, koliko je to moguće u datoj fiksnoj tačnosti (merenoj brojem značajnih binarnih cifara).

Nedeljko,

Ja bih rekao da su korisnicima i progamerima industrije koja ima ko zna koliko aplikacija koje koriste FPU aritmetiku sasvim upotrebljive ...

I nikome - ni autorima, a ni korisnicima tih aplikacija ne smeta sto IEEE754 ima beskonacnost za deljenje sa nulom.

Sta mislis, Nedeljko, sta je onda relevantnije? To sta TI mislis o tome da li je nesto "upotrebljiviji" program ili oni koji ga pisu i oni koji ga kupuju?

Vidis ^ ovo gore je primer kompromisa koji se moze napraviti u inzenjeringu... kada KORISNICIMA rezultata inzanjeringa taj kompromis nije problem.

Nego ne znam da li je neko isprobao ovaj program. IEEE 754 predviđa da ista operacija za iste ulaze mora da proizvede uvek isti izlaz.

Na kompajleru koji ide uz OpenSUSE 11.3 dobio sam različite rezultate pokrećući program više puta i deleći nulu sa nulom, koji su bili između 2 i 3 čini mi se. Na MinGW kompajleru koji ide uz Code::Blocks 10.05 dobijam 1.#QNAN kao rezultat, što je ispravno. Dakel, pomoću onog programa sam računao 0/0.

Prvo grešiš što govoriš u ime svih. OK, tebi ne smeta što je tako. Meni smeta.



To što oni misle ne mora da bude tačno. Kamo lepe sreće kada bi ljudi uvek znali šta im je najbolje. Mislim da ratova ne bi bilo. Logika kaže jasno šta e upotrebljivo, a šta ne.



Kompromis se ne sme praviti po cenu neupotrebljivosti.

Ovo je sad ona priča o tome koji je časovnik precizniji — onaj koji kasni jedan minut ili onaj koji stoji pokvaren? Ti ovde pokušavaš da kažeš da je korisniji časovnik koji stoji jer će u 24 sata dva puta pokazati tačno vreme. Kao inženjer, moram priznati da bi mi više značilo da imam onaj „neupotrebljivi” sat od tog formalno preciznijeg.

Svaki inženjer je barem jednom čuo da će znati da je sazreo kao, dakle, inženjer kada mu bude postalo jasno do koje tačnosti ima smisla da ide. Za nekoga ko se bavi praktičnim problemima (umesto striktno teorijskih razmatranja) to je veliki izazov i mnogi provedu čitav radni vek, a da ne sazreju na taj način.

Nedeljko,

Ti si matematicar, i jasno je zasto se ne slazes sa IEEE inzenjerima koji su standardizovali IEEE specifikaciju i svim onim milionima inzenjera koji istu koriste bez da imaju problema sa njom... ali to je upravo dokaz sustinske razlike izmedju matematicara i inzenjera.

Matemaka ne poznaje kompromise, sama je sebi svrha. Inzenjering je takav da je sve u njemu podredjeno prakticnoj realizaciji - sa svim problemima koju ta prakticna realizacija i nosi i na osnovu toga pravi kompromise u svojim alatima.

A realni brojevi su u inzenjeringu samo jedan od "alata". Pa samim tim i podlazu kompromisima za realizovanje cilja.

Matematicarima su ti kompromisi apsolutno neprihvatljivi - zato sto oni u svom radu te kompromise ne moraju da prave. Ono sto ne primecuju je da se inzenjeri ne bave istim stvarima kao i oni.

Ne, ta priča je besmislena, jer se podrazumeva da časovnik povremeno podešavaš. Ako časovnik podešavaš npr jednom dnevno, onda u nasumično izabranom trenutku očekivanje greške časovnika koji stoji je 6h (ako je brojčanik kružni sa brojevima od 1 do 12), a onoga koji kasni jedan minut 30s. Dakle, taj koji kasni jedan minut je tačniji. Takođe, taj primer nema nikakve veze sa onim o čemu sam pisao.



Za mene je matematika nauka koja pokušava da otkrije zakonitosti deduktivne snage, tj. šta mora da važi (znači nužno) pod koji uslovima. To je ekvivalentno sa tačnošću iskaza u svim interpretacijama polaznih pojmova (ako su sve pretpostavke, uključujući aksiome uključene u formulaciju). Zato je matematika toliko široko primenljiva. Polazne pojmove teorije možeš da interpretiraš kako god hoćeš, sve dok su aksiome te teorije zadovoljene u tom modelu (interpretaciji). Matematika grantuje da će tada važiti sve teoreme teorije u tom modelu. No, da bi se matematika primenjivala, neophodno je razumeti njene iskaze inače ćeš je primenjivati kao boxxter na ES forumima.

Takođe, postoji numerička analiza koja se upravo bavi problemima konačnog računa. Tako da, daleko od toga da je matematika nešto izolovano, što je samo sebi svrha. Naprotiv, to je bez ikakve konkurencije najšire primenljiva nauka, pa samim tim i najpraktičnija.

Matematika o kojoj ti pricas, i kojoj je IEEE754 problem NIJE matematika koja je u "sirokoj primeni".

Inace IEEE754 kao format ne bi imao ni najmanje sanse.

Nedeljko, stvar je u tome da ljudima nije uvek neophodna tacnost.
Treba uzeti u obzir cilj sa kojim je standard pravljen.

Ivane,

Moram da primetim da osim što je Đoković odvalio Federera, ponovo troluješ. Da li bi bio ljubazan da ponovo počneš da pišeš argumentovano?

Ti IEEE inženjeri, ako su uopšte bili na jakim univerzitetima, učili su matematiku od matematičara.

Dobro, koji je to cilj?

Ako neko ovde troluje a to si ti - "diskutujes" o necemu sto je prilicno jasna stvar.

Inzenjering != matematika.

Inzenjering je resavanje PRAKTICNIH problema uz pomoc naucnih alata koji sluze toj svrsi. Matematika je jedna od njih, ali inzenjering poznaje pravljenje kompromisa kako bi se postigao zadovoljavajuci cilj sa uzimanjem u obzir prakticnih realnosti. Svi ti alati su podlozni kompromisima, ukoliko cilj to diktira i ukoliko su ti kompromisi prihvatljivi u realnoj aplikaciji.

Zbog toga je deljenje sa nulom definisano onako kako je definisano. Zbog tih prakticnih realnosti koje su diktirale koliko kompleksna aritmetika moze da bude.

I taj kompromis je bio prihvatljiv ljudima koji su kreatori i korisnici IEEE754 (i to je sve sto je i bitno, zapravo). Matematicari imaju svoj softver i svoje nacine reprezentacije brojeva kako bi do kraja postovali pravila u svojoj nauci. Zbog tih obzira, matematicki softver vrsi izracunavanje visestruko sporije od IEEE754 FPU jedinica - matematicarima to nije problem, informaticarima i inzenjerima jeste. Zbog toga informaticari i inzenjeri koriste BRZU APROKSIMACIJU - a to je IEEE754

Sta tu vise ima da se kaze?

To sto tebi smeta u IEEE754 formatu NIJE matematika, vec njena prakticna implementacija za probleme u inzenjeringu. Njima je IEEE754 implementacija OK... tebi nije.

Resenje je - nadji sebi drugi format. IEEE754 se svakako nece menjati zato sto nekom matematicaru ne odgovara.



Cilj je: DOVOLJNO BRZO IZVRSAVANJE RACUNA SA PRIHVATLJIVIM PERFORMANSAMA I PRIHVATLJIVOM PRECIZNOSCU

I, iznenadjujuce i krajnje sokantno - IEEE754 ispunjava BAS TO.

Da, zapanjujuce - u inzenjerskoj praksi postoje cak i manje precizni formati od IEEE754 sa jos vecim odstupanjima od matematike...

Koriste se u aplikacijama gde su prihvatljive - recimo u grafici, graficke kartice imaju dodatne specificnosti koje su jos veca odstupanja od IEEE754, zato sto u procesu renderinga 3D scena ta odstupanja nisu relevantna uopste.

Sta bi tek matematicari rekli na njih? Svasta - ali sve to sto oni kazu je tu irelevantno, zato sto svrha tih formata nije apsolutna matematicka tacnost.

Za rešavanje ti praktičnih problema koje pominješ služi numerička analiza - grana matematike koja je smišljena baš za to. Ona se bavi i brzinom i (ograničenom) tačnošću izračunavanja i kaže ti šta možeš da dobiješ i kako.

Nego, ja više nisam ni siguran da je 1/0=+oo po IEEE 754 ili su .NET ECMA inženjeri nešto cpali. Konstruktivno bi bilo da to neko proveri. Ja sam sa programom koji sam priložio dobio zaista čudne razultate.

MinGW lepo priznaje da ne može da deli nulu nulom, ali na Linux-u dobijam različite rezultate za iste argumente (0/0) kada više puta pokrenem program.

Praksa i teorija u teoriji su jednake, ali u praksi se razlikuju. :)

IEEE754 aritmetika sa pokretnim zarezom je upravo prakticni kompromis. Siguran sam da je 100% korektna implementacija po zahtevima numericke analize bila uzeta u obzir, ali su dalji kompromisi napravljeni sa drugim realnostima koje su onemogucavale drugaciji tretman deljenja sa nulom.

Kao sto rekoh, proglasavanjem tog deljenja za gresku se mora uloziti znacajno vise resursa za izracunavanje bilo cega sto ima potencijalno deljenje sa nulom u sebi - i to je bilo neprihvatljivo, zato sto zahtevi koji su se postavili IEEE-u nisu toliko rigorozni.

Kod grafike nemaš operacije sa singularitetima. Koriste se matrice reda za jedan većeg od dimenzije prostora (3x3 za 2D grafiku, 4x4 za 3D grafiku). To je račun sa tzv. homogenim koordinatama upravo zbog izbegavanja singularnih slučajeva i iz tog razloga se tu može biti opušteniji.

Nije bitno koliko bitova ima mantisa. To se određuje prema potrebama. Poenta je da taj račun bude smislen. U grafici se takođe koriste aproksimativni algoritmi. Zbog brzine grafičke kartice ne koriste uvek brezenhajma za prelom kose linije, već brže aproksimativni algoritmi, koji prelamaju liniju brže, ali sa više vizuelnih nesavršenstava. Međutim, nijedna grafička kartica neće umesto prave linije da nacrta nešto bezveze, već približno pravu liniju.

Kada razvijaš račun specijalne namene, onda ga prilagođavaš konkretnim uslovima. IEEE 754 je sa druge strane standard za opštu upotrebu. Uopšte nije specijalizovan za grafiku.

Za opstu upotrebu u inzenjeringu - i tu radi posao bez ikakvih problema.

Kome je potrebna striktna matematicka reprezentacija, taj svakako ne koristi IEEE754.

Ama, šta ti to znači striktna matematička reprezentacija i ko priča o tome?

IEEE 754 je račun u ograničenoj tačnosti za opštu upotrebu. To znači da rezultat treba da bude približno tačan, koliko je to moguće računajući u toj tačnosti.

No, niko da se mane filozofije i isproba onaj program. Ovde sam samo ja priložio neke konkretne rezultate.

Aha, tako. Ovo je već konkretan odgovor na konkretno pitanje. To volim, ali se ne slažem sa konstatacijom da se na taj način taj cilj postiže. Već sam naveo primer kojim to potkrepljujem. Koja je to prihvatljiva tačnost sa kojom se može zameniti sa , ili još gore sa ?

Ovo ima daleko više smisla od ovoga. Kao da ne govore o istoj stvari.

Ok, ali u cemu je razlika ako je rezultat Inf ili NaN?

Da, koristi Mathematicu ili nesto slicno. Ali sta cemo sa onima(HPC) kojima treba i brzina i tacnost?

Ovo je banalizacija, primer ti nije dobar. Ako gledas malo siru sliku, svaki inzenjerski posao se bavi ovozemaljskim stvarima: imas gomilu ogranicenja - vreme, novac, resurse, tehnologije koje primenjujes, tehnologije koje razvijas i realizujes primenom postojecih tehnologija ... Beskonacnost je cista apstrakcija. Meni ako se u proracunu pojavi beskonacnost, to samo znaci da sam negde zeznuo stvar, tako da mi je sve jedno da li je + ili -.

Promenljive su ti tipa double, a formatska direktiva u scanf() je %f (float) umesto %lf, tako da se unesene vrednosti pretvaraju u nešto proizvoljno. Kod mene kad unesem 1 i 1 dobijem rezultat 7,57⁻⁶. (Gde uopšte nađe da petljaš sa scanf() u jednoj ovakvoj probi.)



Tima je tačnost, u smislu o kojem Nedeljko govori, najmanje bitna. Proračuni na superračunarima obavezno rade na osnovu približnih matematičkih modela stvarnosti; recimo, postići tri sigurne cifre u odnosu na stvarnost (eksperiment) često je nedostižan cilj. Tako da ako program zaglavi u ove granične operacije u pokretnom zarezu, već je nešto debelo naopako pošlo mnogo pre toga.

(Podrazumevam da se misli na tehničke i prirodnonaučne proračune. Tamo gde je potreban i superračunar i tačna realna aritmetika — ne znam koje bi to oblasti bile — tu se ne koriste brojevi u pokretnom zarezu, već namenske aritmetičke biblioteke.)

*gnik, gnik* Vazduha…



Da ne trujem dalje temu, evo ovde sam tiradisao:

http://www.physicsforums.com/showthread.php?t=204797

http://www.physicsforums.com/showthread.php?t=240568

Sale 123 je natrcao na nesto relano ovde, u cemu je zapravo upotrebna razlika uzmedju +/-Inf i NaN? Oba su showstoperi i oba su realno greske i oba ne mozes koristiti u daljim proracunima.

Sto se tice .NETa provericu sutra ali koliko me secanje sluzi

- System.DevideByZeroException kad podelis cellobrojnu vrednost sa 0
- NaN kad podelis 0.0/0.0
- sign(X)*Inf za X/0.0

u svakom slucaju nema bacanje exceptiona za deljenje nulom u float svetu, kao po specifikaciji. Medjutim ako pokusas da to iskoristis posle za nesto drugo natrcis na neki od System.ArithmeticException derivata, sto je po meni ok i upravo sprecava situacije o kojima pricate (da NaN/Inf zagade calculation flow)



_{[Ovu poruku je menjao mmix dana 12.09.2010. u 10:09 GMT+1]}

>>Da ne trujem dalje temu, evo ovde sam tiradisao:


pazi, ja sam krenuo da citam lnkove ali tu ima puno txt, aj zipuj pa ukratko potkrati tvoju tvrdju sa pocetka teme.

OK, ti si počeo da trokiraš, ja preživljavam "deja vu".
Časlave, taj stav "sam protiv svih", smo svi imali u nekom periodu života. Ja nešto što izračunam, mogu da pošaljem nekome na parčetu papira, sms-om, u txt fajlu, nebitno. Ali ako taj neko ume da koristi samo glupi Excel, pritom i tu zaglavi pokoji put, zašto da tom nekome komplikujem život (a posredno i sebi)? Vidim da si na tom forumu pisao kako si koristio i C, C++, Perl, Python, Matlab itd. OK, znam i ja programiranje u svim tim programskim jezicima (uklj. Fortran) i da koristim Matlab/Simulink, pa ne doživljavam kao hendikep to što moram da koristim Excel. Jbg, postoje neka pravila igre prvo u okviru tima u kojem radim i kraj.

Vi kao da ne razumete o čemu pišem.

Ja uopšte ne raspravljam o tačnosti. Kome treba 5 a kome 25 značajnih cifara, to zavisi od primene. To je pitanje dužine mantise i ja o tome uopšte ne govorim. Ja govorim o (be)smislenosti rezultata.

Na linku sa vikipedije koji sam dao piše da postoje dve nule - pozitivna i negativna. Onda je logično da bude . Međutim, ostaje drugi problem, što je .



Prvo, beskonačnost može da znači nešto sasvim realno, npr. da su dve linije paralelne itd. Drugo, dao sam primer koji arkustangensom prebacuje beskonačnost u konačnost. I šta onda, kad na navedeni način nećeš identifikovati grešku?



Hvala na ispravci. To je već nešto konkretno.



Ne, ja uopšte ne govorim o tome da li nekome treba 3 a kome 33 sigurne cifre.

Ne mogu da shvatim da ne razumeju o čemu pišem ljudi kao što su Ivan, mmix i Časlave, koje za ove stvari prilično cenim. Ko bre priča o tačnosti?

Pa ne razumem iskreno, ne foliram se. Sta je zapravo priroda tvog prigovora? Razumem tvoj matematicki stav o tome ali ne razumem zasto si toliko protiv IEEE standarda? On je sam po svojoj prirodi falican u odnosu na matematicki model pa ma sta ti radio sa njim. Mislim da preciznost i pominju iz tih razloga jer je float nista drugo do "emulacije" neprekidnog seta realnih brojeva. Sam format medjutim nije neprekidan, ima 2⁶⁴ prekida razlicitih duzina, ima i dve nule kao sto si pomenuo, under i overflow granice, itd i to su sve ogranicenja u odnosu na realni model sa kojim zivis i kojih si svestan i koje prihvatas kao posledicu dogovorenog standarda ili bolje receno kompromisa. Zasto je onda 1/0=Inf problem ako si svestan toga? Ako taj scenario tacke prekida predstavlja realan problem za tvoje proracune onda ces kompenzovati model, zar ne?

Ja. I to se ne odnosi direktno na tvoj problem nego na ovo sto je Ivan rekao: "Kome je potrebna striktna matematicka reprezentacija, taj svakako ne koristi IEEE754."

Mislim da Ivan i Časlav Ilić nisu u pravu kada kazu da se koriste specijalne aritmeticke biblioteke za HPC. One se koriste u manjini i to BAS tamo gdje se mora i NE u cijelom programu nego samo u kriticnim djelovim, zato sto je ta emulacija MNOGO sporija od ciste FP aritmetike.

A sto se tice Nedeljko tvog prigovora, mislim da si u pravu. Umjesto Inf bi trebalo da bude NaN, mada u praksi (bar u HPC) veci problem stvara preciznost, nego to o cemu ti pricas.

Kada pominjete matematiku, očigledno mislite na realne brojeve kojih ima beskonačno, pa čak i neprebrojivo mnogo. Jasno je da se oni ne mogu na računaru modelirati tačno, već samo približno. To niko ne spori i realnost se mora prihvatiti (jer nema drugog izbora).

Međutim, upravo iz razloga što se izračunavanja moraju obavljati u ograničenoj tačnosti, a i ulazni podaci su tipično dobijeni merenjem u ograničenoj tačnosti, postoji oblast matematike koja se zove numerička analiza. To je teorija koja opisuje baš to, a uzima u obzir i efikasnost izračunavanja.

Zadatak implementacije pokretnog zareza treba da bude dobijanje približno tačnih rezultata, koliko to dopušta radu toj ograničenoj tačnosti, pri čemu se mogu praviti kompromisi između brzine i tačnosti. No, rezultat i dalje mora biti smislen, koliko je to moguće.

1/0+=+inf ima smisla, ali dolazimo do problema 1/(x-x)=+inf.

Recimo da su a i b neke veličine takve a<b. Međutim, u računaru su predstavljene istim zapisom, jer su vrlo bliske. Šta je rezultat izračunavanja arctan(1/(a-b))? Pa, +pi/2 umesto -pi/2, što je besmislen rezultat. U slučajevima kada se znak razlike ne može odrediti, rezultat delenja tom razlikom mora biti NaN.

Postoji velika razlika izmedju INF i NaN tretmana.

Ako ostavite INF, radice korektno sva > ili < poredjenja sa standardnim kodom. Sa NaN je neophodan poseban tretman - dakle, opet if() statementi i ubijanje performansi zarad necega sto je u datoj aplikaciji krajnje nebitno.

Tipican primer je digitalna obrada signala, dakle klasicna inzenjerska primena - problem je sto se ti blokovi operacija sa poredjenjem izvrsvaju u petljama i/ili na nizovima brojeva, i neka dodatna logika za poredjenje bi bila losa po performanse - a ne dobija se nista bitno, jer ce i ovako i onako +INF rezultat na kraju biti odbacen negde.

Inace, moguce je sasvim lepo naterati FPU da vam baca exception pri floating-point deljenju sa nulom, ako vam to zaista treba - i onda mozete tu raditi sta god hocete...

Naravno, ubice performanse - ali ako su vam bitniji neki drugi aspekti, postoji resenje.

Nedeljko, razumem ja tebe savrseno sta ti pricas. Ta nekorektnost je prihvatljiva za aplikacije koje koriste IEEE754 format. Kao sto rekoh gore, cak postoji i resenje ako bas zelis drugaciji tretman deljenja sa nulom da ti FPU baci exception i da onda ti to promenis na NaN ako zelis. Mada, to isto sam mozes da uradis sa prostim poredjenjem.

Razlike između inf i nan? Pa, evo nekih.

arctan(inf) = pi/2
arctan(nan) = nan

inf == inf
nan != nan

Opet se vezuješ za jednu cpecijalnu namenu. Koliko se ja razumem, to o čemu pričaš u DSP-u su FFT i još neke operacije nad nizovima realnih brojeva, gde ionako nema delenja, pa em što primer nije reprezentativan, em što se ne može tako usko da se gleda na opšti slučaj.

Ne radi se samo o FFT-u, vec o bilo kom blok-deljenju i blok-poredjenju, gde radis sa gomilom vrednosti.

Takve su gotovo sve rutine u signal procesiranju - od FFT-a koji si pomenuo, do svih mogucih i nemogucih filtera, grupisanja signala, operacija sa vektorima, itd...

Bas zbog toga sto NIJE BITAN taj rezultat deljenja sa nulom, islo se na varijantu koja bi omogucila nepromenjeno ponasanje programa zbog performansi.

Sta da ti kazem, nisi ciljna grupa.

Za one kojima je to problem, predvidjeno je da FPU moze da baca division-by-zero exception... Ili uvek mozes da uradis:



^ Upravo zbog ovih IF provera je cela stvar nepozeljna u normalnoj primeni, a koliko su tranzijentni rezultati nebitni samo pokazuje cinjenica da vecina inzenjerskog i IT sveta jako lepo zivi sa INF rezultatom deljenja sa nulom.

Vrlo loše napisan kod. Ovo je dosta bolje:

Kod je samo tu radi poente (jasno je da poredjenje k treba maknuti iz petlje ako je konstantno, a jeste u ovom primeru).

A na nekim platformama je bolje inicijalizovati ceo niz sa NaN a onda deliti samo gde nije deljenje sa nulom - ako se delitelj menja (tipa ako se deli vektor sa vektorom)

U svakom slucaju, to su stvari koje nisu potrebne vecini.

Da ne pricamo da bi NaN tretman zakomplikovao sve ostalo, gde god se vrsi neko poredjenje i sl.

Kako tranzijenti i ovako i onako nisu bitni u tim aplikacijama, ljudi savrseno zive sa tim i imaju vece performanse izvrsavanja.

Onima kojima je to problem postoji tehnicko resenje da se deljenje sa nulom drugacije tretira.

Dakle, rasprava je besmislena, zato sto postoji resenje za one kojima se ne svidja default ponasanje.

U kojoj to inženjerskoj primeni imaš delenje vektora vektorom?

Vektor = niz brojeva.

U kojoj primeni? U bilo kojoj gde treba podeliti jedan niz brojeva drugim. Od 3D grafike, preko obrade signala....

Recimo ako treba da skaliras ulazni signal sa nekim faktorima skaliranja koji su u nizu, tako da se svodi na jednu operaciju mnozenja. Cesto je taj vektor sa mnoziteljima u stvari reciprocna vrednost (tj. zapravo se deli sa njim) pa u pripremi tog niza reciprocnih vrednosti imas problem potencijalnog deljenja sa nulom.

Ni u jednoj od tih primena ne postoji nikakva razlika izmedju NaN i +INF, jer ce biti iseceni na kraju.

Znači, svodljivo je na množenje, ali ponekad neki glupan radi sa recipročnim vrednostima. To je pogrešan dizajn.

Err.. ne.

Potpuno je nebitno da li mnozis reciprocnom vrednoscu, ili delis - situacije u kojima se susreces sa deljenjem sa nulom su iste, samo ce se desiti ili u procesu generisanja reciprocne vrednosti (1.0/x) ili u procesu deljenja.

Uopste ne zelim da ulazim u to sta je pogresan dizajn jer je to apsolutno besmisleno bez dodatnih detalja o samom algoritmu i platformi na kojoj se izvrsava. Nazivati nesto "pogresnim dizajnom" bez ikakvog znanja o algoritmu ili o platformi te o zahtevima nije nista drugo nego diskusija bez ikakvog smisla. Da ne pricamo da je sve to nebitno uopste za temu.

A poenta je da je u ogromnoj vecini inzenjerskih aplikacija rezultat deljenja sa nulom nije kriticna stvar pa da bude matematicki potpuno ispravan.

Za one KOJIMA TO JESTE problem, postoji resenje.

Dakle, postoji resenje za sve - ogromna vecina koristi podrazumeveno ponasanje, jer joj greska koja se desava u podrazumevenom ponasanju nije bitna a za rezultat imaju efikasan kod koji ne mora da zastaje svaki put i nosi se sa NaN vrednostima. Ona manjina kojoj to jeste problem, moze ili da koristi FPU exception, ili da sami obradjuju deljenje sa nulom u svom kodu.

Dakle, PROBLEMA NEMA.

Nisi razumeo poentu. Nije stvar u tome da ti imaš vektor kojim treba deliti, ali da prvo izračunaš recipročnu vrednost, pa onda množiš njom, već da u startu radiš sa vektorom kojim treba množiti.

Kada izračunavaš vektor kojim treba deliti, ponegde možeš dobiti nulu, ali da si umesto toga računao vektor kojim treba množiti, dobio bi na tim mestima beskonačnost ispravnog znaka, tako da ni kasnije sa množenjem ne bi imao problem. Zato je to ispravan dizajn.

Vidiš, svojevremeno sam radio na jednoj grafičkoj aplikaciji, gde je bilo potrebno odrediti najmanji pravougaonik u kome leži neka Bezijeova kriva. Bezijeova kriva je parametarska kriva, kojoj su obe koordinate polinomi po parametru stepena ne većeg od 3, pri čemu se parametar kreće od 0 do 1. Dakle, trebaju mi minimum i maksimum polinoma na segmentu [0,1].

Ideja je bila da odredim konačan skup tačaka S takav da se minimum i maksimum na segmentu [0,1] dostižu u nekim od tačaka skupa S, a da onda odredim minimum i maksimum vrednosti u tačkama iz skupa S. Skup S se sastoji od tačaka 0, 1 i onih nula izvoda polinoma koje leže između 0 i 1. Dakle, skup S ima najmanje dve, a najviše četiri tačke. Jasno je da je i .

Kada se odredi izvod , onda za (pri čemu se uzima da je nule izvoda izražavaju numerički stabilnim formulama , . Naravno, treba voditi računa o delenju nulom i korenovanju negativnih brojeva.

Konačan kod bi mogao da glasi ovako



Kod je imun na jednakost najviših koeficijenata sa nulom (kada izvod nije više kvadratna, već linearna jednačina) i sve vrste singulariteta, pod pretpostavkom da ulazne veličine nisu toliko velike da množenjem dolazi do prekoračenja opsega float tipa (tj. da se neće dobiti međurezultat +/-inf), što je u tom grafičkom programu ispunjeno. Da nije, koristila bi se ovakva funkcija, koja poziva prethodnu:



Prouči malo ove primere, pa će ti biti jasnije šta je dobar dizajn koda koji nešto računa.

Nedeljko,

Tvoj primer je negde primenljiv, a negde nije - zato sto ti negde treba reciprocna vrednost za nesto drugo, pa mozes da je iskoristis i za ubrzavanje deljenja zato sto je dobijas "besplatno".

To zavisi od zahteva koji se traze od konkretne implementacije i njenih detalja, i kao sto rekoh, potpuno je besmisleno da ulazimo u raspravu oko svrzishodnosti toga "uopste" posto je "uopste" suvise nedefinisano. Nema nikakve poente, niti se bilo sta moze zakljuciti.

Prema tome, da, negde je moguce izbeci deljenje kompletno, a negde nije - negde ti je reciprocna vrednost potrebna za nesto deseto, itd...

U svakom slucaju, to je potpuno nevezana prica za IEEE754 format.

Jel imas mogucnost da promenis rezultat deljenja sa nulom? Imas.

Sta jos vise hoces?

Hoces da dokazes da jesi u pravu? Pa u pravu si - deljenje nulom je matematicki pogresno u IEEE754 formatu, ali je ta greska namerna zato sto je irelevantna za vecinu primena + omogucava vece performanse i manji kod. Za sve primene u kojima je bitno da rezultat deljenja sa nulom ne bude broj - videti recenicu 2 pasusa gore.

Hoću da od svakog delenja nulom koje ne da nan, po jedan cent završi u mom džepu.

Mozda je problem u tome kako razmisljamo o "nulama" u floating point aritmetici. To i nisu tacne vrednosti vec skupovi vrlo malih brojeva.

Tako npr. +0.0f cini skup pozitvnih "malih" vrednosti, dok -0.0f predstavlja skup negativnih "malih" vrednosti. Tacna nula i nije ukljucena u ovaj model.

Tacna nula bi bila (int) 0 za koju po IEE754 zaista i vazi 0 / 0 = NaN.

Jasno je da kod floating point brojeva, nije moguce zapisati reciprocnu vrednost zapisa najmanjeg moguceg pozitivnog broja.

To je prosto zato sto je exponent u komplementu dvojke, te se vrednosti krecu u opsegu (-n-1)..(n).

Tako da je opravdano napisati da je

1 / "+0.0f" = +inf
i
1 / "-0.0f" = -inf

jer "+/-0.0f" i "+-inf" predstavljaju beskonacno male i beskonacno velike velicine u ovom zapisu.

Kao što rekoh, 1/(x-x) = +inf. Zašto je razlika identičnih brojeva pozitivna nula?

Pa ako sam u pravu za predstavu nula.. onda nije ni bitno.. imamo pozitivnu i negativnu nulu. Razlika identicnih brojeva moze da bude bilo sta..

Ne znam.. npr dosta je zgodno, ako je domen f-ije skup pozitivnih realnih brojeva da 1/+0.0f == +inf.

Nisi pratio.

Nedeljko, odgovori na ovo pitanje:

Koji je najveci negativni realni broj?

Da li je tacan odgovor:

1. ne postoji
2. 0-

U "ovozemaljskoj matematici" tacan je odgovor pod 1.
U nestandardnoj matematickoj analizi tacan je odgovor pod 2.

Vidis? I matematika je "prljava", kao i inzenjering, cak, stavise, mnogo prljavija.

Zavisno od konteksta koji se posmatra, od ugla pod kojim se napada problem, prave se dobro definisani kompromisi, sa poznatim ponasanjem, ciji je zadatak da omoguce efikasniju dalju analizu, prakticnu primenu, itd. Ako "cistunci" matematicari mogu da prave kompromise, zasto ne bi mogli i inzenjeri, prilikom prakticne primene matematike? Na kraju krajeva, bez prakticne primene matematika gubi svaki smisao.

Zato sto je to KONVENCIJA, koja je dobro poznata, cije su posledice dobro poznate, koja je uvedena da bi se izbegla gomila drugih problema.

Negativna vrednost te razlike je "negativna nula".



Opet demonstriras neznanje:

1. Ako su a i b predstavljeni istim zapisom, sto se racunara tice, a i b su jednaki.

2. Ako je izraz problematican zbog navedene KONVENCIJE, inzenjer prepoznaje potencijalne izvore problema, i implementira dodatno testiranje/izracunavanje. KONVENCIJA je upravo uvedena da se minimizirao broj slucajeva koji ce iziskivati dodatni kod.

_{[Ovu poruku je menjao blaza dana 12.09.2010. u 22:14 GMT+1]}

Rekao bih da ovde neko drugi demonstrira svoje neznanje.

1. Polje realnih brojeva je bilo koje izabrano kompletno uređeno polje. Kompletno uređeno polje je jedinstveno do na izomorfizam. Najveći negativan realan broj ne postoji.

2. Nestandardna analiza je alternativno zasnivanje matematičke analize koje ne počiva na realnim brojevima, tj. kompletnom uređenom polju, već na zasićenom uređenom polju (za model se obično uzima ultrastepen polja realnih brojeva na prebrojiv beskonačan skup, recimo N), koje zbog zasićenosti ne može biti arhimedovsko, pa samim tim ni kompletno uređeno polje, tj. to nije polje realnih brojeva. No, u tom polju takođe ne postoji najveći negativan element. Štaviše,

Niti jedno uređeno polje nema najveći negativan element, jer su uređena polja uvek karakteristike 0, pa se npr. dvojkom može deliti i uvek zadovoljavaju zakon



Ovim si potpisao svoje nerazumevanje matematike. Matematički iskazi imaju precizno definisano značenje. Da si pitao "koji je najveći negativan element uređenog polja", formulacija bi sintaksno gledano bila nedorečena, jer nisi rekao na koje uređeno polje misliš, mada bi u ovom slučaju bila smislena, jer je odgovor isti za sva uređena polja

U proizvoljnom uređenom polju ne postoji najveći negativan element.

Tako da nemoj svoje frljanje da pripisuješ matematici. Ako si se već uhvatio za netandardnu analizu, tamo ne postoji -0, već neprebrojivo beskonačno mnogo negativnih elemenata beskonačno bliskih nuli.

Naravno da je ceo IEEE 754 standard konvencija. A šta standard drugo može da bude, nego konvencija? Ja samo tvrdim da ta konvencija proizvodi više problema, nego što ih rešava.

Kompromise treba praviti, ali na praktičan način. Ja samo smatram da je ovak kompromis više nepraktičan, nego praktičan.

Praktično bi bilo npr. da postoji samo jedna nula i da delenje njom daje NaN, ili da postoje tri nule, 0+, 0- i 0, pa da delenje ovom trećom daje NaN.



A ko je rekao da nisu? Upotrebio si samo drugi termin za istu stvar i onda se praviš pametan.

predstavljeni istim zapisom = isti za računar.

No, to ne menja činjenicu da postoji razlika između tačnih vrednosti i njihovih aproksimacija u računaru. a i b su tačne vrednosti nekih izraza za koje važi a<b, a u računaru su izračunate kao ista vrednost, jer su bliske. Šta tu nije jasno?

Konačan odgovor je dao Ivan, da postoje rešenja i za druge situacije.

Evo jos jedne zanimljivosti, slucaj kada je apsolutna vrednost negativan broj u dzavi:
Funkcija abs u ovom slucaju vraca -2147483648.

Pa, Java nema unsigned int, a najnegativniji int je invarijantan ya potpuni komplement.

Da ali opet se od Math.abs ocekuje da vrati apsolutnu vrednost broja, mada je ovo u Java dokumentaciji navedeno kao izuzetak:


dakle ista prica kao sa pocetka teme - inzenjerski kompromis...

Bolje rešenje od onog koje džava ima je postojanje neoznačenih celobrojnih tipova, a bolje od IEEE 754 rešenja sam naveo.

#include <stdio.h>
#include <math.h>

int main (int argc, const char * argv[]) {



int a;
a = pow(0.0,0.0);
printf("Hello, World!\n %i",a);
return 0;
}

Rezultat je :


Hello, World!
1

A koliko bi to trebalo biti? Da pitamo nastavnika matemeatike, to je gradivo osnovne skole.
Pa naravno da je 0^0 = 1 proveri na googlu, u Pythonu, u Matlabu ili i knjizi za osnovnu skoli prvi cas stepenovanja...
Zamislite da je cak i 0! = 1 i to pise u knjizi za srednju skolu, toga nema za osnovce.

here we go again ...

Da mi to Lopitalimo ipak

To je neodredjena forma i zavisi od konteksta u kojem se koristi. Poenta price je kompatibilnost 2 aplikacije: OO.org Spreadsheeta i MS Excela.

0^0=1 u celobrojnoj aritmetici. U realnoj je nedefinisano.

Poštovana gospodo, ovakva tema koja zauzme par stranica foruma, možda i nije loša zbog dijaloga uopšte. Šteta što se ne radi ni o kakvoj "višoj matematici". Naime da ste slušali malo pažljivije nastavnika matematike u sedmom razredu, kada ste učili stepenovanje i pojam stepena sve bi vam bilo jasno. Evo da ne pametujem:
Stepen je broj koji se množi više puta samim sobom. Broj koji se množi zove se baza ili osnova a koliko puta se množi ( onaj mali brojkić iznad) zove se eksponent ili izložilac. Ako želimo pomnožiti dva stepena istih osnova onda to uradimo na način da bazu prepišemo a eksponente saberemo npr. 2²•2²=2²⁺² ili 4•4 =2⁴=16. Ako pak želimo podijeliti dva broja istih osnova onda bazu prepišemo a eksponente oduzmemo 2²:2² što je 4:4 =1 isto kao i 0⁰=1. Prema pravilu da svaki broj podijeljen samim sobom daje vrijednost 1. Broj 0 nije "ništa" nego broj kao i svaki drugi i ima svoje mjesto na brojnoj osi a to što na skromnim digitronima pokazuje grešku je samo znak njihove nemoći da rade operacije sa stepenima. Uostalom na vašem kalkulatoru kojeg dobijate uz windows-e promijenite izgled (view) u scientific i probajte otkucati "0 x^y 0 =" i vidjet će te da je rezultat 1.

Koliko je ? Kako se u ovu tvoju priču uklapa čuvena formula ?

@niho,

Ozbiljno?

Posle 5 stranica i ljudi koji se bave matematikom na akademskom nivou i njihovih objasnjenja tvoj krunski dokaz je "zdravorazumska" logika izvucena iz simplifikovane materije za 7 razred?

Ne bih rekao da je tako. Nula je ipak nešto drukčija. Ako deliš nulu sa nulom možeš dobiti bilo koji broj.
Zamisli da je u brojitelju ta nula limes neke funkcije, a u imenitelju nula je limes neke druge funkcije i
onda pomoću Lopitala nađeš kolika je ta vrednost 0/0 koja ne mora biti 1. Ako ne znamo na osnovu koje
funkcije ili zakonitosti je dobijena nula u brojitelju i ako ne znamo to isto za nulu u imenitelju onda ne
možemo znati ni rezultat. Pisanje bilo kakvog rezultata koji ne vodi računa o načinu odnosno zakonitosti
po kojoj su nastale te nula je besmisleno. To važi i za matematičare i inženjere. Ne postoji posebna
matematika za inženjere. Praktične potrebe i aproksimacije u tom smislu nisu nikakva druga matematika
već jedna te ista samo što su za praksu dovoljna i približna rešenja.

Dakle moraš znati kako si dobio nulu u imenitelju i kako si je dobio u brojitelju.

Pozdrav, matematiku sam diplomirao 30. septembra 1982. godine. Do sada mi nije palo na pamet da na ovakvim forumima (nemojte pogresno shvatiti, jako cijenim ovaj forum) vršim teorijska izlaganja matematičke teorije i analize iz prostog razloga i priče o intelektualcima, špriceru i kavurmi. Zbog šarolikosti populacije koja koristi ovaj forum mislim da treba pisati što jednostavije (iliti popularnije). Zaboga već odavno ste otišli u off-topic. Pročitajte prvo naslov pa moj post do kraja i onda postavite pitanje, nigdje veze! Ako već želite da pišete o matematici ili pak bilo kojoj drugoj nauci zamolio bih Vas da to uradite na Wikipediji gdje sve više ljudi dolazi očekujući pomoć i rješenje problema a ista je u dubokoj krizi, jako malo tekstova ima o ovoj temi. Znam, lakše je to raditi za šankom. @atelago potpuno se slažem s Vašim mišljenjem ali i to je izvan teme, zar ne. @Nedeljko a ko Vas zanima rezultat lako ćete izračunati a ako se pak radi o još jednoj forumaškoj priči otvorite je kao novu temu, što da ne, i mene zanima koliko ljudi interesuje ta priča :)

@niho22:

Znaci po tvome je 0/0=1?

Koliko je onda 5*0/0? 5? ili opet 1? I odakle se sad pojavila vaznost precedencije operatora? :)

Pa, sve što je na forumu je forumaška priča! Nego šta je? Svašta.

Ne, nego si se našao u nebranom grožću, vidiš da ti priča ne drži vodu i onda lansiraš ovakve floskule.

Da vidimo,





Stvarno nigde veze. Sva argumentacija ti je spala na ovo

Nedavno sam citao excell 2007 biblija i znate sta pise: programeri lotusa su tako napravili pa je onda i excel morao tako da radi, jeste greska ali zbog kompatibilnosti je moralo tako

I to je open office calc samo preuzeo

Mislim da si pomešao Excel sa Matlabom

Dobro, apsolvirali smo da je u matematici , a u inženjeringu .

Mali zakasneli offtopic za Nedeljka: napiši program koji rešava kvadratnu jednačinu. Nema sumnje da znaš dosta o matematici, ali IEEE754 je pravljen kako je pravljen i mnoge odluke su donesene da bi se sačuvalo što je više moguće izraza uobičajene matematike i pored fundamentalnog ograničenja da realnih brojeva ima neprebrojivo mnogo a FP konačno mnogo. Npr denornalizovani brojevi koji svima izgledaju nepoterebni (i komplikacija u procesoru, dodatni stageovi u FP pipelineu), omogućavaju da if (a!=b) c=1/(a-b), c ne bude Inf. Sa druge strane, FP aritmetika ne trpi razna tumbanja izraza tj dovodi do različitih rezultata, npr x^2/sqrt(x^3+1). Pomenuo si atn, ja ću tan. Po tamo nekoj teoremi ako hoćeš tan(Pi/2)=Inf2 treba ti Pi/2. Ali bedaka, Pi/2 nije racionalan broj što svi FP brojevi jesu), a moguće je dokazati čak i da se zaokruži sve kako treba, nećeš dobiti Inf. Takođe sam oblik izraza može daleko da utiče na to šta dobiješ pa da li je kriva FP aritmetika ili neko ko je smatra za realnu.

Takođe ne zaboravi kompajlere, koji su notorni po pitanju tumbanja FP izraza čak i bez pitanja, plus Intelova specijalka da double u registru ostaje na 80b, a kad se stavi u memoriju skreše se na 64b (i tu se može dokazati da dvostruko zaokruživanje sa 64 na 53 bita mantise može da napravi grešku na zadnjem bitu). Mogu da iskopam čitavu listu kratkih triperaških programa koji izbacuju nebulozne rezultate čim se malo čačnu opcije kompajlera ili su jezivo osetljivi na greške zaokruživanja. Npr Kahnovu sumacionu formulu pametan kompajler može sasvim da uništi jer "eliminiše nepotrebne izraze". Da su pitanju integeri jesu nepotrebni, ali ovde jok. Ili recimo broj se kvadrira, od njega se oduzme isti taj kvadrat, izračuna se kvadratni koren od toga i mesto nule dobije se NAN. Opet, problem nije u IEEE754 već u tome što kompajler čačka kod računajući da važi realna aritmetika.

Pre par godina meni su na ovom forumu rekli da nema šansi da nađem bagove u math.h, a Visual Studio 2008 ima jedan takav sočan, kriminalan bag da je to prosto fascinantno i to baš u sin(x) koju sam jednim malim krpežom dovukao da bude pristojnija (bez gledanja u disasemblirani kod, a po tome kako se manifestuje, rekao bih: kao od bede odrađena redukcija argumenta na osnovni interval). I onda neki iskusan programer kaže da math.h može da se uradi sa malo realne analize (Tejlorov polinom itd), takorekuć srednjoškolci.

Ako te zanima, mogu te uputiti na par knjiga koje se bave neki vrlo pipavim detaljima FP aritmetike i svom tom "dark side" tematikom, kao i razlozima zašto su neke stvari rešene kako su rešene (jel neko primetio da IEEE754 nema zaokruživanje OD nule već samo KA nuli?, ali je to ubačeno u najnoviju reviziju standarda, i to zbog decimalne, a ne binarne aritmetike). Takođe, elementarne funkcije sa FP aritmetikom su posebna priča gde ima gomila mesta gde može da se uništi tačnost (4 bita ili 1 decimalna cifra) iako je sve rađeno "zdravorazumski", a posledično stradaju i i identiteti tipa sin(x)=sqrt(1-cos^2(x)). Pow(x,y) kao exp(ln(x)*y) no comment, tako nešto je krajnje neozbiljno sem ako se sve kalkulacije ne rade u znatno većoj tačnosti (koliko većoj? za sada nije poznat odgovor).

Inače, ko misli da je rešavanje kvadratne jednačine lako, neka proba da napiše program koji će trpeti sve moguće varijante (sumanut odnos koeficijenata a a rešenja sasvim normalni brojvi, gubitak tačnih cifara, mesta gde se može desiti overflow i underflow tokom računanja..). Dobijeni program je sve samo ne trivijalan.

Sve je ovo suvo naglabanje i teranje maka na konac dok su u igri školski primerčići sa ulazima koji su fini, obično celi brojevi.

Ontoppic: zar ne beše ako su f i g analitičke funkcije i f(0)=g(0)=0, da je onda lim (x->0) f(x)^g(x)=1 ?

Šta ti misliš? Da ja ne znam šta je pokretni zarez? Je li leba ti, odakle si izvukao tako genijalan zaključak?

Vidiš, svaki algoritam se načelno može izvršavati na računaru ili peške, na papiru. Sledstveno tome, ne postoji nikakva fundamentalna razlika između računa na papiru i računa na računaru, jer i u jednom i u drugom slučaju treba dobiti rezultat u konačnom broju koraka.

Postoje dva fundamentalno različita načina računanja, simbolički i numerički i oba su ostvariva i na papiru i na računaru. Simboličkim oblikom se ne gubi tačnost rešenja, ali je taj oblik nepodesan za poređenja. Numeričkim oblikom se gubi tačnost, ali je podesan za poređenje.



Prema prthodnom se mogu napisati dve vrste takvog programa - za simboličko i numeričko rešavanje kvadratne jednačine. Nijedno od to dvoje nije nikakav problem za realizaciju. Evo, prilažem numeričko rešenje za slučaj kada su rešenja realna i kada je jednačina zaista kvadratna. Mrzelo me je da se bakćem više od toga.

Što se Kahanove formule tiče, nju može da upropasti samo glup kompajler koji misli da je mnogo pametan, budući da sabiranje u pokretnom zarezu nije asocijativno.

Kada jednom nađeš približna rešenja kvadratne jednačine, možeš ih popraviti nekim numeričkim postupkom.

Naravno da ne.

Na žalost, u pravu si.