Fließkomma-Arithmetik, OEIS, Divisionstest

    In der VAX-Diskussion habe ich das Thema der OEIS-Folgen A336777 und A336781 aufgebracht. Das sind zwei einer Reihe von Folgen, die sich mit Unterschieden von Fließkommaarithmetiken beschäftigen. Hier geht es um die Frage, wie oft man 1 durch n teilen kann, ehe man das Ergebnis 0 bekommt.


    Die Diskussion dort ging um Basic, aber das Thema ist natürlich programmiersprachenübergreifend.


    Im folgenden die bisherigen Erkenntnisse. Ergänzungen aller Art sind willkommen.

    IEEE 754 32-Bit-Fließkomma


    Gemäß Wikipedia sind die 4 Byte verteilt auf 1 Bit Vorzeichen, 23 Bits Mantisse, 8 Bits Exponent. Ergebnisse laut A336777:

    Code
    151, 96, 76, 66, 59, 55, 51, 49, 47, 45, 43, 42, 41, 40, 39, 38, 37, 37, 36, 36, 35, 35, 34, 34, 33, 33, 33, 32, 32, 32, 31, 31, 31, 31, 31, 30, 30, 30, 30, 29, 29, 29, 29, 29, 29, 29, 28, 28, 28, 28, 28, 28, 28, 27, 27, 27, 27, 27, 27, 27, 27, 27, 26, 26, 26, 26, ...

    IEEE 754 64-Bit-Fließkomma


    Gemäß Wikipedia sind die 8 Byte verteilt auf 1 Bit Vorzeichen, 52 Bits Mantisse, 11 Bits Exponent. Ergebnisse laut A336781:

    Code
    1076, 680, 539, 464, 417, 384, 360, 341, 325, 312, 301, 292, 284, 277, 270, 264, 259, 255, 250, 246, 243, 239, 236, 233, 230, 228, 225, 223, 221, 218, 216, 215, 213, 211, 209, 208, 206, 205, 203, 202, 201, 200, 198, 197, 196, 195, 194, 193, 192, 191, 190, 189, 188, ...

    Commodore-BASIC


    Gemäß C64-Wiki hat das 5-Byte-Zahlen verteilt auf 1 Bit Vorzeichen, 31 Bit Mantisse, 8 Bits Exponent. Das Programm

    Code
    10 OPEN 1,8,1,"OUTPUT"
20 FOR N=2 TO 200
30 A=1
40 I=1
50 A=A/N
60 IF A>0 THEN I=I+1:GOTO 50
70 PRINT I;:PRINT# 1,I;
80 NEXT N
90 CLOSE 1

    mit Ausgabe gleich auch in eine Datei liefert (gekürzt auf OEIS-Data-Länge):

    Code
    129, 81, 65, 56, 50, 46, 43, 41, 39, 38, 36, 35, 34, 33, 33, 32, 31, 31, 30, 30, 29, 29, 28, 28, 28, 27, 27, 27, 27, 26, 26, 26, 26, 25, 25, 25, 25, 25, 25, 24, 24, 24, 24, 24, 24, 24, 23, 23, 23, 23, 23, 23, 23, 23, 23, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, ...

    Obwohl Commodore-BASIC wie 32-Bit-IEEE ein Byte für den Exponenten, aber 8 Bit mehr Mantissengenauigkeit hat hat, sind die Werte also schlechter. Das liegt daran, daß bei Commodore-BASIC das erste Bit nach dem 'Binärpunkt' immer gesetzt ist (Mantisse zwischen 0.5 und 1). Wenn die Skalierung durch den Exponenten aufgebraucht ist und die Mantisse bei der Division kleiner als 0.5 wird, kommt 0 raus. Bei IEEE hingegen darf die Mantisse bei minimalem Exponenten auch kleiner werden, so daß man (unter Genauigkeitsverlust) weiterdividieren kann.

    WANG 2200T, Basic ?


    Ergebnise laut Georg:

    Code
    329, 208, 165, 142, 128, 118, 110, 104, 100, 96, 92, 89, 87, 85, 83, 81 ,79, 78, 77, ...

    Das sieht aus, als würde mit irgendeiner 'krummen' Exponentenlänge gerechnet, vielleicht 12 Bits.


    Edit: Hier noch die von Georg angegebene Seite, wo steht, daß die Wang 2200 eine BCD-Arithmetik hat:


    http://www.wang2200.org/fp_format.html

    2 Mal editiert, zuletzt von masi ()

    VAXBASIC 3.7


    Ergebnisse laut Toshi:

    Code
    129, 81, 65, 56, 50, 46, 43, 41, 39, 38, 36, 35, 34, 33, 33, 32, 31, 31, 30

    Das ist soweit identisch zum Commodore-BASIC, das ja laut Wikipedia auf Microsoft BASIC zurückgeht, welches es laut Wikipedia mit einer 32-Bit- und einer 40-Bit-Arithmetik gab und das letztere es auch nach BASIC-86 geschafft hat. Laut Wikipedia geht VAX BASIC zurück auf BASIC Plus 2, was zurückgeht auf BASIC-PLUS, was laut Wikipedia 64-Bit-Fließkomma hat, aber eben auch nur 8 Bits für den Exponenten. Das würde also passen. Die Mantisse ist offenbar ebenfalls zwingend normalisiert.

    Ich hatte ja gestern schonmal zwei Bildchen dafür gemacht, hier also noch die Ergänzung von BBC Basic einmal als "BASIC" aufgerufen



    und dann als "BASIC64"


    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    BBC Basic, als BASIC


    Werte laut ThoralfAsmussen:

    Code
    130, 83, 66, 57, 51, 47, 44, 42, 40, 39, 37, 36, 35, 35, 34, 33, 32, 32, 31, ...

    Interessante feine Unterschiede zu Commodore-BASIC.


    Der Sprung von 56 auf 58 ist merkwürdig und bedarf einer Klärung.


    Edit: Sorry, habe die 0 als 8 gelesen. Ist korrigiert.


    Edit: Alle Werte um 1 erhöht, damit so oft gezählt wird, bis 0 erreicht ist. Die Ergebnisse sind jetzt etwas besser als bei Commodore-BASIC.

    2 Mal editiert, zuletzt von masi ()

    Zitat von masi

    Der Sprung von 56 auf 58 ist merkwürdig und bedarf einer Klärung.

    Das ist einfach - die '58' ist im Bild eine '50' ...

    sonst wäre es wirklich komisch


    Ich kann auch gern nochmal I bei 1 anfangen lassen, was ja aber eigentlich nichts (prinzipiell) ändern sollte.


    (Interessanter fände ich fast, wenn man noch die Laufzeiten dazu hätte. Das gibt nämlich an sich auch einen sehr schönen Floating-Point Benchmark ab.)

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Burroughs B5500

    48 Bit Register, davon 39 Bit Mantisse und 6 Bit Exponent zur Basis 8, zwei Vorzeichenbits und ein Steuerbit:


    154 97 77 66 60 55 52 49 47 45 43 42

    41 40 39 38 37 37 36 35 35 34 34 33

    33 33 32 32 32 31 31 31 31 30 30 30

    30 29 29 29 29 29 29 28 28 28 28 28

    28 27 27 27 27 27 27 27 27 27 26 26

    26 26 26 26 26 26 26 26 25 25 25 25

    25 25 25 25 25 25 25 25 25 24 24 24

    24 24 24 24 24 24 24 24 24 24 24 24

    24 24 24 23 23 23 23 23 23 23 23 23

    23 23 23 23 23 23 23 23 23 23 23 23

    23 23 23 22 22 22 22 22 22 22 22 22

    22 22 22 22 22 22 22 22 22 22 22 22

    22 22 22 22 22 22 22 22 22 22 22 21

    21 21 21 ...


    Das Programm musste ich leicht anpassen, sollte aber funktionsgleich sein:


    00000020 FOR N=2 TO 200

    00000030 A=1

    00000040 I=1

    00000050 A=A/N

    00000060 IF A<=0 THEN 70

    00000062 I=I+1

    00000065 GOTO 50

    00000070 PRINT I;

    00000080 NEXT N

    00000090 END

    Zitat von DL5UY

    Burroughs B5500

    48 Bit Register, davon 39 Bit Mantisse und 6 Bit Exponent zur Basis 8, zwei Vorzeichenbits und ein Steuerbit:

    Bedeutet das, daß der Exponent in 8er-Schritten wächst und kleinere Änderungen der Zahl durch mehr Freiheit in der Darstellung der Mantisse realisiert werden? Interessant. Dann hängt die Anzahl der Stellen periodisch vom Exponenten ab.

    Genau so ist es. EXP+1 heißt Matisse 3 Bit verschieben.


    Außerdem für heute ungewöhnlich:

    Es gibt keine Unterscheidung Integer zu Fließkomma.

    Einerkomplement Darstellung, d.h. es gibt zwei Nullen.

    Dezimalpunkt ist ganz rechts - Exponent 0 bedeutet dann "ist ganze Zahl" - auch hier nur 39 Bit Genauigkeit.

    Etwas ähnlich zu dem Thema hatte ich hier bei der pdp8/e bei verschiedenen BASIC Varianten die Maschinengenauigkeit untersucht:

    Maschinen Epsilon


    Wenn ich nun versuche die Reihe zu berechnen, kommen bei mir gar keine Zahlen heraus. Problem scheint der Vergleich "A > 0" zu sein. Ich führe also einen Trick ein und Vergleiche "A+E > E". Dann bekomme ich Zahlen heraus, aber abhängig vom E! Also ganz andere Wenn E=1 oder E=1e-7


    10 E=1E-7

    20 FOR N=2 TO 200

    30 A=1

    40 I=0

    50 I=I+1

    60 A=A/N

    70 IF A+E > E GOTO 50

    80 PRINT I;

    90 NEXT N

    100 END



    10 E=1E-7

    RUN


    IEEE2 BA 5A


    47 30 24 20 18 17 16 15 14 14 13 13 13 12 12 12 12 11 11 11 11 11 11 10 10 10 10 10 10 10 10 10 10

    9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8

    8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7

    7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7

    7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7

    READY

    10 E=1

    RUN


    IEEE2 BA 5A


    23 14 12 10 9 8 8 7 7 7 7 6 6 6 6 6 6 6 6 6 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

    5 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

    4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

    4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

    3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

    READY

    10 E=1E-100

    RUN


    IEEE2 BA 5A


    356 224 178 153 138 127 119 112 107 103 100 96 94 91 89 87 86 84 83 81 80 79 78 77 76 75 74 74 73 72

    72 71 70 70 69 69 68 68 67 67 66 66 66 65 65 64 64 64 63 63 63 62 62 62 62 61 61 61 61 60 60 60 60

    59 59 59 59 59 58 58 58 58 58 57 57 57 57 57 57 56 56 56 56 56 56 56 55 55 55 55 55 55 55 55 54 54

    54 54 54 54 54 54 53 53 53 53 53 53 53 53 53 53 52 52 52 52 52 52 52 52 52 52 52 51 51 51 51 51 51

    51 51 51 51 51 51 51 50 50 50 50 50 50 50 50 50 50 50 50 50 50 49 49 49 49 49 49 49 49 49 49 49 49

    49 49 49 49 49 48 48 48 48 48 48 48 48 48 48 48 48 48 48 48 48 48 48 48 47 47 47 47 47 47 47 47 47

    47 47 47 47

    READY


    Die PDP hat 12Bit Worte und drei Worte sind eine Gleitkommazahl. Mantisse 1Bit Vorzeichen und 23 Bit Zahlendarstellung. Exponent 1 Bit Vorzeichen und 11Bit Exponentwert. Also etwas anders als IEEE 754.


    Diese Reihen kann ich nicht interpretieren.

    Suche Teile und Geräte für DEC PDP8 Systeme, DEC PDP 11/40 (Unibus) und Teletype ASR-33+ ASR-35. Sowie Zubehör, Doku usw. aus dem Umfeld.

    ... einen ham'mer noch ...


    HP Series-80 Standard BASIC (HP 85, 86, 87, 9915, 75)

    • 8 bytes (64 bit) Fließkommadarstellung
    • BCD format (mit:
      • 3 nibbles für den Exponenten (-499...+499)
      • 12 nibbles für die Mantisse
      • 1 nibble für das Vorzeichen

    (die 64 bit passen genau in ein Register der CPU und können deshalb effizient verarbeitet werden)


    (Im Programm musste noch ein ON ERROR GOTO eingefügt werden, sonst gibt es korrekterweise einen UNDERFLOW ERROR, vielleicht ist das das auch das Problem bei dem PDP/8 Programm)


    Liste mit divisor N: Anzahl I

    2: 1658, 3: 1046, 4: 829, 5: 714, 6: 642, 7: 591, 8: 553, 9: 523, 10: 500 ...

    20: 384, ...

    30: 338, ...

    40: 312, ...

    50: 294, ...

    60: 281, ...

    70: 271, ...

    80: 263, ...

    90: 256, ...

    100: 250 ...

    150: 230 ...

    200: 217 ... asymptotisch bei diesem Wert

    DAI-Basic (ROM-Arithmetik)

    Code
    65, 41, 33, 28, 25, 24, 22, 21, 20, 19, 19, 18, 18, 17, 17, 16, 16, 16, 15, 15, 15, 15, 15, 14, 14, 14, 14, 14, 14, 14, ...

    Der Exponentenbereich des DAI ist 'ein bißchen' kleiner als bei VAX HFLOAT.


    Ich habe das unter MAME gemacht:



    Es wäre interessant, wenn jemand die Rechnung zum Vergleichen mit einem DAI mit AMD 9511 machen könnte. Und dann wäre wiederum ein Vergleich mit IEEE 32-Bit interessant, denn der AMD 9511 ist laut http://www.cpu-world.com/CPUs/9511/index.html nicht ganz IEEE-konform (wohl aber etwas später der AMD 9512).


    Edit: Der Exponent darf ungefähr im Bereich +/- 18 liegen. Es wurde gegenüber IEEE 754 vielleicht ein Bit vom Exponenten geopfert, um mehr Genauigkeit in der Mantisse zu bekommen. Da das DAI-Basic vorkompiliert und ein Programm sowohl auf einem Rechner mit oder ohne AMD 9511 laufen können muß, muß das Format in beiden Fällen identisch sein (was nicht heißt, daß in beiden Fällen identisch gerechnet wird). Das heißt aber auch, daß der 9511 sehr weit weg von IEEE 754 ist.


    Edit: Yep. In http://vintagecomputer.net/fjkraan/comp/dai/doc/AM9511.pdf steht, daß der Exponent sieben und die Mantisse 24 Bits hat.

    2 Mal editiert, zuletzt von masi ()

    Der Test bewertet doch gar nicht irgendwelche Komformität oder die Anzahl der signifikanten Stellen, sondern einzig und allein wie klein/negativ der Exponent sein kann. Im Prinzip gehen hier nur die Anzahl der Bits des Exponenten ein. Über die Anzahl der Stellen und bei erlaubter "Denormalität" lässt sich dann der Zahlenwert noch etwas nach kleiner "strecken".