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

• #23 polika senior tag Sir Ny #22

  Új Válasz 2013-08-26 17:02:31 #23

  Ú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 Sir Ny #22 üzenetére

  Bocs, most olvasom milyen pongyolán fogalmaz Abu, X postal korábban. Egyértelműen keveri a szezont a fazonnal (matematikai művelet, eredmény). Most már értem hogy te mire is válaszoltál, mea culpa, nem néztem contextusában a dolgot, de jogos hogy felhívtad rá a figyelmem. Nem veled van problémám hanem a korábban elhangzott pongyola megfogalmazással, amire te is reflektáltál.

• #21 polika senior tag Sir Ny #20

  Új Válasz 2013-08-26 16:09:43 #21

  Ú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 Sir Ny #20 üzenetére

  Szerintem ne keverjük a matekot meg a fizikát, mert a Heisenberg féle valószínűségi tétel/ ill tágabb értelemben a kvantumechanika az csak a fizikai obszerváció matematikai modellje.

  Az hogy nem elképzelhető egy olyan világ ahol egy okozatnak több eredménye is lehet azt pont a te kvantumechanikai példád cáfolja. Jelenleg a fizikusok nem tudják eldönteni hogy egy determinisztikus világban élünk, ahol minden oknak megvan a determinisztikus okozata, vagy egy nem determinisztikus világban ahol az okozat független az októl. Ez egy filozófia kérdés marad, per pillanat nincs egyikre sem bizonyíték

  Továbbá miért ne lehetne egy matematikai műveletnek több eredménye? Ha az axioma rendszered úgy van megírva akkor lehet. Az hogy az adott axióma rendszered igaz, vagy nem az teljesen más tészta, de szintén az adott axióma rendszerben eldönthetetlen dolog (lásd Gödel tételei).

  Egyébként ez az irány teljesen offtpoic, mert a probléma lényege nem a matekról szól, hanem arról, hogy nincsen egységes standard adott feladatra. Per pillanat lehet többféle közel azonos eredményt adó, módszert használni egy adott feladatra. A vita csak arról szól, hogy a technikailag drágább, de matematikailag icipicit pontosabb, vagy a pontatlanabb de technikailag olcsóbb megoldást használják. Ettől függetlenül, mindkét módszer eleve csak egy adott bit értékig pontos/pontatlan, mert a számábrázolás eleve kódolja a TRUNCATE alapú kerekítést 32 vagy 64 bitmélységnél. Ergo a vita cost/benefit jellegű, és elsősorban nem matematikai problémáról van szó szerintem

• #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