Kod koji daje neočekivani rezultat

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

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

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?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

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.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Š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?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

"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.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Š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.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

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 ;)

Potpis

CHUPCKO

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?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

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.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

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.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

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 ....