Keresés

Ahogy én látni vélem, nem volt tömegigény pontosabb lebegőpontos számításokra. Volt például tömegigény kevésbé pontos számítások gyors, párhuzamos végzésére, hangok, képek, filmek előállításához/lejátszásához.

Sziasztok!

A mai processzorok (i3-i7-Ryzen, stb.) HARDVERESEN ugyanúgy csak max. 64-bites lebegőpontos műveletekre képesek, mint a 35-40 évvel ezelőttiek (80486-os, ill. a 287,387 koprocik)?

Miért nem használnak nagyobb pontosságot a szoftverek, ha az ugyanúgy elérhető? Pl. az EXCEL a "double" 53 bit pontosságot használ, az "extended" 64 bit pontosság helyett!???

(A nagyobb pontosság előnyeit aligha kell magyarázni.)

Ha olyan számításokat szeretnék tömegével elvégezni, amihez nem elég a 64 bit pontosság, hanem 96-128 kellene, akkor ez csak szoftveresen, 1-2 nagyságrenddel lassabban fog menni?

Köszönöm.

https://www.evanjones.ca/floating-point-money.html

https://0.30000000000000004.com/

Ha a példabeli architektúrán 0.1-et teszünk egy 'float'-ba, akkor az hexásan ez lesz: 3dcccccd, decimalisan meg ez: 0.100000001490116119384765625

Ha 'double' változónk van, akkor 3fb999999999999a és 0.1000000000000000055511151231257827021181583404541015625 lesz ez a két érték.

Valamint kiszámolhatjuk az előző és következő lebegőpontos értéket, amit ábárzolni lehet ezen az architektúrán:

double:

3fb9999999999999 0.09999999999999999167332731531132594682276248931884765625
3fb999999999999a 0.1000000000000000055511151231257827021181583404541015625
3fb999999999999b 0.10000000000000001942890293094023945741355419158935546875

float:

3dcccccc 0.0999999940395355224609375
3dcccccd 0.100000001490116119384765625
3dccccce 0.10000000894069671630859375

Egy ilyen double az alábbi tartományban képest pontosan tárolni minden egész számot:

-9007199254740992 .. 9007199254740992

ez gyengébb, mint amire az int64_t képes, de több mint az int32_t értéktartománya

Inkább azt tippelném, hogy egy előjelbit, 11 bit karakterisztika, 52 bit mantissza.

(Később). No, olyasmi: http://en.wikipedia.org/wiki/Double-precision_floating-point_format

Illetve, ha jól látom, ez egy little-endian platform, tehát szemléletesebb lehet, ha megfordítom a byte-sorrendet (most az első byte a karakterisztika):

4034000000000000 represents 20
4035000000000000 represents 21
4036000000000000 represents 22
4035800000000000 represents 21.5
4035400000000000 represents 21.25
4035200000000000 represents 21.125
403519999999999a represents 21.1
3ff0000000000000 represents 1
3fe0000000000000 represents 0.5
3fd0000000000000 represents 0.25
3fc0000000000000 represents 0.125
3fb999999999999a represents 0.1

Beidézem a program kimenetét (kicsit átrendezve, hátha jobban hasonlít egy táblázatra), azt kellene látni belőle, hogy még a 0.1 sem véges kettedes tört, vagyis már azt sem tudjuk pontosan ábrázolni.

0000000000003440 represents 20
0000000000003540 represents 21
0000000000003640 represents 22
0000000000803540 represents 21.5
0000000000403540 represents 21.25
0000000000203540 represents 21.125
9a99999999193540 represents 21.1
000000000000f03f represents 1
000000000000e03f represents 0.5
000000000000d03f represents 0.25
000000000000c03f represents 0.125
9a9999999999b93f represents 0.1

Bármelyikről is van mondanivalód, szeretettel várjuk.

Szerintem a topikcím elnagyolt, mert a számok fizikai tárolási módjáról akar szó lenni.

Az ábrázolás szoftverfüggő, a tárolás hardver.

Köszönöm, hogy ennyit fáradoztok, jó ez az idelinkelt bittérkép. Most vettem észre, milyen jól ki van ez találva. :)

Felületesen eddig is ismertem a lebegőpontos ábrázolást, csak nem gondoltam végig, hogy simán hozzá lehet adni 1-et az utolsó bithez, és máris megvan a "rákövetkező" double érték. Eddig attól féltem, hogy a "having an implicit integer bit of value 1" a kettedespont helyén belezavarhat a kitevőbe, de most úgy látom, azzal se kell törődni. Abban a (kb. 1E-16 valószínűségű) esetben is a helyes érték adódik, amikor a kitevő utolsó bitjére van átvitel.

Ki fogom próbálni.

http://en.wikipedia.org/wiki/Double-precision_floating-point_format

/tread

Ebben segíthet egy apró csalás: ez a program kiírja a lebegőpontos számot binárisan, tehát segíthet kitalálni, hogy mit/mennyivel kell növelni.

/* float.c */

#include <stdio.h>

static void Test (double d);

int main (void)
{
    Test (20);
    Test (21);
    Test (22);
    Test (21.5);
    Test (21.25);
    Test (21.125);
    Test (21.1);
    Test (1);
    Test (0.5);
    Test (0.25);
    Test (0.125);
    Test (0.1);

    return 0;
}

static void Test (double d)
{
    size_t i;

    printf ("%6g is ", d);
    for (i=0; i<sizeof (d); ++i) {
        printf ("%02x", ((unsigned char *)&d)[i]);
    }
    printf ("\n");
}

A zárójelbe tett szövegem zagyvaságát nem fogom az indexre, azt én javítottam tönkre.

Kitaláltam neked egy feladatot.

Írjuk meg azt a függvényt, ami egy float (vagy double) x számnak a "rákövetkezőjét" előállítja. Vagyis azt - az adott gépi ábrázolásban egyértelműen létező - legkisebb xx számot, amire xx>x teljesül.

(Úgy látom, nemcsak a backslas törlődik, hanem a következő karaktert is. Itt próbálom ki, ha kettőzöm, akkor is törli? Backslash n (vagy nem az): \n)

Nincs külön int típus, de a kettes módszer az első programban kb ugyanez.

(És a derék index még mindig törli a \backslasht\)

/*

Bocs, JS-ben analfabéta vagyok, csak kíváncsiságból kérdezem: ott nincs egész (int) típus?
Vagy van, de annak a használatát most kizárja a játékszabály?
Közönséges C-ben ezt mindig így (vagy ezzel ekvivalens módon) csináljuk:
*/

int i;
float f, h;
h=1.0/100;
for(i=0; i<300; ++i) {
  f=i*h;
  printf("%1.2fn", f);
}
// Persze lehet tömörebben (f és h bevezetése nélkül) is, de most nem az volt a célom.

Egy másik program, ami mutat egy olyan nagy számot, amit ha eggyel növelünk, önmagát kapjuk (persze ez platformfüggő lehet).

/* dbltest.c */

#include <math.h>
#include <stdio.h>

int main (void)
{
    double num = 9007199254740980.0;

    while (num += 1.0) {
        double num2= num+1;
        double diff= num2-num;

        printf ("%g %g %gn", num, num2, diff);
        if (diff != 1.0) break;
    }
    return 0;
}

Kezdetnek egy JS program, háromszor futtatja le majdnem ugyanazt a ciklust, az első láthatóan rossz eredményt ad, a másik kettő jót.

<html>
<head>
</head><body>

Első mérés (halmozódó hiba)<BR>
<script>for (f=0; f<3; f+=0.01) {
    document.write (f + "<BR>n");
}
</script>

Második mérés<BR>
<script>for (f=0; f<300; ++f) {
    document.write ("" + f/100 + "<BR>n");
}
</script>

Harmadik mérés<BR>
<script>for (f=0; f<3; f= (Math.floor (100*f+0.5) + 1)/100) {
    document.write ("" + f + "<BR>n");
}
</script>
Kész<BR>
</body></html>

A JavaScriptes topikot már jól szétoffoltuk, úgyhogy akár lehet egy külön topik is erre.