Forum: Offtopic Ein Vorschlag zur Intervall-Arithmetik


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Josef G. (bome) Benutzerseite


Angehängte Dateien:

Lesenswert?

1
*PGM ARITH
2
*CON INFO -3:ADD..2:SUB..1:MUL..0:DIV..else:END
3
     MASK -3210:....OPA:....................OPB:
4
*AUT AA. /07  BB. /07  SELECT /00  TEST /00
5
*BEGN
6
*L.JP
7
  1INPUTF /D1 AA.  1INPUTF /E9 BB.  1LFEED
8
  *CASE /03 SELECT
9
    1 oGT8 AA. oADF BB. oST8 AA. oSBF BB. oST8 BB.
10
  *NEXT /02
11
    1 oGT8 AA. oSBF BB. oST8 AA. oADF BB. oST8 BB.
12
  *NEXT /01
13
    1 oGT8 AA. oMUF BB. oST8 AA. oDIF BB. oST8 BB.
14
  *NEXT /00
15
    1 oGT8 AA. oDIF BB. oST8 AA. oMUF BB. oST8 BB.
16
  *LAST
17
  1PRINTF /D1 AA.   1PRINTF /E9 BB.
18
*HERE
19
  1LFEED    1PRINTS /C4 INFO    1LFEED
20
  1PRINTS /C4 MASK  1INPUTN /C9 SELECT
21
  1 oGET SELECT   oAND /FC   oSTO TEST
22
*RP.Z TEST
23
*RETN

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.

von Robert L. (lrlr)


Lesenswert?

die Begründung fehlt
oder kommt die noch?





muss jetzt weg, Microwellenpopkorn kaufen..

von Uhu U. (uhu)


Lesenswert?

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?

von Pandur S. (jetztnicht)


Lesenswert?

> Ein Vorschlag zur Intervall-Arithmetik ..

Heiaaaa.... und der Vorteil ? Genauigkeit, Geschwindigkeit ?
Nachteile ?

von Falk B. (falk)


Lesenswert?

Salvador Dali als reinkarnierter E-Ing?

https://de.wikipedia.org/wiki/Salvador_Dal%C3%AD

https://de.wikipedia.org/wiki/Surrealismus

Wobei hier doch eher starke Parallelen zum Dadaismus vorliegen.

https://de.wikipedia.org/wiki/Dadaismus

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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. ;-)

von (prx) A. K. (prx)


Lesenswert?

Falk B. schrieb:
> Wobei hier doch eher starke Parallelen zum Dadaismus vorliegen.

Eher dazu:
Beitrag "8bit-Computing mit FPGA"
Beitrag "Gibt es eine Programmiersprache mit diesem Schleifentyp?"

von Falk B. (falk)


Lesenswert?

@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?"

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

DA DA DA , ah, ah, DA, DA, DA

https://www.youtube.com/watch?v=VwdW989_NGM

von Uhu U. (uhu)


Lesenswert?

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...

von 🍅🍅 🍅. (tomate)


Lesenswert?

https://www.youtube.com/watch?v=e_mPrhwpZ-8
Jetzt fehlt noch der olle Bindel, dann kanns losgehen

von Robert L. (lrlr)


Lesenswert?

@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?

von Paul B. (paul_baumann)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von Dumdi D. (dumdidum)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Josef G. (bome) Benutzerseite


Lesenswert?

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)

von Josef G. (bome) Benutzerseite


Lesenswert?

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".

von Pandur S. (jetztnicht)


Lesenswert?

Ich bevorzuge eigentlich eher eine Fehlerrechnung, wenn mich denn die 
Genauigkeit interessiert. Und dann muessen die Eingangwerte auch noch 
die passende Genauigkeit besitzen.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Uhu U. (uhu)


Lesenswert?

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?

von Uhu U. (uhu)


Lesenswert?

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?

von Dumdi D. (dumdidum)


Lesenswert?

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?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Dumdi D. (dumdidum)


Lesenswert?

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?

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Robert L. (lrlr)


Lesenswert?

@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 ;-)

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Dumdi D. (dumdidum)


Lesenswert?

MAch doch mal 1,2 explizite Beispiele.

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Dumdi D. (dumdidum)


Lesenswert?

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?

von G. C. (_agp_)


Lesenswert?

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!

;-)

von Josef G. (bome) Benutzerseite


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Dumdi D. (dumdidum)


Lesenswert?

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?

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Robert L. (lrlr)


Lesenswert?

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

: Bearbeitet durch User
von Uhu U. (uhu)


Lesenswert?

Robert L. schrieb:
> wie du so die Genauigkeit GARANTIEREN kannst,

Das ist schon ein ziemlich alter Hut. Einen Überblick erhält man hier: 
http://www.spektrum.de/magazin/rechnen-mit-garantierter-genauigkeit/826769

von Robert L. (lrlr)


Lesenswert?

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..

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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,.

von Josef G. (bome) Benutzerseite


Lesenswert?

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".

von Uhu U. (uhu)


Lesenswert?

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...

: Bearbeitet durch User
von Robert L. (lrlr)


Lesenswert?

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..

: Bearbeitet durch User
von Josef G. (bome) Benutzerseite


Lesenswert?

Robert L. schrieb:
> zusätzich zu deiner "Genauigeitsangabe"
> kommt ja der (normale) Fehler hinzu

Robert 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.

von Robert L. (lrlr)


Lesenswert?

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..

von Josef G. (bome) Benutzerseite


Lesenswert?

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

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Da D. (dieter)


Lesenswert?

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... ;-)

: Bearbeitet durch User
von Robert L. (lrlr)


Lesenswert?

>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.:)

: Bearbeitet durch User
von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Robert L. (lrlr)


Lesenswert?

>????

aus dem RUN.PNG alle "Zahlen" in Dezimalschreibweise
schaffst du das?

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Dumdi D. (dumdidum)


Lesenswert?

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.

von Josef G. (bome) Benutzerseite


Lesenswert?

Dumdi D. schrieb:
> Witzbold.

Mein Beitrag war ernst gemeint.

von Uhu U. (uhu)


Lesenswert?

Josef G. schrieb:
> Dumdi D. schrieb:
>> Witzbold.
>
> Mein Beitrag war ernst gemeint.

Das glaub ich dir gerne...

von Josef G. (bome) Benutzerseite


Lesenswert?

Nur für den Fall, dass es jemand hier noch nicht kennt:
http://www.bomerenzprojekt.de/Website/Hexadezimalsystem.html

von Falk B. (falk)


Lesenswert?

@Josef G. (bome) Benutzerseite

>Nur für den Fall, dass es jemand hier noch nicht kennt:

Was für eine Wissenslücke!

>http://www.bomerenzprojekt.de/Website/Hexadezimalsystem.html

Und täglich grüßt das Murmeltier . . .

: Bearbeitet durch User
von Pandur S. (jetztnicht)


Lesenswert?

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.

: Bearbeitet durch User
von Uhu U. (uhu)


Lesenswert?

Jetzt N. schrieb:
> Also trenn mal Darstellung von den anderen Konzepten. Zeig, was, und wie
> ein Limitsystem leistet, was du ihm zuschreibst.

https://de.wikipedia.org/wiki/Intervallarithmetik

von (prx) A. K. (prx)


Lesenswert?

Josef G. schrieb:
> Als Alternative schlage ich folgendes 8-Byte-Zahlenformat vor:

Du solltest deinen Vorschlag dort einbringen. Wenn die es erst einmal 
falsch gemacht haben, dann ist der Zug abgefahren:
http://standards.ieee.org/develop/project/1788.1.html

von Josef G. (bome) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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?

von Falk B. (falk)


Lesenswert?

@ 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!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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. ;-)

von Falk B. (falk)


Lesenswert?

@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!

von Pandur S. (jetztnicht)


Lesenswert?

> 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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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... ;-)

von Uhu U. (uhu)


Lesenswert?

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...

von Falk B. (falk)


Lesenswert?

@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!

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Pandur S. (jetztnicht)


Lesenswert?

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.

von Pandur S. (jetztnicht)


Lesenswert?

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.

: Bearbeitet durch User
von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Pandur S. (jetztnicht)


Lesenswert?

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.

: Bearbeitet durch User
von Uhu U. (uhu)


Lesenswert?

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...

von Josef G. (bome) Benutzerseite


Lesenswert?

Uhu U. schrieb:
> Aber das ist natürlich nichts für echte Masochisten...

Ich denke eher, das BCD-Format ist etwas für Masochisten.

von (prx) A. K. (prx)


Lesenswert?

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.

von Robert L. (lrlr)


Angehängte Dateien:

Lesenswert?

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..

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

Ich verstehe den Sinn des Ganzen nicht.

von Falk B. (falk)


Lesenswert?

@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).

von Falk B. (falk)


Lesenswert?


von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Robert L. (lrlr)


Lesenswert?

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 ;-)

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Josef G. (bome) Benutzerseite


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.