DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   Programiranje (http://www.devprotalk.com/forumdisplay.php?f=23)
-   -   objektno orjentisano programiranje (http://www.devprotalk.com/showthread.php?t=7205)

kaizen 05. 03. 2009. 17:59

Citat:

Originalno napisao kaizen (Napišite 67046)
Kôd:

System.out.println(100000 * 100000);

Inače degojs nisam siguran da si razumeo poentu moje poruke sa ovim parčetom koda. Netačan rezultat koji se dobija je direktna posledica upotrebe tzv. "primitivnih" tipova podataka.

jablan 05. 03. 2009. 18:07

Citat:

Originalno napisao bluesman (Napišite 67062)
Yebesh oop :)

Da onda lepo pozatvaramo radnje i uposlimo Indijce? Jebeš učenje i napredovanje, jebeš razmenu znanja, jebeš forume... Što ne odrade Indusi, odradiće naši magični editori i svi zadovoljni...

Dragi Tata 05. 03. 2009. 18:09

Citat:

Originalno napisao bluesman (Napišite 67062)
Ja sam imao zadatak da ga implementiram na jedan sajt i odustao sam pa sam napisao svoj kod...

Eto, sam si odgovorio na pitanje "čemu sve to".

Citat:

Originalno napisao bluesman (Napišite 67062)
Yebesh oop :)

Tu se manje-više slažem. Napravili su celu religiju od obične programerske paradigme.

Dragi Tata 05. 03. 2009. 18:15

Citat:

Originalno napisao kaizen (Napišite 67063)
Inače degojs nisam siguran da si razumeo poentu moje poruke sa ovim parčetom koda. Netačan rezultat koji se dobija je direktna posledica upotrebe tzv. "primitivnih" tipova podataka.

Strogo govoreći, nije. Problem je u operatoru za množenje koji sasvim lepo može da se napravi tako da baci izuzetak kod integer overflow situacija i sa "primitivnim" brojevima.

U stvari, priznajem da sam iznenađen da čujem da Javin operator za množenje nije tako urađen.

kaizen 05. 03. 2009. 18:19

Citat:

Originalno napisao Dragi Tata (Napišite 67066)
Strogo govoreći, nije. Problem je u operatoru za množenje koji sasvim lepo može da se napravi tako da baci izuzetak kod integer overflow situacija i sa "primitivnim" brojevima.

Nije šija nego vrat :) Pa bacanje izuzetka je takođe zbunjujuć i neočekivan rezultat za početnika (ne zaboravi konteks oko čega je započeta rasprava, a to je da je "prirodnije i razumljivije da broj nije objekat"). Jedini prirodan, razumljiv i očekivan ishod je da dobije ispravan rezultat množenja.

Dragi Tata 05. 03. 2009. 18:28

Citat:

Originalno napisao kaizen (Napišite 67067)
Nije šija nego vrat :) Pa bacanje izuzetka je takođe zbunjujuć i neočekivan rezultat za početnika (ne zaboravi konteks oko čega je započeta rasprava, a to je da je "prirodnije i razumljivije da broj nije objekat"). Jedini prirodan, razumljiv i očekivan ishod je da dobije ispravan rezultat množenja.

Hteo sam da kažem da je sasvim moguće da operator za množenje detektuje integer overflow i sa primitivnim tipovima a da li će da baci izuzetak ili da bude pametan pa vrati tačan rezultat (što i nije uvek moguće uostalom - šta ako ne postoji integer tip dovoljno veliki da "spakuje" rezultat?) to opet nema veze sa objektima već sa implementacijom operatora množenja.

degojs 05. 03. 2009. 18:33

Citat:

Inače degojs nisam siguran da si razumeo poentu moje poruke sa ovim parčetom koda. Netačan rezultat koji se dobija je direktna posledica upotrebe tzv. "primitivnih" tipova podataka.
NE. To je ograničenje kompajlera, a ne prostih tipova podataka. Kompajler koji bi po difoltu te vrednosti tretirao kao npr. long ili double neće imati problem, a i dalje su "primitivi" u pitanju.

kaizen 05. 03. 2009. 18:33

Citat:

Originalno napisao Dragi Tata (Napišite 67068)
... pa vrati tačan rezultat (što i nije uvek moguće uostalom - šta ako ne postoji integer tip dovoljno veliki da "spakuje" rezultat?)

U tome je i moja poenta zašto "krivim" tip podatka. Kada je broj objekat, čuvanje vrednosti je unutrašnja stvar objekta pa može biti realizovana na razne načine. Da demonstriram:

Kôd:

>> 10000000.class
=> Fixnum
>> 10000000.class.superclass
=> Integer

Kôd:

>> 100000000000000000000000.class
=> Bignum
>> 100000000000000000000000.class.superclass
=> Integer

Kôd:

>> 10000000 * 100000000000000000000000
=> 1000000000000000000000000000000


kaizen 05. 03. 2009. 18:41

Citat:

Originalno napisao degojs (Napišite 67069)
NE. To je ograničenje kompajlera, a ne prostih tipova podataka. Kompajler koji bi po difoltu te vrednosti tretirao kao npr. long ili double neće imati problem, a i dalje su "primitivi" u pitanju.

ma daj, a kada izađe iz njihovih okvira?

Kako ne vidiš da je problem isti kao kada ne enkapsuliraš neki objekat. Umesto da radiš sa interfejsom broja a da te ne zanima kako je realizovano njegovo čuvanje u memoriji, ovde radiš direktno sa tom vrednošću.

degojs 05. 03. 2009. 18:46

Kada izađe iz okvira tih tipova podataka, slažem se da brojevi kao objekti imaju prednost. Živ mi bio, pa kad izađeš iz okvira double tipa, pa se čujemo.. Jednostavno: koliko često se to tebi dešava na poslu?

Dragi Tata 05. 03. 2009. 18:47

Citat:

Originalno napisao kaizen (Napišite 67070)
U tome je i moja poenta zašto "krivim" tip podatka. Kada je broj objekat, čuvanje vrednosti je unutrašnja stvar objekta pa može biti realizovana na razne načine.

Kapiram. Mada, ako imaš BigNum tip, tvoj primer opet može da radi lepo i sa "primitivnim" brojevima kao argumentima - glavno je da postoji overload operatora za množenje koji vraća BigNum objekat. Doduše, onda se problem javlja sa izrazima tipa:

Kôd:

int rezultat = 10000000 * 10000000;
Još jedan tipičan primer Lisp vs Fortran filozofije :)

Inače, da malo zezam Dinketa, u assembleru je trivijalno rešiti ovaj problem - samo proveriš overflow flag posle svake aritmetičke operacije :D

kaizen 05. 03. 2009. 18:50

Citat:

Originalno napisao degojs (Napišite 67072)
Kada izađe iz okvira tih tipova podataka, slažem se da brojevi kao objekti imaju prednost.

:1090: :1029:

degojs 05. 03. 2009. 18:52

:)

Da zaključimo, prelazimo na brojeve kao objekte jer na sveto NIKAD može da se desi da izađemo iz okvira long ili double tipa. Kog datuma je to crveno slovo u kalendaru? :)

Dragi Tata 05. 03. 2009. 18:57

Citat:

Originalno napisao degojs (Napišite 67075)
:)

Da zaključimo, prelazimo na brojeve kao objekte jer na sveto NIKAD može da se desi da izađemo iz okvira long ili double tipa.

Nemoj da si previše siguran. Integer overflow je ozbiljan sigurnosni problem. Vidi recimo ovde: http://www.phrack.org/issues.html?is...&id=10#article

Ja često koristim ovo: http://www.codeplex.com/SafeInt da izbegnem integer overflow.

degojs 05. 03. 2009. 19:02

^Ako bi po difoltu koristio long (64), koliko često bi imao taj problem?

BTW, prvi link nešto neće.

degojs 05. 03. 2009. 19:07

E da, Nemanja, imam još jedno pitanje za tebe: jesi li ti ono pre radio nešto vezano baš za intenzivan rad sa (velikim?) brojevima? Čini mi se, ako si ti bio u pitanju, da reče da se tu uopšte ne koriste danas main-stream jezici (OOP ili ne), već Fortran?

Dragi Tata 05. 03. 2009. 19:10

Citat:

Originalno napisao degojs (Napišite 67077)
^Ako bi po difoltu koristio long (64), koliko često bi imao taj problem?

BTW, prvi link nešto neće.

Pitanje "koliko često" se ne postavlja kod sigurnosnih propusta. Ako "evil-doer" provali da imaš overflow problem on će lako da ti prebaci 64-bitni long.

Meni link radi. Uostalom, samo udari search za "Integer Overflow" i naći ćeš puno interesantnih stvari.

degojs 05. 03. 2009. 19:12

Citat:

Pitanje "koliko često" se ne postavlja kod sigurnosnih propusta. Ako "evil-doer" provali da imaš overflow problem on će lako da ti prebaci 64-bitni long.
Zašto bih ja imao overflow problem, mislim, nije li to moguće sprečiti nekakvom proverom?

Odnosno, hoću da pitam - da li ti je u praksi zaista potrebno da imaš tačan rezultat van opsega long tipa? Ako nemaš potrebu, onda to ne vidim kao problem.

Dragi Tata 05. 03. 2009. 19:12

Citat:

Originalno napisao degojs (Napišite 67078)
E da, Nemanja, imam još jedno pitanje za tebe: jesi li ti ono pre radio nešto vezano baš za intenzivan rad sa (velikim?) brojevima? Čini mi se, ako si ti bio u pitanju, da reče da se tu uopšte ne koriste danas main-stream jezici (OOP ili ne), već Fortran?

Jeste, za numeričke kalkulacije je Fortran ne tata nego deda :) Kod takvih primena OOP slabo prolazi.

degojs 05. 03. 2009. 19:17

^ kaizen, eat that :D

:1090: :1029:

Dragi Tata 05. 03. 2009. 19:26

Citat:

Originalno napisao degojs (Napišite 67080)
Zašto bih ja imao overflow problem, mislim, nije li to moguće sprečiti nekakvom proverom?

Jeste, što da nije. Npr, lako je dokazivo da:

Kôd:

int i = 1 + 2;
Nikad neće dovesti do overflow-a. Problem je kad imaš integere koje direktno ili inderektno unosi korisnik. Onda praktično pre svake operacije koja može da dovede do overflow-a moraš da vršiš proveru. Npr:

http://www.daniweb.com/code/printsnippet260.html

kaizen 05. 03. 2009. 19:31

Citat:

Originalno napisao degojs (Napišite 67082)
^ kaizen, eat that :D

:1090: :1029:

:) pa dobro sad, ja ne znam Fortran, tako da se neću upuštati u raspravu šta to Deda Fortran magično radi sa numeričkim kalkulacijama što ne mogu unuci ...

degojs 05. 03. 2009. 19:42

Samo da dodam, upravo proverio, imamo malo pomoć u samom jeziku (naravno, gde ne mora, onda se ne preporučuje):

checked (C#)

The checked keyword is used to control the overflow-checking context for integral-type arithmetic operations and conversions. It can be used as an operator or a statement according to the following forms...

degojs 05. 03. 2009. 19:46

Citat:

Originalno napisao klaizen
pa dobro sad, ja ne znam Fortran, tako da se neću upuštati u raspravu šta to Deda Fortran magično radi sa numeričkim kalkulacijama što ne mogu unuci ...

E ebi ga. Ni meni se ne ide u raspravu "šta ako long ili double nisu dovoljno veliki" jer nešto nisam siguran da je meni, a i tebi, to stvaran problem - da mi je potreban tačan rezultat van opsega tih tipova.

Dragi Tata 05. 03. 2009. 20:39

Samo pazi - te "fortranske" kalkulacije se izvode sa floating point brojevima a ne integerima. Kod floating point brojeva, često je hardver u stanju da uhvati overflow. Npr, na Windowsu takva stvar završava SEH-om STATUS_FLOATING_OVERFLOW

degojs 05. 03. 2009. 21:34

Pa dobro sad, float, int, whatnot, bitno objekte i Rubi ne koriste :)

merjadok 06. 03. 2009. 12:50

On topic:
Milenko, pošto si napisao da si zainteresovan za časove, možda ne bi bilo loše da podgledaš neka (još bolje sva) predavanja sa sledećeg linka:

http://see.stanford.edu/SEE/lecturel...a-866adcae1111

Citat:

Topics focus on the introduction to the engineering of computer applications emphasizing modern software engineering principles: object-oriented design, decomposition, encapsulation, abstraction, and testing.
Pozdrav,

filmil 07. 03. 2009. 11:40

Off Topic:
Citat:

Još jedan tipičan primer Lisp vs Fortran filozofije :)
Извињавам се што упадам усред озбиљне расправе, али...

Wooooohooooo!!!

ф


Vreme je GMT +2. Trenutno vreme je 07:44.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.