Discussion:
Dynamikbereich von Zahlenformaten
(zu alt für eine Antwort)
Hans-Peter Diettrich
2020-06-30 17:11:31 UTC
Permalink
[Nachdem ich darauf aufmerksam gemacht wurde, daß Thunderbird Tabs schon
beim Abschicken verhunzt, hier nochmal mit fest formatierten Tabellen.]

Es gibt verschiedene Ansätze um Zahlenwerte mit einer beschränkten
Anzahl von Stellen (digits, bits) darzustellen. Aufgrund dieser
Beschränkung ist jedes definierte Modell ein Kompromiß zwischen
Präzision (signifikante Stellen) und Skalierungsfaktor (b^Exponent).

Von IEEE 754 wird zu jeder Variablengröße (Bitzahl) eine feste Anzahl
von Exponentenbits vorgeschlagen. Der Standard ist offen für abweichende
Implementierungen, die jedoch alle auf festen Werten für die Zahlenbasis
b (2 oder 10), Präzision (signifikante Stellen) p und maximalen
Exponenten emax basieren sollen. Die Präzision wird einschließlich des
hidden bit ausschließlich Vorzeichenbit angegeben. Der Bereich kleinster
Zahlen (um 0) wird durch denormalisierte Zahlen (hidden bit = 0) bis
exakt 0 erweitert.

Ein Ansatz mit einem dynamischen Bereich für den Exponenten hat John L.
Gustafson mit seinen Unum-Formaten entwickelt. Die Dynamik wird durch
eine Abnahme der Anzahl der signifikanten Stellen bei hohen Exponenten
erkauft. Dem steht ein minimaler Vorteil von mehr signifikanten Stellen
bei Werten um 1.0 gegenüber. Die hohen Exponenten bis emax werden nicht
nur durch einen Verlust sämtlicher signifikanten Stellen erkauft,
zuletzt (bei emax) fallen sogar alle Exponentenbits weg. Diesen Effekt
habe ich weiter unten mit einer negativen Präzision gekennzeichnet.

Ein weiterer Vorschlag verwendet eine variable Zahl von
Exponentenstellen, deren Anzahl in einem zusätzlichen Bitfeld r (range)
gespeichert wird. Hier eine Tabelle der damit erreichbaren Dynamik in
Abhängigkeit von der Anzahl der Range Bits (rs):

rs 2 3 4 5
es 0-3 0-7 0-15 0-31
emax 7 127 32K-1 2G-1
Faktor 2^7-1 2^127-1 2^32K-1 2^2G-1
rs+es 2-5 3-10 4-19 5-36

Damit läßt sich z.B. mit rs=4 der IEEE Bereich für 128 Bit Zahlen
(emax=16K) übertreffen, mit 11 signifikanten Bits mehr (um 1.0) bis 3
weniger (um e=16K). Gegenüber IEEE 32 Bit (single) wären es +5 bis -2
signifikante Stellen, immerhin 29 statt nur 24 signifikante Bits um 1.0.

Im Vergleich mit IEEE Formaten gleicher Bitzahl läßt sich damit erreichen:

Bits 16 32 64 128
-------------- IEEE -------------------
es 5 8 11 15
emax 15 127 1023 16K-1
p 11 24 53 113
--------- höhere Präzision ------------
rs+es 2+3 3+5 4+7 4+11
emax 7 31 127 2K-1
p 11-14 24-29 53-60 113-124
--------- gleicher Bereich ------------
rs+es 3+4 3+7 4+10 4+14
emax 15 127 1023 16K-1
p 9-13 22-29 50-60 110-124
--------- größerer Bereich ------------
rs+es 3+7 3+7 4+15 4+15
emax 127 127 32K-1 32K-1
p 6-13 22-29 45-60 109-124
-------------- Posit ------------------
es 1 2 3 4
emax 25 111 471 1951
p 1-13 1-28 1-59 1-122
emax 28 120 496 2016
p -1..13 -2..28 -3..59 -4..122

Lohnt sich so eine Verbesserung?
Sonstige Kommentare?
Jens Kallup
2020-07-08 21:54:34 UTC
Permalink
Post by Hans-Peter Diettrich
[Nachdem ich darauf aufmerksam gemacht wurde, daß Thunderbird Tabs schon
beim Abschicken verhunzt, hier nochmal mit fest formatierten Tabellen.]
Es gibt verschiedene Ansätze um Zahlenwerte mit einer beschränkten
Anzahl von Stellen (digits, bits) darzustellen. Aufgrund dieser
Beschränkung ist jedes definierte Modell ein Kompromiß zwischen
Präzision (signifikante Stellen) und Skalierungsfaktor (b^Exponent).
Hallo Hans,

ein Statement von mir dazu, so wie ich das im Koppe hab:

Thunderbird ist ein gant normaler HTML-Editor - beim schreiben von Mails
und News.
Hierbei kannst Du in den Einstellungen auch festlegen, ob die Beiträge
allgemein in HTML, Text, oder Mischform erstellt werden sollen.
Ich versuche meistens Texte/Artikel in fester Schrifftbreite zu
erstellen.
Für Formatierungen würde ich vorschlagen:
- erst Text in rohform,
- dann Formatierungen vornehmen.

Bei fester Schrifftbreite werden auch die Tabs einheitlich in 9 Zeichen
Länge/Breite als 1 Zeichen 0x09 hex (Basis 16 - 0x0f) dargestellt.

Thunderbird gibt eine feste Breitenlänge vor, so dass es schon mal eng
werden kann mit Tabellen oder überlangen Text.

Was meinst Du mit formatierten Tabellen ?
HTML What You See Is What You Get - WYSIWYG ?

Nun, in Newsgroups wird für/von den Kommunikationspartnern eigentlich
reines Text-Format verwendet.
Das hat zum einen Historische Gründe, und ich selbst finde es angenehmer
keine Werbeblöcke oder andere verkorkste Schriftzüge zu sehen, die das
lesen beeinträchtigen.

So, nun zu den Zahlenwerten:
Es gibt eigentlich keine begrenzten Zahlenwerte.
Wird ein Limit erreicht, wird einfach eine Neue Spalte eingeführt, und
die Berechnungen gehen weiter, und weiter, und weiter, ...

So ist es eigentlich schon egal wie groß der Zahlenbereich ist.

Was Du hier als Zahlenbereich nennst, wird in der Informatik als Bit-
breite bezeichnet.
Wobei 1 Bit jeweils 2 Zustände annehmen kann.
Die kleinste Bit-Einheit ist 0, und die größte Bit-Einheit ist 1.
Also 0 - Strom liegt *nicht* an, 1 - Strom *fließt*.

Mit diesen Bit kannst Du kkomplexe und zugleich einfache Komponenten
basteln.

- zu Zeiten von MS-DOS waren 16 Bit Computer (CPU) aktuell
- zu Zeiten von Windows95 waren 32 Bit ...
- zu Zeiten von WindowsXP sind 64 Bit ...

Auf Grund der dieser beschränkten, und standardisierten Bitbreite war/
ist es möglich, das Programme nicht für jeden Computertyp der gleichen
Baureihe einzeln und aufwendig programmkiert werden müssen.

Bei Berechnungen sind dann jeweils 2 Hoch n (n zum Beispiel: 16,32,64)
mögliche Wertigkeiten, die im Speicher abgebildet werden können.

Beispiel: 2^16 (zwei hoch 16) damit lassen sich 65535 Speicherstellen
darstellen.
Jede einzelne Speicherstelle steht für eine Zahl.
Also: 0 bis 65535 .

Im Prinzip lassen sich 16 Bit Berechnungen auf einen IBM-PC genauso gut
auch auf einen Commodore C-64 8-Bit Computer bewerkstelligen.
Diese brauchen dann aber unter Umständen die doppelte Zeit an Taktzyklen

Leider ist es so, dass der Technik auch natürliche Grenzen gesetzt sind.

So kann es schon vorkommen, das die auf dem Prozessor aufgedampften
logischen Einheiten bei langen Betrieb des Gerätes kaputt gehen und sich
daraus dann falsche Berechnungen ergeben.

Daher hat man auch hier die Präzission standardisiert.
Zum einen wegen dem oben beschriebenene, zum anderen wegen dem programm-
technischen Aufwand.

Ich will das mal an einen 15 Bit Computer verdeutlichen:
Bei einer 2^16 Bit CPU, besteht die Zahl 65535 aus genau 5 Digits.
1 Digit kann 0, 1, 2, 3, 4, 5, 6, 7, 8, oder 9 sein.

nehmen wir mal an, wir wollten den Bruch 1/3 darstellen.
Wie wir wissen ist dies eine unendliche Periode 0,333...

Da Computer Dummies sind, wird der Computer versuchen für alle Ewigkeit
ein Ergebnis zu suchen ohne an ein Ziel zu kommen.
Auf diesen Weg wird auf Grund der Wärmeeinwirkung die Oberfläche der
CPU verändert und es kommt irgendwann zu einen rundungsfehler bzw.
Überlauf.
Wir Menschen machen also Programme für Computer, und können so bestimmen
wenn dieser rekursive Vorgang beendet werden soll.

Da nun diese 5 Digits zur damaligen Zeit ein robuster Wert darstellte,
hatte man sich gedacht, das alle Ergebnisse, die kleiner 2^15 waren
nach der komma Stelle 4 Digits bekammen,
Das 5te Digit stellte hierbei das Komma nach der Null dar.

Da Nun die Computer nach dem EVA Prinzip arbeiten:
E = Eingabe,
V = Verarbeitung,
A = Ausgabe.

würde der Computer vom außenstehenden Menschen von rechts nach links
arbeiten.
Das heißt: Alles was links rein kommt, wird rechts wieder zuerst
ausgegeben.
Das klingt im ersten Moment etwas verwirrend und kommisch;
ist aber so gemeint:

(Ich gehe jetzt mal von einer breite von 3 Zeichen aus, wobei die Zahlen
mit 0 am Anfang aufgefüllt (padding) werden:

Die Aufgabe
123 + 10 = 133

wird in der RPN = rückwärts - polnische - notation
berechnent, wobei immer erst 2 Zahlen, und dann ein zugehöriger
Operator - in dem Beispiel also Plus (+) verarbeitet.
Das sieht dann so aus:

010
123
+++

Der Computer macht dann intern folgende Rechnung:
1. - null einlesen
2. - eins einlesen
3. - null einlesen
4. - bitbreite erreicht, fange neuen Zahlenblock an zu lesen
5. - drei einlesen
6. - zwei einlesen
7. - eins einlesen
8. - bitbreite erreicht, fange neuen block an zu lesen
9. - lese Operator (im dem falle eine Anweisung aus 3x +)

Anschließend wird wieder von links nach rechts das Ergebnis
gelesen und entsprechen ausgegeben: 1 3 3

Man kann sich also merken:
- Eingabe: von rechts nach links
- Ausgabe: von links nach rechts

Und programmtechnisch hat man sich überlegt - zum Beispiel
bei einer Ganzzahl-Division mit Rest, den ganzzahligen Teil
in einen Register - zum beispiel BX, und den Rest in das
Register CX zu legen.
Somit kann man recht schnell, sich einen Computer im Computer
basteln - klingt zwar doof, ist aber so, würde die Maus sagen
;-)

Jens

Lesen Sie weiter auf narkive:
Loading...