Nisam programer, ali verovatno neki error, jer ne vidim da se zatvorio taj tag <?php

Ne postoji sintaksna greška. Kod je ispravan. Kod php-a se i ne preporučuje pisanje zatvarajućeg taga ukoliko nije neophodno, jer se može desiti da zbog nekog spejsa iza zatvarajućeg taga nenamerno pošaljemo sadržaj pre hedera...

Rezultat ovog programa je celi broj. Promenljiva x ima inicijalnu vrednost 1. Operator ++ uvećava promenljivu za jedan. Plus sabira vrednosti. Rezultat je _____

P.S.
Napisao sam maločas da bi trebalo da je isti rezultat i kod ostalih jezika iz C familije, pa rekoh da testiram C i JS i rezultat se razlikuje :) C i PHP daju isti rezultat.

Unarna operacija dobila prioritet.



Mislim da je to pre ko zna kliko godina opisano u dokumentaciji za php.

Da, zato je prethodno rešenje 4. Zašto je ovde 3?
JS:

0001
0010
------
0011

Ovde je dovoljno samo da prepoznate o kom programskom jeziku se radi :)

@everback

Code daje uvek ocekivan rezultat -> jer za razliku od ljudi, ima jasno navedena pravila po kojima se taj rezultat dobija, po kojima radi. Eventaulne greske nastaju kod preciznosti... ali to je neka druga tema.
To sto si ti naveo je primer loseg programiranja. Tj. primer bas kako ne treba da se pise code - jer code na prvom mestu treba da bude jasan. Ne bi bio kraj sveta da je kreirana jos jedna promenjiva, i vishe ne bi bilo razmatranja sta ce biti kako interpretirano i gde.

...

[to state the obvious:]
Ovo je primer right first vs left first evaluacije izraza... Tj. u jednom slucaju racunanje izraza pocinje prvo sa desne strane, gde se inicijalni broj ikrementira za 1 i postaje 2, i posle sabira sam sa sobom, sto je (sada 4, jer je u mejuvremenu postao 2 umesto 1). Dok u drugom slucaju on je 1, i sabira se sa samim sobom inkrementiranim za jedan, tj. sa 2, pa daje 3 kao rezultat.

Opet, idiotski primer (isforsiran), koji sluzi samo da objasni kako kod ne treba da izgleda. Tj. sta da se izbegne, ako se zeli jasan i pravilno napisan kode. Kao i da prikaze razliku izmedju left i right evaluacije izraza.

Obicno se ta evaluacija koristi, kad se zeli ubrzati/napraviti cistiji kode, da se ne pishe pedeset if-ova...


if (mojPointer != null && mojPointer->nekaVrednost < zeljenaVrednost)
{
obavestiMamuDaJeSkuvanaSarma();
}

U tom slucaju left first chekira da li je uopste pointer setovan... pa tek onda u ostatku izraza trazi promenjivu iz njega, ako jeste. Ako nije odma preskace ceo blok. Ali opet, treba znati specificnosti jezika i kompajlera ako se pise takav code. Sigurnije je pisati dva odvojena if-a.





_{[Ovu poruku je menjao Cube25 dana 19.01.2018. u 13:07 GMT+1]}

Ljudi očekuju rezultat, tako da kod ne može da daje uvek očekivani rezultat. Kod nema pojma šta ljudi očekuju. Očekivanja su često nerealna :) Uglavnom, ovo je tema o tome, a ne o dobrom kodu.

P.S.

Ne kaže se idiotski nego idiJotski.

P.P.S.

Samo se zezam, idiotski je ispravno, nije ispravno iZforsiran.

Ne znam za PHP, ali u C-u ti je to undefined behavior. Dvaput menjanje vrednosti varijable bez intervenieng sequence poijnt ;)
eidt:
Zapravo nisam siguran posto samo printas, najverovatnije je ok ;)

Zapravo, nije izvesno da će rezultat biti 4. Svakako ++ ima prednost nad +, što znači da će svakako sabiranje biti izvršeno nakon ++, ali pitanje je koje dve vrednosti će biti sabrane, tj. da li će vrednost levog $x biti uzeta u obzir pre ili posle primene ++ (što nije ni u kakvoj vezi s prioritetom ++ u odnosu na +). Pogledaj ovde:

Zapravo jeste undefined behavior kako sam pretpostavio ;p

@Bojan
Ok, onda ovo jeste definitivno kod koji proizvodi neočekivani rezultat, a sada je jasno i zašto JS daje vrednost 3.

@Branimir Maksimovic
Kod mene je prošlo kompajliranje i rezultat je 4. Kompajler je gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609. Sigurno je da i kod C-a rezultat zavisi od implementacije kompajlera. Čini mi se da je u poslednjim verzijama c++ standarda to definisano.

Kada sam već tu, čudni kod nešto iznad je Intercall i prikazan je najjednostavniji način kako da se u ovom programskom jeziku ispiše na konzoli Hello word. Naravno ja ne znam Intercall.

Undefined behavior je greska u run-time ;)
Ja sam kompajlirao sa gcc-trunk i to je najsveziji moguci koji ti cak daje warninge i o nedefinisanom ponasanju ;p

Očigledno, kao što su neki rekli, inkrementiranje ima prioritet.

Međutim, interesantno je da sledeći kod radi normalno:

Kako parsuje +++ ?

Verovatno kao $x++ +$x

meni je zanimljivije da eclipse dozvoljava

gde ne zna da li hocu x++ ili ++x
a ne dozvoljava

gde bi mu bilo jasno da sigurno ne mislim 1++ dok je 1+ ++x sasvim legitimno

a x++ +x kao i x+ ++x daju rezultat 3

Iz toga sto si napisao bi se dalo zakljuciti da inkrement x++ inkrement ima prednost u odnosu na sabiranje pa je x+++x zapravo (x++)+x. Iz tog razloga 1+++x ne prolazi jer je to (1++)+x a 1++ ne moze da se izvrsi.
Isto ponasanje je i u C# / Visual Studio. x+++x moze, x+++1 ne. Takodje, x+++x je automatski formatirao (dodao space-ove) i napravio x++ + x.

Ne verujem da se Eclipse tu nešto pita. Javac ne dozvoljava inkrementiranje literala.

Ovo je C ekvivalent:



inc mora da se izvrši pre plus jer je rezultat od inc operand za plus. Međutim, redosled izračunavanja operanada od plus (prvo prvi, pa drugi ili prvo drugi, pa prvi) je nedefinsan. Prepušta se kompajleru da postupi kako hoće u cilju optimizacije. Kada na GNU/Linux sistemu kompajliram GNU-ovim gcc-om, dobija se 4, a kad kompajliram Apple-ovim clang-om, dobijam 3.

Kada x + ++x kompajliram clang-om, dobijam upozorenje "unsequenced modification and access to 'x' [-Wunsequenced]".

Pa vidi ovo nije nimalo isto kao osnovni primer, zato sto je u prethodnom slucaju undefined, a ovo tvoje unspecified ;)
Razlika je u tome sto kod undefined, kompajler moze da uradi bilo sta (recimo lansira raketu), a kod unspecified mora da da rezultat ali koji nije specificiran ;p

Zamenio sam prefiksno inkrementiranje unarnom funkcijom i sabiranje unarnom funkcijom da se lepše vidi.

U čemu smatraš da je tačno razlika?

Pa funkcija izmedju parametara ima sequence point ali je redosled evaluacije parametara unspecified, dok operatori nemaju seqence point, pa se istovremeno vadi i menja vrednost x sto je undefined behavior.

edit: naravno ovo se odnosi na C i C++, ne na druge jezike.

_{[Ovu poruku je menjao Branimir Maksimovic dana 20.01.2018. u 18:45 GMT+1]}

Možeš li to da dokumentuješ?

Drvo izračunavanja je sledeće:



redosled izvršavanja grana je nedefinisan. Isto važi i za operatore.

Opste poznata stvar...

Nije nedefinisan nego nespecificiran. Kazem postoji velika razlika u nedefinisanom i nespecificiranom ponasanju u kompajlera kod C i C++.
Pitanje je jedino jel ovo tvoje unspecified ili undefined. Tu nisam siguran posto nisam pogledao u citap.

I ne bih lenj da proverim:



Znaci samo u slucaju da direktno inkrementiras u parameter listi je undefined, a u tvom slucaju, posto zoves inc, to je unspecified
zato sto poziv f-je ubacuje sequence point, a ne zarez u parameter listi kako sam prvo mislio ;)

Undefined behavior - ponšanje može biti u istom stanju mašine različito, odnosno isti program pokrenut više puta sa istim ulazima može imati različito ponešanje i rezultate. Primer: ponašanje zavisi od vrednosti promenljive kojoj prethodno nije dodeljena vrednost, pa je vrednost u principu nasumična (zatečeno stanje u memoriji).

Unspecified behavior - ponašanje nije definisano standardom, pa program kompajliran različitom kompajlerima može imati različito ponašanje. Primer: redosled izračunavanja argumenata funkcije na mestu poziva ili redosled operacija koje se izvršavaju u različitim nitima.

Pogodite sta ovo daje kao rezultat ;)
Samo moze sa C kompajlerom, C++ ovo ne moze da proguta.

Oba rezultata "čini" mi se da su dobra jer razlika je minimalna, samo jedan (1)

Kada se karakteri u stringu "9>AEFK" pomere za deset mesta dobijemo karaktere "CHKOPU", što su gle čuda sve karakteri u tvom imenu. Pretpostavljam da će rezultat rada programa biti tvoje ime.

Ali treba da znaš da rand funkcija nije standardizovana. Razni kompajleri proizvode različite rezultate za isti početni seed. Čak i isti kompajleri u različitim verzijama mogu da proizvedu različit rezultat. Zato, ono što funkcioniše kod tebe ne mora da funkcioniše kod nekog drugog.

On to vrlo dobro zna, ali je zajebant. Pored ostalog, gcc mu izbacuje upozorenja




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

Ono sto je neocekivano u tom kodu je sto ljudi ne razlikuju teoriju od prakse. Naime, u teorijiu izmedju teorije i prakse nema razlike, ali u praksi i te kako ime.

Ajde da se malo poigramo sa nekim cudom kompajliranim kodom. Uradimo listu simbola tako kompajliranog programa.



Sta mozemo videti, da je gomila funkcija definisano, ali ne i rand i srand. Koja naime pripadaju glibc-u. Dakle mozemo slobodno da tvrdimo da rand nije deo jezika nego standardne biblioteke. Samim tim cime god da kompajliras i ako ne menjas standardnu biblioteku davace isti kod.

A ako odemo jos korak dalje i vidimo da li je stdlib po POSIX.1-2001. A da kazemo da nema smisla ako nije :)))), onda cemo videti da se uvek isto implementira rand i srand.

Sve u svemu jos jedna neocekivana stvar je da ce na skoro svim linuxima, androidima, openwrtovima da da isti rezultat :). E sada i to mi je dovoljno :)))). Sve u svemu kod daje neocekivan rezultat, na prvu loptu, a kada razmislis shvatis da radi :)))).

Sve u svemu, jesam zajebant i znam da skolnim upozorenja, ali eto volem da imam u jednom redu potpis :).

P.S. Ideja je originalno moja. a program je sladak, pricali vi sta hocete :))))).

A ko garantuje da će kompajler koristiti glibc implementacije funkcija rand i srand, a ne neke svoje? Da li će sve verzije glibc-a da imaju istu implementaciju?

Ma, kapiram ja tebe, samo može kraće i preglednije:

Uspeo sam da nađem još kraće i čitljivije rešenje:

Chupcko:


Sjajno !

Ovo je sample implementacija iz standarda:



No nije obavezno da kompajler to koristi.

Naravno, zezam se. Sledeća "primedba" bi bila: "A gde su tu klase i objektna orjentisanost?".

Može li neko da mi objasni u čemu je smisao svega ovoga?

Za obfuskaciju izvornog koda u C-u postoje gotovi alati. Ako neko zna bolje metode, neka ih formuliše u vidu opšteg slučaja i to objavi i/ili napravi softver.

Mislim da kapiram. Poenta je u umetnosti.

Umetnost postoji da nas istina ne bi ubila.

http://www.ioccc.org/

Ovo mi je bila inspiracija :)))

A sto se tice rand i srand, toliko programera naokolo, dajte bar jedan primer drugacije implementacije rand i srand? To jest dajte neku platformu na kojoj kod nece raditi ono sto treba :))))))))))) Za sada samo pricate kako teoretski to nece raditi, a ni jedan prakticni primer kako ne radi :). Mada da se ne lazemo, meni je bitno da prodje sa gcc i clang :).

A evo i nesto ste novo naucili :))), a i definitno kod daje neocekivan rezultat :PPPP.

P.S. Nedeljko main(){puts("Paja Patak");} Jos je krace, ali treba znati c :)

Na koliko si platformi probao?

Na svim koje su mi pale saka, mada skoro svuda je bio gcc ;). Ako vam iz prve radi na omiljenom c kompajleru, moze se reci da je tesko naci gde ne radi :). Ali ajde demantujte me, voleo bih da vidim tu implementaciju kompajlera/standardnih biblioteka.

Pazi, apsolutno nigde nema garancije da to svuda treba da radi isto...

edit:
no nebitno.

Ima li neko nešto od ovoga pri sebi:

1. Linux, intel C/C++,
2. Windows, intel C/C++,
3. Windows, MinGW,
4. Windows, clang,
5. Windows, Visual C++,
6. Windows, Borland C++,
7. Mac, XCode?

Bilo bi dobro da se isproba.

Proverio sa VC++ VS2013, ne radi. E sad to je C++ ;)
Radi se o glibcu. Znaci nista sto koristi MS CRT nece raditi.

A evo kad se koristi musl umesto glibc:

U Visual C možeš da kompajliraš baš C, tako što ćeš da napraviš .c fajl. Može se kompajlirati iz komandne linije ili nekog IDE-a (može i Code::Blocks).

Od kada se moze programirati na windowsu :))))))))))), inace dobra poenta sa razlicitikm libc implementacijama, moracu negde da probam jos na ulibc i dietlibc. Mada koliko vidim nece da radi, kada nisu POSIX implementacije :).

Deo man 3 rand:



I da, naravno da sam od samog pocetka znao da nece to bas biti prenosiv kod, ali eto radi bar negde :))). Ali ajde ozbiljno ko jos koristi rand iz libc-a za nesto ozbiljnije ;).

A šta ti koristiš u C-u umesto rand-a? Naravno da postoji potreba za pseudoslučajnim brojevima koji su

1. brzi sa simulacije,

2. sigurni za kriptografiju.

1 i 2 je obično u suprotnosti jedno sa drugim, pa postoji potreba da se isporuči oboje zasebno, da bi se koristilo po potrebi ono što odgovara.

Ako mi zatreba ozbiljni random brojevi, koristim ono sto isporucuje OS, kako radim na linuxu samo, procitam /dev/random :), ili /dev/urandom ako je malo manje bitno :).

Naravno za neku ozbiljnu prenosiviju foru uzmem openssl/rand ako licenca zadovoljava potrebe :)

Trebaju mi pseudoslučajni brojevi koji ispunjavaju sledeće uslove:

1. da mogu da namestim seed i da dobijam deterministički proizvoljno dug niz,
2. da budu kriptografski sigurni,
3. da se generišu onoliko brzo koliko je to moguće.

A mir u svetu neces ???

Mislim pa ko te sprecava da napises sam takvu funkciju :), ti bi barem trebao toliko da znas matematiku :).

Mislim da i ovo sto ima i sto je opste prihvaceno treba da zadovolji. Ne verujem da sad mozes iz rukava da izvuces nesto bolje u kraktkom vremenu.

Misim da Čupko odbija da prizna da ovaj kod ima samo umetničku vrednost i da potencira na rešenjima koja su neprenosiva na Windows.

Ovi programi imaju vrednost da zezaju kvazi programere :), da ih natera da se zamisle ...

Evo jos jednog davno napisanog, moze jos malo da se skrati, ali necu da kazem gde :)




P.S. Jesu umetnost, svaki koji sam napisao je malo remenk delo :).

Kome ovo treba i zašto razmišljati o tome? Meni je danas trebalo ovo:

Treba da napravim matricu nekih podataka, pri čemu se broj vrsta i broj kolona računaju na osnovu nekih ulaznih podataka. Recimo da je u pitanju C. Jeste C++, ali problem je isti.

Kako implementirati bezbednu alokaciju?

Šta ovde ne valja? Recimo da se negde obrađuje izuzetak koji može da baci operator new.

Pa ti si jos u fazi zaradjivanja para pisanjem koda :))), pa nemas vremena da razmisljas o umetnosti, ti prolazis kroz decije bolesti programiranja :).

A sta ne valja u kodu, otkud znam, ko zna sta je trebalo, a ko zna sta si ti uradio :)))).

pa koristis vektor vektora, i onda nema da brines.

U C++ koristis klase koje implementiraju to gruntovanje i brigu.
Sto se tice zaradjivanja, to ide tek kad prodjes decje bolesti :P

Neee zna, neee zna, utata!

Ne valja računanje vrednosti size. Sabiranje i množenje mogu da daju prekoračenje usled koga je rezultat besmislen. Može biti čak i nesiguran.

Evo popravke:


Savetujem vam čitanje man stranica.

Vece gluposti odavno ne procitah.

Ajde da ne ispadnem da nista nisam napisao:

Stavi size_t umesto unsigned i 467443687 i 39463029637 umesto 5 i 10, pa da vidimo kako radi.



_{[Ovu poruku je menjao Nedeljko dana 14.01.2020. u 02:15 GMT+1]}

Dobro, onda pojedinacno rows < MAX_SIZE && cols < MAX_SIZE
prevideo sam da mnozenje radi wraparound.

A šta ako imaš 64GB RAM-a i treba ponekad da imaš 2 reda sa 8e9 kolona ili 8e9 redova sa 2 kolone, kako kad?

Rekao si da veću glupost odavno nisi pročitao, a rešenje ti je pogrešno.

Sajber napadi se često zasnivaju na nepokrivenim slučajevima.

U slucaju da ti treba toliko podataka prvo proveris da li imas dovoljno rama na raspolaganju.

BTW:
imas SIZE_MAX definisanu konstantu

Na koji način ćeš da izvršiš bezbednu alokaciju?

Naravno da alokacija neće uspeti ako nema dovoljno slobodne memorije. Taj slučaj se posebno obrađuje.

Međutim, ti moraš imati algoritam alokacije koji u slučaju da ima dovoljno slobodne memorije ispravno alocira, a u suprotnom ne alocira i to detektuje.

Problem je overcommit. Alokacija ce uspeti cak i onda ako nema dovoljno memorije pa ce puci na prvom pristupu.
Bezbednu alokaciju mozes uraditi samo od sistema do sistema zbog toga.

edit:
overcommit ima svoju dobru stranu, pogotovo na serverima ali znatno otezava hendlovanje
alokacije. I da ne mora odmah da pukne nego u bilo kom trenutku kada sistem ostane bez
slobodnog prostora.

Rekao bih da ovo radi:

Naravno, radi šta treba da radi. Ako ne može da se alocira, to se detektuje, a inače se alocira kako treba.

Nemoj da se vadiš.

Ne radi.

stavi:


i dobija se:

A ima check. Nista onda neke bolje vrednosti u okviru overcommit limita:




a pre toga da malo povecam:

Inace za bilo koje velike vrednosti a,b i c ce da pukne ako:


1 je nerestriktivni overcommit.

Znaš kako, na Windows-u ovo radi i po C/C++ standardima radi. Prema tome, to je problem nekih poluoperativnih sistema.

WinNT je imao memory overcommitment dok Linux nije postojao, ali kao opciju, koja je podrazumevano isključena. Nije Linus kriv, jer za izbor podrazumevanih podešavanja nije zadužen on, već je to do proizvođača GNU/Linux distribucije.

Da ti kazem, na serverima je overcommit must, jer mnoge konfiguracije ne bi radile. Windows ne radi to, ali na serveru i nije bas nesto prisutan.
Pre bih rekao da je OS koji to ne podrzava polu prozvod, jer na OS-u koji to podrzava u ovom slucaju Linux-u, moze da se konfigurise.
Zbog toga sto ne znas da li ce OS overcommitovati ili nece ako hoces da alociras puno podataka onda moras da se spustis na system
specific nacine:
Recimo na Linux-u:

I na WinNT-u to postoji opciono, samo je podrazumevano isključeno.

Da li ti shvataš posledice toga?

To znači da aplikativni programer (dakle, koji piše program koji radi u user space-u) ne može da napiše program koji ne puca na sistemu sa podrazumevanim podešavanjima. Zašto u C/C++ standardima piše to što piše? Zašto pri podrazumevanim podešavanjima to ne radi po standardima?

Ah, jos jednom pitanje da li je stariji OS ili programski jezik :)))), mislim da svi koji prakticno programiraju znaju da je stariji OS i njegova je poslednja :)

Nedeljko, kao sto rekoh, ne mogu ja da gledam u pasulj sta si ti hteo a sta si napisao :). Taj kod koji si naveo ne radi nista neocekivano, uci se na prvoj godini da pre alociranja moras obratiti paznju da ne preteras ... Nista neocekivano ... mada je neocekivano da tako nesto ovde postavis ...
Samo napred u ucenje ...

Branimir, moracu jednom da pocnem da programiram :))))) za sada tek ucim :), a inace doslo je vreme da se prvo krene u zaradjivanje para, pa tek ucenje, tako je i meni na mom trenutnom poslu :)))), radim u necemu sto nikada nisam video :))))).

Ajde da stavimo jos jedan neocekivani kod :), prosto da ne bude da nisam nista napisao ...

Evo, recimo ovo, sam pisao from scratch

Nije. Od OS-a sam stariji ja. Moja je poslednja. Ne može me OS sprečiti da ga zamenim drugim.

I na kraju nije bilo odgovora na pitanje kako to paziti i šta sa kodom nije u redu.

Nedeljko:"Nije. Od OS-a sam stariji ja. Moja je poslednja. Ne može me OS sprečiti da ga zamenim drugim."

Osim ako ne radis za pare, pa klijent diktira OS... ili si u nekoj firmi gde *ti* odlucujes u startu...

edit:
Chupcko"Branimir, moracu jednom da pocnem da programiram :))))) za sada tek ucim :), a inace doslo je vreme da se prvo krene u zaradjivanje para, pa tek ucenje,"
Znas kako kada sam ja poceo da zaradjujem to je bilo na krekovanju i reverse inzenjeringu pocetkom 90ih...

U svakom slučaju, nije najstariji OS, već čovek.

Čovek je taj koji bira, podešava i dizajnira OS. To bi trebao da bude onaj kome taj OS treba. Ako je u pitanju klijent, to je njegova stvar. Ako napravi loš izbor, njemu će se obiti o glavu. Moje je da mu pomognem oko izbora, ne da mu namećem izbor.

Nedeljko, zar ja treba da te ucim kako se testira program, kako se analizira, kako se radi dokazivanje u hoarevoj logici ?

A sto se tice OS-a, cim ga instaliras i u njemu izvrsavas, on je najstariji, osim ako ne podesis drugacije ... A ako ijedan OS dopusta podesavanja, to je Linux, pa cak i ako nemas nesto sto ti treba, izvoli pa napisi ...

Branimire, ne bih se ja bas hvalio krekovanjem :)

@chupcko

Hvala na odgovoru, ali

Što se testiranja i analiziranja programa tiče, ubeđen sam da to znaš bolje od mene, pa, što me ne bi malo i učio.

Što se tiče Horovih logika, ne sviđaju mi se. Ima boljih rešenja.

Horove logike zahtevaju da prvo napišeš program, pa da onda dokazuješ specifikaciju. Bolje da napišeš specifikaciju i da se onda iz nje poluautomatski generiše program sa dokazom specifikacije. Čovek zna kako da napiše program po specifikaciji, ali mu računar asistira automatizujući ponešto.

Ako tako prostu stvar ne znas ... Mislim za cije zdravlje babe ja to da radim :)))) Mozda je problem sto se previse lozis, probaj da se vratis osnovama, mozda pomogne :)

Q.E.D.

chupcko:"Branimire, ne bih se ja bas hvalio krekovanjem :)"

Ko kaze da sam se hvalio? To su bile moje prve sljake... dal se hvalim ili ne hvalim, nebitno.

edit:
sto se tice dokazivanja i testiranja, niko mi to jos nije trazio, a profesionalno se bavim programiranjem od 1992.
to je tek skoro postalo popularno i generalno naginje ka funkcionalnim jezicima koji su dobri za pisanje
naucnih papira ali neupotrebljivi u praksi osim u usko specificnom domenu kao sto je Erlang na primer.

@chupcko

Ja nikada nisam mislio da sam popio svu pamet sveta i nikada nisam prestao da učim. Zovi ti to osnovama ili drugačije, svejedno.


@Branimir Maksimovic

Te radnje su zabranjene. Pisanje o tome na javnom mestu je baš čudno, bez obzira da li ti misliš da se time hvališ ili ne hvališ.

Zabranjene su mozda sada, ali 1992 nije tako bilo, pogotovo sto su i sankcije bile zabranjene pa smo ih opet dobili...

Krekovanje je uvek bilo zabranjeno. Odakle ti da su sankcije bile zabranjene?

Za vreme sankcija nije. To sto sam radio moze i da se jos racuna kao patriotski cin jer sam radio na stetu neprijatelja a u korist Srbije :P

Hajde, nađi zakone koji su tada bili važeći. Ti pričaš o tome da li je to bilo moralno ili nije. Moral i zakoni nisu isto. Legalno je ono što je po zakonu, a ne ono što je patriotski ili moralno. Nažalost, to dvoje nije u skladu.

Da li je to bio moralan patriotski čin ili nije? Zavisi od celine. Prvo, na koji je način to finansirano? Preko virusa ili na drugi način?

Nedeljko zaista ti nedostaje elementarna logika. Zemlja pod sankcijama, u ratu, a ti ces da postujes zakone nasih neprijatelja
tim pre sto je ono sto radis upravo zbog postupaka nasih neprijatelja. Smesno. Povlacim se iz diskusije.

Ono što ti ne shvataš je da ni u jednoj zemlji, pa ni našoj, ne važe zakoni drugih zemalja, već zakoni te zemlje. Ja pričam o tome da je krekovanje i tada bilo zabranjeno zakonima naše zemlje.

Američki zakoni nikada nisu važili kod nas jer je druga jurisdikcija u pitanju. Međutim, naši zakoni su tada takođe zabranjivali krekovanje.

U potpunosti neočekivan rezultat da neko pristane na rečnik u kom "mi" imamo "neprijatelje" :)

Ovde je jedino neocekivana neozbiljnost nekih ucesnika diskusije. Nema vise primera koda koji daju neoceivani rezultat? Sve se svelo na standard :)

Evo vam nesto sto ce vas strucnjake da malo zbuni :))

Pa, ovde je isto u pitanju samo standard.

Bukvalna vrednost 'a' je po C++ standardu tipa char, a po C standardu tipa int. Samo, za to se koristi makro __cplusplus.

Za sta, za utvrdjivanje koliko je velika konstanta u memoriji? Zar to ne znaci da C++ nije nadskup C :), veoma neocekivano ...

Pa, to se zna odavno da C++ nije nadskup od C-a. Ti si dao primer koji se kompajlira sa oba kompajlera, ali daju različite rezultate. Evo primera koji se kompajlira C kompajlerom, ali ne i C++ kompajlerom.


Najstandardniji primer koji se kompajlira sa oba kompajlera, a daje različite rezultate je:

Evo još jednog


#define ne radi, tako da kada se kompajlira bilo kojim kompajlerom, rezultat je ispravan.



#undef ne radi, tako da kada se kompajlira bilo kojim kompajlerom, reyultat je ispravan.

Evo još jednog najstandardnijeg primera koda koji se kompajlira C kompajlerom, a ne kompajlira C++ kompajlerom.

Međutim, chupcko hoće primere gde se ne koristi makro __cplusplus. Rešenje je Google.

Write a C program that won't compile in C++ - GeeksforGeeks

Write a program that produces different results in C and C++ - GeeksforGeeks

Ipak, u svim tim primerima je C++ "u pravu", tj. bolje je ono što predviđa C++. Dakle, radi se o popravkama C-a, a ne o žrtvovanju ičega.

Postoje primeri nečega što je definisano u C-u, a nije u C++-u, i većina bi rekla da je "bolje" u C-u. Najpoznatiji primer je type punning kroz unije: u C-u jasno definisano, dok U C++-u ne - jasna su pravila kada počinje lifetime objekta, čitanje neaktivnog člana unije nije takav slučaj. Kao i reinterpret_cast niza karaktera pročitanog iz socketa u objekat radi deserijalizacije (vidi predlog za std::bless i promene u C++20).

Unije nisu objektno orjentisane i ne bi ih trebalo koristiti u C++ programima, osim za tipove koji nisu klasni (imaju trivijalan podrazumevani konstruktor, destruktor, bla bla) kao zamenu za reinterpret_cast, mada postoji reinterpret_cast kao zamena za unije.

Unije su tu samo radi obezbeđivanja kompatibilnosti unazad sa C kodom.

reinterpret_cast u objekat? Ne bi valjalo. Serijalizaciju i deserijalizaciju treba rešavati drugačije.

O tome se radi, type punning preko unije nije definisan čak ni za trivijalne tipove. Inače, ni templates, a ni primitivni tipovi nisu objektno orijentisani, pa se koriste :-). Unija ima svoje mesto - primitivna std::variant, i to je to.

template se uklapa u OOP, kao i prosti tipovi.

Daj mi use case za unije u C++ programima, a da nije legacy.

Kao po obicaju Nedeljko ne kapira ono sto je bitno, u onom kodu je neocekivano da C nema konstante koje su tipa char :) barem stariji C.

A C++ i gluposti koje rade da nesto zabrane a opet omoguce je glupost koja ce ga ubiti kao jezik...
Unije postoje sa razlogom, pa cak ih je i paskal imao :) E sada sto zivite u doba kada je 32Gb memorije prosek, ko je vama kriv :)

Nije mi baš jasno šta to Nedeljko ne kapira, ali chupcko ne kapira da C ima konstante koje su tipa char i da se pišu ovako:

a da je 'a' zapravi literal. U C-u će da radi i ovo:

Unija je problematična jer nema garancije da se ispravno čita ono što tamo piše, odnosno da čitaš ispravno polje. Naravno, to može biti odgovornost programera. Kod OOP-a (za koji je C++ pravljen) je poenta da se što više provera vrši od strane sistema.

Za štednju memorije služi nasleđivanje. Niko ti ne brani da imaš pokazivač na strukturu tipa A, a iz te strukture izvedene razne druge strukture, pa da identifikuješ tip itd.

Navedi use case gde je unija značajna, a da imaš OOP.

Oćeš da rešavaš probelem C-ovski? Nema problema. One unije koje rade u C programima, radiće i u C++ programima.

Inače, postoji način da se napiči full featured OOP unija u C++ programu, ako se baš hoće, samo ima malo više da se kuca.

Bezim iz diskusuje, previse gluposti se prica :)

Kada bude neki zanimljivi kod koji daje neocekivani rezultat ...

Bežiš ti iz diskusije iz drugih razloga.

Sada nešto što ne piše u standardu C-a. Najpre izvršimo ovaj program:

Nakon što on završi sa radom, izvrši se ovaj program

Kako to da drugi program nije našao ništa od bajtova sa vrednošću 255, koje je posejao po memoriji prvi program?

Dakle, da pojasnim



Dakle, nije došlo do ispisa poruke "Nonzero byte found!". Zašto?

Pogledaj implementaciju Boost.Variant2:

https://github.com/boostorg/va...ude/boost/variant2/variant.hpp

Naravno da je moguća potpuno ista implementacija koristeći rekurzivno nasleđivanje kroz template parameter pack, samo što je onda veličina objekta jednaka sumi svih objekata + pading. Unija dolazi vrlo prigodna kao primitivni alat za građenje alata sa višim nivoom abstrakcije.


[/quote]

Netačno, što je i poenta mog posta. Ovo radi u C-u, a nedefinisano je u C++-u:



https://stackoverflow.com/a/17799428/133707

Kod mene se ovo ne kompajlira ni gcc-om, ni clang-om. Kompajliranjem bilo sa g++, bilo sa clang++, radi savršeno.

Probaj ti to.

Izvinjavam se, C ne dozvoljava anonimne unije u ovom obliku. Evo istog programa koji se kompajlira i sa C i sa C++ kompajlerom. Međutim, u C-u je ovaj program potpuno definisan, dok u C++-u ovaj program sadrži undefined behavior (pristupanje neaktivnog člana unije):

Možda je u teoriji u C++ jeziku to nedefinisano, ali u praksi radi. Probao sam sa g++ i clang++ kompajlerom i inverzni kvadratni koren se računa ispravno.

"U praksi" je vrlo klimav pojam. Ne postoji garancija da će ovaj program raditi na svim implementacijama, pa ni u narednoj iteraciji GNU C++ kompajlera. Već smo videli takve primere sa strict aliasing, sa std::launder, pa se i na ovo ne sme oslanjati.

Howard Hinnant u SO linku sa koga sam preuzeo ovaj primer kaže:



A evo ga i link ka celoj diskusiji unutar C++ komiteta o ovome (WG21 UB study group): http://www.open-std.org/pipermail/ub/2013-July/000071.html

Imaš li ti primer da to ne radi na nekom kompajleru? Zbog čega bi neko kvario kompajler u sledećim verzijama? Vidi, ako ne postoji fundamentalan razlog protiv toga da radi kako se očekuje, svi će tako da naprave kompajler.

Imaš li ti dokaz da radi na svakom kompajleru? Pošto standard, koji definiše šta je C++, a ne kompajleri, za ovaj program kaže da je nedefinisan.

Ovaj kod nije portabilan, za razliku od C verzije koja jeste, u kojoj je ponašanje jasno određeno standardom.

Fundamentalni razlog može da bude vrlo prizeman, kao što je optimizacija, kada kompajler može da vidi da se u samo jedno polje unije upisivalo, i da zameni celu uniju samo jednim poljem, ostavljajući sve ostalo nedefinisano.

Već sam ti dao primere u prošlosti kada je kompajler zbog optimizacije kao fundamentalnog razloga, potpuno razbio neportabilne programe. Najčuveniji je strict-aliasing, koji je razbio mnogo toga, uključujući i Linux kernel. Evo Linusova poruka na tu temu (https://lkml.org/lkml/2003/2/26/158, boldovanje moje):




https://www.mail-archive.com/[email protected]/msg01647.html



Još nekoliko primera, kao što su https://davmac.wordpress.com/2009/10/ možeš naći na https://stackoverflow.com/ques...ct-aliasing-and-horror-stories

Ne mogu da pronađem tačno kada je GCC podrazumevano uključio strict aliasing, ali https://www.gnu.org/software/gcc/bugs/ kaže "recently":

Govorimo o primeru programskog koda koji se kompajlira C kompajlerom, C je portabilan, C++ neportabilan u praksi. Ti ga nisi naveo. Navodiš neke primer koda koji nije C portabilan, što nije tema.

Ja tvrdim da toga nema jer ne postoji razlog za to.

Autore C++ standarda je blam da napišu da se unije koje se kompajliraju C kompajlerom, kompajliraju C++ kompajlerom na isti način, već hoće da formulišu opštu OOP teoriju o uslovima kompajliranja unija, pa to ne uspevaju u celini. Posledica toga je da ono što piše u C++ standardu ne obuhvata sve slučajeve koji su obuhvaćeni C standardom.

Sa druge strane, autori kompajlera itekako razlikuju tipovi koji suštinski nemaju veze sa OOP-om (trivijalni podrazumevani konstruktor, konstruktor kopije, pomerajući konstruktor kopije, destruktor, operator dodele, pomerajući operator dodele, operatori poređenja) zbog optimizacije. Posledica toga je da se svi takvi tipovi koji, koji obuhvataju sve C-ovske tipove (struktura koja ništa ne nasleđuje i nijedna metoda nije navedena je obuhvaćena time) kompajliraju na isti način kao u C-u.

Da li neko zna odgovor na pitanje postavljeno ovde

https://www.elitesecurity.org/p3932749

Pre nego što operativni sistem da procesu stranice memorije, uvek se izvrši brisanje vrednosti (zapravo, drugačije, neki operativni sistemi to rade na živo pre slanja programu http://lists.dragonflybsd.org/...ommits/2016-August/624202.html, neki uvek dodeljuju 0 stranicu i pomoću CoW daju novu u slučaju da pišeš u nju). U suprotnom, tvoj program bi mogao da dobije stranicu memorije sa šiframa iz Chromiuma, ili slično..

_{[Ovu poruku je menjao Burgos dana 29.01.2020. u 10:35 GMT+1]}

-- EDIT: greške u kucanju.

_{[Ovu poruku je menjao Burgos dana 29.01.2020. u 10:36 GMT+1]}

Da, tako je.

Pre nego što se blok osnlobođen od nekog procesa dodeli nekom drugom procesu, on mora biti popunjennulama iz sigurnosnih razloga.

[chupcko@main] 1 /home/chupcko > cat test.java 

class test

{

  public static void main(String[] args)

  {

    if(-Integer.MIN_VALUE > 0)

      System.out.println("Yes");

    else

      System.out.println("No");

  }

}

[chupcko@main] 0 /home/chupcko > javac test.java 

[chupcko@main] 0 /home/chupcko > java test 

No

Šta je tu neočekivano? Ako se Integer pamti sa n bitova, onda je najmanji broj min=-2^(n-1), a najveći max=2^(n-1)-1. Naravno da je -min=max+1>max, a pošto se računa po modulu 2^n, od toga se oduzima 2^n i dobija se min kao rezultat. Dakle, -min će biti isto što i min, što je negativno.

To u Javi gde je definisan overflow i underflow. U C i C++ to je undefined behavior ;)
Dakle da je primer u C-u, rezultat bi bio nepredvidljiv :P

Nedeljko, ti si majstor da promasis temu cak i kada je zicer. Sta mislis sto sam bas u JAVI napisao??? Od 20 jezika koje aktivno koristim, bas JAVA.

Sta je sledece, da mi tvrdis da postoji vrednost v tipa t tako da vazi da je v != v :)

A sto jes jes rezultat je neocekivan.

Ja ne znam šta kažu članovi Centralnog Komiteta Komunističke Partije standardizacije jezika, znam samo da ne postoji C ili C++ kompajler na kome će ovo da radi drugačije:



Naravno, veličina tipa int može da varira, ali će vrednosti za x i -x biti iste i treći ispisani broj će biti 0.

@chupcko

https://www.gnu.org/software/g...ode/Wraparound-Arithmetic.html

Da, vidiš, pravu si.

Cepem ti se u GCC. Sa -O1 -fexpensive-optimizations radi kako treba, a sa -O2 ne radi kako treba. clang radi kako treba i sa -O3.

a probaj ovo:


kod mene:


ako pogledas kod:


Kompajleri ni ne gledaju sta je x-x podrazumevaju da je 0.

x-x i jeste 0, bez obzira na to šta je x.

To bi trebalo da bude aritmetika u sistemu ostataka po modulu . Naravno da je .

Ovo nije bas neocekivano, ali ajde ;)

[chupcko@main] 0 /home/chupcko > cat test.java 

public class test 

{ 

  public static void main(String[] args) 

  { 

    if(Float.NaN == Float.NaN)

      System.out.println("YES");

    else

      System.out.println("NO");

  }

}

[chupcko@main] 0 /home/chupcko > javac test.java 

[chupcko@main] 0 /home/chupcko > java test

NO

Ne znam šta se u opštem slučaju ne poklapa sa ne znam čim.

U bazama je NULL==NULL jednako NULL.

Rezultat je 1.

Jel? A gle ovo:



Na ovo:


Znaci potpuno izbacuje kod koji ne moze da se desi :P
x-x ako racuna ne moze biti 0 nikako, a uzmi bilo koji kod koji racuna da ce biti overflow bice
izbacen:P

1. x+100<x može da bude tačno za neke x.

2. x-x ako se računa, mora biti 0 za svako x. Sedi, pa računaj.

Dakle ti ne shvatas da kompajler izbacuje kod koji proverava overflow?

Ako proveru x!=-x stavi da je netacno a x-x == 0 da je tacno to ne valja, ili mislis drugacije?

Ne shvatas da je potpuno izbacio proveru x+100 < x?

x!=-x je nekada tačno, a nekada netačno. Za x==0 i x==INT_MIN je tačno, a za ostale vrednosti je netačno.

x-x=0 je tačno za sve vrednosti x i može se zameniti nulom. Ne može jedino f(x)-f(x) jer f može da ima bočne efekte ili x-x za volatile x jer čitanje dva puta ne mora da da istu vrednost. Ne znam odakle ti da uplićeš x-x u ovo.

Branimir Maksimovic ne shvata da računanjem x-x nikakva provera nije moguća, pa ni provera prekoračenja.

Inače, rešenje za ove budalaštine je u slučaju GCC-a sledeći switch: -fwrapv. Na clang-u je sve u redu.

Ima li još ovakvih budalaština, da znam šta me čeka.

U prvom testu se bez optimizacije dobija ispravan odgovor Yes, a sa optimizacijom đene-đene. Sa -fwrapv se takođe dobija "Yes". U drugom testu se dobija No, bez obzira na sve. U trećem i četvrtom testu se dobija ispravan odgovor Yes, bez obzira na sve.

Dakle, zbir označenog i neoznačenog broja je neoznačen, pr čemu nema upozorenja da se porede označen i neoznačen broj.

-Wextra je neophodno uključiti za upozorenje

Eto ipak je bilo neocekivano. Ima puno takvih stvari, ali to je zato sto ti zamisljas C kao neki mocni jezik, a on je samo malo jaci makroasembler ;)))). Dobro puno jaci.

Ja bih voleo da je to tako, ali nije.

Ja bih hteo jezik bez tih cpanja, a da je ono što C treba da bude.

C je bas ono sto treba, nema sranja, tako masina racuna, on to prepusta procesoru, ne upusta se u proracun. Ako zelis ti nesto specijalno presretni, ali ne kukaj kako je posle sporo :).

Zato C i jeste zamisljen kao jak asembler, zato je i potreban, zato je i brz, zato je i zanimljiv, nema puno proseravanja ala klasice i neke glupe zabrane ili ona proseravanja sa funcionalnim glupostima :).

A neocekivoanosti, pa i nisu za one koji su citali standard :).

Sedi i napravi svoj jezik, ja jesam moj, ali je sada smesan, 95-e je bio zanimljiv :))))

Problem je u tome što nije tako. Kada se bukvalno prevede na asembler, dobije se drugačiji rezultat.

Optimizacije ne smeju da promene rezultat.

Pa, napravio sam za pare kad je neko tražio i u upotrebi je.

Zavisi od kompajlera, proveri npr. na nekom online interpreteru, vratiće grešku, jer je pređena vrednost 2^32 (ako se kompajlira u 32-bitni kod), i to tačno za 1.

Zabole me za onlajn kompajlere. Stavi unsigned umesto int i onda je po C standardu, pod pretpostavkom da je taj tip veličine 32 bita.

Nedeljko:"Optimizacije ne smeju da promene rezultat."

Osim ako se ne radi o UB-u, kada mogu.

Eh, dosli smo do sustine teme:

Ako optimizujes UB i dobijes UB, sto se bunis :)

Na svu srecu dobri programeri pisu i testove svog koda, pa na neki nacin kontrolisu UB :)

Da li ima neki kod koji je neocekivan a da nije posledica UB?

Recimo neka sitna stavka u dokumentaciji koju niko ne cita?
Za vecinu ljudi je neocekivano videti nesto tipa: 2["abcdef"] u c-u, ali to je pokriveno standardom i izuzetno neprakticno, osim ako ne zelis da zezas juniore.

To je neočekivano ponašanje jer u standardu pišu neočekivane stvari.

Evo šta daje neočekivan rezultat:



Umesto 8, dobiće se -2, jer je neki "genije" iz IEEE-ja mislio da to treba da se slaže sa promenom znaka. Pritom, u računu ostataka primenu ima račun sa potpunim sistemom ostataka, kao što je 0,...,n-1 ako se računa ostatak pri delenju sa n, dok "slaganje sa promenom znaka" nema nikakvu primenu.

To je što bi jedan pokojni profesor rekao "kad moleri prave hemiju", što mu je bio izraz za šarlatanstvo, diletantstvo.

Zatim, IEEE je uveo dve nule u IEEE 754 standard. Jedna je negativna, a druga ima dva značenja - pozitivna i čista nula, što takođe nema primenu. Ivan Dimković me je nekada ubeđivao da je za multimediju bolje da bude glupost, nego NaN, što možda koristi da dekodiranje zvuka i šteti za sve ostalo.

Naravno, te budalaštine su ugrađene u hardver.

Kod Python-a su ostavili obe mogućnosti, operator % za operande različitog znaka daje rezultat koji ima isti znak kao drugi operand, dok fmod iz math biblioteke daje obrnuto, odnosno ostatak koji je istog znaka kao prvi operand, kao što je dato u primerima ovde: https://www.askpython.com/python/python-modulo-operator-math-fmod

Stvar je u tome da je u C-u % remainder operator, not moduo.

Recimo u Rustu ima:


koji daje oba rezultata:

Da li ti znaš šta je to remainder ili ostatak?

Ocigledno se racuna kao ostatak:

Pojam ostatka se ne definiše programskim jezicima, već teoremom o euklidskom delenju.

Neka su i celi brojevi takvi da je . Tada postoje jednoznačno određeni celi brojevi i takvi da važi

, .

Pritom, broj zovemo ostatkom pri delenju broja brojem .

Naravno, umesto skupa , moguć je i drugi izbor sistema ostataka, ali on treba da ima elemenata i razlika bilo koja dva elementa tog skupa ne sme biti deljiva sa .

Programski jezici treba da se usklađuju sa time, jer je to plod mnogovekovnog matematičkog iskustva, da je tako praktičnije. Sve teoreme se odnose na to i tako se radi lakše.

Što se neočekivanog ponašanja tiče, može li neko da navede situaciju kada je implementacija u C-u na način koji je uobičajen za C sporija od implementacije u Javi ili C#-u, na način koji je uobičajen za njih?

"Pojam ostatka se ne definiše programskim jezicima, već teoremom o euklidskom delenju."

Ocigledno ne. Zato Rust ima i rem_euclid f-ju. Gleda se prakticna primena na hardveru.

Pa pazi ako je deljenje konstantnom onda je verovatno optimizovano kao shift i multiply u svim tim jezicima. Stara verzija Jave nije to radila pa je C bio brzi, za C# ne znam.

Hardver su očigedno pravili kako ne treba, to jest na način koji je manej praktičan, a onda kad je tako kako jeste, onda su softveraši dovedeni pred svršen čin, pa

- prave funkcije koje se direktno oslanjaju na hardver, jer su brze, budući da su hardverski implementirane, a vrše posao u slučeju nenegativnih operanada,

- prave dodatne funkcije, koje nisu toliko brze jer nisu hardverski implementirane, ali vrše posao u široj klasi slučajeva.

Da li neko zna primenu za -2%10==-2? Ja znam primene za -2%10==8.

Što se ovog pitanja tiče, mislio sam na sledeće:

Ako treba da optimizujemo program tako da u dugim periodima obavi što veću količinu posla u odnosu na utrošeno vreme, da li je GC koji odloženo čisti đubre efikasniji od free, koji briše komad po komad? Recimo da imamo veliki broj alokacija i dealokacija.

Eh, tako je kada neko ne nauci lepo istoriju racunarstva i misli da je racunarstvo u sluzbi matematike :))))))).

To sto ti ocekujes da masine prate tvoju matematiku, to je tvoj problem, cinjenica je da masine imaju svoja definisana pravila, pa na tebi je da ih naucis i koristis kako tebi treba :)))))))))).
A kao sto jednom rekoh: C je samo dosta dobar makroasembler ;)))) Prati masinu a ne ljude ;)

Svakako da GC nije efikasniji od rucne dealokacije tim pre sto je to thread koji to radi dok se program izvrsava. Znaci postoje dva pristupa: da zaustavi program pa to odradi ili da pravi membarove cime se drasticno
usporava pristup memoriji. U svakom slucaju Rust je u pocetku imao GC, ali su ga odbacili zbog performansi. Nema besplatnog rucka, pa tako convenience da ne moras da pazis kada sta oslobadjas
ima svoju (veliku) cenu.

chupcko

Nije to moja matematika, već matematika mnogih vekova izučavanja od strane velikih umova, koji su došli do toga šta je primenljivije, lakše i elegantinije.

Kapiram ja da C prati hardver, ali se onda postavlja pitanje zašto je hardver takav.

Niko da pruži odgovor na ključno pitanje. Koje su primene za -2%10==-2? Primena za -2%10==8 je na primer određivanje koliko je dana proteklo između dva datuma u nekakvom proleptičkom kalendaru.


Branislav Maksimovic

Hvala. Upravo sam to želeo da čujem, ali nisam siguran da je odgovor tačan, pa bi želeo malo podrobnije obrazloženje. Dakle, GC se pali ponekad, retko. Kada se upali, on svakako oduzme neko vreme, što nije podesno za real time. Međutim, ako aplikacija nije real time, obzirom da se GC retko pali (i još postoje optimizacije sa generacijama objekata), da li je u dugom vremenskom intervalu ukupno potrošeno vreme alokaciju i dealokaciju kraže u slučaju GC-a ili u slučaju ručnog brisanja?

Nedeljko:"da li je u dugom vremenskom intervalu ukupno potrošeno vreme alokaciju i dealokaciju kraže u slučaju GC-a ili u slučaju ručnog brisanja?"

Nije problem ukupno potroseno vreme nego, kao sto sam naveo, to sto program dok traje dealokacija mora da se zaustavi sto jako
boli u vreme kada imas 64 kora ili mora da ima konstantno usporenje zbog membarova koje moraju non stop da se postavljaju
prilikom svakog pristupa objektima. Eto recimo imas 64 threada koji bi nesto radili, ali dealokacija ih sve zaustavi. Kod
rucne dealokacija toga nema zato sto cak i najprostiji alokator ce blokirati na lok samo threadove koji alociraju ili dealociraju
u istom trenutku, obaska sto imas one alokatore koji su lock free.

Dobro, recimo da imam 4 jezgra ili 2 jezgra. Postoji li slučaj kada će program da obavi više posla ako koristim na primer Boehm GC u C-u ili malloc/free/realloc u C-u? Dakle, u slučaju da imam mali broj jezgara itd.

Ako smem samo da dodam, jos jedan problem sa GC-om je sto ne znamo kad ce tacno da odradi posao.

Zauzece memorije moze biti poprilicno dok se GC (napokon) aktivira.

Ma, to je problem za real time. Ne pričamo o real time aplikacijama. Ja pitam da li postoji slučaj kada je efikasniji. Naveo sam na šta se odnosi.

GC ima dodatni posao da locira sve reference koje moze osloboditi. Klasican alokator to nema nego tacno 1 oslobadja.
Boehm GC ima jos problem sto ne moze razlikovati int od pointera tako da moze da se desi da se napravi memleak
ukoliko se desi da neki od intova ima isti sadrzaj kao pokazivac. Osim toga kod GC-a ne smes da se igras sa pointerima,
da shiftujes andujes i slicne rabote. (to mislim na BoehmGC koji radi sa C/C++).

Ako je program napravljen ovako:



Ako se obe funkcije pozivaju isti broj puta na sledeći način:



i količina slobodne memorije je tolika da GC ne mora da čisti za sobom, sve su šanse da će program sa GC raditi brže. Čak i ukoliko GC ima potrebu da očisti memoriju, GC će samo proći po steku, videti samo jedan pokazivač (samo jedan ptr je živ, samo se on obilazi, ostali su nedostižni) i svu ostalu memoriju osloboditi u jednom potezu. U tom slučaju je praćenje referenci trivijalno, jer je stek mali, pa je cena toga amortizovana. Takođe, što je manja alokacija, to manje đubreta, iz čega sledi što više GC allokacija pre nego što si prinuđen da očistiš đubre.

Ovo ces moci zakljuciti tek onda kada je N dovoljno veliko da se dealokacija izvrsi nekoliko puta. Pri tom ako to sto
alociras u sebi ima reference GC ce svakako da bude sporiji, zato Boehm ima markiranje alocirane memorije da ne
sadrzi pointere. U jezicima koji su GC friendly ne moras da se bavis time...
No pazi sad, a sta cemo sa .NET GC-om koji je compacting, to znaci da mora da iskopira heap pa apdejtuje *sve
reference* u programu.
Generalno GC funckionise sve 5 dok program ne postane nesto vise od hello world primera, e onda ....

Nedeljko, tako je kako je, neko mudar je resio da napravi novu matematiku, a tebi ako se ne svidja, pa sedi i napravi novi chip :))))))))). Zato i ne treba matematicari da se smaraju programiranjem, smore barem dva puta, prvi put kada otrkiju toplu vodu, a onda kada shvate da ta topla voda je previse topla ;)))).


A i ti dramis, kao da ne mozes ono sto ti treba da sam izracunas :)

Inace jedina prednost GC-a se eliminise koriscenjem arena alokatora. Znaci najocigledniji primer je pisanje servera. Znaci jedan request
alocira kolko treba bez oslobadjanja i onda u cugu oslobodi sve sto je alocirano za dati req, sto je sigurno brze od bilo kakvog GC-a.

Apsolutno se slažem. Odgovarao sam na Nedeljkovo pitanje "Recimo da imamo veliki broj alokacija i dealokacija.". Generalno je teško dati odgovor na ovakva pitanja, ali je moguće napraviti primere.



Svakako, ali compating GC ima svoje prednosti. Kao i generational, kao i konkurentni, kao i... Sve je stvar kompromisa. Razlog zbog čega GC-u nije mesto u sistemskim jezicima je što zahteva kompromis.



Ne slažem se sa ovim. Nekoliko godina sam pisao network-heavy aplikacije koristeći GC, koje su bez problema radile >3000 req/s po jednom CPU jezgru bez ikakvih problema (https://github.com/sociomantic-tsunami/swarm, https://github.com/sociomantic-tsunami/ocean, https://github.com/sociomantic-tsunami/dhtnode, ...).

Neki diletant je rešio da napravi novu matematiku

Samo ne znam kako. Najviše što mi se nudi je FPGA.

Ne treba. Svako treba da se bavi svojim poslom. Samo, neki poslovi su multidisciplinarni. Opet treba da se sluša struka. Kada se implementiraju kriptoalgoritmi, mora neki kriptograf da se angažuje.

Ne radi se o tome, nego se radi o tome da ne postoji primer praktične primene onakvog operatora % kakav je u hardveru u slučajevima kada se razlikuje od onakvog kakav je u matematici.

Hvala svima na komentarima u vezi sa GC-om. To me je zanimalo.

Što se tiče toga šta GC inače postiže, evo šta piše na MSDN-u:

Ovo nije tačno.

Problem automatskog čišćenja otpadaka je u opštem slučaju Tjuring nerešiv.

Otpadak se definiše kao podatak kome se ne može pristupiti u nastavku izvršavanja programa, za ma kakve ulaze u program.

Recimo, u kodu



je str otpadak odmah po ispisivanju, ali GC to ne može da shvati. Čak i ako se izričito pozove da počisti šta može, džaba.

_{[Ovu poruku je menjao Nedeljko dana 06.07.2020. u 15:31 GMT+1]}

Nije istina da program ne može da pristupi promenljivoj str. Može, ali neće. I zato str nije otpadak. Da zaista ne može da pristupi onda bi zaista bio otpadak. Recimo ovako:



Po definiciji C# jezika str je "živ" sve dok ne izađe iz svog opsega. To znači da je promenljiva dohvatljiva pomoću refleksije. Možeš da u programu izlistaš sve lokalne promenljive i da im tako pristupiš. Nema te logike koja može da pokrije sve slučajeve i sa 100% sigurnosti ustvrdi da li promenljivi pristupa i posle neke tačke u kodu, i zato se niko time i ne bavi, nego se sve svodi na oblast važenja, pa i definicija otpatka.

Po definiciji otpatka jeste otpadak. Program nakon ispisivanja ne može da pristupi toj promenljivoj, je ma kakvi da su ulayi u pitanju u nastavku, do pristupa neće doći. Tad podatak je memorijski dostižan. Ako bismo zamrznuli izvršavanje i promenili program tako da sa zatečenim stanjem memorije (ne računajući kod, već samo podatke)

To je u opštem slučaju Tjuring neizračunljivo. Dam ti sors i ti kreneš da interpretiraš program, pri čemu interpreter može da pamti kakve god metainformacije o dotadašnjem toku izvršavanja. Identifikacija otpadaka je algoritamski nerešiva.

Postoje sistemi dovoljnih uslova pod kojima je nešto otpadak i to je ono što se implementira.

Pa i dalje mi nije jasno sto ti mislis da je % operator u c-u ono sto je u matematici kongruencija ? Prosto nije, kao sto sto ima puno primera gde ne vazi ta tvoja tradicionalna matematika ;)

Jedan od lepih primera je:



a probaj posle i/j*j/i :)

Da mi je znati šta je ovde u neskladu sa matematikom, osim tvojih iskaza.

Prvo, kongruencija nije operacija, već relacija, dok je ostatak pri delenju operacija. Da li se sećaš šta su kongruencije u algebri i čemu služe u matematici (šire od algebre)?

Drugo, ne vidim da je rad programa u suprotnosti sa matematikom. Ako je

, , ,

a jeste, onda je sve u redu. U programu piše da se štampa

što je ,

što naravno da u opštem slučaju nije 1. Ko je očekivao keca, taj nije dobro naučio matematiku.

Takođe, je ,

što takođe u opštem slučaju nije isto što i ono prethodno.

Burgos:

Ti si verovatno tu natprosecan, ja sam mislio na gomilu ljudi koji su pre ili kasnije naisli na probleme sa GC-om, i kada ono forsiranje ciklusa kolekcije postane neminovnostost i kada convenience predje u thinkering zbog problema
sa performansama.

Slažem se, i sam sam (pre ili kasnije) naišao na iste probleme, koje je bilo (ne)moguće zaobići uz manje ili više truda.

e tako kao sto je / u c-u istvari ceo deo deljenje, tako je i % nesto deseto ... tako ti je to

Ja bih jos malo gnjavio na temu GC-a, konkretno opisacu mehanizam koji postoji u Delphi-ju (ne znam da li postoji u nekom drugom jeziku).

Delphi sam po sebi ne podrzava GC. Ali, postoje Delphi interface-i, koji funkcionisu otprilike ovako:

1) Delphi interface ima na sebi reference counter. Ukoliko counter postane nula (0), instanca na kojoj 'lezi' interface se brise (free).
2) Definisemo klasu koja na sebi implementira neki interface.
3) Ako kreiramo instancu klase preko interface-a, automatski se postavlja reference counter na 1.
4) Svako prosledjivanje interface-a nekoj metodi/funkciji/cemu god, automatski uvecava reference counter (bukvalno se prati stack); vazi i obratni put (vracanje iz stack-a).
5) Kad u jednom trenutku reference counter postane 0 (nema vise nacina da se instanci pristupi iz programa) instanca se brise.

Kako sam ja shvatio, ovo je neko polu/resenje opisanog problema detekcije 'stvarno' odbacenog podatka.

Koje su, po vama, performanse opisanog mehanizma u odnosu na klasican GC..?

Za Delphi, Automated Reference Counting je dobar izbor. Najveći problem sa klasičnim GC-om u
aplikacijama koje se prave u Delfiju je stop-the-world faza kada GC mora da pauzira sve niti, što
rezultuje u blokiranju UI-a.

Prednosti ARC u odnosu na GC:

- Ne postoji velika "stop-the-world" faza, već se sve radi inkrementalno, nema blokiranja celog programa.
- Ne postoji "kašnjenje" u čišćenju, što rezultuje nižim utroškom radne memorije.

Mane:

- ARC ne može da se izbori sa ciklusima u drvu zavisnosti bez pomoći programera.
- Održavanje brojača, naročito u višenitnom okruženju nije besplatno, i plaća se svaki put.

Iz tog razloga, svaki put kada vidim std::shared_ptr (C++ wrapper za ARC) u kodu koji pregledam, tri puta postavim
pitanje da li je zaista potreban, i uglavnom nije. Olakšava upotrebu jezika, brigu o dealokacijama, ali u većini slučajeva
nije potreban, naročito ako nema nikakvog deljenja između niti. Mnogo je bolje samo alocirati objekat, pozaljmljivati ga,
davati ga uz pomoć std::move-a, kada nema potrebe da se zadrži, i uništiti ga automatski po isteku lifetime-a, ali je dosta
teže misliti o svemu ovome. Zato Rust blista, jer te lifetime-checker sprečava da uradiš nešto nebezbedno.

Samo se postavlja pitanje praktične primene tog desetog.

Zato sam ja postavio pitanje, koja je praktična primena operatora %, kod koga -2%10 i 8%10 nisu isto.

@Burgos


A da li zapravo C blista, jer te ne ograničava, nego vrši čak i custom alokaciju, po kakvim god hoćeš algoritmima, dok ti Rust ne da napraviš kružno pokazivanje?

Znam ja zašto to Rust radi. Koristi reference counting, koji ne funkcioniše u slučaju kružnih pokazivanja. Međutim, to onda znači da svoju ideju (pođimo od dvostruko uvezane liste) ne možeš da implementiraš direktno, već da moraš da implementiraš neku zamenu za tu tvoju ideju, što otežava programiranje u Rust-u.

Na kraju mi se najviše sviđa C - daje ti odrešene ruke da implementiraš šta hoćeš kako hoćeš. Može sve to i C++ uz nuđenje nekih dodatnih automatizacija, što je takođe dosta dobro.

Evo šta piše na sajtu programskog jezika D:



Daleko od toga da su autori programskog jezika D za potcenjivanje, ali mi Banetovi i Burgosovi argumenti deluju uverljivije.

- Nisu uporedili reachability method i reference counting method u dužim razmacima izvršavanja programa.

- To što destruktori nemaju telo, ne znači da ne postoji programski kod koji oslobađa t memoriju. Postoji, samo što se pali ponekad, se upali GC.

- Destruktori ne oslobađaju memoriju samog objekta, već samo memoriju na koju atributi objekta pokazuju, tako da se ništa ne menja time da li je sam objekat na steku ili ne.

- Da, GC se pali ponekad, kada ponestane memorije, ali koliko je amortizovano vreme u oa slučaja?

- Programi sa GC-om mogu imati curenje, ako su loše napisani, baš kao i ostali.

Rust "blista" u kontekstu niske cene upravljanja resursima bez kompromisa u sigurnosti. Cena se plaća, samo na drugom mestu - između tastature i stolice :-).

Rust ne koristi reference counting, osim ako ne koristiš https://doc.rust-lang.org/std/rc/struct.Rc.html ili slično, već postoji sistem "pravila" koje moraš da poštuješ. Pojednostavljeno, to su:

- Svaki objekat može biti pozajmljen samo jednom istovremeno za pisanje.
- Svaki objekat može biti pozajmljen neograničeno mnogo puta za čitanje.
- Nijedan objekat ne može biti istovremeno pozajmljen za pisanje i čitanje istovremeno.

To naravno spotiče programera da napiše kod kakav želi, i ograničava ga na "sigurnu" teritoriju. Na primer, ovo ne da ne dozvoljava
da napraviš dvostruko ulančanu listu na uobičajeni način (https://rcoh.me/posts/rust-linked-list-basically-impossible/ - ako imaš A - B - C dvostruko ulančanu listu, čvorovi A i C moraju da budu vlasnici čvora B, a ne mogu istovremeno), nego ne dozvoljava ni jednostavne paradigme za koje ti kao programer znaš, ali kompajler ne može da dokaže da su ispravne:



Rust tim radi na ovome, ovaj problem je već rešen, i videćemo šta će biti u narednih par godina: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md, https://github.com/rust-lang/rust/issues/43234 (mislim da su već daleko odmakli od situacije od pre par godina kada sam poslednji put pisao Rust). Sličnih primera sigurno ima, ali ja ne mogu da ih se setim, jer sam upravo najviše problema imao sa ovim. Inače, non-lexical lifetime upravo rešava problem koji si naveo:





Da, to i mene privlači ka C++-u, ali... "Kako hoćeš" ima velikih problema kada radiš u timu od nekoliko stotina ljudi na jednom projektu. Nijedna osoba nema pregled celokupnog projekta, niti predstavu o tome šta si želeo. Na primer, ukoliko pozivaš neku funkciju foo i proslediš svoj string, ne možeš znati da li će foo uzeti referencu na string, tj. možda znaš sada, ali ne znaš za par dana, kada neko izmeni foo(), zbog nečega potpuno drugog, ne osvrćući se na to što si napisao. Ili kada ti uradiš isto to, nekoliko meseci kasnije. Sigurnost se svodi na dobar code-review, dobre testove, dobro deljenje znanja, itd. U nekim oblastima (kada je sigurnost od najvišeg značaja, čak ispred produktivnosti i performansi) to može biti neprihvatljivo.

Što se tiče D programskog jezika - projekti koje sam okačio na kojima sam radio godinama su upravo pisani u D-u. Autori nisu za potcenjivanje, ali argumenti koje su naveli su... malo pristrasni :-). Svakako da su to prednosti, ali nijedna mana nije navedena...

@Burgos

Koliko znam, Rust koristi reference counting, a pravila koja nameće, a koja se proveravaju u fazi prevođenja, sprečavaju pravljenje kružnih pokazivanja, tako da reference counting može da funkcioniše.

Koliko ljudi radi na Linux kernelu, koji se piše u C-u? Kada su Linusa Torvaldsa pitali zašto ne koristi C++, koliko znam, naveo je tri razloga:

1. Ako C odbija budale sa projekta, to mu je već dovoljna prednost.

2. Sve što mu u sistemskom programiranju koristi od C++-a, to ima i C. Zašto onda potezati C++?

3. C++ kod se mnogo sporije kompajlira.

Što se autora programskog jezika D tiče, problem je što navedeni argumenti ne drže vodu. Dakle, to što su naveli kao razloge da je upravljani kod često brži od neupravljanog, jednostavno nije tačno. Ako postoje primeri gde je upravljani kod brži od neupravljanog, u takvim primerima razlozi svakako neće biti ti, jer to što su napisali su netačnosti.

Ne, Rust jezik (bez stdlib dodataka kao Rc) ne koristi reference counting (koji se dešava prilikom runtime-a) već praćenje vlasništva nad objektima tokom kompajliranja. Pravila koja nameće nisu tu da bi sprečili kružna pokazivanja (iako je to nuspojava) već radi sigurnosti i efikasnosti izvršavanja:

1. pošto samo jedan entitet može biti vlasnik objekta, kada se završi život objekta, objekat se može uništiti, bez brige da li neki drugi entitet drži isti objekat - nema potrebe za reference countingom.
2. Ukoliko je vlasništvo preneseno drugom entitetu, prvobitan vlasnik ne može ni na kakav način da pristupi objektu, jer to može dovesti do situacije da je novi vlasnik uništio objekat, i pritom omogućava drugom vlasniku da uništi objekat kada želi/čim mu više nije potreban.

Sve ovo se dešava prilikom kompajliranja, i zna se da, ako se program uspešno kompajlira, program radi ispravno bez ikakve provere/reference counting-a/skupljanja đubreta tokom izvršavanja programa.

Dakle, ponaša se kao ručno vođenje računa o tome kada uništiti objekat - uništava ga onaj ko ga je stvorio, osim ako je u međuvrmenu prebacio odgovornost na drugoga.

Na kapiram, kako onda ti sa Rustom mozes da napravis multi-threaded kod? kako moze kompajler da predividi koji thread ce u kom trenutku imati pristup objektu?

Jer pitanje nije: koji će thread imati pristup objektu, već koliko će thread-ove imati pristup objektu u istom trenutku. Ako izuzmeš globalne objekte, objekti su uglavnom dostupni samo jednoj niti - ona koja ih je napravila. Ukoliko želiš da deliš podatke između niti, moraš proslediti objekat kroz kanale (čime daješ ownership thread-u na drugom kraju kanala i source thread ne može više da mu pristupi), ili koristiti mutex koji garantuje da samo jedan thread ima pristup u jednom trenutku - svaki drugi pokušaj rezultuje u greški u prevođenju.

No to ne sprecava Rust implementore da naprave Rc/Arc strukturu :P
Znaci nije deo jezika ali funkcionise kao shared_ptr kod C++-a.
Bez Rc strukture tesko da bi mogla da se implementira bilo kakva dinamicka struktura podataka....

mmix:"Na kapiram, kako onda ti sa Rustom mozes da napravis multi-threaded kod? kako moze kompajler da predividi koji thread ce u kom trenutku imati pristup objektu?"

vrlo lako, samo pokrenes thread i kraj, sad ima i async koji krije mt kod u okviru jezika. E sad kveker sa threadovima je isti kao i ostala pravila koja je Burgos naveo +
sto mora objekt neki da podrzava Send i Sync traitove da bi se predao threadu i mogao da ih menjas inace nista iz threada ne mozes da promenis.
Naravno imas Mutex/Arc i slicne pomagalice koje prikrivaju to pa mozes menjati.

Inace Rust ima raw (* pointer-e) koje mozes zawrapovati u unsafe blokove i nista od restrikcija onda za njih ne vazi. To se zakopava
u lib i onda odozgo imas privid da je sve dendi. Zapravo bez raw pointera malo sta fundamentalnmo moze da se implementira u Rustu.
Da bi zeznuo reference checker ljudi prave clone metode koji samo prave laznu kopiju da bi kompajler mogao da se prevari :P

Ali to je BS. Ja vidim da se ljudi nesto loze na taj Rust, ali meni deluje kao potpuno retardiran jezik namesten da javascript-level mindsetovi mogli da prave metal-level i sistemski code. Dalja idiokratizacija struke.

U cemu je poenta trpeti to izivljavanje ako na kraju moras da koristis raw pointere? Onda bude jos gore nego da imas GC. Mogu da zamislim generic overhead za send/sync traits koji uopste ne vidis u kodu.

Poenta je sledeća:

Rust je razvila Mozilla fondacija za potrebe razvoja FireFox-a. Otkako je izašao FireFox Quantum, koji je napisan u Rust-u, nasuprot ranijem FireFox-u, koji je bio pisan u C++-u, FireFox Quantum radi dosta brže, a možda se i brže razvija.

To je poenta.

Pa poenta je onda da je stari Mozilla kod bio trash. Ne znaci da Quantum ne bi bio brzi da je krsteno napisan ispocetka u C++u i da je zasluga ubrzanja u Rust-u. Stalno se potencira ta brzina, a sve je "should" and "would". "Mi smo bajbolje ali LLVM nas zeza", itd, itd.

Malo se brkaju teze ovde. Jedna je stvar sto firme hoce da predju sa C++ na Rust zbog prevalentnog raspadanja IT skolstva fokusiranog na davanje fakultetskih diploma pyhon/javascript imbecilima. Taj aspekt mogu da razumem, da si kao firma u problemu da nadjes ljude koji znaju dobro da programiraju dalje od osnovnih struktura i pozivanja biblioteka koje je neko treci napisao, taj problem i mi imamo kontinuirano. A potpuno je druga stvara pricati u superlativu o programskom jeziku koji je u osnovi debilan i iznudjen i kod kojeg si konstantno primoran da radis protiv njega da bi nesto smisleno uradio. Mogao si onda da napravis i biblioteku za python i da je pozoves iz pythona. Apsolutno deluje kao immature tehnologija koja sasvim sigurno ne zasluzuje da bude u kernelu OSova kao sto je Windows ili Linux.

Da, zato sam rekao "bez stdlib dodataka kao Rc" koje se implementiraju vani :-).



Ne znam, ne delim isto mišljenje. Mislim da bi osobe sa JS pozadinom imale velikih problema sa Rustom. Dolazeći iz C i C++ sveta, oberučke prihvatam svaku pomoć
u tome da sam više siguran kada prosledim softver na stotine hiljada (možda i milione) mašina, da će raditi najbolje što može. Ne radi se ovde o osnovnim strukturama i pozivanju biblioteka, mi pišemo naše biblioteke, implementiramo nove algoritme i pripadajuće strukture podataka, ali je kompleksnost ogromnog projekta nešto što strašno jede produktivnost. Pomoć jezika u ovome je nešto vrlo dobrodošlo.



U većini slučajeva ne moraš :-). Kao što ni u većini slučajeva u C++ kodu ne koristiš raw pointere, već value-based semantiku. Čak ni za polimorfizam u C++-u (slično kao i u Rust-u), nisu potrebne reference. Sada, kao i u C++u, i u Rust-u su potrebni hardware abstraction layer-i, optimizovani vektori, itd. Kao i u C++u, Rust omogućava da se dođe do samog hardvera. Pogledaj ovu moju škrabotinu sa kojom sam pre par godina se igrao sa rust-om i ARMom: https://github.com/Burgos/micoos/ - svi viši layeri (kao što je process, msgbox, timer, scheduler ...) nemaju unsafe delove, dok za samo rvanje sa registrima korisim asm. Što znači da mi kompajler daje sigurnost kako rade viši delovi, naravno, sve dok mogu da garantujem za niže delove. U C++-u, sigurnosti nema ni za više, ni za niže slojeve.



Send/Sync su deo tipa i nemaju runtime overhead, koliko znam.



Ne znam na osnovu čega misliš da si primoran da radiš protiv njega? Naravno da ne možeš da pišeš na isti način na koji bi pisao u C-u, ali možeš vrlo lako i produktivno da pišeš kod, bez da se osećaš oštećen i da radiš protiv kompajlera, samo je paradigma drugačija. Meni je teže da pišem kod u Python-u, nego u Rust-u, a provodim slično vremena nad oba jezika (~10% nedeljno).



Kao nekome ko je proveo malo vremena sa njim, meni deluje sasvim drugačije. Ne kažem da je panacea, ali ne mislim ni da je drop in zamena za C da bi se JS programeri osposobili za bare metal programming.

Pazi, Rust uopste nije za pocetnike. Ja sam se jedno par godina mucio da skapiram kako sta da izvedem a da ne radim thinkering i botbu sa kompajlerom. Overhead nema za send i sync to je samo formalnost,
tj kompajler samo proveri da li je trait implementiran za strukturu nista od toga ne postoji u kodu kad se iskompajlira. U rustu se traitovi koriste za genericko programiranje, vrlo retko
ih koristis bas kao interface( kao u C# ili Javi) pa da ima taj dynamic dispatch overhead.

Znas kako, mnogi C/C++ programeri se slazu sa tobom. Ali stvar je u tome da kad jednom napises Rust program on nema klasicnih problema kao recimo C++. No delepoing time je veci u Rustu zbog toga. Nisam bas siguran
da jezik koji je sebe napravio takvim da produzava vreme razvoja i ne koristi GC, da je usmeren Python/JS programerima, al ajde. Jezik koji jeste usmeren Python programerima je Go i to je sasvim druga kategorija.

Rust je prevenstveno namenjen za funkcionalno programiranje, a ne objektno-orjentisano. Nije ista paradigma.

Dakle, nudi sigurnost za safe deo, koji je gro projekta, pod pretpostavkom da su osnovne strukture koje su ostale unsafe dobre, a one čine mali deo projekta.

Sve to može i u C-u ručnim vođenjem računa o svemu, ali ovde jezik pomaže oko te provere.

Tako je, ML deo jezika je baš puslica, mada je Rust imperativan, kao uostalom ML familija...

Cini mi se da pukovnik Linus rekao jednu-dve pohvalne reci o Rustu

https://www.theregister.com/20...nux_maintainers_says_torvalds/

Ocekivano, ako misli da se sa ovim nastavi:

Ko god je kompajlirao kernel zna koliko se kompajliraju drajveri, pausalno 90% vremena se provodi kompajlirajuci drajvere...

@Branimir Maksimovic

Pa, funkcionalno programiranje je takođe imperativno. Skoro svo programiranje je imperativno.

Imperativno programiranje podrazumeva da se mašini ne opisuje problem koji rešava, već postupak rešavanja problema.

Deklarativno programiranje podrazumeva da se mašini opisuje problem koji se reševa, a ne postupak njegovog rešavanja.

Primer ovog drugog je prolog. Tamo se opisuje problem u vidu sistema logičkih formula i definicija u određenoj sintaksi, pri čemu su te formule takve da postoji opšti algoritam za rešavanje takvih sistema, koji je ugrađen u implementaciju jezika.

Nedeljko:"Pa, funkcionalno programiranje je takođe imperativno. Skoro svo programiranje je imperativno."

Nije. U Haskell-u recimo da bi uveo sekvence imas specijalan tip: Monade. Znaci u pravom f-nalnom jeziku
se sekvence uvode preko nekih metoda koja nisu u okviru samog jezika.
No u Haskell-u nemas petlje, varijable i te stvari koje cine imperativno programiranje.
Svakako da mozes implementirati petlje preko rekurzije ili varijable preko hendlova
ali to nije native u jeziku.

Ja ovde kao neocekivano vidim kako razna ubrzanja pisanja koda samo uspore na kraju :)

Krenuli ste u offtopic, ajde napravite temu za smaranje sta je bolje ili c.

Pa, naravno da je bolje "ili c".

Da li si hteo da kažeš da

"Razna ubrzanja pisanja koda samo uspore izvršavanje na kraju."

ili možda da

"Razna ubrzanja pisanja koda samo uspore pisanje koda na kraju."?

FF postoji za različite platforme, ne znam koliko su zajedničkog C++ koda imale verzije za različite platforme, a koliko kod Rust-a.

Ono, kad bi se bar kod svih OS-ova uniformisao API što se tiče osnovnih elemenata GUI-a (prozor, meni, osnovne kontrole, itd.), tj. da nazivi API metoda i parametri budu isti, ili da bar postoji neki prevodilac između različitih platformi.
S obzirom na rast popularnosti .NET Core kad bi dodali mogućnost kreiranja makar elementarnog GUI-a na različitim platformama, ali to bi zahtevalo različite implementacije tih delova biblioteke na različitim platformama, što otežava dalji razvoj, a i vidim da su kod .NET Core 5 planirali da integrišu Xamarin. Međutim, kako je kod .NET Core 3 dodata mogućnost kreiranja Win formi (tj. Win GUI aplikacije), sa naglaskom da to za sada radi samo na Windows-u, možda je u planu da u nekoj budućoj verziji dodaju tu mogućnost za Linux i MacOS.

Eto, možda sam sabajle jutros malo nalupetao nekih stvari koje se neće ostvariti, ali nikad se ne zna sa MS-om. Ako naprave .NET Core verziju sa kojom može da se kreira normalan GUI na različitim platformama (ne Xamarin forms), C# će postati još popularniji.

Kod ozbiljnih projekata kao što je FF i koji su od početka cross-platform, gro koda je zajednički, jer gro koda nema veze sa specifičnostima OS-a.

Ako si pravio nešto ozbiljno, tipa AutoCAD, ali što nije odpočetka cross platform, pa si prosipao Win32 API pozive po projektu, onda naravno da portovanje može biti problem.

^ Tako je, win32 api je stop za bilo kakvo razmisljanje o cross platform portiranju, tako da za win forms(.NET) mrka kapa.

Mislim da ce ms$ probati za par godina preko web assembly tj blazora, ali je za sada to na dugom stapu.

Nije nikakav stop. Lako ga je apstrahovati u obliku nekog omotača, koji može da bude cross platform, a i ne mora.

Mozda je lako napraviti interface, ali je druga prica za njegovu implementaciju, jer ne postoje win ekvivalentne funkcije u linux kernelu i obrnuto.

Interfejs opisuje prirodu problema. Onda se on implementira na svakom sistemu posebno. Program se onda oslanja na interfejs.

Verovatno ce praviti nekog electron-like monstruma.
Ono sto bih ja voleo videti je cross-platform WPF al' slaba sansa.

A šta su prednosti WPF-a? Brže radi us loženim slučajevima zbog zamene GDI-ja DirectX-om i korišćenje istih komponenti az desktop i web?

Možda je mislio za već postojeće aplikacije, kao i programere koji rade za Win platofrmu, a sad bi postali konkurentni i na Linux-u. To ne bi trebao da bude toliki problem, Linux već ima npr. Wine, kad bi se MS uključio, mogao bi da realizuje 100% kompatibilnost, ali čemu onda Windows, svi bi pobegli od Win10.

Mislim da M$ zeli da privuce Linux programere definitivno, ali ne zeli da odvuce Windows programere na Linux :P

Pa, ja sam to rekao iz skroz licnog razloga, ne kao neko opste dobro*. Meni se taj framework svidja. Ima svoje mane ali sveukupno gledano mi je se svidja kako radi, kako se radi razvoj desktop aplikacija u njemu, sveobuhvatnost (od low-level grafike, preko 3D-a do konkretnog UI-a).
Sto se cisto tehnickih razloga tice, necu reci prednosti jer bi to znacilo u odnosu na nesto a svakako postoje tehnologije koje imaju nesto od toga, ali dobre strane su mu to sto je (vecinom) u pitanju vektorska grafika, sto koristi graficku akceleraciju (u trenutnoj implementaciji DirectX), layout sistem koji ima, sistem sa content controls i items controls**, data binding, x(a)ml kao jezik za UI, itd. Stilovi su, imho, bolje uradjeni nego kod html/css-a.

Ono sto bih ja voleo da vidim je da MS odvoji WPF od DirectX-a vec da napravi sistem da se render moze implementirati na razlicitim grafickim API-evima i da se ili pri build-u ili, jos bolje, tokom izvrsavanja moze odrediti koji ce se koristiti. Onda se mogu napraviti implementacije rendera na OpenGL-u koji je vec cross-platform, dok i sam WPF moze raditi sa .NET Core-om a krajem godine sav .NET ionako ide na Core pa ce taj deo biti multi-kulti anyway.


*Iako bi verovatno bilo, bez ovog UWP bauljanja po mraku gde vec godinama ne mogu da se odluce sta hoce (i sta nece).

**Imas mogucnost da kao sadrzaj jedne kontrole stavis bilo sta, drugu kontrolu, grafiku, tekst... Za Items tip kontrole imas mogucnost definisanja izgleda item-a pa mozes imati ListBox koji npr. prikazuje listu kontakata gde je svaki kontakt prikazan sa slikom, imenom, godistem i dugmicima edit/delete. Kreiranje takvih stvari je uniformno kroz xaml.

Mislim da .net moze biti interesantan samo nekome ko ima kod u tome pa hoce da radi i na OSX i na Linux-u.
Mikrosoftu svakako da ne odgvora da GUI radi na Linux-u.

MS$-ov glavni biznis je sada cloud, u tom smislu su zainteresovani da sto vise ljudi pici po NET Core, jer to implicira veci broj narudzbi Ažure instanci. Naravno ima dosta i sekundarnih ciljeva, kao sto je veci user base za testiranje itd.

Sto se desktopa, odgovorio sam gore, znaci moze neki ciri bu, ciri ba, kao sto je Xamarin koji prevodi "template" u platform speficni kod. Cak za macOS moras da radis build na mac-u.
Druga varijanta je "Electron like monstrum" kao sto je spomenuto, znaci chromium ili slicno kao render.

Da se vratimo na temu:

Šta radi ovaj kod, kompajliran 32-bitnom verzijom MinGW-a na Windows-u):

VS2017 poziva konstruktor A pa destruktor A. mingw nemam.

edit:
i g++ na Manjaru isto daje.

_{[Ovu poruku je menjao Branimir Maksimovic dana 14.07.2020. u 16:16 GMT+1]}

Ima na jednoj drugoj temi u forumu za C/C++.

Program puca prilikom završetka rada.

Otkači pre vremena neki dll u kome se nalazi funkcija free() potrebna za delete.

To se dešava samo sa MinGW kompajlerom i samo za thread_local static objekte čiji destruktor ima neki free()/delete ili sličnu funkciju.

Evo o čemu pričam:

To se ne dešava sa MinGW-w64. Radi se o bagu u jednom određenom kompajleru, koji dugo nije ispravljen.

Da se vratimo na temu.


Ovaj kod ispisuje "razlicito".

Na kojoj platformi/kompajleru? Koliko znam, negativna nula ima drugačiju reprezentaciju, ali je i dalje nula, tj. (0 == -0) == true.
Kod koji daje neočekivani rezultat (i koji sam nekoliko puta video :( ) je:

Koliko znam, znak se beleži jednim bitom, pa ako je - 0.0 < 0.0,onda će i memcmp dati različito, no nisam se bavio tom egzotikom...

Da, u IEEE754 reprezentaciji, jedan bit određuje znak i memcmp daje (ne)očekivani rezultat. Ovo se javlja kao problem, npr. pri optimizaciji poređenja vektora koji imaju floating-point elemente, gde naivan pristup sa memcmp daje pogrešan rezultat ili ukoliko se heširanje takvog vektora vrši kroz niz bajtova, umesto kroz vrednosti elemenata, itd.

Da, moleri prave hemiju, kao i sa operatorom %.

Jednakost (-2)%10==(-2) nema nikakvu praktičnu primenu, za razliku od jednakosti (-2)%10==8, koja ima praktičnu primenu. Međutim, neki "genije" je odlučio da u računar ugradi ovo drugo.

Isto tako i ovde. 1.0/0.0 nije NaN, nego INFINITY, dok je 1.0/(-0.0) jednako -INFINITY, pri čemu su to različite vrednosti.

Paran broj nula uz negativne vrednosti je besmislica.

Svojevremeno me je Ivan Dimković ubeđivao da to tako treba jer je u specijalnom slulaju sa dekodiranjem multimedije tako podesnije.

Dobro, u tom slučaju je podesnije, ali u mnogim drugim slučajevima nije, pa se napravi više štete nego koristi.

Nije nikakav problem da se zbog nekakve primene ubaci dodatna operacija. Jedno delenje za to, a drugo delenje za ostalo.

Zahvaljujem se Burgos-u na ispravci. Evo budalaštine:





Dakle, x == y i 1/x != 1/y, a nije NaN, niti greška zaokrugljivanja.

Windwows-ov Calculator je kod koji daje neočekivan rezultat. Evo:

Evo jednog koda u prilogu.

Ako se kompajlira sa gcc -O1 ili clang -O1, onda puca ne ispisujući ništa. Ako se kompajlira sa gcc -O2 ili clang -O2, onda ispisuje "Original list has 100000000 elements." i tek onda pukne.

Radi se o optimiyaciji steka, s tim da eliminacija steka u rekurzivnoj funkciji count nije baš jednostavna. fpc ne ume da tako nešto uradi prilikom kompajliranja odgovarajućeg Pascal koda.

Sa eliminacijom steka u funkciji reverseList već ni gcc ni clang ne mogu da se izbore, mada je iterativno obrtanje liste moguće. Jednostavno, kompajleri nisu dovoljno pametni da transformišu taj kod u iterativan. Naravno, to je u slučaju te funkcije i očekivano.

Nije neočekivan, kod mene radi "normalno" i daje isti rezultat za Standard: otkucaš 2+5, i kad pritisneš zvezdicu na numeričkoj tastaturi, izbaci 7, što kad se pomnoži sa 3 daje 21. Isto se dešava i kada operatore za sabiranje i množenje biraš na samom kalkulatoru umesto na tastaturi.
Kod Scientific verzije "sačeka" da uneseš '2+5*3' i kao rezultat daje 17.
Ne zna, možda im je to bio neki "bug" koji je brzo ispravljen novim ažuriranjem.

Sta je ovde cudno, program sa undefined behavior da puca?
Meni je najveci grad duhova bio kada sam u cpp fajlu definisao struct Data a da nije u anonimnom namespaceu. MS ima u afx*.h libu struct Data forvard deklaraciju i implementaciju u nekom libu.
To je izazvalo takve nepredvidjene rezultate da sam izgubio 5 sati dok nisam provalio u cemu je fazon. Ono sto je meni tu super interesantno je na koju foru je VC povukao definiciju strukture
iz drugog fajla a da nije prijavio nikakvu gresku ;)

Elem da objasnim u cemu je fazon, Radi se o strict aliasingu. Znaci kompajler podrazumeva da se radi o pointeru na strukturu a ne samo na pointeru na pointer. Zbog toga nesto mulja
dok optimizuje i verovatno kesira po registrima. Imao sam slican bug kod jednog lika re 10 godina, upravo na implementaciji linked liste i tog prvog noda koji je maskirao pointerom, pa je popravka
bila da se pointer kvalifikuje kao volatile da bi se sprecilo to kesiranje u registrima.

edit:
ma zaboravi ovo sto sam napisao, u tvom slucaju je obicno probijanje steka rekurzijom ;)
Sad probao i skapiram da je na Linux-u stek premali za milion rekurzivnih poziva ;)
ulimit -s kolko_treba i reseno

_{[Ovu poruku je menjao Branimir Maksimovic dana 08.04.2021. u 00:10 GMT+1]}

Branimir Maksimovic

Da, probijanje steka rekurzijom. Nema undefined behavior-a.

Ono što je neočekivano, je da ne puca funkcija count(), koja je takođe rekurzivna. Zapravo ona puca bez optimizacija, a ne puca sa optimizacijama.

Dakle, kompajler ima optimizacije sa kojima uspeva da eliminiše rekurziju u funkciji count(), dok to ne uspeva sa funkcijom reverseList().

Tail call recursion to je kada se rekurzivni poziv radi sa jump umesto sa call posto se onda rekurzija prakticno pretvara u petlju. No kod mene sa -O1 puca i count.
E sad, da nema undefined behavior, da, program je 100% po propisu. Nema casta nema prljavih zezalica ;)

edit:
evo nerekurzivne verzije te dve f-=je ;)


nisam stavio proveru u reverse ako je lista prazna ili sa jednim elementom :P



<sub>[Ovu poruku je menjao Branimir Maksimovic dana 08.04.2021. u 11:08 GMT+1]

[Ovu poruku je menjao Branimir Maksimovic dana 08.04.2021. u 11:10 GMT+1]</sub>

Pa, u prvoj poruci sam napisao da puca i count() pri -O1, odnosno da sa -O1 ne ispisuje ništa. Takođe, nije problem napisati obe funkcije nerekurzivno, ali onda ova tema ne bi bila obrađena - sa manje optimizacije puca, a sa više optimiozacije radi dobro (barem count() funkcija).

Međutim, interesantno je kako je kompajler bio dovoljno pametan da eliminiše rekurziju u count() funkciji. Ne radi se samo o zameni call sa jump, nego i o nenagomilavanju lokalnih promenljivih. Stek se nagomilava usled pamćenja adrese povratka (usled call, što jump nema), kao i usled lokalnih promenljivih. Treba eliminisati i jedno i drugo.

To bi bilo lako ako se svi izlazi iz funkcije svode na

1. return nerekurzivni izraz;

2. return count(nerekurzivni izraz);

Međutim, ovde rekurzivni poziv glasi

return count(l)+1.

https://en.wikipedia.org/wiki/Tail_call

Nego, rekurzija mora biti pod kontrolom, zato sto ovakvi problemi dolaze nenadano i tu ne moze nista da se uradi, zbog toga obicno dodas nivo rekurzije
pa ako sei zgubi kontrola opalis exception ili vratis gresku, sto u principu znaci da je nesto poslo naopako.

mjanic

Rezultat je pogrešan i nema tu šta dalje.

Zašto je pogrešan?

Ne postoji fundamentalna greška u tome da se cifra 1 piše kao 5, a cifra 5 kao 1. To je stvar konvencije kako ćemo šta pobeležavati. Možemop se dogovoriti da izbacujemo prioritete matematičkih operacija.

Međutim, postoje konvencije koje se podrazumevaju, a koje se uče u školama širom sveta. Ovo je u suprotnosti sa time.

Drugo, prioritet matmatičkih operacija nije slučajno takav kakav jeste, nego da bi se smanjila potreba za pisanjem zagrada.

Ako imamo artilkle u količinama k1, k2 i k3 sa jediničnim cenama c1, c2 i c3, onda je cena svega k1*c1+k2*c2+k3*c3.

Postoje suprotni primeri, gde bi se pisalo manje zagrada kada bi sabiranje bilo starije od množenja, ali je mnogo više primera gde je zgodnije da množenje bude starije od sabiranja.

Asimetrija između sabiranja i množenja potiče otuda što je sabiranje distributivno u odnosu na množenje, ali množenje nije distributivno u odnosu na sabiranje. Drugim rečima, u opštem slučaju važi

(a+b)*c=a*c+b*c,

ali u opštem slučaju ne važi

a*b+c=(a+c)*(b+c).

Ne kontam, ta slika koju si ti postavio može da bude i fotošop, kažem da kod mene radi kako treba, samo što kod standardne verzije ne čeka da uneseš ceo izraz, već čim uneseš npr. 2+3, on to odmah sabere kad pritisneš *, ako hoćeš da ti radi kako ti očekuješ, onda aktiviraš "scientific" (kako, inače, rade ovi 'scientific' digitroni koje koriste u školama i na fakultetima, a za one 'obične' ne znam, možda rade isto, a možda i kao ovaj 'standard' kod Win10).

Dakle, 'Standard' ti jednostavno ne dozvoljava da uneseš izraz npr. 2+5*3, već nakon pri 2+5 odmah izračuna da je to 7 prilikom pritiska *. Dakle, 'Standard' funcioniše tako što izborom bilo kog binarnog operatora (sabiranje, oduzimanje, množenje, deljenje, itd.) digitron izračuna prethodno unet izraz, tj. najčešće binarnu operaciju za prethodno uneta dva broja i odgovarajući operator između njih - praktično kao da si nakon uneta dva broja i operatora između njih pritisnuo =.
Da li je to ispravno ili ne, i ne zanima me, nikad ne koristim 'standard' digitron. Ali, mislim da su oni stari veliki digitroni (koristili se u prodavnicama, a možda ih neko koristi i danas) upravo tako radili (pa mora za mleko i 2 hleba umesto 95 + 40*2 mora da se kuca 95*1+40*2).

Ocigledno niko ovde ne pamti vreme od pre kompjutera.

Stvar je vrlo prosta: app Calculator je u osnovnom modu emulacija kancelarijske racunske masine.
A zasto kancelarijska masina radi tako kako radi? Zato sto na svaki pritisnuti operator, masina ispisuje operaciju + argument operacije na traku.
A sta ce nam traka? Pa nekad su se trake s tih masina prilagale u (recimo) bankama (SDK, itd.) prilkom predaje racuna, izvoda, i slicnog - kao dokaz ispravnosti onoga sto pise na dokumentu (najcesce sume).

Na slici je očigledno "standard".

Ukucaj lepo "2+5*3", tako kako piše, znak po znak i onda pritisni "Enter". Dobićeš 21. To što on nakon unosa zvezdice napiše 7 kao međurezultat i onda nakon pritiska "*3" i "Enter" ispiše "21", ne menja činjenicu da je to pogrešno. To što kalkulator "tako radi" nije opravdanje za pogrešan rezultat. Ako nekada nije bilo tehničkih mogućnosti da se prave mašine koje poštuju prioritet operatora, nije opravdanje za takve kalkulatore na računaru, koji ima potrebne tehničke mogućnosti.

To da je ponašanje kalkulatora u standard modu "pogrešno" je samo jedna ocena. Ja očekujem to "pogrešno" ponašanje, jer sam na njega navikao, i ja nisam sam. Možda će promeniti ponašanje kad većina nas matorih izumre...

Nije samo jedna ocena. To je kao kada bi cifru 5 pisali kao cifru 8 i obrnuto. Jednostavno se u školama uče drugačije konvencije. Ako neki očekuju da je 1+2=5 zato što imaju drugačiju interpretaciju upotrebljenih oznaka, onda su oni ti koji se ne uklapaju u ostatak sveta.

Evo jedan kratak primer/dokaz da je Kalkulator u osnovnom modu emulator kancelarijske racunske masine.

Ukucajte ovako nesto

72
/
12
=

dobicete 6, ocekivano.

A sad ukucajte

36
=

i sta ste dobili?

Nepobitno, Kalkulator (osnovni mod) radi tacno kao (pra)istorijska kanc. masina.

Radi pogrešno. Sve ostalo je nevažno.

Ne radi ono što si ti zamislio, pa je zato pogrešno? Ne radi onako kako te naučila učiteljica, pa je zato pogrešno?
Za ono što se uči kod učiteljice nije potreban ovaj digitron u Standard modu, pa i ne mora da radi tako!

Tebi ako se ne sviđa kako radi, aktiviraj Scientific mod, tu radi onako kako ti očekuješ.

Ne radi ono što piše u međunarodno opšteprihvaćenim konvencijama, koje se uče u školama i na univerzitetima širom sveta. Dakle, svuda, na svim nivoima obrazovanja.

U standard modu radi pogrešno, a najgore je kada se greške ne tretiraju kao greške, nego kao nešto isparvno. Da se tretira kao bag ili nesavršenstvo prethodnih verzija, već bi bilo ispravljeno.

Problem je što ti očekuješ da to bude "digitron" i da radi onako kako si navikao da pišeše. U Standard modu ne možeš da unosiš više od jednog operatora, dakle napišeš 2+5 i čim pritisneš * on izbaci broj 7 koji množi sa sledećim unetim brojem. Ako više puta pritisneš samo znak jednako, šta se dešava?
Ako se malo igraš, videćeš da to nije običan digitron, jer nije ni napravljen da se koristi kao običan digitron/kalkulator, jer se sabiranje i množenje uči u prvih nekoliko razreda osnovne škole pa nema potrebe za to koristiti klasičan digitron :)

Koliko sagovornika sa oprečnim mišljenjem je potrebno, pa da bi neko stavio i svoje mišljenje u širu perspektivu?

@mjanjic

"U standard modu ne možeš...". Koji je vek i koji su resusrsi potrebni da se napravi da možeš?

"On izbaci... ako više puta pritisneš... šta se dešava?". Ovo se svodi na opisivanje ponašanja dotičnog programa. Nije sporno da se on tako ponaša. Oko toga smo se složili. Ne slažemo se oko toga da li je to ponašanje ispravno ili pogrešno.

Vidim ja da to nije "standardan digitron", nego neko njecpa. O tome i pišem. Tamo piše "Calculator, standard mode", ali nije "običan digitron".

"... pa nema ni potrebe da se za to koristi klasičan digitron.". Gde ima potrebe da se koristi ovakav digitron? Ne zanima me gde nema, nego gde ima. Use case gde je ovaj u prednosti. Ne jednako dobar, nego u prednosti.


@Mihajlo Cvetanovic

Upravo ste vi ti koji ste u manjini. Ja govorim o tome šta se uči u celom svetu na svim nivoima obrazovanja. Jedini osnov po kom vi očekujete to što očekujete je taj što ste videli da jedan pojedinačan proizvod tako radi.

Objektivno, standardnim konvencijama se minimizuje potreba za pisanjem zagrada uz zadržavanje infiksne notacije. U prefiksnoj i postfiksnoj ne trebaju zagrade, ali zato one imaju druge nedostatke.

Cek malo. Koliko mi je poznato, onaj najobicniji kalkulator ("digitron") se ponasa upravo kao i standard mode u Windows-ovom kalkulatoru. I u njemu kad kucas 10+5*4 dobijes 60 a ne 30.
Svaki obican kalkulator koji sam ja video je tako radio. Scientific kalkulatori ne, kao i scientific mode u Win kalkulatoru.

Već je neko ranije napisao zašto je to tako i kakvu mašinu oponaša "standardni" kalkulator.

@Shadowed

To što postoje loši proizvodi ne menja činjenicu da su ti proizvodi loši i ne znači da ih treba kopirati.

@mjanjic

Tamo piše "Calculator, Standard mode", a ne emulator neke prastare mašine. Te prastare mehaničke mašine su tako pravljene zbog tehničkih ograničenja. Bilo je skupo da se naprave tako da poštuju prioritet operatora, a mnogi inženjeri elektronskih mašina nisu znali potrebne algoritme. To sve ne znači da to tako treba.

Pijačni kalkulator: Ako je količina -tog artikla, a njegova jedinična cena, onda se ukupna cena računa kao

.

Ako se poštuje prioritet operacija, ne trebaju zagrade. Unosi se brzo lako.

Priznajem da nisam vec godinama koristio fizicke kalkulatore ali urpavo ti "pijacni" su racunali operacije redom kako se unose, bez pravljenja prioriteta.
Da li je trebalo praviti emulaciju toga ili ne, svako moze imati svoje misljenje. Medjutim, ako je neko pravio emulaciju toga i ako aplikacija radi kao taj kalkulator koji je pravljena da emulira, aplikacija je ispravna.
Ispravnost aplikacije se ne gleda na osnovu toga da li zadovoljava matematicka pravila vec da li zadovoljava zahteve narucioca (u ovom slucaju je MS i narucilac i izvrsilac).
Ako meni neko naruci da mu napravim simulator tela u gravitacionom polju i hoce da gravitaciona sila opada sa rastojanjem a ne kvadratom rastojanja, simulator ce biti ispravan jedino ako simulirana gravitaciona sila opada sa rastojanjem iako ne prikazuje ispravno zakone fizike.

Kupac je onaj ko licencira Windows. Niko od MS-a nije tražio neke takve stvari, tako da se ne mogu pozivati na to. Takođe, nigde ne piše da je simulator nekog krša, nego da je kalkulator u standardnom načinu rada.

To što "pijačni" kalkulatori ne valjaju, ne znači ni da valjaju, ni da ih treba kopirati.

Isti taj MS, kada pravi Excel ili kompajlere za programske jezike, tamo je 1+2*3=7 i nikako drugačije jer MS tu mora da bude ozbiljan.

Ovo je nešto nalik na Notepad. Napravili su katastrofu od editora da ne bi bili pšredmet antimonopolskih tužbi. Danas je Notepad dosta bolji nego što je bio, ali to je to.

Zato sam i naveo da je MS i narucilac. Hteli su da naprave neki proizvod na neki nacin i to uradili. Napravljeni program ispunjava specifikaciju i ako je ispunjava, ispravan je.
Da li je specifikacija trebala da bude takva ili ne je stvar misljenja i svako ima svoje.
Ne treba ti Excel kao primer. Sam taj calc.exe ce ti raditi 1+2*3=7 ako je u drugom modu za koji je specifikacijom predvidjeno da tako radi.

Da je MS tako razmišljao, kako je on naručilac i da je nešto dobro ako zadovoljava njegovu specifikaciju, ne bi namlatio tolike pare. Biće da stvari stoje drugačije. Ko to na kraju plaća? Korisnici koji licenciraju, a ne MS.

Windows je njihov proizvod, nije ga neko narucio od njih. Napravili su ga po svojoj zamisli i prodavali.
A mogu da se kladim da vecini i odgovara ovakav calc kakav jeste jer ima oba nacina rada i svako moze da bira koji hoce.

Windows je uspeo jer je MS osluškivao tržište. Da se ponašao po filozofiji "ovo je naše i ima da bude kako smo mi zacrtali", ne bi bio toliko široko prihvaćen, koliko god da MS ima pravo na to.

OK, onda je trziste reklo da hoce calc takav kakav jeste pa su ga uradili po specifikaciji trzista i opet, sve dok zadovoljava specifikaciju ispravan je, cak i ako ne zadovoljava matematicka pravila.

U svakom slucaju, taj detalj je nebitan. Ko god da je autor specifikacije, sve dok program radi po njoj - ispravan je. Mozda se tebi ne svidja specifikacija al' ne znaci da je program neispravan.

Nije ispravan, a tržište svakako nije odabralo Windows zog Calculator-a i Notepad-a. Kome na Windows-u treba standardan editor, taj skida Notepad++. Kome treba kalkulator, takođe skida nešto drugo. Ne znam šta, jer kalkulatori na GNU/Linux-u i android-u rade kako treba.

Cekaj sad, je l' MS radio calc po svojoj ili trzisnoj specifikaciji? Odluci se :)
Ali kao sto rekoh, po cijoj god da je radio, ako program radi po specifikaciji - radi kako treba ma koliko ti ponavljao da nije tako.
Kalkulatori koje si pomenuo za Linux su takodje ispravni jer rade po specifikaciji koja je bila za njih.

WTF? Nema ovde nikakve greske.

- Da li negde pise da ti standardni kalkulator omogucava unosenje formula? Ne, standardni kalkulator uvek izvrsava trenutne operacije i nema nikakav prostor ili funkcije za drugacije
- Da li to moze tebe da zbuni? Ne znam kako - gde vidis da pise tvoja formula? Nigde - ona postoji samo u tvojoj glavi, standardni kalkulator niti je ima, niti moze da je ima

Evo ti cak i specifikacija:

https://github.com/microsoft/calculator



Dakle, standardni kalkulator u Windowsu ne radi ono sto zelis, ali to i ne tvrdi. Upravo obrnuto: specifikacija kaze da rade upravo onako kako se i ponasa.

Pogledajte ovaj screenshot, standard kalkulatora, koji je Nedeljko postavio:

https://www.elitesecurity.org/p3959626

Iznad rezultata 21, piše: 2 + 5 x 3 =

Pre par nedelja, kada sam pogledao temu, postavio sam oba kalkulatora (standardni i scientific) jedan pored drugog, ukucao isti izraz, i uporedio rezultat.

Ubeđen sam da je na oba kalkulatora, iznad rezultata (21 za standard i 17 za scientific) bio potpuno isti izraz 2 + 5 x 3 =.

Ono na šta sam ja lično imao primedbu (nisam se javljao u diskusiji), upravo je ovaj izraz koji je bio ispisan iznad rezultata standardnog kalkulatora, koji mi je zbunjujuć spram rezultata, kada ga kao celinu pogledam.

Evo, malopre sam na istom računaru pokušao da reprodukujem isto, i u standard verziji više nema tog izraza, već samo onaj poslednji međurezultat, kako se i očekuje.

Nek bude da sam umislio ovo za izraz na standard kalkulatoru, dok se ne dokaže da je neki update rešio probem.

Pazite, mozda sam "prolupiska", ali meni to iznad izlgeda kao lista izvrsenih operacija u redosledu, ali ne i formula.

Windows 10, Calculator 10.2103.8.0

Pisala formula ili ne, starinski kalkulatori su poštovali prioritet i asocijativnost operacija, uz ograničavanje broja istovremeno otvorenih zagrada. To je dokaz da je to tehnički izvodljivo. Svejedno je da li je izraz prikazan ili ne.

A to da korisnik treba da gleda na github za uputstvo... Šta reći? Šta je sledeće -- piše u sorsevima, pa rastumači C# (ili koji već treba jezik).

Ne radi se ovde niokakvoj nuklearnoj fizici (na šta verovatno Ivan Dimkovic pretenduje upotrebom izraza "matematička formula", kao da je to za neku apstraktnu matematiku), već o onome što se uči u osnovnoj školi i primenjuje u najprostijim kućnim obračunima.

MS može da ima svoje specifikacije, pa neka napiše uočljivo upozorenje, da kalkulator ne radi kako bi trebalo, nego odmah primenjujući operacije.

O čemu mi ovde raspravljamo? Koliko je 2+5*3?

Na win calc-u odmah izvrsava operaciju i daje medjurezultat koji dalje podleze operacijama, ne ceka (=) pa da radi procesiranje cele formule, sa svim pravilima oko toga koja je operacija starija...
Ono gore, jeste samo neki array [2, +, 5, *, 3] tj. kolekcija ukucanog.

Na mac calc-u, ne radi medjurezultat, vec ceka (=) i tretira ucukano kao formulu, znaci 2+5*3 na mac-u je 17.

Secam se ta 2 slucaja, kroz maglu na nekom od casova informatike u srednjoj skoli..

Nedeljko, pukao si.



Ne, odes na google i ukucas: Microsoft Calculator Specification... vecini ljudi ne treba, posto nisu pahuljice niti im je vrana pojela mozak pa da ocekuju od imitacije $0.99 kalkulatora da ima pamcenje.

Mislim da si ti verovatno jedina osoba u celom vidljivom univerzumu koja je tako nerazumna. O kojim starinskim kalkulatorima pricas? O starinskim kalkulatorima sa NEPOSREDNIM racunanjem (znas, oni sto izgledaju bas kao taj Windows "Standard" kalkulator)? Daj neki model? Bas bih voleo da ih vidim.

Nemam nikakvu plastiku ovde i koliko se secam nisu oni imali nikakvo pamcenje, ali mozemo da probamo malo istorije u softveru:

- WINDOWS 2000 -



- WINDOWS 3.1 -



Ok, Microsoft, pojma nema... daj da nadjem neki malo ozbiljniji OS... hmm....

SunOS? Ovaj OS je bukvalno terao sve ozbiljno ranih i sredine 90-tih... radna stanica kod vaseg telco operatera je terala SunOS, radna stanica na uniju je terala SunOS i tako.

- SUNOS 4.1.4 -

Sta kaze njegov kalkulator? Uh, za pocetak me je iznenadio izgled. OK jasno, ovaj OS verovatno nikad nisu koristili "amateri", pa mu i ne treba amaterski calc.

Uh, gulp...

Kucam lepo direkt: "2", onda "+", onda "5", onda "X" onda "3" i konacno "="... i dobijem sta? 21. Dodjavola, izgleda cak ni Sun korporacija ne slusa Nedeljka, nije samo Microsoft korporacija.



Ali cekaj, ima BONUS... ubacim ti ja SunOS kalkulator u "SCIENTIFIC" i... os qr, radi isto :-)

- YEAH, SCIENCE... BITC*ES... ?! Science? -



AUUUU! Zamisli kad Windows radi bolje posao od ovoga... eeeee kako li su svi ti ljudi uopste nesto radili tada - mozda nisu bili pahuljice sa peskom u vag-u :-))))

--

Jel treba jos neki da testiram? Ono, DEC Alpha + OpenVMS ili neki HP UX? HP najbolje - to bi bilo kul :-))))

_{[Ovu poruku je menjao Ivan Dimkovic dana 28.04.2021. u 22:41 GMT+1]}

Naravno da je matematicka formula. I to onda predstavlja problem koji zahteva specificno parsiranje i postovanje specificnih pravila.

Kada su jeftini kalkulatori za domacice (pardon, za domacicX - da ne budemo patrijarhalni) preplavili svet, implementacija evaluacije formula koja bi postovala redosled operacija bi takve uredjaje otpisala iz trzista.

Cisto perspektive radi: kad je doslo do revolucije i kada su trziste preplavili Japanci, prvi iole dostupni "dzepni" kalkulatori poput Sharp QT-8B su kostali $470 (danasnjih $3073).

Da, $3073... tek tamo krajem 70-tih su poceli da se omasovljavaju pravi jeftini kalkulatori koji spacaju u klasu "four functions" :)

Kuriozitet - prvi evropski "four functions" kalkulator je napravljen u SFRJ, od firme "Digitron" :-) iz Buja u tadasnjoj SFR Hrvatskoj --> model DB 800, kostao je koliko i Fica.



Konacno, kada su OS-evi na mikroracunarima krenuli da oponasaju kalkulatore u GUI-ju, logicno je da je iskopirano celo ponasanje onoga sto se "kopira".

Tako i dan danas "dzepni kalkulator za domacice" radi bas kao i njegov fizicki uzor. Bilo sta drugo bi samo zbunilo ljude do daske i bilo bi kontraproduktivno.

Kome treba korektno ponasanje u evaluaciji, taj nema nikakav problem da se prebaci u odgovarajuci mod, ili da instalira odgovarajuci softver.

Ja sam imao ovako nešto

Na MS-ovom kalkulatoru nigde ne piše da je to emulator neke određene mašine, nego "Calculator, Standard mode".

Znaš kako, kada se plaćaju računi, nema tu "ja sam primenjivao operacije odmah". Ti fazoni na sudu ne prolaze.

Uzmi MacOS ili GNU/Linux ili *BSD. To su (posle Windows-a) četiri vodeća desktop OS-a.

Uzmi android i iOS. To su vodeći mobilni OS-ovi. Na ostalima (van desktopa i mobilnih uređaja) se kalkulatori ne očekuju.

Nedeljko,

Da li ti bilo gde na ekranu vidis ispisanu istoriju operacija? Ne.

Da li bilo gde drugde pise da digitron radi evaluaciju formule? Ne.

Kalkulator samo oponasa isto izgledajuci fizicki uredjaj.



Ne, zato sto se od tebe kao osobe za mozgom i odgovornoscu ocekuje da znas sta radis.



Koji fazoni? Ako se budes vadio na digitron, mozes samo ocekivati da iznerviras sudiju. Sudiji se *ebe za digitron a nemas cak nista ni da dokazes da je digitron van sopstvene specifikacije.

Sudija bi te pogledao kao budalu i naredio ne samo da platis stetu nego i da se izbacis iz strukovnog udruzenja racunovodja.



Eto, koristi njih i svima super.

Pa, upravo ti o tome pričam. Kada se dođe do para, onda je 2+3*5=17.

Ako na sudu budeš tvrdio da je zbog načina rada kalkulatora 2+5*3=21, sudija će te pogledati ko budalu i ostalo šta si napisao da sleduje. Znači, taj kalkulator je neispravan.

Takođe, na kalkulatoru nigde ne piše da je emulator nekog drugog uređaja. Neki (mehanički) uređaji su u prošlosti tako pravljeni zbog tehničkih ograničenja (bilo je skupo da se napravi bolje), a elektronski zbog neznanja odgovarajućeg algoritma od strane inženjera koji su to projektovali. Ako je nešto zaista emulator nečega, onda treba da piše da je emulator. Inače je "čuvanje kompatibilnosti" sa takvim reliktima prošlosti besmislica.

Eto, android, iOS, MacOS, GNU/Linux i *BSD rade kako treba. Samo Windows izvodi besne gliste. Kako ostali nisu "zbunili domaćice"?

Na "Standard" kalkulatoru ne možeš da uneseš izraz "2+5*3", a da ti ne izračuna međurezultat, tj. čim otkucaš "2+5*", prikaže ti "7*".

Da li je to ispravno ili ne je neka druga tema, ti uporno namećeš da kalulator treba da uradi ono što si ti zamislio u glavi. Po toj logici "Standard" kalkulator treba da ima i mogućnost kucanja zagrada, ali ih nema!

_{[Ovu poruku je menjao mjanjic dana 30.04.2021. u 09:38 GMT+1]}

Satandard je ono što se uči u školama, a ne ono što MS nalupava.

Zasto bih ja tvrdio tako nesto? To moze da tvrdi samo budaletina koja ne zna sta radi.

Budaletina koja ne razume razliku izmedju:

- Formule 2+5*3 na "papiru"
i
- Direktnog unosenja brojeva i operacija u 4-f digitron

je samo budala koja ne zna da koristi digitron. Ako takva osoba ima neku profesionalnu odgovornost, to nece biti dobro po nju. Zapravo ne bi trebalo da bude dobro za idiota koji je zaposlio - ali to je vec druga prica.



Apsolutno ne, i siguran sam da i ti to jako dobro znas.

Taj rezultat (21) je po specifikaciji tog digitrona zato sto oponasa "klasicni" dzepni 4-f.

Ta specifikacija >nije< ekvivalentna ispravnoj evaluaciji matematicke formule. Sa takvom specifikacijom su ljudi ziveli vise od 2 decenije, pa prezivesmo nekako. Sve sto treba da uradis je da se izbacis iz tog moda, ili da koristis nesto drugo (neki drugi kalkulator, OS, stagod.)



Ne mora da pise, ali posto ne pise ni jedno ni drugo ostaje vizuelna asocijacija na uredjaj koji je davao 21.



Cuj, da ljudi iza prvog integrisanog kola nisu znali matematicki redosled operacija, cisto sumnjam da bi imali integrisana kola.

Razlog zasto su ti digitroni davali 21 je zato sto je to bila najjeftinija opcija u vreme rata sa Japancima kada je svako kolo, svaki bajt - bilo skuplje nego zlato.



Mozda "treba", ali se pokazalo da vizuelna asocijacija sasvim dovoljno radi posao osim kod jako malog % vrlo za*banih individua.



Odlicno, pravi svoje proizvode ili kupuji one koji ne oponasaju ono sto mislis da je besmislica.

Slobodno trziste, slobodna volja.



Samo Windows? Mislis "Samo Windows" i skoro svaki bogovetni dzepni 4-f digitron koji mozes kupiti za minimalne pare?

Piše, ko zna da čita:



https://github.com/Microsoft/calculator

Odlično, onda u tom "kalklatoru" na računaru odaberi "Scientific" mod i to je to, radiće ti isto kao to što si imao!

Moguce je da taj Nedeljkov kalkulator radi evaluaciju kao moderni kalkulatori na PC masinama.

Moj komentar se odnosio na ultra-jeftine kalkulatore "four functions" - dizajna, koji koriste tzv. "trenutni mod" iliti momentalno izvrsavanje operacija kako se unose.

Verovali ili ne, postoji standard i za ovo:

Za ljude koji su zainteresovani malo: https://en.wikipedia.org/wiki/Calculator_input_methods
Strucna literatura: https://www.amazon.com/Algorit...ators-John-Ball/dp/0471030708/



A, sad, meso - svakome ko ovo pogleda sa malo razumevanja ce biti odmah jasno da se ovde ne radi o jednom zahtevu i jednom resenju.

Postoje razlicite upotrebe kalkulatora, sa razlicitim ciljevima za optimizaciju. Zbog toga i postoji vise notacija kao i vise nacina racunanja. AES je samo jedno od njih, ali izuzetno popularno (i verovatno bi bilo gadno menjati navike ljudima koji su to integrisali u milijarde procesa).

Dakle:

1. Nije tacno da Windows kalkulator radi pogresno - Windows kalkulator radi po svojoj specifikaciji koja je dostupna svima
2. Nije tacno da je ta specifikacija neka nasumicna MSFT-ova glupost, to je oponasanje rada najzastupljenijeg tipa dzepnog kalkulatora
3. Cak ni to ponasanje nije nesto nasumicno, postoji strucna literatura i naziv (videti gore)
4. Imitiranje ovoga nije bila ekskluziva Microsofta - videti SunOS 4.1.4 gore
5. Tacno je da su neki drugi softverski proizvodi, primarno operativni sistemi - poput Linux-a ili iOS-a presli na drugi nacin racunanja i za "standardni" kalkulator, ali to su drugi proizvodi sa drugim prioritetima - srecom postoji izbor

Sta se iz svega ovoga moze zakljuciti?

TL;DR - tresla se gora, rodio se mis.

PS: http://bturn.com/10124/geeks-behind-the-iron-curtain :-)

Na PS linku pise:
“This is really important, I think that Croats, Serbs, Bosnians, etc. like to grow up too fast.
But for creating geeky stuff you must have the eternal spirit of a child.”

Bio je nedavno jedan dokumentarac o nekoj propaloj americkoj kompaniji (zaboravio sam ime) koja je puno obecavala.
Tu se mogao da vidi koji je to duh a puno imena je posle napravilo znacajne karijere ili kompanije.

Rekao bi da toga sada ima puno u Srbiji a verovatno i drugim delovima Balkana.

Sto se standarda tice ima jedno americko pravilo "Idiot otporno".
Tako je napravljeno da idiot ne moze pogresno da upotrebi.

Ako znas da se standardi tako "pazljivo i detaljno" prave (zlonameran bi rekao za idiote :) a manje zlonameran siroko upotrebljivo)
onda ocekujes samo neko (manje ili vise logicno) objasnjenje sto nesto radi bas tako kako radi.

Meni je cudnije sto u TV slgalici program u resenje ubacuje zagrade kod sabiranja i oduzimanja.
Pre neki dan je bilo neko resenje do kojeg je igrac dosao blize nego taj program.
Znaci da program ne pokriva sva resenja, sto je manjkavo, i ako uglavnom pronalazi bolja od igraca.

Ako ćemo da cepidlačimo, "2+5*3" nije matematička formula, već matematički izraz (expression, term), dok bi matematičke formule bile "2+5*3=17" i "2+5*3=21", od kojih je prva tačna, a druga netačna, ali ovde nećemo cepidlačiti oko toga.

Ako je rezultat neispravan, onda je kalkulator neispravan. Niko nije uspeo da navede nijednu prednost nepoštovanja prioriteta nad poštovanjem prioriteta.

Rekoh, kada se dođe do para i do suda, onda je 2+5*3=17.

Sud tu predstavlja neku objektivnu stvarnost - koliko god da poštenih sudija sudi u procesu o dugovanjima i potraživanjima, svi će dobiti isti rezultat.

Novac predstavlja nešto što je važno.

Dakle, matematika opisuje nekakvu objektivnu stvarnost, koja se primenjuje na nešto što je važno. MS-u taj kalkulator očigledno nije važan.

Neka MS to ubaci tamo gde mu je važno - u Excel ili kompajlere i interpretere.

Živelo se sa inkvizicijom šest vekova, pa se preživelo nekako. To inkviziciju ne čini ispravnom.

Ako ništa ne piše, onda se podrazumevaju konvencije koje se uče kroz obrazovni sistem.

Znali su prioritete operacija, ali ne i algoritam koji to radi i kako da ga implementiraju. To što su se razumeli u hardver, ne znači da su im softverski skilovi bili na tom nivou. Edsgar Dajsktra je znao, ali ne i ti inženjeri.

BTW u vreme integrisanih kola nije bilo rata sa Japancima.

U svakom slučaju, razlozi su bili neznanje+tehnička ograničenja, tako da je nasleđivanje toga budalaština.

Kako da ne. Onda bi svi sledili taj primer, pa ga ne sledi niko van MS-a. Bofl roba postoji i zbog nje deca dobijaju kečeve, jer sa njih nauče da je 2+5*3=21 iako nije.

Onda ti ne znaš da čitaš, pošto se tamo ne pominju niti reč "emulation", niti reč "emulator", niti neka sličnog značenja.

Uporedi ono što si citirao sa svojim odgovorom na to. Dakle, ti tvrdiš da tamo piše da je taj kalkulator emulator nekog drugog uređaja.

Neću ni da ga koristim. Nemam ja problem, ali to ne menja činjenično stanje da je to bofl.

A sad meso:

Ivan se poziva na literaturu iz 1978 godine, kada je kalkulator koštao ko Svetog Petra kajgana. Danas je 2021. Posle 43 godine treba nasleđivati nekadašnja ograničenja u ceni i rasprostranjenosti znanja.

Stvari relevantne 70-tih:

- Manje memorije = manje kola = manja cena
- Manje kompleksan algoritam = manje kola = manja cena

Stvari relevantne i dan danas:

- Za neke poslove, brze operacije

Kao sto sam napisao, cela stvar ima ime, ima specifikacije (ne MSFT-ove) i svoju svrhu.



Nedeljko samo treba da promeni mod operacije u Windows kalkulatoru, ili da instalira neki drugi.

Ili da predje na neki drugi OS koji ima default kalkulator koji postuje redosled operacija, a ne da trebas da mu menjas mod.

Problema, zapravo, nema.

Ama bas nigde.

Zabole me. Danas je 2021.

Koji su to poslovi i brze operacije, kod kojih nepoštovanje prioriteta daje prednost u odnosu na poštovanje prioriteta? Ne zanimaju me slučajevi gde je isto, nego samo gde nepoštovanje prioriteta daje prednost u odnosu na poštovanje. Konkretan use case.

Nedeljko nema problem, a ivan treba da

prizna da je nepoštovanje prioriteta lošije u odnosu na poštovanje i da je samim tim ta praksa pogrešna.

Primljeno k' znanju, ali posto nisi ti proizvodjac MS softvera, ne verujem da ce to imati ikakvog efekta na univerzum.



Imas citav istorijat i razloge postojanja raznih notacija. Ovog puta mene sad zabole da ti prezvakavam to. Ako te zanima, proucices. Ako te ne zanima, sto mene boli ona stvar da ti prepevavam.

Za ostale - evo jedne strane iz "matore knjige" koja prikazuje broj pritisaka na dugme potrebnih sa raznim konvencijama. Zamislite tipicno poslovno pitanje "kako da minimizujem broj pritisaka, ali bez da imam komplikacije sa obukom sekretarica".





Tebi bas lose ide parsirsanje. Ko je uopste i rekao da "Nedeljko ima problem"?

Receno je da problema nema. Em sto je jasno sta kalkulatori rade, em sto postoji specifikacija - em sto moze da se bira sta ko hoce.



2. Reci da je "nepostovanje priroteta losije u odnosu na postovanje" je besmisleno bez konteksta
3. Pokusavati nazvati nesto "pogresnim" pozivajuci se na nedovoljno preciziran problem je u najbolju ruku greska, a u najgoru intelektualna neiskrenost

A onda moze da se odgovori i:

1. Ivan nema nameru da "priznaje" netacne ili nedefinisane tvrdnje kao 2 i 3.

Ali samo ti vidis u kalkulatoru sa neposrednim izvrsavanjem nekav izraz "2+5*3=21".

Kalkulator sa neposrednim izvrsavanjem nema ni mogucnost reprezentacije tog izraza (posto ima samo 2 registra za brojeve), vec se njegovo stanje moze opisati sa nizom stanja u vremenskim trenutcima koji odgovaraju unosenju brojeva ili operacija:



Gde se stanje, ocigledno, obnavlja prilikom pritiska prstom na tastaturu.

U ovoj implementaciji nekakav izraz "2+5*3=" postoji samo u Nedeljkovoj glavi i samo je njegov propust sto ocekuje da se prozivod ponasa drugacije od sopstvene specifikacije.

Nije potrebno gubiti vreme sa "pogresnim" - nema nicega pogresnog u neposrednom racnanju, ako je implementacija korektna. Ovde je jos sve lepo dokumentovano, od specifikacije pa do algoritma za evaluaciju.

...

U svemu ovome Nedeljko ignorise cinjenicu da pokusava primeniti nekakva pravila na pogresan problem. Ne zeli da cita specifikaciju proizvoda koji pokusava da koristi, ko to jos radi - i sto bi neko citao MS djubre. Na objasnjenje da to nije 'MS djubre' i link na strucnu literaturu tj. knjigu koja je biblija za kalkulatore odgovara da je... matora (iako se sustinski nista nije promenilo ako se misli o pravom problemu, a ne o pogresnoj supstituciji u necijoj glavi) ...

Mentalni WD40 je potreban.

Đubreta ima i uvek će ga biti, ali to ne menja činjenice da je đubre đubre i da ga treba nazvati đubretom.

Mogu oni da na cifru 8 pišu kao 5 i obrnuto ako hoće i da to dokumentuju kao specifikaciju, ali to ne menja navedene činjenice.

I upravo po toj knjizi i potrebi smanjenja broja pritisaka na tastere je AES lošiji od RPN. Naveo si dokaz u moju korist.

Problema nema, kao što i postojanje šunda ne predstavlja problem. Šund je prirodna posledica slobode stvaralaštva, hiperprodukcije i različitosti kvaliteta stvaralaca i ja u tome ne vidim nikakav problem. Međutim, ovde se poriče da je šund šund.

Naveo sam kontekst - navedi mi use case gde je AES bolji od RPN. ne jednako dobar, već bolji.

Preciziran je. Korisnici se zbunjuju time što to odstupa od podrazumevanih definicija koje se primenjuju kada se ne naglasi drugačije. Iskaz "1+2=5" može biti tačan uz podesan izbor značenja upotrebljenih simbola, ali se tako nigde ne stiže. Takođe, te podrazumevane definicije su uvedene sa razlogom i imaju dužu istoriju od istorije kalkulatora na koju se pozivaš.

Uskočio si sebi u usta. Pročitaj znak po znak koje si tastere pritiskao i šta je bilo prikazano na kraju. Dakle, taj kalkulator kaže da je 2+5*3=21. Plavo je ulaz, a crveno je izlaz.

Dakle, nisi u stanju da navedeš use case gde je to bolje.

Dakle, ovo je MS đubre, bez obzira da li je greška u specifikaciji, implementaciji ili čemu god hoćeš trećem ili kombinaciji toga. Ako napišeš u specifikaciji da se 5 piše kao 8 i obrnuto i proizvod je usklađen sa tim, to neće značiti da je proizvod dobar, nego će ostati smeće.

AES je bio istorijski opravdan samo u vreme kada je to bio kompromis sa tehničkim mogućnostima i cenom, a nikako danas.

Stalno se piše o tome kako nešto nije "user friendly", o nekakvim "krivama učenja" itd, a ovde se insistira na tome da je usklađenost sa specifikacijom dovoljna.

Ne, nisam, nego ti, iz nekog razloga, u svom zakljucivanju ne mozes da koristis vise od jednog registra u tvojoj glavi. Sto je ironicno - posto upravo pokusavas da odbranis upotrebu steka :-)

Cak sam i napisao jedan od optimizacionih ciljeva. Dzaba ti ako nesto zahteva manje unosa ako se teze usvaja, ili ako je skuplji po pitanju implementacije.

Ne kupuje musterija algoritam, nego proizvod za resavanje nekog problema moj Nedeljko. Vecina stvari na tom stupnju su multidimenzionalni problemi.

Ali teraj dalje ako bas insistiras na "Standard" rezonu. Meni zabavno.



O ne ne ne, neces tako moci da se izvuces. Ti si koristio termin pogresna praksa. To je malo ozbiljnija stvar koja zahteva ozbilnije objasnjenje.

Dobio si odgovor da bez konteksta ne mozes nasumice nazivati stvari "pogresnim" - bez konteksta to nema nikakvo znacenje. Jasno je meni sto si presao na RPN vs. AES, posto bi za ovo prvo morao opet da algoritmu dodajes osobine koje nema, ili svrhu koju ne adresira. Onda bi, po N-ti put ispalo da u stvari ti pravis gresku (namerno, sada je jasno).

Ali ako vec pricas o "boljem": proizvod je "kalkulator" za neku konkretnu upotrebu. Vidi gore komentar oko optimizacije. Ti od drveta ne vidis sumu.



Samo ti vidis nekakve porazumevene definicije koje ne apliciraju na proizvod ili algoritam. U industrijskoj dozi tvrdoglavosti ne mozes da primetis da je cela planeta van akademije i specijalistickih upotreba savrseno zivela sa AES kalkulatorima decenijama - zive i danas sa istim kalkulatorima i Windows "Standard" kalkulatorom.

To bi trebalo nesto da ti kaze - da sednes i zapitas se da mozda ima tu necega sto nisi video.

Sto je najgore, intelektualno si neiskren zato sto se prostom primerom rigora koji zahtevas vidi da si TI taj koji pravi gresku i koji potpuno neosnovano trazi da se jedan algoritam ponasa kao potpuno drugaciji.



Apsolutno netacno. Ne samo netacno, nego i za zaljenje.

Tvoj pokusaj da koristis istu boju za razlicita stanja AES kalkulatora kreirajuci iluziju da postoji memorija i da se radi o jednom dugom izrazu je samo jos bolja i ociglednija demonstracija tvoje intelektualne neiskrenosti.

Do ovoga covek moze samo da je pretpostavlja, ali sad je vise nego ocigledna. Sam si lepo pokazao da lepo razumes AES i RPN (a kako ne bi) a sada se pravis mutav pa pravis ovakvu deciju gresku. Satro.

Znas, da se ne poznajemo ovde duze pa da pomislim da ne kapiras :-)

Na zalost, samo mislis da ces druge da navuces na "fintu" - na nivou ubacivanja deljenja sa nulom klincima. Ali niti smo klinci, niti sumnjam da se neko lozi na te finte ovde. Ne stoji ti.

Ivan Dimkovic optimizije kalkulator kao in place algoritam u 2021. godini? Windows 10 nema dovoljno resursa, pa mu treba optimizacija za to?

Da sumiram:

1. Saobraznost deklaraciji nije dovoljna da proizvod ne bude smeće.

2. Saobraznost deklaraciji znači samo da si samom sebi kriv što si to uopšte kupio i/ili koristio, odnosno da nemaš pravo na povraćaj novca i/ili servis u vezi sa tim.

3. Saobraznost deklaraciji ne znači da se po proizvodu ne može javno i osnovano pljuvati u interesu kupaca i/ili korisnika.

4. Ubuntu 20.04 desktop i Windows 10 su (recimo) potpuno saobrazni svojim deklaracijama, ali je Windows 10 daleko zastupljeniji. Canonical-u je slaba uteha što je ubuntu 20.04 desktop saobrazan deklaraciji.

5. Iskaz "1+2=7" može biti tačan uz odgovarajući izbor značenja upotrebljenih znakova. Postoje definicije koje se podrazumevaju ako se ne naglasi drugačije.

6. Odstupanje od podrazumevanih definicija proizvodi štetu u pogledu težeg učenja. Prema tome, odstupanje od podrazumevanih definicija se može opravdati samo ako se time dobija korist veća od pričinjene štete.

7. Bez obzira na saobraznost proizvoda deklaraciji, postoje pogrešne poslovne odluke.

Ne, optimizacije su radjene 70-tih - ceo svet se navikao 80-tih i Microsoft nece to da menja. Smeta ti? Promenis mod, promenis softver, promenis OS - sve moze, niko ti ne brani.

Znas vrhunac intelektualne neiskrenosti je sto bi ti vrlo lako ovde drvio kako ni iOS/Android/Linux kalkulator nije tacan. Secam se jako dobro tvoje teatrize na temu float-ova (IEEE754).

Kao matematicar po treningu, tebi nije nikakav problem da nadjes niz odstupanja zbog kojeg si IEEE standard hteo da posaljes u istoriju.

Nedeljko i sarlatanski procesori: https://www.elitesecurity.org/p2691533
Nedeljko i sarlatanska IEEE754: https://www.elitesecurity.org/p2691703

Ali problem je uvek isti - gledas pogresnu stvar, kojoj si pripisao da mora da zadovolji neke tvoje standarde za koje nije ni predvidjena.

Bas kao sto IEEE754 nije univerzalni format za skladistenje svih brojeva i ponasanja koja si navodio nisu greska vec su namerno tu zbog inzenjerskih odluka , tako ni "Standard" kalkulator koji izigrava AES kalkulator ne poznaje koncept izraza (osim najprimitivnijeg izraza koji opisuje njegovo funkcionisanje prilikom pritiska tastera).



Tacno. Da li je to iko dovodio u pitanje?



Tacno.



Tacno. Ali ti ne "pljujes" osnovano vec Windows kalkulatoru pripisujes osobine koje nema i neke svoje ideale pokusavas proturiti kao pravila koja bi trebalo svi da postuju.

To nema veze sa "osnovano". Sto se interesa tice, treba dodati "pretpostavljenog" pre.



Poenta deklaracije je jasna specifikacija sta proizvod radi. Sama po sebi nije prediktor poslovnog uspeha.

Zasto trpas te nepovezane stvari zajedno, bog samo zna.



Da, tacno. Ali ovde nikad nije ni doslo do toga - koristimo kompletno standardnu matematiku na nivou osnovne i srednje skole. Nema potrebe nista budziti.

Ironicno, upravo tebi treba masta kako bi AES kalkulator proglasio netacnim.



Nema nikakvog odstupanja od "podrazumevenih definicija". AES kalkulator ne radi ono sto tvrdis da radi, pa na njega te "podrazumevene definicije" ne apliciraju.



Bullsh*t.



Ne zavredjuje komentar. Poceo si od pogresne pretpostavke.



Tacno - samo sto niko nije ni tvrdio suprotno. E sad kakve ovo veze sa temom ima... ne znam.

Ja ne pripisujem Windows kalkulatoru osobine koje nema, nego navodim osobinu koju ima i koja je lako proverljiva, a formulacija te osobine je



Tu osobinu itakako ima.

Prioriteti operacija nisu "moji ideali", nego konvencija koja se uči u školama. Odstupanje od nje kao podrazumevane definicije čini proizvod težim za učenje.

Interes korisnika je da manje uče (odnosno da se koriste standardne konvencije) i da manje kucaju (vidi tabelu koju si citirao). Po oba osnova je RPN bolji od AES-a.

U školama se uči da je 2+5*3=17, tako da AES ne radi po tome.

A što se tiče šarlatanskih procesora, oni koji su smislili da 8%10 nije isto što i (-2)%10 ne znaju čemu račun ostataka služi. Nisu ga primenjivali, nego im je palo na pamet da to treba da se slaže sa promenom znaka, što nema nikakvu primenu.

Nisi dovoljno precizan, a siguran sam da bi zahtevao i mnogo vise od ovoga.

Kazes:



Ono sto je zaista tacno je: U "standard modu" daje 21 kao rezultat unosa: 2, +, 5, * i 3

Znajuci da AES kalkulator nema koncept proizvoljnog matematickog izraza, "2+5*3" jednostavno za taj kalkulator nema smisla.

Pre nego sto krenes sa odgovorom, moze i alternativa:

U "Standard modu" daje 21 kao rezultat unosa onoga sto ja ocekujem da treba da odgovara izrazu 2+5*3"



Ali ta konvencija ne aplicira na ovaj algoritam. AES algoritam ne sluzi za racunanje proizvoljnih matematickih izraza.

Niti AES kalkulatori, bar svakako ne MSFT-ov, ne tvrde da rade tako nesto.

Znas sta bi stvari ucinilo MNOGO laksim za ucenje? Objasnjavanje da treba mucnuti glavom i ne gubiti vazne detalje iz vida. Dete koje tako resava probleme ce odmah videti zato ovo nije ni problem uopste.

Maksimalno olaksanje, a boga mi i edukativna korist.



Da, kada to posmatras iz tog ugla.

Ali postoji i drugi ugao - ugao kupca tih digitrona. U vreme pocetaka su to bili privrednici. Interes privrednika je visedimenzionalni problem koji ukljucuje:

- Brzinu kucanja (brze kucanje = veca produktivnost na papiru)
- Cenu treninga na kalkulator (utice na ukupne troskove)
- Cenu kalkualtora (utice na ukupne troskove)
- % populacije koja moze da se iztrenira da koristi kalkulator (veci % = jaca pozicija poslodavca u pregovoru plate, utice na ukupne troskove)

Interes drugog tipa kupca "inzenjer" je sasvim drugaciji, interes kupca "arhitekta" je isto drugaciji (jos veci akcenat na manje gresaka) i sl.

Znaci kad si planirao PROIZVOD "kalkulator" - odmah si uocio da ces morati imati vise modela, te da ce neki modeli morati biti prilicno ogoljeni i zaglupljeni.

Ne mislim na tebe licno, naravno - ako si stvarno ovakav, bojim se da bi kalkulator kao proizvod zavrsio u nekom muzeju kao opskurni eksperiment napravljen u 10 primeraka. Nije bilo moguce ubudziti dovoljno memorije i snage da prodje sve Nedeljkove testove.



Naravno, zato sto AES ne racuna proizvoljne matematicke izraze. Isto nesto sto se uci u skolama: da proveris da li znas o cemu pricas.

Ja ne znam šta je to "proizvoljan matematički izraz". Taj pojam ima smisla samo u odnosu na izbor jezika. Ovde su to dekadni numerali i određene operacije, koje unutar određenog opsega veličine i tačnosti taj kalkulator podržava.

Kada pritisnem tastere 2,+,5,*,3 i = tim redom, naravno da očekujem vrednost izraza 2+5*3 u odnosu na podrazumevane konvencije i očigledna ograničenja (opsega i tačnosti), koja se ovde inače ne ispoljavaju. Šta drugo treba da očekujem? Ako treba da očekujem nešto drugo zbog primene nekih drugih konvencija ili čega god, to znači da treba više da učim kako se to koristi.

Od četiri kriterijuma koja si nabrojao, RPN je u prednosti nad AES po tri kriterijuma - brzini kucanja, lakoći učenja i % ljudi koji mogu biti obučeni, a AES samo u pogledu cene kalkulatora u određenim slučajevima u koje ne spada kalkulator na PC-ju, koji ide uz OS. Cena bi bila ista i da je Windows-ov Calculator potpuno RPN.

Dakle, po jednom kriterijumu je svejedno, a po preostala tri je RPN u prednosti.

70-tih je AES bio u značajnoj prednosti po tom jednom kriterijumu, a sada više nije ni po tom.

Kupca zabole za tvoje algoritme.

Apsolutno se slazem, naravno da kupca zabole za "moje algoritme" A posto u zivotu nisam ni jedan algoritam napisao niti implementirao a da ima veze sa dzepnim kalkulatorima... tako da bi cudilo i da ih uopste zabole, ali ajd - kako ti kazes :)

Medjutim, kad vec pricamo o kupcima, vidis - AES kalkulatori i njihova "emulacija" u Windowsu su prodati milijardama puta do sad. Pazi kad si ti prva osoba da sam cuo da se zali oko ovoga.

Nije mi poznato da su postojali sporovi na sudovima ili neke objave o steti... reklo bi se da je trziste savrseno razumelo mogucnosti kalkulatora sa AES algoritmom.



Jasno, samo sto Windows verovatno ima drugacije ciljeve. To bi trebao Microsoftu da se obratis - ali ne bi uopste bilo cudno da Microsoft nece da menja ponasanje digitrona kako ne bi imali nezadovoljne korisnike naviknute na AES.

Da parafraziram tebe: kupca koji hoce da mu kalkulator radi isto kao i prosli zabole za tebe i tvoje prioritete.

Ne znam da li je tako, ali to je sasvim moguc scenario - postoje sasvim legitimni razlozi zasto bi proizvod zadrzao takvo ponasanje.

Obratite paznju, prosirite kalkulator malo na desno da dobijete pogled i na "istoriju".

Unesite:

2
+
5
X
3
=


Kao sto vidite, Microsoft je >cak< napisao korektno istoriju operacija u skladu sa AES algoritmom.

Ovo je vrlo zanimljiv detalj - koji pokazuje da su ulozili dodatno vreme i razvojne resurse kako bi bilo 100% jasno sta se tacno racuna.

Uzevsi u obzir da imaju implementiranu i evaluaciju matematickih izraza (Scientific mod) to znaci da su nepotrebno pukli pare na ne-resenje? :)

Ne, nego je upravo ideja da "Standard" ostane kompatibilan sa dzepnim kalkulatorima. Sto ima opravdanja i smisla.

Dakle, imamo AES kao relikt prošlosti, koji je imao prednost nad RPN samo u ceni tokom nekoliko godina, a u svemu ostalom je lošiji od RPN-a.

Decenijama kasnije treba "održavati kompatibilnost" sa time zadržavajući nešto što je lošije umesto da se pređe na bolje. To je ono što Ivan Dimković zastupa da je ispravno.

Kako je MS izbacio podršku za 16-bitne procese, pa na Windows-u ne možeš da igraš Doom, osim kroz virtuelizaciju i FreeDOS?

Koliko je dece dobilo kečeve na kontrolnom iz matematike zato što su tako "naučili" sa Windows kalkulatora, pa onda to primenjivali na kontrolnom?

Uložili su dodatan trud da naprave nešto lošije nego bez tog truda. Uložen trud nije garancija da je rezultat bolji.

Čuj, žalbe i sporovi. Pravni osnov za tužbu ne postoji jer je proizvod saobrazan deklaraciji, ali saobraznost deklaraciji ne znači da je proizvod dobar. To smo kao apsolvirali, pa se opet ponavlja.

I još nešto. Kako izgleda ekran nakon pritiska na znak jednakosti, već sam pokazao. Dakle, piše da je 2+5*3=21.

Po Ivanovoj filozofiji nije trebalo prelaziti sa rimskih akvaduka na savremeni vodovod da bi korisnici primenjivali stare navike.

https://answers.microsoft.com/...24-5f16-46c5-87fe-9da0a297a4d4


Verovatno su posle slicnih pisanja ispravljali ono sto Nedelko vidi u ono sto Ivan vidi.

To nije "Ivanova filozofija", nego samo jos jedan neiskren pokusaj trolovanja - zasto, ne znam.

Na prvi pogled Nedeljkova interpretacija "Ivanove filozofije" izgleda strahovitio povrsno, ali biti ovako selektivno povrsan ne moze biti slucajnost. Nedeljko, matematicar po treningu sa okom za detalj i koji nalazi probleme u inzenjerskim opisima realnih brojeva zaboravlja citave dimenzije problema kada njemu odgovara. Hmm...

Opet je zaboravio da primeti da Microsoft Calculator ima i druge modove racunanja, te da je AES aktivan samo u najprostijem kalkulatoru koji 1-1 kopira dzepni kalkulator sa ulice: po izgledu i po ponasanju. Zanemarimo da ljudi ne ocekuju parsiranje izraza tamo gde se i ne ispisuju tako - ali kome god to treba, na 2 klika je od odgovarajuceg moda.

Dakle, analogija sa akvaduktima je besmislena i tragicno povrsna.

@Nedeljko,



Koja je to verzija kalkulatora? Da li mozes da pokazes?

Da li je kalkulator dosao sa Windows-om ili si ga ti napravio iz izvornog koda? Da li si nesto menjao?

Da ne bi bilo zabune, evo malog video klipa koji pokazuje "stock" Windows 10 i originalni Windows kalkulator (digitalno potpisan MSFT-ovim kljucem):



Video govori vise od 1000 slika...

Ja sam analogiju sa akvaducima obrazložio.

AES je imao prednost samo u cenu tokom određenog brokja godina, a sve ostalo su mane. Da nije bilo ni problema sa cenom, nikada se ne bi ni pojavio.

Sada, kada je tako, neki po navici očekuju takvo ponašanje, pa je jedina prednost AES-a njihovo nemenjanje navika. U vreme kada su ukidani akvaduci, jedina prednost akvaduka je bilo nemenjanje navika korisnika. Prešlo se na bolja rešenja žrtvovanjem te jedine prednosti akvaduka. Preterivanje u zahtevu nemenjanja navika je kočnica napretka.

Ja sam svojevremeno slikao kalkulator sa Windows-a 10 kakav je tada bio. Datum poruke je 31.7.2020. Možda su oni u međuvremenu nešto menjali kroz ažuriranja, ne bih znao.

Evo linka:

https://www.elitesecurity.org/p3959626

Mogu da probam opet. Naravno, na moja pitanja se ne odgovara.

Kakva crna kocnica napretka? Za gotovo bilo sta ozbiljno (cuj ozbiljno - ozbiljno na nivou osnovne i srednje skole) ces preci na Sci kalkulator i ovako i onako - tako da je nekakva potencijalna steta od propustanja ispravne evaluacije nikakva. Sci kalkulator je deo istog kalkulatora, dakle 0 dodatnih troskova, samo treba da ga odaberes.

Daleko veci problem MS kalkulatora je sto sto je jako dugo vremena bio igracka. Otprilike kao nekadasnji MS Paint. Odaje utisak da je MSFT bukvalno stavio neki minimum samo da moze da se kaze da OS ima "kalkulator", "paint", "notepad" i sl. - iako je kvalitet tih aplikacija bi minimalan i danas bi to sto rade vise odgovaralo tehnickom demou a ne komplet aplikaciji. Windows filozfija 80-tih, 90-tih i ranih 2000-tih je bila "kupi ili skini 3rd party sw.".

Sad je to postalo malo bolje - Microsoft je bar malo uvideo da moraju umiti te aplikacije koje idu sa Win-om, ali je i dalje to slabo.

Na primer, Apple, u Mac OS kalkulatoru ima RPN mod (https://support.apple.com/en-gb/guide/calculator/welcome/mac)

Ali AES mod u standardnom kalkulatoru nije jedna od tih mana. Naprotiv, jedna od retko pametnih odluka firma koja inace ima tendenciju da menja stvari menjanja radi.

Steta koja bi se napravila iznenadnim menjanjem ponasanja standardnog kalkulatora je daleko veca od nekakve imaginarne prednosti koja je i ovako i onako na 2 klika cak i na samom Windows-u, za svakoga kome treba kalkulator kao uredjaj za resavanje matematickih izraza (plus, bukvalno, svako kome treba resavanje izraza ce iz odmah traziti i dodatne opcije poput zagrada, vise memorija i sl. - sto moze dobiti samo sa Sci).

Zapravo mene cudi kako novi Microsoft nije jednostavno pogazio sve bas kako Nedeljko zeli, to im je modus operandi u proteklih par decenija.

Kad su mogli da krnu Ribbon koji je ukrao vertikalni prostor taman kad su u modu usli 16:9 monitori, "Modern UI" koji je ukinuo efekte zbog baterije a onda to nasilno sa sacmarom nametnuo desktop-ima, "Connected Standby" (koji pali laptope, ljudi se zale levo i desno i Microsoft odgovara kako? Eliminacijom reg. kljuca za "workaround" gasenjem CS) i sl. sto ne bi mogli da krnu i promenu ponasanja necega za sta i moja baba zna kako radi.

Ne bi im bilo ni prvi ni poslednji put.



Na koja tvoja pitanja se ne odgovara?

Daj verziju digitrona i odgovori da li je to stock kalkulator koji dolazi sa Windows-om. Ako da, daj nam verziju Windows-a.


_{[Ovu poruku je menjao Ivan Dimkovic dana 02.05.2021. u 20:10 GMT+1]}

Nisam ništa menjao, nego sam samo upalio kalkulator kakav je u tom trenutku bio deo Windows-a 10 po instalaciji OS-a.

Nije mi odgovoreno na recimo sledeća pitanja


Takođe i na ovo:

Znači, ukidanje podrške za 16-bitne procese nije problem, a ukidanje podrške za AES je problem.

Pitanje na koje nije odgovoreno je takođe

Klinci se susrecu sa zagradama, vec na polovini prvog razreda, znaci malo pre ili posle polugodista.

Sto mene tice, ne secam se da mi trebao, a retko i bio dozvoljen kalkulator za matis-matis za celo trajanje skolovanja, od prvog osnovne do kraja faksa.

Klinac kući vidi kako radi kalkulator na računaru i misli da je to ispravno. Onda radeći u školu kontrolni bez kalkulatora, primenjuje ista pravila peške i dobije keca.

Nedeljko,

Da li mozes da uradis 2 stvari:

1. START -> unesi "winver" (ENTER) - dobices dijalog sa verzijmo Windows-a (moja: Version 21H1 (OS Build: 19043.962)). Da li mozes da podelis koju verziju Windowsa si koristio za test?
Alternativa: winver se moze uneti i u komandnoj liniji (Windows Terminal)

2. Startuj kalkulator, klikni na "hamburger meni" (tri horizontalne crte, u gornjem desnom uglu prozora) i idi na "About" --> koja je verzija kalkulatora?



Prioritet nije nikakav problem ako se zna da nece biti postovan, onda se adaptira unos prema tome.

Poslovi gde se unose sekvence brojeva sa jednostavnim + i - operacijama izmedju (dakle, prioritet nikad nije problem), mahom u prodaji ili nabavci (komercijalnim delovima firme).

Ovi poslovi su pre toga koristili "adding machines" koje su mahom vremena bile mehanicke, i jako kratko elektronske. Dzepni kalkulator je minimalna nadogradnja tih masina, gde je dodato jos nekoliko operacija.



Da, i to mnogo veci. Ukidanje 16-bitne podrske je 100% jasno i ne dovodi nikoga u zabludu - program >nece< raditi. Sa druge strane, "popravljeni" kalkulator bi izgledao isto, samo bi davao razlicite rezultate.



Ako je to tacno, to je onda odlicna stvar - dokaz da sistem i funkcionise. Ako je neko nesto pogresno naucio ili ne kapira sta radi (a gresi): adekvatna ocena za to je ona koja ukazuje na nedovoljnost.

Nije ta osoba pala sa Marsa na kontrolni, znacii bili su casovi sa predavanjima, primeri, domaci zadaci, zbirke - ocekuje se da si do tog kontrolnog materiju i savladao. Ako za sve to vreme nisi ukapirao da postoje razlike izmedju tvojih rezultata i, recimo, zbirke zadataka... sta da covek kaze?

U tom slucaju je odlicno da mu/joj se sto pre objasni da ima problem koji trazi korekciju.

Lepo piše:

Izvor: https://github.com/microsoft/calculator

Objašnjenje za "single-step", odnosno "immediate-execution calculator": https://en.wikipedia.org/wiki/Calculator_input_methods


Da li ima smisla koristiti ovu vrstu kalkulatora za "Standard" mod je neko drugo pitanje, na nekom od MS foruma ima kratka rasprava na tu temu, ali nema adekvatnog odgovora tehničke podrške, osim da se koristi "Scientific" mod ako se želi unošenje izraza za koje se evaluacija ne vrši automatski (npr. https://answers.microsoft.com/...24-5f16-46c5-87fe-9da0a297a4d4).

Ivane,

Već sam napisao da je snimak od 31.7.2020. Ja ne mogu da se vratim u prošlost i uzmem brojeve verzija od tad. Sada kalkulator prikazuje isto što i tebi, a verzije su

20H2 (OS Build 19042.928)
10.2101.10.0

S tim da je sada snimak drugačiji. Pokazuje 7*3=21.

Od onda je OS ažuriran, tako da to ne znači da je onda bilo isto ovako.

Drugo, nisi naveo slučajeve gde je AES danas bolji od RPN. Naveo si slučaj gde množenja i delenja nema, tako da se AES i RPN u tom slučaju poklapaju, pa nijedan nije u prednosti i naveo si prednost AES-a koja je postojala nekada (cena), ali ne i danas.

mjanic nastavlja da insistira na saobraznosti proizvoda sa deklaracijom, za šta smo već rekli da ne znači niti da je proizvod kvalitetan, niti da treba tako da se pravi.

Ja mislim da je tu Microsoft napravio kiks. Ne bi trebalo da dva kalkulatora istog dizajna, istog "proizvođača", na području aritmetike daju dva različita rešenja. Dodavanjem trigonometrije, logaritama i slično, nije razlog da kalkulator "razmišlja" drugačije kod aritmetičkih operacija.

@Nedeljko, OK moguce, ko zna sta oni rade sad kada je u modi "Agile" - moguce je da si ti i ostatak sveta bili zrtve probanja kojecega od strane MSFT-a.

Ima tema bas o ovome, gde ucestvuju i dev-ovi: https://github.com/microsoft/calculator/issues/138

I koliko vidim, bas su u nekom momentu ukljucili print izraza koji ocigledno ne bi trebao da postoji - slika iz 2019 nema problem na glavnom delu prozora (jedini koji vidis osim ako ne "prosiris" prozor).

Znaci, bag koji si ti video Nedeljko se desio posle ovoga.

ALI - ako prosirite prozor da vidite memoriju - eto baga i tada. U toku 2020 je verovatno neko "poboljsao" i glavni deo prozora i ubacio da ispisuje "izraz" iznad rezultata (izraz koji je besmislen). Ocigledno je to bio MSFT bug koji je poceo pre glavnog bug-a - a onda se privremno prosirio dok neko to nije ispravio sve: i memoriju i glavni ispis.

Koliko vidim, u problematiku se razumeju, samo ne mogu da se dogovore sta je najbolji nacin sto se prikazivanja tice :-))))



AES ne moze biti bolji od RPN-a ako samo gledas algoritam. Ali kalkulator je mnogo vise od algoritma za racunanje izraza. Postavlja se pitanje koliko lako se ljudi navikavaju na RPN, pogotovu ta grupa koja koristi te najjednostavnije kalkulatore.

Ako pogledas genezu toga, AES kalkulator je "duhovni" naslednik masine za dodavanje, koja je duuugo vremena posle dolaska kalkualtora bila omiljen alat racunovodja. Glupa ko cigla, ali si 100% siguran da ne gresi.

I onda, cepaj - poredi, cepaj - poredi, cepaj - poredi, cepaj - poredi :-)

Danas imamo Excel mada ne bih se izneandio da u nekom podrumu negde beancounter sve to rucno proverava sa masinicom, liniju po liniju - kakav stek, kakva memorija, kakvi bakraci.



TI je imao serije kalkulatora koje su imale osnovne varijante sa AES racunanjem.

Sve dok kalkulator prikazuje sta radi, ili 100% izgleda kao neki objekat cije je ponasanje poznato - ne vidim u cemu je problem.

Evo sad cak i ispisuje tacno koje operacije racuna, pa nema nikakve sanse da neko pomisli da je izracunat izraz X, kada je izracunat izraz Y.

Ako je Windows u pitanju, a ako je Linux u pitanju, onda itekako vidiš problem u tome što ne radi onako kako je tebi palo na pamet.

Linux? Danas meni Linux radi bolje nego Windows (10).

Nekada davno? Nekada davno nije radio - ono, uopste. Secam se avantura, ubacis narezani DVD, original ISO - i zavrsis u zoni sumraka.

To nije "ne radi kako je meni palo na pamet" nego - "ne radi, uopste".

Kako da ne.

Sećam se kada si hteo da ga narežeš sa dd na usb, pa si ga narezao na sda (hard disk), umseto na sdb (usb flash) i nije te bilo broga da to proveriš kada te dd već pita za admin lozinku.

Drugima je radio, tebi nije.

Rekoh, ovo je isto kao da su cifre ispreturane, ali da to tako piše u dokumentaciji.

:) Kad se setim...

https://www.elitesecurity.org/...prikosnoveni-OS-nezavisni-test



Znaci boot u Borat-a direktno. Bez intervencije.

Mada, sad posle 13 godina kad to pogledam - nije nista 'falilo tom Linuxu. To sto nije radio na svakom hw-u, ili sto mu je usability bio los - ocigledno su to bile "potrosacke" stvari koje glavne klijente/korisnike Linuxa nisu doticale.

Jedina smejurija su bili fanboyi - kojima je Linux bio kao isusova krv. Neprikosloveni OS :-) Ali... svi fanboyi su isti, nebitno da li je Linux vs. Win, PC vs. Mac, NVIDIA vs. AMD, Audi vs. BMW... fanboyizam je stanje uma, i to vrlo lose - i nije ni smesno.



To svakako nije mogao biti ovaj gore put (sprz na optiku), ali da - moguce.

Samo se covek pita koji moj moras bilo sta da "rezes" "dd-om" a da nisu rane ili srednje 90-te...

Pa, i nisi morao ništa da režeš dd-om. Oduvek sam koristio neki drugi alat.

Ti si bio majstor da ti nešto ne radi, jer nije radilo kako je tebi palo na pamet.

U vezi sa Windows-ovim kalkulatorom problem očigledno postoji.

Nepotrebna degradacija kvaliteta da bi bilo isto kao nešto iz kamenog doba - akvaduk.

Ivan:"Samo se covek pita koji moj moras bilo sta da "rezes" "dd-om" a da nisu rane ili srednje 90-te..."

pa i ne moras, ima brasero i k3b odavno. Ne znam sto si koristio dd? Verovatno iz nekog specificnog razloga...
Mislim ono dd je dobar da wipejues disk pre prodaje da ne mogu da urade recover podataka ;)

[quote]Nedeljko:
Ti si bio majstor da ti nešto ne radi, jer nije radilo kako je tebi palo na pamet.
[quote]

Nije radilo. Tacka. Da sam hteo PC da koristim kao reklamu za Borat - The Movie, onda bi mozda i bilo prihvatljivo.

Kapiras, nisam imao OS u niskoj rezoluciji, spori OS, OS koji hrahira.

Ne, OS nije hteo ni da se instalira.



Windows kalkulator radi bas onako kako treba:

a) Prepoznatljivi sw. "dzepni kalkulator" izigleda i radi bas kao dzepni kalkulator --> da se baba i deda ne iznenade
b) 2 klika ti daju "sci" mod koji se ponasa kako ocekujes da se ponasa sci kalkulator --> odlicno za srednjeskolce i neke studente
c) Za klinca koji 'akuje nesto ima programerski mod - meni omiljen cesto za binarne maske i hex. proracune
d) Eno ga i na githubu

Degradacija kvaliteta? Za nesto sto je dzabe je vise nego pristojan.

[quoe]
Pa, i nisi morao ništa da režeš dd-om. Oduvek sam koristio neki drugi alat.
[/uote

E, Nedeljko ajde ne se*i vise. Ovaj snimak koji gledas - skinuo sam KLOT ISO slika ne znam ni sam koliko verzija, nista im radio nisam - samo ubacio disk u drajv, resetovao i dobijao s*anja.

Na kraju neki ljudi nasli na Ubuntu forumima ljude sa identicnim problemima - toliko o tome da je to bio samo moj problem.

Ja sam tada to zvao "Linux je kupus" - sa stanovista korisnika Linux jeste izgledao kao kupus tada, ali fora je u tome da niko nije valjao taj Linux kao proizvod koji bi trebao da radi kao Windows. Cak je i Canonical bio oprezan oko hvalisanja.

Te budalastine su dolazile od Linux fanboya koji pre svega pojma ni o sopstvenom OS-u nemaju, a kamo li drugo.

13 godina kasnije, verujem da je razlog one smejurije bilo sto niko nije testirao tu kombinaciju (WS ploca, 8800 GTX NVIDIA i neki SCSI diskovi).

To ne opravdava Linux skroz - ona Borat slova i jako losi UI sabloni nisu pozitivna stvar... ali niko ti ga nije prodao i rekao da to radi.

U ovome je suština:

Jeste c*anje al' je džabe. Jeste džabe, al' je c*anje.

Proizvod/uslugu koja je je to što Windows Calculator jeste, neću koristiti, pa bio džabe ili ne. Jednostavno, nešto što je loše ne treba koristiti.

Pritom, Windows Calculator nije džabe. Možeš li da ga dobiješ legalno i besplatno? Ne. Treba kupiti Windows koji se plaća, a čiji je ovaj kalkulator sastavni deo.

To se zove akvaduk - čuvanje neke zaostavštine u nedogled, uprkos tome što je u datom trenutku je nazadna i zaostala.

Ne sustina da si toliko tvrdoglav da ne mozes da prihvatis da, jednostavno, nisi u pravu.

Windows kalkulator moze da se ponasa kao dzepni kalkulator (sve sa odgovarajucim algoritmom - AES) ali i kao naucni (ili programerski).

To nije znak nizeg kvaliteta vec vece paznje na detalj.

Koristi ti sta hoces, ali ne izmisljaj neistine.

AES je akvaduk. Nema nijednu prednost nad RPM-om. Nisi uspeo da navedeš nijednu. Nekada je imao prednost u pogledu cene, a sada u kompatibilnosti sa rekliktom prošlosti.

Da, 31.7.2020. je pisalo šta je pisalo i to je bio "kod koji daje neočekivan rezultat". Sada imamo malo blažu varijantu, ali i dalje je akvaduk.

OK, Nedeljko :-)

Evo jednog zaista neočekivanog rezultata.



Ja razumem da kalkulatori računaju sa određenom tačnošću, ali koji je car ovde ubacio ?

Dakle, čovek je uneo



i dobio

.

Nije mi Windows pri ruci, ali bi trebalo da ovo u slučaju kompajliranja 32-bitnim MinGW kompajlerom puca prilikom završetka rada, odnosno da sistemu neće vratiti 0 kao status.

Na ostalim kompajlerima radi kako treba.