Die übliche Intervall-Arithmetik verwendet für das Rechnen mit
garantierter Genauigkeit zwei gewöhnliche float-Zahlen für die
untere und obere Grenze eines Intervalls.
Als Alternative schlage ich folgendes 8-Byte-Zahlenformat vor:
Die ersten 2 Byte bestehen aus einer 1 am Anfang, 14 Bit für den
Exponten e, und aus dem Vorzeichen S. Die restlichen 6 Byte sind
die vorzeichenlose Mantisse M. Die Zahl stehe für das Intervall
S*[M-1,M+2]*2^(e-1fff)
Steht am Anfang 0 statt 1, soll das "unbestimmt" bedeuten. Oder
es soll anzeigen, dass die restlichen Bits für eine Integer-Zahl
stehen, und nur wenn alle Bits 0 sind, bedeutet das "unbestimmt".
Integer-Zahl wäre dann -3fffffffffffffff bis +3fffffffffffffff
Als Format des Hexadezimal-Strings einer float-Zahl
schlage ich vor: SnNnnnNnnnNnnnEXPN mit S= + oder -
EXPN ist der Exponent im Bereich -800 ... +7ff
Das letzte n der Mantisse nNnnnNnnnNnnn darf nicht 0 sein.
Die letzte 1 im letzten n dient als Terminierungszeichen.
Das Bit davor ist das letzte gültige Bit mit Wertigkeit 2^k.
Das Fehlerintervall ist S*[-1,+2]*2^k.
Wenn 0 bis 3 Bit im letzten n gültig sind, müssen
mindestens 0 bis 3 führende Bit im ersten n Null sein.
Ich habe dieses Zahlenformat auf dem von mir entwickelten
8bit-Rechner implementiert. Bisher stehen nur die 4 Grund-
Rechenarten zur Verfügung. Es gibt dazu ein Demonstrations-
Programm, das man mittels Emulation auf Linux-PC testen kann.
Falls jemand es ausprobieren will: Informationen auf den
Seiten Emul und Testcard meiner Website. Von der Seite
Downloads werden gebraucht emul.c, coka, teca.
http://www.bomerenzprojekt.de
Nach Starten des Emulationsprogramms gebe man ein 1.FLOP #
Zeichen 1: man drücke 6 dann 1, Zeichen #: man drücke 2 dann 0.
Der Quelltext des Demonstrations-Programms wird in das Text-RAM
geladen und automatisch compiliert. Das Programm wird gestartet.
Zur Eingabe der erfragten Werte schalte man in den Ziffernmodus
mit Taste #. Bei float-Zahlen das Vorzeichen S stets angeben.
EXPN stets mit 4 Zeichen angeben (Vorzeichen und 3 Ziffern)
Führende Nullen der Mantisse können weggelassen werden.
Josef G. schrieb:> Die übliche Intervall-Arithmetik verwendet für das Rechnen mit> garantierter Genauigkeit zwei gewöhnliche float-Zahlen für die> untere und obere Grenze eines Intervalls.
Wer sagt das?
"Gewöhnliche" float-Zahlen sind binär codiert und das hat den
entscheidenden Nachteil, dass die Wandlung vom Dezimalsystem nach Float
und zurück fehlerbehaftet ist.
Um dieses Problem zu umgehen, benutzt man für Intervall-Arithmetiken mit
garantierter Genauigkeit BCD-codierte Fließkommazahlen.
Welche Vorteile soll es denn gegenüber einem BCD-codierten
Fließkommaformat haben? Beseitigt es das Wandlungsproblem?
Uhu U. schrieb:> Um dieses Problem zu umgehen, benutzt man für Intervall-Arithmetiken mit> garantierter Genauigkeit BCD-codierte Fließkommazahlen.
Worin besteht der Zusammenhang zwischen Intervall-Arithmetik und der
Frage der internen Darstellung von Fliesskommarechnung?
Das Wandlungsproblem besteht bei binärer Fliesskommadarstellung immer,
egal ob Intervall-Arithmetik oder nicht. Dennoch hat man ausser bei Geld
praktisch nur mit binärer Rechnung zu tun. Und bei der Gehaltsabrechnung
fällt mir grad kein ernsthafter Anwendungsfall von Intervall-Arithmetik
ein. ;-)
@A. K. (prx)
>> Wobei hier doch eher starke Parallelen zum Dadaismus vorliegen.>Eher dazu:>Beitrag "8bit-Computing mit FPGA">Beitrag "Gibt es eine Programmiersprache mit diesem Schleifentyp?"
Ich kenne Josef und seinen Werdegang hier im Forum . . .
Beitrag "Re: wer kann sich noch an den hex-zeichensatz erinnern?"
Jetzt N. schrieb:> und der Vorteil ?
Vorteil gegenüber dem üblichen Rechnen mit Gleitpunkt-Zahlen:
Die Buchführung über die Auswirkungen von Rundungsfehlern
macht der Rechner selber. Der Anwender muss sich nicht
ständig darüber Gedanken machen.
Vorteil gegenüber der Verwendung von zwei unabhängigen
Zahlen für Unter- und Ober-Grenze: Weniger Speicherplatz.
Und man muss nur eine einzige Zahl eingeben/ausgeben.
Nachteil gegenüber der Verwendung von zwei unabhängigen
Zahlen für Unter- und Ober-Grenze: Die Fehler-Intervalle
wachsen bei längeren Rechnungen schneller an.
A. K. schrieb:> Worin besteht der Zusammenhang zwischen Intervall-Arithmetik und der> Frage der internen Darstellung von Fliesskommarechnung?
Was nutzt die garantierte Genauigkeit, wenn sie nicht im gewohnten
Zahlensystem darstellbar ist?
> Das Wandlungsproblem besteht bei binärer Fliesskommadarstellung immer,> egal ob Intervall-Arithmetik oder nicht.
Eben. Und deswegen nimmt man die BCD-Darstellung, die ist nämlich ohne
Fehler als Dezimalzahl darstellbar...
@Josef G
ich hab davon (zugegeben) 0E-1 Plan
ein extended float (80-bit) schaut für mich nicht viel anders aus als
dein Vorschlag
https://en.wikipedia.org/wiki/Extended_precision
könntest nicht ein Praktisches Beispiel, also konkrete Berechnung Posten
mit der üblichen 80-bit float, und deinem 8-byte float
wo man sieht wie weit die Ergebnisse auseinander liegen?
Falk B. schrieb:> DA DA DA , ah, ah, DA, DA, DA
Was ist los mit Dir, Papa?
Ist Dein Radio nicht mehr da,
hat man's Dir vielleicht versaut,
die deutsche Welle eingebaut?
;-)
MfG Paul
Uhu U. schrieb:> Was nutzt die garantierte Genauigkeit, wenn sie nicht im gewohnten> Zahlensystem darstellbar ist?
Was nützt die Vermeidung des Wandlungsfehlers, wenn das Ergebnis um
etliche Stellen links von diesem Fehler ungenau ist?
Der Wandlungsfehler wird zwar das in der Ausgabe angezeigte Intervall
gegenüber dem binär ermittelten Intervall geringfügig vergrössern, aber
es geht i.d.R. weniger darum, das um jeden Preis kleinste Intervall zu
ermitteln. Vielmehr will man jenes Intervall ermitteln, in dem das
Ergebnis garantiert liegt. Es gibt ja Rechnungswege, bei denen die
Grösse dieses Intervalls extrem von den Eingangswerten abhängt.
A. K. schrieb:> Es gibt ja Rechnungswege, bei denen die> Grösse dieses Intervalls extrem von den Eingangswerten abhängt.
Ja eben - und da ist der Ansatz mit nur 14 bit Exponent doch nicht
brauchbar.
Dumdi D. schrieb:> Ja eben - und da ist der Ansatz mit nur 14 bit Exponent doch nicht> brauchbar.
Ich frage mich eher, ob seine Darstellung irgendwas mit
Intervall-Arithmetik zu tun hat.
A. K. schrieb:> Ich frage mich eher, ob seine Darstellung irgendwas mit> Intervall-Arithmetik zu tun hat.Josef G. schrieb:> Die Zahl stehe für das Intervall S*[M-1,M+2]*2^(e-1fff)
Uhu U. schrieb:> Josef G. schrieb:>> Die übliche Intervall-Arithmetik verwendet für das Rechnen mit>> garantierter Genauigkeit zwei gewöhnliche float-Zahlen für die>> untere und obere Grenze eines Intervalls.>> Wer sagt das?
Statt "zwei gewöhnliche float-Zahlen" hätte ich
schreiben sollen "zwei unabhängige Gleitpunkt-Zahlen".
Ich bevorzuge eigentlich eher eine Fehlerrechnung, wenn mich denn die
Genauigkeit interessiert. Und dann muessen die Eingangwerte auch noch
die passende Genauigkeit besitzen.
Josef G. schrieb:> Die Zahl stehe für das Intervall S*[M-1,M+2]*2^(e-1fff)
Das gilt dem Prinzip nach für jedes beliebige endliche Zahlenformat bei
nicht endlichem Ergebnis. Das macht daraus keine Intervall-Arithmetik.
A. K. schrieb:> Der Wandlungsfehler wird zwar das in der Ausgabe angezeigte Intervall> gegenüber dem binär ermittelten Intervall geringfügig vergrössern, aber> es geht i.d.R. weniger darum, das um jeden Preis kleinste Intervall zu> ermitteln.
"i.d.R." gibts weder in der Mathematik, noch im Compilerbau...
Wie willst du Konstanten genau in dein Programm bringen, wenn du nicht
genau weißt, was der Compiler daraus macht? Willst du Zwischenergebnisse
etc. binär abspeichern?
Josef G. schrieb:> Statt "zwei gewöhnliche float-Zahlen" hätte ich> schreiben sollen "zwei unabhängige Gleitpunkt-Zahlen".
Hast du wirklich keinen Dreh gefunden, dich noch billiger aus diesem
Dilemma davonzustehlen?
A. K. schrieb:> Das macht daraus keine Intervall-Arithmetik.
Wenn man die 'Mantisse' schiebt, d.h. ein paar Nullen davor setzt und
dafür den Exponenten vergrößert, dann kann man damit das Intervall
vergrößern (auf Kosten des Wertebereiches und der Genauigkeit). Ob das
gemeint war? Ob das sinnvoll ist?
A. K. schrieb:> Das gilt dem Prinzip nach für jedes beliebige endliche Zahlenformat bei> nicht endlichem Ergebnis. Das macht daraus keine Intervall-Arithmetik.
Korrekt. Bei den vier Grundrechenarten ist Josefs "Intervall-Arithmetik"
ja noch trivial zur Fehlerabschätzung eines Ergebnisses nach oben und
unten. Aber schon bei x² ist er aufgeschmissen.
A. K. schrieb:> Josef G. schrieb:>> Die Zahl stehe für das Intervall S*[M-1,M+2]*2^(e-1fff)>> Das gilt dem Prinzip nach für jedes beliebige endliche Zahlenformat bei> nicht endlichem Ergebnis. Das macht daraus keine Intervall-Arithmetik.Dumdi D. schrieb:> Wenn man die 'Mantisse' schiebt, d.h. ein paar Nullen davor setzt und> dafür den Exponenten vergrößert, dann kann man damit das Intervall> vergrößern (auf Kosten des Wertebereiches und der Genauigkeit).> Ob das gemeint war?
Genau so ist es gemeint. Und das Entscheidende bei meinen Routinen
war die Ermittlung der korrekten Anzahl der erforderlichen Shifts.
> Ob das sinnvoll ist?
Das muss die Praxis zeigen.
Frank M. schrieb:> Aber schon bei x² ist er aufgeschmissen.Josef G. schrieb:> Bisher stehen nur die 4 Grund-Rechenarten zur Verfügung.
Es wäre noch viel zu programmieren, zB. auch Multiplikation
mit Integer-Zahlen und Division durch Integer-Zahlen.
Josef G. schrieb:> Und das Entscheidende bei meinen Routinen> war die Ermittlung der korrekten Anzahl der erforderlichen Shifts.
D.h. soetwas wie 50000 +- kleiner Fehler + 1+- sehr großer Fehler
kann schon zum 'Out of range' führen?
Dumdi D. schrieb:> kann schon zum 'Out of range' führen?
Versteh ich jetzt nicht, wie du das meinst. Die Größe des
Fehler-Intervalls ist bei meinem Zahlenformat gekoppelt
an den Exponenten. Zu Beispielen kann ich nur etwas
sagen, wenn die Exponenten bekannt sind.
@Josef G.
bitte mal eine konkrete Frage beantworten:
wo ist der Unterschied (VORTEIL) zu normalen Float z.b. 64-bit
double-precision real oder 80-bit extended-precision real
https://en.wikipedia.org/wiki/Intel_8087#IEEE_floating_point_standard
dein Zahlenformat schaut exakt gleich aus..
und "NaNs" hast auch nicht DU erfunden ;-)
Robert L. schrieb:> dein Zahlenformat schaut exakt gleich aus..
Meine Zahlen sind Intervalle. Es wird garantiert (falls ich
keine Fehler programmiert habe), dass das Ergebnis einer
Rechnung innerhalb der Intervall-Grenzen liegt.
> und "NaNs" hast auch nicht DU erfunden ;-)
Hab ich auch nicht behauptet.
Dumdi D. schrieb:> MAch doch mal 1,2 explizite Beispiele.
Siehe Eröffnungsbeitrag, Bild run.png
Es werden die Operationen Add,Sub,Mul,Div ausgeführt und
das Ergebnis ausgegeben, dann wird die Operation jeweils
rückgängig gemacht und das Ergebnis wieder ausgegeben.
Man erkennt, wie sich beim Endergebnis die Stellenzahl
gegenüber dem ersten eingegebenen Wert verringert hat.
Josef G. schrieb:> Siehe Eröffnungsbeitrag, Bild run.png
Ne, ich meine einfach mal eine Zahl. Wie würde das Interval
[1005,2 ; 1010,9] z.B. in Deiner Darstellung aussehen?
Paul B. schrieb:> Falk B. schrieb:>> DA DA DA , ah, ah, DA, DA, DA>> Was ist los mit Dir, Papa?> Ist Dein Radio nicht mehr da,> hat man's Dir vielleicht versaut,> die deutsche Welle eingebaut?> ;-)> MfG Paul
Los Paul
du musst ihm voll in die Eier haun
https://www.youtube.com/watch?v=wnNrtGVrCis
Aber nicht wörtlich nehmen, gelle!
;-)
Dumdi D. schrieb:> Ne, ich meine einfach mal eine Zahl.
Beispiel +A3456+003 (ohne führende Nullen der Mantisse)
Die letzte Ziffer 6 der Mantisse ist 0110, steht
also für den 2-Bit-Wert 01. Die zweite 1 ist das
Terminierungszeichen. Das Fehlerintervall ist
[-1,+2]*(Wertigkeit des letzten gültigen Bits)
Der Wert ist also +A3454*10^3
Das Fehlerintervall ist +[-4,+8]*10^3
Oder ausgeschrieben: Die Zahl steht für
das Intervall +[A3450,A345C]*10^3
Josef G. schrieb:> Meine Zahlen sind Intervalle. Es wird garantiert (falls ich> keine Fehler programmiert habe), dass das Ergebnis einer> Rechnung innerhalb der Intervall-Grenzen liegt.
Ich sagte doch schon, dass Du damit schon bei x² voll auf die Fresse
fliegst.
Ich erkläre es mal überspitzt:
x sei exakt 0. Ich schreibe es nun mal als Intervall [-1, +1]. Das ist
zwar nun bewusst sehr ungenau, aber egal wie schmal Du das Intervall
machst, Dein Fehler wird derselbe sein.
Nun rechnest Du: -1² = +1
+1² = +1
Du bekommst also als Ergebnis-Intervall [+1,+1] heraus. Das liegt weit
außerhalb des exakten Ergebnisses. Dieses ist NICHT im Intervall
enthalten!
Dieses Problem hast Du bei allen nicht-linearen Zusammenhängen. Bei
Rechnungen nahe von lokalen Minima/Maxima versagt Deine
"Intervall-Arithmetik" komplett. Und davon gibt es unendlich viele
Beispiele.
Josef, Deine Grundschulmathematik hört bei der 4. Klasse auf. Die Leser
hier sind aber schon älter.
Und Plus-Minus mit Intervallen ist total uninteressant, weil immer
exakt. Das Ergebnis kann nämlich nicht mehr Stellen haben als die
Summanden.
Josef G. schrieb:> Beispiel +A3456+003
ok. Die Formel soll ja:
S*[M-1,M+2]*2^(e-1fff)
sein. Was ist die 003? e? e-1fff? Warum schreibst Du dann
Josef G. schrieb:> +A3454*10^3
sollte es nicht eher A3454*2^(003-1fff) sein, oder A3454*2^(003) wenn
man mal annimmt dass Du die 1fff 'im Kopf mitführst'? Ist aber trotzdem
2^ und nicht 10^. Oder drehst Du Dir die Regeln wie Du lustig bist?
Dumdi D. schrieb:> Warum schreibst Du dann
Der Zusammenhang zwischen Binärzahl und Hex-String
am Beispiel der Zahl +A3456+003 ist folgender:
Der Hex-String anders geschrieben:
1010.0011.0100.0101.0110 *10^3
Die letzte 1 der Mantisse ist das Terminierungszeichen, das Bit
davor ist das letzte gültige Bit. Damit bleibt von der Zahl:
1010.0011.0100.0101.0100 *10^3 mit Fehler [-4,+8]*10^3
Die ungültigen 2 Bit werden entfernt
1010.0011.0100.0101.01 *(2^2)*(10^3)
Anders geschrieben
10.1000.1101.0001.0101 *(2^2)*(10^3)
Wegen 10^3 = (2^4)^3 = 2^(4*3) wird daraus
10.1000.1101.0001.0101 *2^(4*3+2)
Anders geschrieben
28d15 *2^(4*3+2) mit Fehler [-1,+2]*2^(4*3+2)
Die abgespeicherte 6-Byte-Mantisse ist 000000028D15
Der abgespeicherte Exponent e ist 4*3+2+1fff
Der Festlegung 1fff für den Offset des Exponenten ist
so gewählt, dass die obere und untere Grenze des Exponenten
mit den entsprechenden Grenzen im Hex-String übereinstimmt.
Frank M. schrieb:> x sei exakt 0. Ich schreibe es nun mal als Intervall [-1, +1].>> Nun rechnest Du: -1² = +1> +1² = +1>> Du bekommst also als Ergebnis-Intervall [+1,+1] heraus.
Exakte Werte (Intervalle mit Länge 0) gibt es in meinem Zahlen-
format nicht. Meine Intervalle um den Nullpunkt sind unsymmetrisch:
+[-1,+2] und -[-1,+2], also [-1,+2] und [-2,+1]
Ich rechne keineswegs so, wie du meinst. Habe es gerade ausprobiert:
+08+000 * +08+000 liefert +01+002 (führende Nullen weggelassen)
+08+000 steht für [-10,+20]*10^0, also für [-1,+2]*10^1
+01+002 steht für [-2,+4]*10^2, und das ist korrekt.
klingt interessant
ich sehe hier (min.) zwei Probleme:
wie du selber schreibt, man kann bei den Startwerten nicht jede
beliebiege Genauikeit vorgeben, sondern nur "deine"
also 0 [-1, -1] gibt es einfach nicht..
braucht man das, hat man schon verloren..
bzw. was wäre die beste Annäherung an diesen Wert in deinem
Zahlenformat??
wie du so die Genauigkeit GARANTIEREN kannst, versteh ich auch nicht,
z.B: bei einer Division durch 3: zusätzich zu deiner "Genauigeitsangabe"
kommt ja der (normale) Fehler hinzu der sich dadurch ergibt, dass man
das Ergebnis in Binär (auch dezimal) nicht 100% genau darstellen kann
das müsste bei deiner Garantierten Genauigkeit miteinbezogen sein,
worduch diese (unnötig?) schlechter wird
dazu kommte dann die Genauigkeitsangabe irgendwie (kompliziert) in die
Mantisse ("Trennzeichen") hineincodiert wird, d.h. das frisst
automatisch Float-Genauikeit (weil weniger BIT für den Float teil übrig
bleiben) was wiederum deine Genauigkeit ändert (ein Teufelskreis?)
die Genauikgeitsangabe (Trennzeichen + 0000) braucht generell extrem
viel Platz, nach mehreren Rechenschritten müsste ja hintern erst mal 20
Nullen kommen, dann dein Trennzeichen, dann erste die Zahl, für die dann
aber immer weniger BIT übrig bleiben??
ICH würde das (vorher) alles auf einen PC simulieren, in JAVA/C# oder
auch C Konsolenprogramm oder Exel, wo du HUMAN READABLE alles genau
ausgeben kannst, damit man sich auch auskennt, nicht wie in run.png...
ich würde auch immer mit Extremwerten Rechnen (PI - 3,1416000) jeweils
in der höchsten genauigkeit, dann damit weiter rechnen usw.
was liefert diese division in deiner aktuellen implementierung?
+08+000 / +08+000
Uhu U. schrieb:> wie du *so* die Genauigkeit GARANTIEREN kannst,
hab ich geschrieben, und nicht
> wie man die Genauigkeit GARANTIEREN kann,
warum ich daran zweifle steht im restlichen Text, den du in deinem Zitat
ignoriert hast..
Robert L. schrieb:> wo du HUMAN READABLE alles genau ausgeben
Das Konzept ist dem Threadstarter nicht vermittelbar, bzw. er hat sehr
andere Vorstellungen davon, was das sein könnte. Manche erinnern sich
mit Grausen an den "Hexadezimalzeichensatz" und die Argumentation
drumheru,.
Robert L. schrieb:> zusätzich zu deiner "Genauigeitsangabe"> kommt ja der (normale) Fehler hinzu der sich dadurch ergibt, dass man> das Ergebnis in Binär (auch dezimal) nicht 100% genau darstellen kann
Versteh ich nicht, wie du das meinst. Die Umwandlung der gespeicherten
Binärzahl in einen Hex-String, wie von mir vorgeschlagen, ist ohne
Genauigkeits-Verlust, ebenso die umgekehrte Konvertierung vom
Hex-String in die gespeicherte Binärzahl.
> die Genauikgeitsangabe (Trennzeichen + 0000) braucht generell extrem> viel Platz,
Die Genauigkeitsangabe braucht in der gespeicherten
Binärzahl überhaupt keinen Platz.
Was meinst du mit "Trennzeichen + 0000"?
> was liefert diese division in deiner aktuellen implementierung?>> +08+000 / +08+000
Das ist eine Division Null durch Null und liefert "unbestimmt".
Josef G. schrieb:> Versteh ich nicht, wie du das meinst. Die Umwandlung der gespeicherten> Binärzahl in einen Hex-String, wie von mir vorgeschlagen, ist ohne> Genauigkeits-Verlust, ebenso die umgekehrte Konvertierung vom> Hex-String in die gespeicherte Binärzahl.
Nachdem du mit deinem Hex-System-für-Jedermann/frau auf die Schnauze
gefallen bist, ist es natürlich höchst clever, jetzt genau darauf
aufzubauen.
Da kann sich die Hausfrau glücklich schätzen, dass sie für den
Einkaufszettel keine Intervallarithmetik braucht und falls doch einmal,
kann sie auf das bewährte Pascal-SC von Kulisch zurück greifen - das mit
BCD-Floats implementiert ist und deswegen die Benutzer nicht mit solchem
Unsinn plagt...
Josef G. schrieb:> Versteh ich nicht, wie du das meinst. Die Umwandlung der gespeicherten> Binärzahl in einen Hex-String, wie von mir vorgeschlagen, ist ohne> Genauigkeits-Verlust, ebenso die umgekehrte Konvertierung vom> Hex-String in die gespeicherte Binärzahl.>
man kann binär nach hex wandeln, ohne verluste? na was für Erkenntnis
du kannst "1/3" also 0,333.. NICHT nach binär wandeln, ohne "verluste",
DAS hab ich gemeint,
>>> Was meinst du mit "Trennzeichen + 0000"?
sorry "Terminierungszeichen"
"Die letzte 1 der Mantisse ist das Terminierungszeichen,"
> Die Genauigkeitsangabe braucht in der gespeicherten> Binärzahl überhaupt keinen Platz.
doch: "Die ungültigen 2 Bit werden entfernt"
du brauchst ein Terminierungszeichen und 2 "ungültige Bit" zum speichern
der Genauikgeit.. und natürlich ist das "Platz" der dir von den 8Byte
dann fehlt..
Robert L. schrieb:> zusätzich zu deiner "Genauigeitsangabe"> kommt ja der (normale) Fehler hinzuRobert L. schrieb:> du kannst "1/3" also 0,333.. NICHT nach binär wandeln, ohne "verluste",
Rundungsfehler bei Division durch 3 sind in dem von mir
verwendeten Fehler-Intervall enthalten. Deshalb verstehe
ich nicht, was du mit "zusätzlich" meinst.
>> Die Genauigkeitsangabe braucht in der gespeicherten>> Binärzahl überhaupt keinen Platz.>> doch: "Die ungültigen 2 Bit werden entfernt">> du brauchst ein Terminierungszeichen und 2 "ungültige Bit" zum speichern> der Genauikgeit.. und natürlich ist das "Platz" der dir von den 8Byte> dann fehlt..
Nein. Das Terminierungszeichen und die ungültigen 2 Bit stehen nicht
in den gespeicherten 8 Byte, sondern lediglich im Hex-String,
und der wird normalerweise nicht gespeichert.
ok, ist mir jetzt dann doch zu blöd, ich hab mich echt bemüht es zu
verstehen, aber wenn du es nicht schaffst, das in verständlich zu
Präsentieren, dann .. sch.. der Hund drauf..
Würde man im Hex-String den Exponenten zu Basis 2 angeben,
wäre wie in der gespeicherten Binärzahl auch im Hex-String
Fehler-Intervall = [-1,+2]*(Wertigkeit des letzten Bits),
und man hätte nicht das Problem der Sonderbehandlung der
letzten Ziffer der Mantisse. Nachteil wäre aber, dass zB.
bei Verschlechterung der Genauigkeit um 1 Bit (Erhöhen des
Exponenten um 1 und gleichzeitiges Shiften der Mantisse um
1 Bit nach rechts) die Ziffern der Mantisse sich ändern
würden und die Zahl nicht wiederzuerkennen wäre.
Gibt man im Hex-String den Exponenten zur Basis 10 an
(mit 10 ist natürlich die hexadezimale 10 gemeint),
ergibt sich zwangsläufig das Problem, dass die Zahl der
gültigen Bits in der letzten Ziffer variabel ist. Man
könnte die Zahl der gültigen Bits der letzten Ziffer
in einer zusätzlichen Ziffer angeben, was aber den
String mindestens um 1 Zeichen verlängern würde.
Deshalb habe ich die Festlegung eingeführt, wonach die
letzte Ziffer nicht null sein darf und die letzte 1 der
letzten Ziffer als Begrenzungsmarke dient. Die Zahl 0..3
der gültigen Bits ist daraus ersichtlich.
Das Fehler-Intervall
[-1,+2]*(Wertigkeit des letzten gültigen Bits)
kann man auch schreiben als
[-2,+4]*(Wertigkeit der Begrenzungsmarke)
Um das Zahlen-Intervall zu erhalten, für welches der Hex-String
steht, hat man in der Mantisse die Begrenzungsmarke zu entfernen
und das Fehler-Intervall zu addieren. Man erhält dasselbe, wenn
man die Begrenzungsmarke stehenlässt und folgendes addiert:
[-3,+3]*(Wertigkeit der Begrenzungsmarke)
Man kann den Hex-String also so interpretieren, dass man die
letzte Ziffer als gewöhnliche Ziffer liest so wie sie dasteht,
und sich ein symmetrisches Fehler-Intervall hinzudenkt, wobei
die Intervallgrenzen folgender Tabelle zu entnehmen sind:
1
1/3 2/6 3/3 4/C 5/3 6/6 7/3 8/18
2
9/3 A/6 B/3 C/C D/3 E/6 F/3
Wenn die letzte Ziffer 1 ist, ist der Fehler [-3,+3]
Wenn die letzte Ziffer 2 ist, ist der Fehler [-6,+6]
usw.
+6A452+003 steht also für +6A452*10^3 +/- 6*10^3
Noch ein Versuch, die Umrechnung zwischen Binärzahl und
Hex-String zu beschreiben, diesmal in umgekehrter Richtung
Gegeben seien die 8 Byte der Binärzahl, mit Mantisse M
und Exponent e, sie stehen für [M-1,M+2]*2^(e-1fff).
e lässt sich schreiben als 4*k+r mit r = 0..3
Wegen e = 0000..3fff gilt k = 000..fff
Damit e-1fff = 4*k+r-4*800+1 = (r+1)+4*(k-800)
Also 2^(e-1fff) = 2^(r+1)*10^(k-800)
Also M * 2^(e-1fff) = tM * 10^(k-800)
mit tM = M*2^(r+1)
tM erhält man durch Shiften von M um r+1 Bits nach links.
k-800 ist der Exponent zur Basis 10 im Bereich -800..+7ff
Man muss nur noch tM (unsigned integer) und k-800
(signed integer) in Hex-Strings umwandeln.
Uhu U. schrieb:> Nachdem du mit deinem Hex-System-für-Jedermann/frau auf die Schnauze> gefallen bist, ist es natürlich höchst clever, jetzt genau darauf> aufzubauen.
Er ist doch damit nicht auf die Schnauze gefallen. Wir haben nur noch
nicht begriffen, wie genial das ist, und dass wir das unbedingt
brauchen... ;-)
>Hex-String
interessiert (so) niemanden
wie das in den 8Byte im Speicher abgelegt ist, ist wichtig
wie die Zahlen (Operanden und Ergebnis) (jeweils das "intervall")
FIXFERTIG (vorzugsweise dezimal, zur not auch hex) ausschaut..
(obere/untere grenze fixfertig ausgerechnet) muss hin
(zwischendurch dann plötzlich eine "Tabelle mit Intervallgrenzen"
hervorzaubern, ist eine Frechheit, mehr nicht... zeigt maximal wie
Betriebsblind du bist.:)
Robert L. schrieb:> wie das in den 8Byte im Speicher abgelegt ist, ist wichtig
Steht bereits im Eröffnungsbeitrag:
Josef G. schrieb:> Die ersten 2 Byte bestehen aus einer 1 am Anfang, 14 Bit für den> Exponten e, und aus dem Vorzeichen S. Die restlichen 6 Byte sind> die vorzeichenlose Mantisse M.Robert L. schrieb:> wie die Zahlen (Operanden und Ergebnis) (jeweils das "intervall")> FIXFERTIG (vorzugsweise dezimal, zur not auch hex) ausschaut..> (obere/untere grenze fixfertig ausgerechnet) muss hin
????
> zwischendurch dann plötzlich eine "Tabelle mit Intervallgrenzen"> hervorzaubern,
Wie die Werte in der Tabelle zustandekommen, ergibt
sich aus meinem Beitrag, jeder kann es nachrechnen.
Robert L. schrieb:> aus dem RUN.PNG alle "Zahlen" in Dezimalschreibweise> schaffst du das?
Wenn jemand unbedingt das dämliche Dezimalsystem verwenden
will, dann muss er diese umständliche Arbeit schon selber
erledigen. Ich werde ihm diese Mühe nicht abnehmen.
Josef G. schrieb:> Robert L. schrieb:>> aus dem RUN.PNG alle "Zahlen" in Dezimalschreibweise>> schaffst du das?>> Wenn jemand unbedingt das dämliche Dezimalsystem verwenden> will, dann muss er diese umständliche Arbeit schon selber> erledigen. Ich werde ihm diese Mühe nicht abnehmen.
Witzbold. Mach doch wenigsten mal von einer Zahl die Umrechnung in
Dezimalschreibweise.
Das Hexsystem ist nur eine Darstellung. Und dem Dezimalen gleichwertig.
Gerechnet wird da noch gar nichts. Es gibt auch noch das Oktalsystem,
fuer Leute, die keine Buchstaben unter die Zahlen mischen wollen. Und
fuer Leute mit 17 Fingern waere allenfalls ein Siebzehnersystem
sinnvoll.
Also trenn mal Darstellung von den anderen Konzepten. Zeig, was, und wie
ein Limitsystem leistet, was du ihm zuschreibst.
Die PNGs sind schrecklich. Erinnern mich an fruehesten ASM, wo alles
maximal kryptisch war, wo man auch kein Papier und keine Drucker hatte
Ich konnte frueher im Hex System rechnen. Adressoffsets zusammengezaehlt
und so. Ein ASM war damals viel zu teuer.
A. K. schrieb:> Du solltest deinen Vorschlag dort einbringen.
Meine Vorstellung über die Verbreitung des hexadezimalen Ziffernsatzes
und des hier vorgeschlagenen Zahlenformats zur Intervall-Arithmetik
ist eher, zunächst einige Hobbyisten als Mitstreiter zu gewinnen.
https://de.wikipedia.org/wiki/Graswurzelbewegung
Josef G. schrieb:> Meine Vorstellung über die Verbreitung des hexadezimalen Ziffernsatzes> und des hier vorgeschlagenen Zahlenformats zur Intervall-Arithmetik> ist eher, zunächst einige Hobbyisten als Mitstreiter zu gewinnen.
Wieviele Mitstreiter hast Du schon gewonnen?
@ Frank M. (ukw) Benutzerseite
>> ist eher, zunächst einige Hobbyisten als Mitstreiter zu gewinnen.>Wieviele Mitstreiter hast Du schon gewonnen?
Gekauft!
Beitrag "Tester gesucht für FPGA-Projekt"
Und es gab sogar Wahnsinnige, die das gemacht haben!
Falk B. schrieb:> Und es gab sogar Wahnsinnige, die das gemacht haben!
Naja, für 100 EUR Cash... würde sich so mancher als wahnsinnig
bezeichnen lassen. ;-)
@Frank M. (ukw) Benutzerseite
>> Und es gab sogar Wahnsinnige, die das gemacht haben!>Naja, für 100 EUR Cash... würde sich so mancher als wahnsinnig>bezeichnen lassen. ;-)
Ich würde lieber 1 Monat Lochkarten stanzen als mir diesen Müll auch nur
eine Minute anzutun!
> https://de.wikipedia.org/wiki/Intervallarithmetik
Quote :
Allerdings entspricht das Ergebnis immer einer Worst Case-Analyse für
gleichverteilte Fehler, andere Wahrscheinlichkeitsverteilungen sind
nicht möglich.
Ueberzeugt leider nicht. Flupp ... in die Tonne.
Falk B. schrieb:> Ich würde lieber 1 Monat Lochkarten stanzen als mir diesen Müll auch nur> eine Minute anzutun!
Das kann ich absolut nachfühlen.
Hier:
Beitrag "Re: Tester gesucht für FPGA-Projekt"
hat er nochmal auf 300 EUR erhöht. Aber auch dafür würde ich es nicht
machen.
Bei 30000 würde ich jedoch ins Grübeln kommen... ;-)
Josef G. schrieb:> Meine Vorstellung über die Verbreitung des hexadezimalen Ziffernsatzes> und des hier vorgeschlagenen Zahlenformats zur Intervall-Arithmetik> ist eher, zunächst einige Hobbyisten als Mitstreiter zu gewinnen.> https://de.wikipedia.org/wiki/Graswurzelbewegung
Du solltest in das Statut dieser Hobbyistengruppe einen Punkt
1
Die Mitglieder geloben, sich täglich mindestens 30 Minuten mit einer
2
Neunschwänzigen Katze selbst zu kasteien.
3
4
Das härtet für mindestens 36 Stunden so stark ab, dass es das Mitglied als
5
Wohltat empfindet, mit Fließkommazahlen im Hex-Format arbeiten zu dürfen.
aufnehmen. Damit wirst du sicherlich von Interessenten überrannt
werden...
@Frank M. (ukw) Benutzerseite
>Bei 30000 würde ich jedoch ins Grübeln kommen... ;-)
Für kein Geld der Welt! Ich bin nicht käuflich, schon gar nicht für
Schwachsinn!
Jetzt N. schrieb:> Das Hexsystem ist nur eine Darstellung. Und dem Dezimalen> gleichwertig. Gerechnet wird da noch gar nichts.> ...> Also trenn mal Darstellung von den anderen Konzepten. Zeig,> was, und wie ein Limitsystem leistet, was du ihm zuschreibst.
Das kann man nicht trennen, die hexadezimale Darstellung ist
wesentlich, weil bei dezimaler Darstellung die Rundungsfehler der
Umwandlung dazukommen und die Einfachheit des Konzepts zerstören.
Es wird bei Hex gerundet, und es wird bei Dezimal gerundet. Da ist kein
Unterschied.
Einfach eine teilerfremde Zahl verwenden. zB (beide Dez und Hex) durch
3.
Entweder floatstellen nachschieben bis dir die Lust vergeht oder gleich
runden.
Rechnen wir doch ein einfaches Beispiel. Ein spannungsteiler mit einem
NTC.
Rfix + NTC R(T)
R(T) = R0 * Exp( B *(1/T - 1/T0))
nun hat
das B eine toleranz von 1%,
R0 hat auch 1%
und Rfix hat auch einen fehler von 1%.
Welchen Fehler hat das Ergebnis und welches sind die Beitraege.
Jetzt N. schrieb:> Es wird bei Hex gerundet, und es wird bei Dezimal gerundet.> Da ist kein Unterschied.
Beim Rechnen mit Binärzahlen wird gerundet.
Beim Anzeigen des Ergebnisses wird nochmal gerundet,
falls man das Dezimalsystem verwendet.
Diese nochmalige Rundung entfällt, wenn man
das Hexadezimalsystem verwendet.
Entsprechendes gilt bei der Eingabe.
In meiner Welt nimmt man soviele signifikante Stellen wie man eben
benoetigt. Die Rechnung darf zu Beginn auch genauer sein wie das
Ergebnis.
Weshalb soll ich mir ein anderes Zahlensystem aneignen.
Josef G. schrieb:> Diese nochmalige Rundung entfällt, wenn man> das Hexadezimalsystem verwendet.
Die Rundung entfällt auch, wenn man gleich im BCD-Format rechnet - die
Wandlung in Dezimalzahlen ist dann Rundungsfehlerfrei.
Aber das ist natürlich nichts für echte Masochisten...
Josef G. schrieb:> Ich denke eher, das BCD-Format ist etwas für Masochisten.
Nö. Für BWLer. Damit am Ende des Tages keine Mahnung für 1ct rausgeht,
bloss weil irgendwo die Summe aus 10ct-Stücken nicht aufging.
das Problem ist nicht "DIE" Hex-Darstellung ansich, sondern DEINE (vom
Josef G) Hex-Darstellung
DORT ist ja irgendwie komisch in EINER Zahl AUCH die "Genauikeit"
versteckt..
DAS müsstest du einfach nur "ausrechnen" und ALS INFO (von miraus auch
in HEX) jeweils dazuschreiben... (also die obere und untere Grenze als
separate werte, oder mit +/- wenn es symetrisch wäre..)
das muss aber der PC machen, und nicht ich als Mensch bei JEDER zahl..
im Anhang mal die Addition, wie aber da jetzt die "genauigkeit" Verloren
geht, also mit welchem konzept versteh ich wie gesagt nicht..
@A. K. (prx)
>Nö. Für BWLer. Damit am Ende des Tages keine Mahnung für 1ct rausgeht,>bloss weil irgendwo die Summe aus 10ct-Stücken nicht aufging.
Dafür brauche ich keine BDC, es reichen stinknormale Integer, wenn es
sein muss 64 Bit mit Auflösung zu 1 Millicent, für die
Prozentrechnungen. Der Rundungsfehler geht dann in die Kaffeekasse (oder
an die Bank, welche bekanntlich immer gewinnt).
Robert L. schrieb:> DORT ist ja irgendwie komisch in EINER Zahl AUCH die "Genauikeit"> versteckt..>> DAS müsstest du einfach nur "ausrechnen" und ALS INFO (von miraus auch> in HEX) jeweils dazuschreiben... (also die obere und untere Grenze als> separate werte, oder mit +/- wenn es symetrisch wäre..)>> das muss aber der PC machen, und nicht ich als Mensch bei JEDER zahl..
Man könnte das alles dazuschreiben, das würde aber den String deutlich
verlängern und wäre hochgradig redundant. Genau deshalb habe ich diese
Konvention bezüglich der letzten Ziffer vorgeschlagen. Und die ist
nicht so kompliziert, wie sie auf den ersten Blick aussieht.
Josef G. schrieb:> Man kann den Hex-String also so interpretieren, dass man die> letzte Ziffer als gewöhnliche Ziffer liest so wie sie dasteht,> und sich ein symmetrisches Fehler-Intervall hinzudenkt, wobei> die Intervallgrenzen folgender Tabelle zu entnehmen sind:
Man müsste in der Tat die Tabelle einfach auswendiglernen.
Man würde dann beim Blick auf die letzte Ziffer ohne
Nachzudenken das Fehlerintervall erkennen.
Wolfgang R. schrieb:> Ich verstehe den Sinn des Ganzen nicht.Josef G. schrieb:> Vorteil gegenüber dem üblichen Rechnen mit Gleitpunkt-Zahlen:> Die Buchführung über die Auswirkungen von Rundungsfehlern> macht der Rechner selber. Der Anwender muss sich nicht> ständig darüber Gedanken machen.>> Vorteil gegenüber der Verwendung von zwei unabhängigen> Zahlen für Unter- und Ober-Grenze: Weniger Speicherplatz.> Und man muss nur eine einzige Zahl eingeben/ausgeben.
Josef G. schrieb:> Robert L. schrieb:> Man könnte das alles dazuschreiben, das würde aber den String deutlich> verlängern und wäre hochgradig redundant. Genau deshalb habe ich diese> Konvention bezüglich der letzten Ziffer vorgeschlagen. Und die ist> nicht so kompliziert, wie sie auf den ersten Blick aussieht.
nur für UNS DEPPEN, damit wir es verstehen
auf einem Monitor mit 0xF00 Pixel breite wäre das auch verkraftbar, wenn
mal was doppelt ist ;-)
Josef G. schrieb:> Nachteil gegenüber der Verwendung von zwei unabhängigen> Zahlen für Unter- und Ober-Grenze: Die Fehler-Intervalle> wachsen bei längeren Rechnungen schneller an.
"Schneller" heißt – wenn ich das richtig verstanden habe – "extrem viel
schneller". Ich möchte das anhand der Addition von mehreren Zahlenwerten
mit Fehlerintervall verdeutlichen:
In der klassischen Intervalarithmetik ist bei der Addition zweier Zahlen
die Intervallbreite des Ergebnisses die Summe der Intervallbreiten der
beiden Summanden und damit größer als das Maximum der Intervallbreiten
der beiden Summanden. Um das Ergebnis in deinem Format darstellen zu
können, muss die Intervallbreite des Ergebnisses auf die nächstgrößere
Zahl der Form 3·2^i aufgerundet werden. Damit ist die Intervallbreite
des Ergebnisses doppelt so groß wie die größere der Intervallbreiten der
beiden Summanden.
Das ist dann akzeptabel, wenn nur zwei Zahlen mit ähnlich großen
Fehlerintervallen addiert werden sollen.
Bei der Addition von n Zahlen hingegen wächst die Intervallbreite in
jedem Schritt mindestens um den Faktor zwei. Die Intervallbreite des
Gesamtergebnisses beträgt damit mindestens das 2^(n-1)-fache der
Intervallbreite des ersten Summanden. Deswegen ist schon nach relativ
wenigen Additionsschritten die Intervallbreite des Ergebnisses so
riesig, dass dieses unbrauchbar wird.
Während bei der klassischen Darstellung (je ein Zahlenwert für Unter-
und Obergrenze) die Intervallbreite der Summe aus n Werten mit linear
mit n wächst, wächst sie mit deiner Darstellung exponentiell. Bei
anderen Operationen (Multiplikation, Division usw.) sieht das Ganze
nicht besser aus.
Ein weiterer gravierender Nachteil deiner Darstellung liegt darin, dass
damit keine Intervalle dargestellt werden können, bei denen die beiden
Grenzen unterschiedliche Vorzeichen haben.
Yalu X. schrieb:> "Schneller" heißt – wenn ich das richtig verstanden habe
Addition von 16(dez) Zahlen, jede habe Fehlerintervall 3
15(dez) Additionen ==> Fehlerintervall 3*2^15
Alternative Additionsreihenfolge: Binärbaum
erste Schicht liefert 8 Zahlen mit Fehlerintervall 3*2
zweite Schicht liefert 4 Zahlen mit Fehlerintervall 3*2^2
dritte Schicht liefert 2 Zahlen mit Fehlerintervall 3*2^3
vierte Schicht liefert Ergebnis mit Fehlerintervall 3*2^4
Tatsächlich ist der Fehler allerdings größer, weil bei
Addition von Zahlen mit gleichen Exponenten in der Hälfte der
Fälle sogar 2 Bitstellen verloren gehen. Nur bei verschiedenen
Exponenten ist der Fehler des Ergebnisses in jedem Fall das
2-fache des Maximums der Fehler beider Summanden.
In meinem ersten Beitrag zu diesem Thema hatte ich geschrieben:
Beitrag "Re: 8bit-Computing mit FPGA"> Bei dem vorgeschlagenen Zahlenformat ist die Größe des Fehler-> Intervalls stets gleich 3 mal eine Zweierpotenz. Wenn sich bei> Rechenoperationen eine kleine Vergrößerung des Fehlerintervalls> ergäbe, führt dies im Rahmen des Zahlenformats gleich zu einer> Verdopplung des Fehlerintervalls. Um das zu vermeiden, wird man> für Zwischenrechnungen zusätzlich ein "internes" Zahlenformat> einführen, bei welchem wie in der üblichen Intervall-Arithmetik> untere und obere Grenze als zwei unabhängige Zahlen behandelt> werden. Nach Abschluss der Zwischenrechnungen wird das Ergebnis> dann in das vorgeschlagene Format konvertiert und abgespeichert,> wobei die dann auftretende Verschlechterung des Fehlerintervalls> entsprechend seltener vorkommt.Yalu X. schrieb:> Ein weiterer gravierender Nachteil deiner Darstellung
In meinem Zahlenformat haben die Zahlen mit Mantisse Null
verschiedene Vorzeichen der Intervallgrenzen: Es gibt
eine positive Null und eine negative Null
[-1,+2]*2^k und [-2,+1]*2^k
Mag sein, dass wegen des zu schnellen Anwachsens des Fehlers
mein Zahlenformat für numerische Mathematik unbrauchbar ist.
Dann muss ich mich halt geschlagen geben.
Josef G. schrieb:> Alternative Additionsreihenfolge: Binärbaum
Ja, dadurch kann man das Problem im Beispiel der Addition von n Zahlen
deutlich entschärfen. Auf der anderen Seite heißt das aber, dass man als
Programmierer die Terme immer passend zu deiner Zahlendarstellung
umstellen muss, was vor allem bei einer variablen Anzahl von Operanden
nicht ganz leicht ist.
So wird bspw. die Berechnung der Summe der Elemente eines Arrays, die
man normalerweise mit einer einfachen Schleife erschlägt, zu einer
nichttrivialen Aufgabe. Am einfachsten geht das mit einer rekursiven
Funktion, die aber die Gefahr von Stacküberläufen mit sich bringt.
Eine nichtrekursive Lösung erfordert aber das Verwalten eines eigenen
Stacks für die Zwischenergebnisses, was die Sache wieder ein ganzes
Stück komplizierter macht.
Sobald man es aber mit gemischten Termen (Additionen, Multiplikationen
und Divisionen) zu tun hat, führt i.Allg. auch die Termumstellung nicht
mehr zum Ziel.
Josef G. schrieb:> Mag sein, dass wegen des zu schnellen Anwachsens des Fehlers> mein Zahlenformat für numerische Mathematik unbrauchbar ist.> Dann muss ich mich halt geschlagen geben.
So sieht es wohl aus.
Kleine Ergänzung, falls jemand diesen alten Thread findet:
Wenn man Intervall-Arithmetik mit getrennten Werten für untere
und obere Schranke betreibt, dann wird man trotzdem gerne bei
Eingabe und Ausgabe nur einen Wert angeben wollen. Und für
diesen Zweck mag das vorgeschlagene Zahlenformat sinnvoll
sein, auch wenn es zum Rechnen nicht geeignet ist.
Thread beobachten
Seitenaufteilung abschalten