- Magisk
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Milyen okostelefont vegyek?
- Teljes külső kijelzővel hódítana a Flip7, ami kapott egy kistestvért is
- Yettel topik
- Samsung Galaxy S21 FE 5G - utóirat
- Na! Ez egy JÓ utólagos autós fejegység - Minix CP89-HD
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Mobil flották
- Xiaomi 13 Pro - szerencsés szám
Új hozzászólás Aktív témák
-
dezz
nagyúr
Már látom, hogy már az elején félreértettelek. Azt hittem, hogy a GPU-nál nem foglalkoznak a sorrendiséggel és már eleve ez komoly gondot jelent.
Viszont akkor semmi újat nem mondtál Abunak a #18-asban, hiszen ő is arról beszélt, hogy elméletben hogyan kellene lennie és ehhez képest a gyakorlatban nem úgy van.
"Ez a hozzáállás alapvetően sérül a gyakorlatban, és ez nem a kerekítési probléma miatt van, hanem mert véges az ábrázolható kettedesjegyek száma."
Ha már újra a #18-asnál jártam, erre is reagálnék: persze, hogy nem a kerekítés miatt van. Viszont éppen emiatt van szükség a kerekítésre, aminek a megvalósítása befolyásolja a kapott eredményt, ezért szükséges követni a szabványokat.
-
flugi
tag
A GPU kódot ha kézzel lapogatjuk ki (memóriaterhelés ritkítás aritmetika közé), akkor gyorsul. Ez alátámasztja azt a heurisztikus állásfoglalást is, hogy a GPU stream processzor nem rendez át, mert az sokat bonyolít a magon, és sok a mag. Ezt a feladatot a driver végzi el, amikor előállítja az adott architektúra számára kedves átrendezést fordítási időben. (a fenti kísérletet nVidia GPU-n, assemblerrel csináltuk)
Az OpenCL és a driver adatfüggőséget kezel, ahol is nem átrendezhető két művelet, ha az egyik írja a másik bemenetét.
-
flugi
tag
Oké, most érthetően kifejezted magad, elnézést kell kérnem a gyanúsításért. De ha már kekeckedünk, legyünk precízek.
Egy pl. C/C++ nyelven kifejezett x=a+b+c értékadásnak pontosan egy megoldása van, mivel az összeadás műveletek azonos prioritásuk miatt jobbról balra értékelődnek ki, amit nem rendezhet át se fordító, se processzor az adatfüggőségek miatt.
Ha arra hivatkozunk, hogy az összeadás kommutatív, tehát tetszőleges sorrendben jó az összeadás, akkor az a matematika a maga valós, racionális számaival, ahol az x=a+b+c pontosan egyetlen megoldása van, de ugye az most nem játszik, most a lebegőpontos számok játszanak.
Ha tehát úgy fogalmazol, hogy az a+b+c összeg operandusainak tetszőleges átrendezése más-más eredményt adhat lebegőpontos számoknál, akkor pontos vagy. Ez ugye akár 3*2*1=6 lehetséges sorrend, viszont ha feltételezzük, hogy az összeadás kommutatív (IEEE kompatibilis implementációnál például az), akkor 3 féle lehetséges eredménye van.
Összefoglalva: csak abban tévedsz, hogy az utasítások általánosságban átrendezhetőek. Ez nem így van, például x86-on C/C++-ban nem. Vegyük észre, hogy ha sérül az asszociativitás a műveletre nézve, akkor a gépi kódú lépésekre bontás szintjén a kommutativitásra hivatkozva sem rendezhetünk át utasításokat, mert potenciálisan sértjük az asszociativitást. Az ADD utasítás két operandusát szabad csak felcserélni, és azt is elvileg csak olyan architektúrán, ahol az implementáció kommutatív.
Kész vagyok viszont elismerni az igazad, ha tudsz mutatni olyan nyelvet, fordítót, és architektúrát, amit használnak is valamire, és ahol az x:=a+b+c kifejezése nem determinisztikus, mert én nem ismerek ilyet.
-
dezz
nagyúr
Ja, értem, szóval a CPU-k odafigyelnek erre. A GPU-k ugye in-orderesek, nem? Szóval, akkor az OpenCL nem figyel erre oda, vagy mi?
Magam is belefutottam érdekes problémákba ezzel kapcsolatban, amikor annó (90's) átírtam pár kódomat (off-line renderelt grafikai effektek reklámfilmekhez) 68k CPU ASM-ről FPU-sra. Olyannyira számítottak a kerekítés eltérései, hogy egyes grafikus effekteknél meglepő módon jól láthatóan bezavart a végeredménybe és át kellett írni a kódot miatta.
-
flugi
tag
Természetesen az a+b+c=x egyenletnek (amennyiben x ismert, és a,b,c értékekre kell megoldani) végtelen sok megoldása van. Három megoldása egyetlen értelmezésben sem lehet, a kötött operandusok számától függően vagy pontosan egy megoldás van, vagy végtelen sok.
A másodfokú egyenlet megoldásakor sem azt mondja a programozó, hogy kérek egy megoldást. Konstruktív megoldást kell adjon a programozó a másodfokú egyenlet megoldására. Konkrétan a x1 := (-b + sqrt(b*b - 4*a*c))/(2*a) értékadással konkrétan az egyik, x1 := (-b - sqrt(b*b - 4*a*c))/(2*a) értékadással konkrétan a másik értéket számolják ki (pozitív diszkrimináns esetén).
Matlabban van [x1 x2] = roots([a b c]) függvény, ami lényegében pont ez, csak komplex számokkal dolgozik, és konkrétan mindkét megoldást visszaadja. Nem csak random az egyiket.
Ha messzemenően jóindulatúan kezelem az általad elmondottakat (amire nem sok okom van, mert több jel utal arra, hogy nem vagy képben, mintsem hogy túl bonyolult fogalmakra utalsz azok megnevezése nélkül), akkor azt mondhatom, hogy az iteratív közelítő eljárások, genetikus algoritmus implementációk hasonlítanak arra, amit körvonalazol, de ezeknek a módszereknek semmi értelme zárt alakban kifejezhető értékek keresésekor, és a példa még mindig a másodfokú egyenlet volt. Ráadásul ezeknek a módszereknek a lassúságuk az egyik fő ismérvük.
-
Sir Ny
senior tag
,,a példa értelmezése szerint az egyenletrendszernek egyetlen, két értékű megoldása van, az 1 és a -1 páros. Egyetlen pár, amiben két valós szám van. Egyetlen más pár sem megoldása az egyenletrendszernek. Nincs alternatíva."
az a+b+c=x egyenletnek pedig három jó megoldása van, amelyből a programozó csak egyet kér, de azt rábízza a processzorra, hogy melyiket. (mert így gyorsabb)
Az a baj, hogy túl buta vagy, vagy úgy csinálsz (trollkodsz) hogy lopkodd az én időmet. (azaz csak lopkodod az én időmet mindenféle értelem nélkül, nem tudom túl buta vagy-e, vagy ez szándékos). Én abbahagytam.
-
flugi
tag
a példa értelmezése szerint az egyenletrendszernek egyetlen, két értékű megoldása van, az 1 és a -1 páros. Egyetlen pár, amiben két valós szám van. Egyetlen más pár sem megoldása az egyenletrendszernek. Nincs alternatíva.
Ez a matematika. Valós számok, racionális számok, egész számok. Nem float típus típusértékhalmaza, hacsak külön nem jelöljük, mivel ezek a halmazok nem alkotnak csoportot vagy gyűrűt. Nem jelölte a példa. A számelméleti axiomák nem teljesülnek a számítástechnikai típusokra, speciális fogalmakat kell hozzá használni.
Más: a 0.999 leírva nem egyezik meg a 0.999... kezdetű végtelen törttel, és én természetesen nem gondolhattam a végtelen törtre, ez a kontextusból nyilvánvaló volt. A 0.999 = 999/1000 racionális érték. A float és double értékek mindegyike egy racionális szám, és mint ilyen, az 1-es érték, és a 0.999 kezdetű float érték különböző.
Egyszálú igényes CPU programok esetében lehet gondoskodni a helyes eredmény erőltetéséről, ami az esetek jó részében elegendő a jó megoldáshoz. Vannak olyan több hónapos futási eredmények klasztereken, ahol az eredmény sokadik tizedesjegyének pontossága kedvéért fut a program a futásidő felében, mert azon a szakterületen ez a tizedesjegy éppen nagyon fontos. Ilyen esetekben a klasszikus "kisebb számokat adom össze először" hozzáállással már sokszor meg lehet oldani a determinisztikus helyes eredményt adó programot, máskor egyéb trükkökre is szükség lehet.
Schrödinger macskája pedig arról szól, hogy abban a kvantummechanikai modellben, ahol úgy fogalmazunk, hogy "összeomlik a hullámfüggvény" a megfigyelőtől, annak milyen vicces következménye egy olyan gondolatkísérlet, ahol direkt nem omlasztjuk össze egy darabig. A véletlengenerálás ebben a dologban egy (persze kihagyhatatlan, de) részletkérdés. Nem arról szól a Schrödinger macska, hogy nem lehet tudni, hogy él-e vagy nem, hanem hogy mikor mit lehet tudni, nyitás előtt és után. Pláne nem arról szól, hogy akár él, akár nem, mindkettő jó megoldás
-
Sir Ny
senior tag
,,A példád irreleváns. Az egyenletrendszernek van két megoldása valós számokon, ez két konkrét megoldás. "
tetszőleges program tetszőlegesen kerekítve véges (illetve ami ennél fontosabb: előre meghatározható) számnyi különböző eredményt adhat, csak a szerencse dönti el, hogy melyiket.
Az analógia nem irreleváns, de teljesen tökéletes.
- Programozó - tanár
- Több lehetséges jó eredménnyel járó feladatot kérnek
- Elfogadnak egy jó megoldást
- Mind a matematikában, mind a számítástechnikában nincs megszabva hogy hogyan kell eljutni addig=> mind a matematikában mind a számítástechnikában a végrehajtó egységtől függ, hogy melyik eredményt adja
- Mind Pistike, mind a GPU belső ütemezése rejtély, azaz tekinthetőek fekete doboznak, amely a tanár/programozó számára teljesen véletlenszerűen ad vissza egy eredményt a lehetséges jó eredmények közül=> az égvilágon semmi különbség nincs a matematikával.ű
,,Schrödinger macskája annak köszönheti a népszerűségét, hogy furcsa, és sokan, köztük te is asszociatívan használják, vagyis "erről eszembe jutott" módon."
Nocsak, de nagy mellénnyel van valaki. Ha nem tudsz szöveget értelmezni, minek ugatsz? Írtam, hogy az egész világ (klasszikus fizikai része) így működik, nem csak a matematika, hogy a lehetséges eredményekből kapsz egyet véletlenszerűen (ha van valahol számodra ismeretlen adat, akkor számodra véletlenszerűen) és írtam, hogy ha belevesszük a nemklasszikus fizikát, akkor is csak a lehetséges állapotok száma nő meg, és azok közül kapunk egy (tényleg)véletlenszerűt. (Azt hiszem hogy most a tér kvantált, de nem teljesen követem, hogy mikor melyik)
,,Abu azt mondta, hogy az baj, ha matekot végigszámolva hol 1, hol 0.999999 jön ki, és ilyen értelemben van több válasz ugyanarra a kérdésre."
Igen, és ebben téved. Ez a példa meg különösen idióta, tekintve hogy 0,999=1, tehát ha van egy 3/3-as kifejezésed, akkor a számolásod módjától függően juthatsz el a 0,999, vagy az 1 alakig (bár megegyeznek úgyhogy lényegtelen).
szerk:,,Ebből következően hiába igaz, hogy a matematikában az összeadás kommutatív, float és double számokra az ADD gépi utasítás nem az."
A matematikában az összeadás
kommutatívasszociatív? Nocsak? Én eddig azt hittem tetszőleges három fixhosszú lebegőpontos számot összeadva sorrendtől függő eredményt kapok
-
flugi
tag
Az out of order képességnek ügyelnie kell arra, hogy ne legyen megváltoztató hatása. Nem ütemezhet át olyan utasításokat, amik egymás eredményeit olvassák. Ha vesszük az a+=b; a+=c; dataflow-t, akkor az kifejtve matematikailag egyenértékű kellene legyen az a := a + b + c -vel, de sajnos az utasítások sorrendje pontosan a számábrázolási pontatlanságok miatt számít.
Két számnál még nem különösebben érdekes ez, de ha vesszük a következő példát:
#include <iostream>
#include <iomanip>
#include <vector>
using namespace std;
int main()
{
int N = 100;
float f = 1.0;
vector<float> szamok(N);
for (int i=1;i<N;i++) {
szamok[i] = f;
f*=.8;
}
float sum = 0.0;
for (int i=0;i<N;i++) {
sum += szamok[i];
}
cout <<setprecision(16) << sum << endl;
sum = 0.0;
for (int i=0;i<N;i++) {
sum += szamok[N-i-1];
}
cout <<setprecision(16) << sum << endl;
return 0;
}Akkor az adott mértani sorozat összege 5-höz tart, elegendő darabszámú sorozattag összege a float precizitás erejéig pontosan ki is adja az eredményt (a második eredmény 5), míg ha rossz sorrendben adjuk össze a számokat, akkor az eredmény 4.99999.
Ebből következően hiába igaz, hogy a matematikában az összeadás kommutatív, float és double számokra az ADD gépi utasítás nem az.
-
flugi
tag
Schrödinger macskája annak köszönheti a népszerűségét, hogy furcsa, és sokan, köztük te is asszociatívan használják, vagyis "erről eszembe jutott" módon.
A példád irreleváns. Az egyenletrendszernek van két megoldása valós számokon, ez két konkrét megoldás. Megoldási elvektől függően tudok olyan aritmetikai kifejtést adni, amivel a végigszámolás (ami ugye, emlékszünk, tartalmaz gyökvonást is, a másodfok miatt, úgyhogy a példád ilyen szempontból kényelmes) helyes megoldásnak egy 0.9999999938782736 alakú megoldást fog adni 1 helyett. Nem az a probléma ugyanis, hogy magának az egyenletrendszernek hány megoldása van, hanem az, hogy tetszőleges megoldáshoz való eljutás, a konkrét kiszámolás lépései azok, amiken a számábrázolás miatt zaj van, kerekítési pontatlanságok ÉS számábrázolási határok. Akinek van teszkógazdaságos számológépe, az tudja, hogy gyökháromszor gyökhárom az 2.99999999. A drágábbak sem azért tudják, hogy 3, mert ennek kell kijönnie, hanem mert szerencsésebbek a kerekítési és számábrázolási kérdésekben. Nem véletlen, hogy az FPU 80 biten számolja a 64 bites double-t.
Abu azt mondta, hogy az baj, ha matekot végigszámolva hol 1, hol 0.999999 jön ki, és ilyen értelemben van több válasz ugyanarra a kérdésre. Ezt kreatívan kell félreérteni a válaszod kiindulópontjához, és még kreatívabban képzavarba verődve a Schrödinger cicájához eljutni.
-
Sir Ny
senior tag
,,Schrödinger cicája pedig tartja az irreleváns tudományosnak szánt hivatkozások világrekordját, szoros versenyben a Gödel tétellel, és a relativitáselmélettel. Nem csoda, hogy itt is felbukkant
"Öm. Nem. Schrödinger cicája az egyetlen olyan (gondolat)kísérlet ami egyrészt ölég népszerű, másrészt pedig a determinisztikussághó' van köze.
,,Ez a matematikában tényleg így van. Csak programozásban nem."
Csak akkor, ha matematika = adott aritmetikai műveletek adott sorrendben való végrehajtása. BTW programozástól (programfutástól) is elvárhatnánk ugyanezt.
De ha már a programfutást feladat-centrikussá tesszük, azaz megmondjuk a szegény processzornak hogy micsináljon, és pont leszarjuk hogy hogyan csinálja, (bízunk benne hogy jól majd meglepődünk, hogy nem), akkor a matematikától is el lehet várni ugyanezt.
Például egy feladat: Pistike, itt van az egyenletrendszer, határozd meg egyetlen megoldását. Mondjuk: a=b és a*b=1. És Pistike csűri csavarja és az jön ki, hogy a=b=-1. Katinak meg a=b=1. És itt a hangsúly nem Pistikén van, vagy hogy rosszul számol: ha az a feladat, hogy valahogy határozza meg, és az a feladat, hogy egyetlen megoldást adjon meg a sokból, akkor akármelyik jó. Pont, mint a programozásnál, ott is az a processzor feladata, hogy adjon egy jó eredményt ahogy tud. Abu meg ha a matematikáhó' nem ért, ne szóljon belé.szerk: ha már aritmetika: ugye tudod, hogy a programfutás az az aritmetika és ezáltal a matematika része?
-
-
flugi
tag
ez képzavar a javából. Abu állítása az volt, hogy tetszőleges aritmetikai kifejezés (akár több értékű is) determinisztikus, mivel a matematika átrendezési szabályai mentén masszírozott tetszőleges úton kapott végeredmény azonos. Ez a matematikában tényleg így van. Csak programozásban nem.
Schrödinger cicája pedig tartja az irreleváns tudományosnak szánt hivatkozások világrekordját, szoros versenyben a Gödel tétellel, és a relativitáselmélettel. Nem csoda, hogy itt is felbukkant
-
flugi
tag
a kerekítés szó többféle jelentése itt keveredik. Ha úgy értjük, hogy a kettedeslevágás helyett igényesebben csinálást nevezzük kerekítésnek, akkor arról az igaz, hogy nagy számú művelet mellett a kijövő eredmény várható értéke közel torzításmentes becslése a valódi végeredmény adott számábrázolásra csonkolásának. Ezzel szemben a kettedeslevágás mindig a nulla felé torzít, tehát sok művelet esetében a várható érték is a nulla felé mozdul el.
Vicces apróság, hogy ha kettedeslevágás után az utolsó bitnyi értéket random hozzáadnánk a mantisszához, akkor statisztikailag javulna a pontosság
-
-
dezz
nagyúr
"a GPU atomikus művelete (amivel a párhuzamosan számolt részeredményeket összedolgozni érdemes) ütemezőfüggő sorrendben hajtódik végre, CPU programokban ez általában determinisztikus, hacsaknem több szálú, trükkös kódot csinál az ember."
A komolyabb CPU-k jó ideje out-of-order végrehajtást használnak (feltéve, hogy nincs dependencia). Egy olyan kód, hogy pl.:
a=b+c
d=e+f
g=a+d
lehet, hogy így hajtódik végre:
d=e+f
a=b+c
g=a+d -
polika
senior tag
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.
-
Sir Ny
senior tag
,,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)."
olvastad abu-t: ha több eredménye van, akkor a több eredményt egybeveszi, és egy eredménynek tekinti. Pl halmaznak. Logikus, ugye? (nem.)
-
polika
senior tag
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
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Sir Ny
senior tag
eredetileg ezt írtad: ,,Olyan nincs, hogy egy matematikai műveletnek több lehetséges eredménye van."
abban az értelmezésben hogy a több eredmény is egy eredmény (WTF?) lehet hogy igaz, de akkor ez nem matematika hanem világfüggő. Sőt, el sem lehet képzelni más világot mint hogy ugyanabból az állapotból elvégezve ugyanazt a műveletet ne ugyanazt kapjuk (vagy legalábbis néhány ugyanaz közül valamelyiket. Schrödinger macskás kísérleténél maradva: akárhányszor elvégezzük, mindig azt kapjuk, hogy vagy ilyen pozícióban van egy macskahullánk, vagy ilyen pozícióban egy élő macskánk)
-
polika
senior tag
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).
-
flugi
tag
Ez a hozzáállás alapvetően sérül a gyakorlatban, és ez nem a kerekítési probléma miatt van, hanem mert véges az ábrázolható kettedesjegyek száma. Egy IEEE float-ban 23, egy IEEE double-ben 52 kettedesjegy van. Ha van néhány ezer számod, amik nagyságrendben is eltérnek egymástól, akkor az összegük értéke attól fog függni, hogy milyen sorrendbe adod őket össze, mert ha a nagyobbakkal kezded, akkor a részösszeg nagyságrendje annyira különbözhet az összeadás kisebb operandusaitól, hogy azok konkrétan nem okoznak változást a bitekben, mert a 23-id (vagy akár 52-ik) kettedesjegy utániak.
Az tehát eleve lehetetlen feladat, hogy egzakt, lebonyolításfüggetlen eredményt várjunk el. A kerekítési, illetve pontossági elvárások, amiket az IEEE float és double leír, azért érdekesek, mert amennyire lehet, maximalizálni tudják az egyes aritmetikai lépések pontosságát. Egy klasszikus közelítő GPU implementáció egy-két bitben akár el is térhet ettől, cserébe a hatékonysága akár 10-szeres is lehet. Tipikus, hogy a szögfüggvényeket float-ban GPU-n néhány FMA lépéssel lehet hardveresen megoldani, de ennek az eredménye nem egyezik pontosan az IEEE float pontosságával, ami grafikában általában tökmindegy, de egy GPGPU alkalmazásban fontos lehet, mert a sok részeredmény sok pontatlansága gyorsabban nő, mint az IEEE kevesebb pontatlansággal járó részeredményei.
Érdekességképpen megjegyzendő, hogy különösen GPGPU alapokon domborodik ki a különböző ütemezések miatti eltérő részeredmény-csoportosítás miatti "újra számolom és más jön ki" jelenség, mivel a GPU atomikus művelete (amivel a párhuzamosan számolt részeredményeket összedolgozni érdemes) ütemezőfüggő sorrendben hajtódik végre, CPU programokban ez általában determinisztikus, hacsaknem több szálú, trükkös kódot csinál az ember.
-
Abu85
HÁZIGAZDA
A másodfokú egyenleteknek több megoldásuk van, de nem több eredményük. Ha a megoldásokkal elvéghez a részműveletek, akkor mindig ugyanazt az eredményt kapod, vagyis az egyik oldal egyenlő a másikkal.
(#12) menpee: Igen. Megoldásuk lehet több, de az nem egyenlő az eredménnyel. Ha behelyettesíted a megoldásokat, akkor az egyenlet mindegyik megoldással igaz lesz, azaz egyik oldal egyenlő a másik oldallal.
-
QG
tag
A "matematikailag helyes" kerekítés igazából nem jó:
(A+B+C)/2==A/2+B/2+C/2 ugye ismerős matematikából. Behelyettesítve 1, 2, 3at:
(1+2+3)/2=3
Ha előbb osztas és kerekítesz:
1/2+2/2+3/2 --> kerekítve 1+1+2=4 Nyilván rossz.Ezért találták ki azt már régen, először könyvelésben, aztán a könyvelőprogramoknál, hogy párosra kerekítünk:
1/2+2/2+3/2 --> kerekítve 0+1+2=3 Ez meg a jó eredményt adja.Szóval a kérdéskör bonyolultabb, mint az alsó tagozatok kerekítési szabályok. Ha valakit bővebben érdekel:
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html -
Sir Ny
senior tag
,,Olyan nincs, hogy egy matematikai műveletnek több lehetséges eredménye van."
lásd még másodfokú egyenletek.
Vagy kör és egyenes meszése (nem csak az algebra).Alapvetően a matematikai műveletek sok potenciális értéken hajtódnak végre (például az x^2 függvény minden valós számon) és sok potenciális értéket adnak ki eredményként, amin el lehet végezni egy újabb műveletet..
-
menpee
aktív tag
Ha emlékeim nem csalnak, akkor például az exponenciális egyenleteknek is több megoldásuk lehet ugyanazon művelet esetén is. Az integrálásnál pedig konkrétan akármi, ahogy azt a +C jelöli. És akkor még nem is osztottunk végtelent végtelennel
Természetesen csak kötekedés, a cikk és a hsz.-ed mondanivalója érthető és elfogadható
-
Abu85
HÁZIGAZDA
Az egész matematika arra épül, hogy egy művelet esetében mindig ugyanazt az eredményt kapd. Ezért vannak szabályok. Olyan nincs, hogy egy matematikai műveletnek több lehetséges eredménye van. Egy szabályt kell rá alkotni, és annak tudatában egy eredménye lehet.
A top hardverek ezért támogatják a legfőbb kerekítési módokat. Ez a szabály, és ezt betartva lehet minden hardveren ugyanaz az eredmény. -
#10
drkbl
őstag
Meteorhead
#7
drkbl
őstag
válasz
Meteorhead
#7
üzenetére
Mert a kerekítés tág fogalom, a cikk állításával ellentétben nincs egyértelműen helyes matematikai kerekítés.
-
#9
Meteorhead
aktív tag
#32839680
#8
Meteorhead
aktív tag
Már látom is lelki szemeim előtt a reklámkapmányokat, amint X mobiltelefongyártó aranyos reklámmal a Duracell nyuszik nyomán az aranyosra rajzolt készülékük "még mindig megy", amikor a konkurencia már kipurcant.
Erre jön az ellen-reklámhadjárat, aholis Y gyártó nyomja, hogy X és Y ülnek a padban, tanárnéni kérdez egy egyszerű matek kérdést, és X rávágja a rossz választ, míg Y persze tudja, villogtatva, hogy "bezzeg ő tudja a matematikát".
-
#7
Meteorhead
aktív tag
Meteorhead
aktív tag
Ez a kerekítés dolog tényleg érdekes, bár őszintén szólva nem értem, hogy miért akarnak annyira eltérni a szabványoktól (még ha nincs is rájuk erőszakolva) a gyártók. Egy konkrét példa: vegyünk egy közepesen innovatívnak számító játékot, ami gagyinak mondható, de AI-t számol IGP-n. Valami hardcoded változó (aggresszivitás, segítőkészéség, stb.) valamilyen ágens típusban 1,5. A játék konrétan könnyebb/nehezebb lehet valakinek a HW-én, mint egy másik gyártóén, de legalábbis konkrétan más lesz a játékmenet.
Az SI rendszert sem azért találták ki, hogy szívassuk magunkat, hanem mert a szabványok JÓK. Hol lenne a világ USB nélkül? Bár a változatosság gyönyörködtet, de a változatos malfunction már annyira nem. És ha emmiatt többet fogyaszt a mobi, akkor tessék elfogadni hogy itt tart a technika, és nem kiskapukkal nyújtani az akkumulátoridőt.
...szerintem.
-
#6
Abu85
HÁZIGAZDA
BlackPriest
#4
Abu85
HÁZIGAZDA
válasz
BlackPriest
#4
üzenetére
Mert a hardverben a kerekítési szabályok külön áramkört igényelnek. Így is lesz plusz áramkor a .05-ös és az alatti kerekítésekre, de egyszerűbb a biteteket "levágni", míg matematikailag helyesen korrigálni.
-
#4
BlackPriest
őstag
BlackPriest
őstag
Miert egyszerubb a peldaban lefele kerekiteni? (Ha van laikusnak valo valasz)
-
#2
danikollar
őstag
danikollar
őstag
Érdekes téma!
-
#1
CsuBaKamBra
tag
CsuBaKamBra
tag
Egy kis elírás: ... de az már alapvető az ... (4. bek.)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Crypto Trade
- Okos Otthon / Smart Home
- A fociról könnyedén, egy baráti társaságban
- Magisk
- War Thunder - MMO Combat Game
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Kertészet, mezőgazdaság topik
- Bambu Lab 3D nyomtatók
- BestBuy ruhás topik
- Milyen okostelefont vegyek?
- További aktív témák...
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD Touch I HDMI I Cam I W11 I Gari!
- Okosóra felvásárlás!! Samsung Galaxy Watch 5 Pro, Samsung Galaxy Watch 6 Classic
- Honor Pad X8a 64GB Wifi,1 év Garancia
- Thinkpad X230 legenda: i7 CPU, IPS kijelző, 12 GB, dupla SSD, magyar villbill, webcam, fingerprint
- Samsung S23 Ultra 256GB Állapot: 10/10 6 Hónap Jótállás!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest