Új hozzászólás Aktív témák

• #19 polika senior tag flugi #18

  Új Válasz 2013-08-26 14:57:00 #19

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  polika

  senior tag

  válasz flugi #18 üzenetére

  A probléma amiről írsz akkor valós, ha a kerekítési pontosság közelében szeretnéd a végeredményed pontosságát megkapni. Ahogy írod, ez 1-2 műveletnél közel hozható, viszont kurvasok művelet kis hibája ténylegesen torzíthatja az eredményt, főleg ha a float számaidnál az ábrázolási pontosság határait feszegetik a különböző részösszegek (igen nagy ill igen kicsi számok kevert halmaza).

  A vicc ráadásul az egészben hogy a pontos kerekítés hiánya, vagy megléte nem érinti számotevően a kerekítési hibákat, bár kétségtelen hogy a tuncate vs kerekítésnél statisztikailag a truncate egy 2-esnyi deficitben van, de ez jóval 1 tizedesnyi alatt van. Tehát igazából a két módszer összevetésénél csak az a valós hogy nem egyformán produkálja a hibákat. DE hibás a cikknek azon ki nem mondott, konklúziója hogy ha minden hardver a matek szerint kerekítene, akkor az eredmények pontosan ugyanazt adnák, összevethetők lennének.

  Én eleve a hardveres kerekítést nem teljesen értem hogy miért van rá szükség ha ennyivel bonyolítja az áramköri elemeket ill tranzisztor számot?

  Mert ugyebár az ábrázolásból adódó részösszeg hibákon nem segíthetsz, a kerekítés az bármikor használva csak rontja a kapott értéked pontosságát, részösszegeket kerekíteni pl tök érelmetlen dolog, csak ott van értelme a kerekítésnek ahol emberek számára értelmezhető számmá szeretnénk alakítani az EREDMÉNYT, azaz kerekíteni csak a végeredménynél van értelme. Mind program futás, mind programozási értelemben a részösszegek kerekítése hülyeség (pontatlanabb, lassabb). Mert ha mondjuk van 23 bitnyi értékes információm akkor ha truncatelek, ha kerekítek csak 23 bitnél kisebb hasznos információ lesz ennek az eredménye, azaz értelmetlen. Ahhoz meg hogy legyen egy emberek számára készült végeredmény jellegű outputnál egy kerekített érték azt szoftveresen is simán lehetne kezelni, ugyanis grafikai problémában eleve nincs ilyen érték, GPGPU tipusú problémában ahol KURVASOK számítás van, ott meg pont jellemzően a végeredmény jellegű kerekített értékből van iszonyú kevés.

  Én teljesen megértenék egy olyan szavbányosítási verziót ahol a 32 bites pontosságnál a standard a truncate lenne (mobil/grafikára optimalizált alacsony tranzisztor szám, alacsony fogyasztás optimalizált standard), és a dupla pontosságú 64 bitet is tudó hardvernél lehetne csak követelmény a helyes kerekítés (GPGPU matematika, modellezésre használt hardver, ahol elsődleges kicsikarni minden lehetséges pontosságot).

Új hozzászólás Aktív témák