Bei den Floatingpoint-Librarys sind zwei Formate gängig. Das eine ist das IEEE-754-Format, das andere ist das Fast-Floating-Point-Format.

Die unterscheiden sich darin, dass beim IEEE-754-Format das "linkste" Bit das Vorzeichen enthält, und die nächsten 8 Bit die Potenz zur Basis 2.

Beim Fast-Floating-Point-Format enthalten die ersten acht Bit die Potenz zur Basis 2 und erst das Bit danach das Vorzeichen. Dadurch kann man wohl einige Shift-Operationen sparen. Um dieses Format scheint es sich in Deinem Fall zu handeln.

Wenn man eine Fließzahl im Zweiersystem mit Zweier-Potenzen darstellt, erhält man immer als erste und einzige Binärziffer vor dem Komma eine 1.
Und weil das so ist, wird diese 1 nicht mitgespeichert, sondern die ganze Binär-Mantisse um eins nach links verschoben, sodass am Ende der Mantisse noch ein Bit spendiert werden kann.

Zudem wird nicht zum Wert 1 der Exponent mit 0 gespeichert, sondern zum Wert 2.

Vielleicht rührt daher Dein Faktor 4 ? Ich weiß ja nicht, wie Du das umrechnest.


[ Diese Nachricht wurde geändert von: Brizz am 12 Dez 2008 21:36 ]

Die Mainframes normalisieren den Exponenten auch nicht jedesmal, sondern nur zur Basis 16.
Da können also auch in der Mantisse schonmal führende Nullen auftauchen. Wer weiss, welches Format hhemetsbergers Rechner verwendet.
Deshalb sagte ich ja schon, dass es vom Prozessor abhängt, und man ohne Kenntnis der Formate mit hoher Wahrscheinlichkeit Gigo produziert.

_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

Danke für die Beiträge. Wie anfangs erwähnt, verwende ich den PIC16F84.

Ich habe mir die Application Note AN575 (IEEE 754 Compliant Floating Point Routines) von Microchip angesehen und dort volle Übereinstimmung mit meinem Floating Point Calculator (Freeware von Andrea Guiotti) gefunden. Die angeführten Beispiele lassen sich völlig korrekt nachvollziehen.

Die AN575 stammt aus dem Jahr 1997 und sagt, dass sie für die gesamte PIC16/17 Familie gültig ist. Damals gab es wohl die F Serie noch nicht, doch andererseits finde ich bei Microchip kein neueres Dokument. Es dürfte also gelten.

Es handelt sich um das Format, das das Sign Bit im MSB von High-Bite (f0) verpackt. Dies wird auch eindeutig im Header der Routinen zum Ausdruck gebracht. Hier ein kurzer Ausschnitt aus dem Programm.

Code :

; 32 bit floating point representation ; EXPONENT 8 bit biased exponent ; It is important to note that the use of biased ; exponents produces a unique representation of a ; floating point 0, given by ; EXP = HIGHBYTE = MIDBYTE = LOWBYTE = 0x00, ; with 0 being the only number with AX = 0. ; HIGHBYTE 8 bit most significant byte of sign-magnitude ; representation, with SIGN = MSB, and implicit ; mantissa MSB = 1 and radix point to the left of MSB ; MIDBYTE 8 bit middle significant byte of sign-magnitude matissa ; LOWBYTE 8 bit least significant byte of sign-magnitude matissa ; ; RADIX ; EXPONENT POINT HIGHBYTE MIDBYTE LOWBYTE ; xxxxxxxx . Sxxxxxxx xxxxxxxx xxxxxxxx EXPBIAS equ H'80' ;

Was mir hinsichtlich des Faktor 4 verdächtig scheint, ist die Instruktion ‚EXPBIAS equ H’80’’, denn die definiert einen Bias für den Exponenten, der schließlich in den diversen im Programm verwendeten FP Routinen benutzt wird.

Es fällt einfach auf, dass der besagte Faktor 4 eine Vergrößerung von EXPONENT um dezimal 2 bedeutet.

Microchip definiert in der AN575 den Bias für das 32-bit Format mit 0x7F. Die Original-Routinen von Microchip enthalten dementsprechend die Instruktion EXPBIAS equ D’127’. Das erklärt allerdings nur ein Delta von 1, nicht jedoch von 2, das einem Faktor 4 entsprechen würde.

Möglicherweise hat der Programmierer (der ja die FP Routinen eingebaut und modifiziert hat), hier einen Trick angewandt, den ich auf Anhieb nicht sehe. Ich glaube, auf der Fährte zu sein, doch ich hab’s noch nicht ganz.


Liebe Grüße, Johann

Zitat :

Die AN575 stammt aus dem Jahr 1997 und sagt, dass sie für die gesamte PIC16/17 Familie gültig ist. Damals gab es wohl die F Serie noch nicht, doch andererseits finde ich bei Microchip kein neueres Dokument. Es dürfte also gelten.

Das wäre auch unwichtig.
Selbst wenn die inzwischen mit einer Dampfmaschine rechneten, müsste genau so gearbeitet werden, wie das IEEE754 definiert. Das ist prozessorunabhängig.
Sonst ist es entweder kein IEEE754 Format, oder falsch. Letzteres ist bei Intel schon vorgekommen. Deren FDIV-Bug hat's sogar bis ins Silizum geschafft.

Zitat :

Was mich verwirrt, ist, dass bei jeder Dateneingabe der Wert mal 4 genommen wird. Beispiel: Im Kommentar steht:

Wo steht dieser Kommentar und das Beispiel denn und wer multipliziert was mit 4 ?

Zitat :

Der ‚Verbreiter’ im Internet (wohlbekannt) kann diesen Faktor 4 auch nicht erklären. Er hat die Routinen ebenfalls einst irgendwo bezogen.

Ich habe keine Lust zu erraten, was du damit meinst.





_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

Perl,

Mir geht es keineswegs um Geheimniskrämerei, sondern ich wollte die Helfenden nicht über Gebühr beanspruchen. Wenn das missverstanden wurde oder das Gegenteil entstand, sorry.

Es handelt sich um den Code für das LC-Meter auf dem Link:

http://www.sprut.de/electronic/pic/projekte/lcmeter/lcmeter.htm

Wie gesagt, das Programm läuft und ich konnte auch meine Änderungen durchführen, weil ich halt alle FP Eingaben mit 4 multipliziert habe. Nur befriedigend war das halt nicht.

Nachdem ich die im Programm inkludierten FP Routinen mit der Originalfassung (erwähnte AN575) verglich und die Abweichung bei der Initialisierung des Bias sah (EXPBIAS equ H’80’), war mein Verdacht, dass der unbekannte Programmierer bewusst Änderungen an den Routinen vorgenommen hat, die eben diesen Faktor 4 bei Parametereingaben erfordern. Nur ganz durchschaut habe ich die Sache nicht. Das ist die Botschaft meines vorigen Beitrags, in andere Worte gefasst.

Nach wie vor würde es mich interessieren, wie dieser ominöse Faktor 4 entsteht, auch wenn ich mit ihm umgehen kann. Danke.

Liebe Grüße, Johann

Das die AN von Microchip nicht immer das Gelbe vom Ei sind, solltest Du wirklich in Betracht ziehen.
Ich habe auch aus einem Bastlerbuch eine Routine für I2C Kommunikation übernommen, das in Microchipunterlagen seinen Ursprung hatte. Fazit war, daß die Routine ein sehr besch-eidenes Bustiming an den Tag legte. Wenn eine Komunikation zu stande kam, dann war das eher zufällig als gewollt.

Schöne Grüße Selfman

_________________
Traue keinem Ding, das du nicht selber vermurkst hast.

Herzlichen Dank an alle, die Beiträge geleistet haben.

@selfman
Danke für diesen abschließenden Beitrag. Ich schließe das Projekt mit der Erkenntnis, dass beschriebener Effekt durch die in dieser (von mir nur kopierten und modifizierten) Software verwendete Version der Microchip Floating Point Routinen verursacht wird. Mag sein, dass die Routinen von einem der ‚Vorprogrammierer’ abgeändert wurden.

Ich habe die aktuellen Microchip Routinen heruntergeladen und in einem kleinen Testprogramm damit experimentiert. Da funktioniert die Dateneingabe ganz normal. Das braucht keinen Faktor 4. Auf einen Einbau der aktuellen Routinen in oben erwähntes Projekt habe ich des Aufwands wegen verzichtet. Dort habe ich einfach alle Eingaben vervierfacht und die Sache funktioniert einwandfrei. Manchmal gibt man sich halt damit zufrieden, nicht alles zu wissen. Eigentlich tut man es immer.

Lg, Johann