Vergleich auf 0

Hi Leute,

auf einer FreeBSD-5.5, mit perl-5.8.8, DBI-1.50, taucht folgendes
Problem auf (schematisch dargestellt):

val: Ergebnis eines ORACLE select, mit 0 bis 6 Dezimalstellen.


my $sum = 0
my $val = 0

sum=0

val=2852.382,

$sum += $val

sum=2852.382

val=-47.74,

$sum += $val

sum=2804.642

val=-2804.642,

$sum += $val
if ($sum == 0)
{
}
>>> sum=4.54747350886464e-13
>>> Die if ($sum == 0) Abfrage geht nicht, da sum nicht 0 ist.
>>> Danach läuft's wieder normal, soweit da irgendwas normal ist :-) ...

val=2753.974,

$sum += $val

sum=2753.974

val=-50.3915,

$sum += $val

sum=2703.5825





Kann mir jemand erklären oder einen Tipp geben,
wie ein so kleiner Wert 4.54747350886464e-13 zustandekommt?
Hängt das mit der Fließkomma Präzision zusammem?
Wie kann man das vermeiden?


Danke für's Lesen und Tipps
Wolf

Re: Vergleich auf 0

Wolf Grossi!

> Hängt das mit der Fließkomma Präzision zusammem?

Ja.

> Wie kann man das vermeiden?

Begrenzt durch Einsatz genauerer Fließkommazahlen.
Ansonsten durch Fixkommaarithmetik.


Gruß
Daniel

Re: Vergleich auf 0

Daniel Fischer wrote:
> Wolf Grossi!
>
>> Hängt das mit der Fließkomma Präzision zusammem?
>
> Ja.
>
>> Wie kann man das vermeiden?
>
> Begrenzt durch Einsatz genauerer Fließkommazahlen.
> Ansonsten durch Fixkommaarithmetik.

Das heißt wohl, daß man das Problem mit
$sum+=sprintf("%.6f", $val);
lösen muß.

Danke,
Wolf

Re: Vergleich auf 0

Wolf Grossi wrote:
> sum=3D2804.642
>
> val=3D-2804.642,
>
> $sum +=3D $val
> if ($sum == 0)
> {
> }
> >>> sum=3D4.54747350886464e-13
> >>> Die if ($sum == 0) Abfrage geht nicht, da sum nicht 0 ist.

Das ist das klassische Fliesskomma Problem, welches nicht nur auf Perl
beschraenkt ist:

Obwohl (von dem Vorzeichen abgesehen) der print-befehl exakt den
gleichen Betrag 2804.642 fuer "num" und "val" anzeigt, ist die interne
Darstellung nicht identisch: In Wirklichkeit zeigt der print-Befehl nur
eine Annaeherung im Dezimalformat eines ansonsten binaer
verschluesselten Bruches an.

Dass die binaer verschluesselten Brueche dann doch nicht identisch sind
kann man (leider) daran merken dass die Differenz nicht Null ist.

Das Problem ist so einfach nicht loesbar, jedoch wird eine Notloesung
(mit der "printf"-Funktion) wird in Perlfaq 4 vorgeschlagen:

C:\>perldoc -q 999

+++++++++++++++++++++++++++++++++++
++ Found in C:\Perl\lib\pod\perlfaq4.pod
++ Why am I getting long decimals (eg, 19.9499999999999) instead
++ of the numbers I should be getting (eg, 19.95)?
++
++ Internally, your computer represents floating-point numbers
++ in binary. Digital (as in powers of two) computers cannot store
++ all numbers exactly. Some real numbers lose precision in the
++ process. This is a problem with how computers store numbers
++ and affects all computer languages, not just Perl.
++
++ perlnumber show the gory details of number representations and
++ conversions.
++
++ To limit the number of decimal places in your numbers, you can
++ use the printf or sprintf function. See the "Floating Point
++ Arithmetic" for more details.
++
++ printf "%.2f", 10/3;
++
++ my $number =3D sprintf "%.2f", 10/3;
+++++++++++++++++++++++++++++++++++

Uebrigens, weiss jemand ob eine Deutsche Uebersetzung der Perl
Documentation schon veroeffentlicht wurde ?

> >>> Danach läuft's wieder normal, soweit da irgendwas normal ist :-) .=
..

Das ist durchaus moeglich, jedoch das heisst nicht dass das selbe
Problem 5 Zeilen spaeter nicht wieder auftritt.

Re: Vergleich auf 0

Wolf Grossi schrieb:

> Daniel Fischer wrote:
> > Wolf Grossi!
> >
> >> Hängt das mit der Fließkomma Präzision zusammem?
> >
> > Ja.
> >
> >> Wie kann man das vermeiden?
> >
> > Begrenzt durch Einsatz genauerer Fließkommazahlen.
> > Ansonsten durch Fixkommaarithmetik.
>
> Das heißt wohl, daß man das Problem mit
> $sum+=3Dsprintf("%.6f", $val);
> lösen muß.

Das Problem löst Du damit sowenig, wie Du Krebs durch Morphium heilst.
Du verdeckst halt nur die Symptome.
Lösen kann man das Problem nur, wenn man die hoffentlich von Oracle
gelieferten Strings nicht als Gleitkommazahlen benutzt. Es gibt
sicherlich CPAN-Module für Decimals. Zur Not tut auch BigInt.

Re: Vergleich auf 0

Klaus:

Obwohl (von dem Vorzeichen abgesehen) der print-befehl exakt den
gleichen Betrag 2804.642 fuer "num" und "val" anzeigt, ist die interne
Darstellung nicht identisch: In Wirklichkeit zeigt der print-Befehl nur
eine Annaeherung im Dezimalformat eines ansonsten

binaer verschluesselten Bruches an.
^^^^^^^^^^^^^^^^^^^^^^^^^^

Was verstehst du darunter? Perl speichert Gleitkommazahlen,
soviel ich weiß, als "double" ab. Was ist hier ein "verschlüsselter
Bruch"?


LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Vergleich auf 0

Wolf Grossi!

>> Begrenzt durch Einsatz genauerer Fließkommazahlen.
>> Ansonsten durch Fixkommaarithmetik.
>
> Das heißt wohl, daß man das Problem mit
> $sum+=sprintf("%.6f", $val);
> lösen muß.

Nein, Fixkommaarithmetik heißt nicht, dass man Fliesskommaarithmetik
betreibt und dann einfach ein paar Stellen abschneidet. Fixkommarechnung
ist *genauer* als Fliesskommarechnung!


Gruß
Daniel

Re: Vergleich auf 0

Mahlzeit!

Ferry Bolhar wrote:

> binaer verschluesselten Bruches an.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Was verstehst du darunter? Perl speichert Gleitkommazahlen,
> soviel ich weiß, als "double" ab. Was ist hier ein "verschlüsselter
> Bruch"?

Der "double".

Die Vorkommastellen sind ganz normal Bits für 1, 2, 4, 8, 16, ...
Die Nachkommastellen sind Bits für 1/2, 1/4, 1/8, 1/16, ...

Zahlen wie 0.75 lassen sich prima darstellen (0.75 == 1/2+1/4, also im
einfachsten Fall _binär_ _verschlüsselt_ "Null Komma Eins Eins"), aber
bei 1/3 ergeben sich halt die gleichen Probleme bei der binären
Darstellung wie bei der Darstellung im Dezimalsystem (0.333333[...]).

Gruß,
Christian
--
sub _{print"\n"}_;for(;$s<9;++$s){$_='1E2018201E00001E2018201E00001E2018201'
..'E002020001C2222221400005CA2A2A27C02001C2222221C20003E0402 02201F2422221C00'
..'242A2A2A12002020001C2222221F20001C2A2A2A0C';while(s;(..); ;){printf'%c',hex
$1&1<<$s?40:32}_}$_=':::Christian Garbs:',y;:;\t;;print;_;_

Re: Vergleich auf 0

On 2006-09-06 16:45, Daniel Fischer wrote:
> Fixkommarechnung ist *genauer* als Fliesskommarechnung!

Ich bin schwer in Versuchung, darauf einfach mit "Quatsch" zu antworten,
aber ich beschränke mich auf ein präziseres: "Nur in wenigen Fällen".

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

On 2006-09-06 11:09, Klaus wrote:
> Wolf Grossi wrote:
>> sum=2804.642
>>
>> val=-2804.642,
>>
>> $sum += $val
>> if ($sum == 0)
>> {
>> }
>> >>> sum=4.54747350886464e-13
>> >>> Die if ($sum == 0) Abfrage geht nicht, da sum nicht 0 ist.
>
> Das ist das klassische Fliesskomma Problem, welches nicht nur auf Perl
> beschraenkt ist:

Das hat überhaupt nichts mit Fließkomma zu tun. Das ist ein Problem der
Zahlenbasis: Wir sind es gewohnt zur Basis 10 zu rechnen und sehen daher
eine Zahl wie "-2804.642" (d.h. -2804642/1000) als exakt an, während wir
nichts daran finden, das wir Zahlen wie 53/793 oder Pi nicht exakt
darstellen können. Computer rechnen aber (meistens) zur Basis 2, und
1/10 (sowie alle positiven Potenzen davon, wie 1/100, 1/1000, etc.) ist
in Basis 2 genausowenig exakt repräsentierbar wie 1/793 in Basis 10.
Daher muss ein Computer, der -2804642/1000 als eine Zahl zur Basis 2 mit
begrenzter Genauigkeit speichern möchte, diesen Wert auf den nächsten in
dieser Basis darstellbaren Wert runden, also auf ein Vielfaches von 2^n,
wobei n in diesem Fall bei IEEE-754 Doubles den Wert -41 hat, wenn ich
mich nicht verrechnet habe. Das ist im Prinzip genau das gleiche, wie
wenn ich 53/793 als .06683480453972257250 (d.h.
6683480453972257250*10^-20) darstelle.


hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

Peter J. Holzer wrote:
> On 2006-09-06 11:09, Klaus wrote:
>> Wolf Grossi wrote:
>>> sum=2804.642
>>>
>>> val=-2804.642,
>>>
>>> $sum += $val
>>> if ($sum == 0)
>>> {
>>> }
>>> >>> sum=4.54747350886464e-13
>>> >>> Die if ($sum == 0) Abfrage geht nicht, da sum nicht 0 ist.
>>
>> Das ist das klassische Fliesskomma Problem, welches nicht nur auf Perl
>> beschraenkt ist:
>
> Das hat überhaupt nichts mit Fließkomma zu tun.

Weshalb argumentierst Du dann mit IEEE-754?

Re: Vergleich auf 0

On 2006-09-07 01:40, Achim Grolms wrote:
> Peter J. Holzer wrote:
>> On 2006-09-06 11:09, Klaus wrote:
>>> Wolf Grossi wrote:
>>>> sum=2804.642
[...]
>>>> >>> sum=4.54747350886464e-13
>>>> >>> Die if ($sum == 0) Abfrage geht nicht, da sum nicht 0 ist.
>>>
>>> Das ist das klassische Fliesskomma Problem, welches nicht nur auf Perl
>>> beschraenkt ist:
>>
>> Das hat überhaupt nichts mit Fließkomma zu tun.
>
> Weshalb argumentierst Du dann mit IEEE-754?

Weil es eine wohlbekannte binäre Zahlendarstellung ist. Du wirst
feststellen, dass die Tatsache, dass es eine Fließkommadarstellung ist,
in meiner Argumentation keine Rolle spielt, nur die Tatsache, dass sie
binär ist. Das Argument bleibt bei jeder binären Darstellung das
gleiche.

Nehmen wir als weiteres Beispiel eine 32-Bit-Fixkommadarstellung mit 16
(binären) Nachkommastellen:

2804.642 müsste dann in 65536stel ausgedrückt werden, was aber nicht
exakt möglich ist. Die nächste Annäherung wäre 183805018/65536 oder
2804.641998291015625 (AF4.A45A hexadezimal).

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

Ingo Menger wrote:
[snip]
>> Das heißt wohl, daß man das Problem mit
>> $sum+=sprintf("%.6f", $val);
>> lösen muß.
>
> Das Problem löst Du damit sowenig, wie Du Krebs durch Morphium heilst.
> Du verdeckst halt nur die Symptome.
> Lösen kann man das Problem nur, wenn man die hoffentlich von Oracle
> gelieferten Strings nicht als Gleitkommazahlen benutzt. Es gibt
> sicherlich CPAN-Module für Decimals. Zur Not tut auch BigInt.
>

Hm, wie kann ich die von ORACLE gelieferten, mit Dezimalpunkt
versehenen, numerischen Zeichenketten *anders* als Gleitkommazahl verwenden?

Werde die CPAN/Decimals checken.

Wolf

Re: Vergleich auf 0

Super,
danke für die zahlrechen Ausführungen und interessanten Details.
Ich hab was von Fixkommaarithmetik gelernt und Beiträge der
Uni Saarland und der Mechatronik Uni Linz gelesen.
Da ich aber keine Digitalen Regler anwende, bin ich mir dort etwas
deplaziert vorgekommen, ich will ja nur addieren und subtrahieren.

Ja, was ich aber immer noch nicht weiß ist:
- Wie mach ich's richtig?
- Wie addiere und subtraheire ich in perl Zahlen, die Dezimalstellen
enthalten?

Danke,
Wolf

Re: Vergleich auf 0

Super,
danke für die zahlrechen Ausführungen und interessanten Details.
Ich hab was von Fixkommaarithmetik gelernt und Beiträge der
Uni Saarland und der Mechatronik Uni Linz gelesen.
Da ich aber keine Digitalen Regler anwende, bin ich mir dort etwas
deplaziert vorgekommen, ich will ja nur addieren und subtrahieren.

Ja, was ich aber immer noch nicht weiß ist:
- Wie mach ich's richtig?
- Wie addiere und subtrahiere ich in perl Zahlen, die Dezimalstellen
enthalten?

Danke,
Wolf

Re: Vergleich auf 0

Wolf Grossi wrote:
> Ingo Menger wrote:
>>
>>Lösen kann man das Problem nur, wenn man die hoffentlich von Oracle
>>gelieferten Strings nicht als Gleitkommazahlen benutzt. Es gibt
>>sicherlich CPAN-Module für Decimals. Zur Not tut auch BigInt.
>
> Hm, wie kann ich die von ORACLE gelieferten, mit Dezimalpunkt
> versehenen, numerischen Zeichenketten *anders* als Gleitkommazahl verwenden?

Du könntest auch Oracle rechnen lassen. Oracle speichert und
rechnet mit Dezimalzahlen exakt, sofern diese innerhalb der
vereinbarten Precision exakt darstellbar sind - Datentyp NUMBER.
Da hast Du diese Effekte nicht.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Vergleich auf 0

Wolf Grossi schrieb:

> Ingo Menger wrote:
> [snip]
> >> Das heißt wohl, daß man das Problem mit
> >> $sum+=3Dsprintf("%.6f", $val);
> >> lösen muß.
> >
> > Das Problem löst Du damit sowenig, wie Du Krebs durch Morphium heilst.
> > Du verdeckst halt nur die Symptome.
> > Lösen kann man das Problem nur, wenn man die hoffentlich von Oracle
> > gelieferten Strings nicht als Gleitkommazahlen benutzt. Es gibt
> > sicherlich CPAN-Module für Decimals. Zur Not tut auch BigInt.
> >
>
> Hm, wie kann ich die von ORACLE gelieferten, mit Dezimalpunkt
> versehenen, numerischen Zeichenketten *anders* als Gleitkommazahl verwend=
en?
>
> Werde die CPAN/Decimals checken.

Meist haben diese Pakete einen Konstruktor für ihren numerischen
Datentyp, der ein Stringargument nimmt.

Re: Vergleich auf 0

Wolf Grossi schrieb:
> Super,
> danke für die zahlrechen Ausführungen und interessanten Details.
> Ich hab was von Fixkommaarithmetik gelernt und Beiträge der
> Uni Saarland und der Mechatronik Uni Linz gelesen.
> Da ich aber keine Digitalen Regler anwende, bin ich mir dort etwas
> deplaziert vorgekommen, ich will ja nur addieren und subtrahieren.
>
> Ja, was ich aber immer noch nicht weiß ist:
> - Wie mach ich's richtig?
> - Wie addiere und subtrahiere ich in perl Zahlen, die Dezimalstellen
> enthalten?

Kommt darauf an.
Normalerweise kann man ganz normal rechnen. Nur das Ergebnis muss man
dann eben runden. Wenn du zwei Zahlen vergleichen willst, darfst du
nicht mit == arbeiten, sondern subtrahierst die beiden Zahlen und
guckst, ob der Absolutbetrag der Differenz kleiner als ein Epsilon ist,
das du entsprechend der Größe deiner Zahlen wählen musst.

Wenn dir die Genauigkeit von Double nicht ausreicht, musst du Module
verwenden, die genauer rechnen können.

Wolf

Re: Vergleich auf 0

[snip]
> Kommt darauf an.
> Normalerweise kann man ganz normal rechnen. Nur das Ergebnis muss man
> dann eben runden. Wenn du zwei Zahlen vergleichen willst, darfst du
> nicht mit == arbeiten, sondern subtrahierst die beiden Zahlen und
> guckst, ob der Absolutbetrag der Differenz kleiner als ein Epsilon ist,
> das du entsprechend der Größe deiner Zahlen wählen musst.
>
> Wenn dir die Genauigkeit von Double nicht ausreicht, musst du Module
> verwenden, die genauer rechnen können.

Danke;
Wolf

Re: Vergleich auf 0

Peter J. Holzer schrieb:

> On 2006-09-07 01:40, Achim Grolms wrote:
> > Peter J. Holzer wrote:
> >> On 2006-09-06 11:09, Klaus wrote:
> >>> Wolf Grossi wrote:
> >>>> sum=3D2804.642
> [...]
> >>>> >>> sum=3D4.54747350886464e-13
> >>>> >>> Die if ($sum == 0) Abfrage geht nicht, da sum nicht 0 ist.
> >>>
> >>> Das ist das klassische Fliesskomma Problem, welches nicht nur auf Perl
> >>> beschraenkt ist:
> >>
> >> Das hat überhaupt nichts mit Fließkomma zu tun.
> >
> > Weshalb argumentierst Du dann mit IEEE-754?
>
> Weil es eine wohlbekannte binäre Zahlendarstellung ist. Du wirst
> feststellen, dass die Tatsache, dass es eine Fließkommadarstellung ist,
> in meiner Argumentation keine Rolle spielt, nur die Tatsache, dass sie
> binär ist. Das Argument bleibt bei jeder binären Darstellung das
> gleiche.

Das Argument bleibt bei jeder Fliesskommadarstellung zu einer
beliebigen Basis b dasselbe. Für alle diese Darstellungen gilt, daß
nicht jeder Wert 1/n in endlich vielen Stellen dargestellt werden kann.
Bei b=3D2 sind das u.a.. alle n, in deren Primfaktoren mindestens eine 5
auftaucht. Oder eine 7. Letztere kann man aber auch nicht mit b=3D10
darstellen. Mit b=3D14 hingegen ohne Weiteres.
Die Binärdarstellung ist insofern natürlich besonders fatal, da
praktisch kaum irgendwelche Brüche genau dargestellt werden können.
Numerisch viel besser wäre z.B. eine Darstellung zur Basis b =3D
(Produkt der ersten 100 Primzahlen). (Allerdings dürften dann die
Elektorniker und Chipbauer leicht indigniert gucken, wenn Du sowas
verlangst.)

Re: Vergleich auf 0

Peter J. Holzer!

> On 2006-09-06 16:45, Daniel Fischer wrote:
>> Fixkommarechnung ist *genauer* als Fliesskommarechnung!
>
> Ich bin schwer in Versuchung, darauf einfach mit "Quatsch" zu antworten,
> aber ich beschränke mich auf ein präziseres: "Nur in wenigen Fällen".

Hast ja Recht, als globale Aussage ist das Unfug. Ich präzisiere:
Mit einer bekannten maximalen Anzahl von Nachkommastellen ist die
Fixkommarechnung genauer. Für das Beispiel des OP mit drei Stellen halte
ich sie also weiterhin für richtig.


Gruß
Daniel

Re: Vergleich auf 0

Daniel Fischer wrote:
> Peter J. Holzer!
>
>> On 2006-09-06 16:45, Daniel Fischer wrote:
>>> Fixkommarechnung ist *genauer* als Fliesskommarechnung!
>> Ich bin schwer in Versuchung, darauf einfach mit "Quatsch" zu antworten,
>> aber ich beschränke mich auf ein präziseres: "Nur in wenigen Fällen".
>
> Hast ja Recht, als globale Aussage ist das Unfug. Ich präzisiere:
> Mit einer bekannten maximalen Anzahl von Nachkommastellen ist die
> Fixkommarechnung genauer. Für das Beispiel des OP mit drei Stellen halte
> ich sie also weiterhin für richtig.
>
>
> Gruß
> Daniel

Ja, eh - aber *wie* geht das mit Fixkommarechnung?
Was is'n das - hab nur was gefundebn für den Bau Digitaler Regler.
Und ich will ja nur addieren...
Oder bin ich in der flaschen ng?

Wolf

Re: Vergleich auf 0

Wolf Grossi schrieb:

> Daniel Fischer wrote:
> > Peter J. Holzer!
> >
> >> On 2006-09-06 16:45, Daniel Fischer wrote:
> >>> Fixkommarechnung ist *genauer* als Fliesskommarechnung!
> >> Ich bin schwer in Versuchung, darauf einfach mit "Quatsch" zu antworte=
n,
> >> aber ich beschränke mich auf ein präziseres: "Nur in wenigen Fäl=
len".
> >
> > Hast ja Recht, als globale Aussage ist das Unfug. Ich präzisiere:
> > Mit einer bekannten maximalen Anzahl von Nachkommastellen ist die
> > Fixkommarechnung genauer. Für das Beispiel des OP mit drei Stellen ha=
lte
> > ich sie also weiterhin für richtig.
> >
> >
> > Gruß
> > Daniel
>
> Ja, eh - aber *wie* geht das mit Fixkommarechnung?

Es gibt in der Sprache Perl keine "eingebaute" Fixkommarechnung. (In
SQL schon).

> Und ich will ja nur addieren...
> Oder bin ich in der flaschen ng?

Du bist im falschen Netz. Das Netz, wo fertige Lösungen
schlüsselfertig gepostet werden, ist noch nicht erfunden. Hier werden
nur Hinweise gegeben. Du hast - neben der Explizierung der Ursachen
für das Fehlverhalten Deines Programms - bisher folgende Hinweise
erhalten:

- versuche, wenn möglich, Oracle selber in SQL rechnen zu lassen
(Schlüsselwörter: sum, group by)
- verwende ein geeignetes package, das Rechnen mit Dezimalstellen
implementiert.
- falls das nicht geht, verwende ein package, das big integers
implementiert und programmier die Skalierung selbst

Ich füge noch folgende Hinweise hinzu:

- lies die FAQ dieser Gruppe
- versuche, herauszufinden, was CPAN ist, was ein package (Paket) ist,
usw.
- google ein bischen, z.B. nach "big decimals perl" oder anderen
geeigneten Schlüsselwörtern.
- frag zurück, wenn Du einen Hinweis hier nicht verstehst, aber bitte
nicht in der Art: "Man hat mir immer noch keine Lösung genannt!
Bääähhh!"

Re: Vergleich auf 0

Ingo Menger wrote:
> Wolf Grossi schrieb:
>
>> Daniel Fischer wrote:
>>> Peter J. Holzer!
>>>
>>>> On 2006-09-06 16:45, Daniel Fischer wrote:
>>>>> Fixkommarechnung ist *genauer* als Fliesskommarechnung!
>>>> Ich bin schwer in Versuchung, darauf einfach mit "Quatsch" zu antworten,
>>>> aber ich beschränke mich auf ein präziseres: "Nur in wenigen Fällen".
>>> Hast ja Recht, als globale Aussage ist das Unfug. Ich präzisiere:
>>> Mit einer bekannten maximalen Anzahl von Nachkommastellen ist die
>>> Fixkommarechnung genauer. Für das Beispiel des OP mit drei Stellen halte
>>> ich sie also weiterhin für richtig.
>>>
>>>
>>> Gruß
>>> Daniel
>> Ja, eh - aber *wie* geht das mit Fixkommarechnung?
>
> Es gibt in der Sprache Perl keine "eingebaute" Fixkommarechnung. (In
> SQL schon).
>
>> Und ich will ja nur addieren...
>> Oder bin ich in der flaschen ng?
>
> Du bist im falschen Netz. Das Netz, wo fertige Lösungen
> schlüsselfertig gepostet werden, ist noch nicht erfunden. Hier werden
> nur Hinweise gegeben. Du hast - neben der Explizierung der Ursachen
> für das Fehlverhalten Deines Programms - bisher folgende Hinweise
> erhalten:
>
> - versuche, wenn möglich, Oracle selber in SQL rechnen zu lassen
> (Schlüsselwörter: sum, group by)
> - verwende ein geeignetes package, das Rechnen mit Dezimalstellen
> implementiert.
> - falls das nicht geht, verwende ein package, das big integers
> implementiert und programmier die Skalierung selbst
>
> Ich füge noch folgende Hinweise hinzu:
>
> - lies die FAQ dieser Gruppe
> - versuche, herauszufinden, was CPAN ist, was ein package (Paket) ist,
> usw.
> - google ein bischen, z.B. nach "big decimals perl" oder anderen
> geeigneten Schlüsselwörtern.
> - frag zurück, wenn Du einen Hinweis hier nicht verstehst, aber bitte
> nicht in der Art: "Man hat mir immer noch keine Lösung genannt!
> Bääähhh!"
>
Danke für Deine Ausführungen.
Wolf

Re: Vergleich auf 0

Wolf Grossi!

> Ja, eh - aber *wie* geht das mit Fixkommarechnung? Was is'n das - hab
> nur was gefundebn für den Bau Digitaler Regler. Und ich will ja nur
> addieren...

Hilft Dir http://de.wikipedia.org/wiki/Festkommazahl weiter? Der Artikel
ist nicht ganz perfekt, aber es sind Beispiele drin.


Gruß
Daniel

Re: Vergleich auf 0

Daniel Fischer wrote:
> Wolf Grossi!
>
>> Ja, eh - aber *wie* geht das mit Fixkommarechnung? Was is'n das - hab
>> nur was gefundebn für den Bau Digitaler Regler. Und ich will ja nur
>> addieren...
>
> Hilft Dir http://de.wikipedia.org/wiki/Festkommazahl weiter? Der Artikel
> ist nicht ganz perfekt, aber es sind Beispiele drin.
>
>
> Gruß
> Daniel

Danke für Deinen freundlichen Hinweis :-)
Wolf

Re: Vergleich auf 0

On 2006-09-07 11:08, Daniel Fischer wrote:
> Peter J. Holzer!

Irgendwie klingt die Einleitungszeile nach Kasernenhof. Ich liebe es
nicht besonders, angebrüllt zu werden.


>> On 2006-09-06 16:45, Daniel Fischer wrote:
>>> Fixkommarechnung ist *genauer* als Fliesskommarechnung!
>>
>> Ich bin schwer in Versuchung, darauf einfach mit "Quatsch" zu antworten,
>> aber ich beschränke mich auf ein präziseres: "Nur in wenigen Fällen".
>
> Hast ja Recht, als globale Aussage ist das Unfug. Ich präzisiere:
> Mit einer bekannten maximalen Anzahl von Nachkommastellen ist die
> Fixkommarechnung genauer. Für das Beispiel des OP mit drei Stellen halte
> ich sie also weiterhin für richtig.

Das blöde dabei ist aber, dass die Anzahl der Nachkommastellen zwar
bekannt aber unendlich ist. Eine Fixkommadarstellung mit unendlich
vielen Nachkommastellen ist aber etwas unhandlich.

Im Fall des OP bringt daher eine Fixkommadarstellung ohne Änderung der
Zahlenbasis IMHO überhaupt nichts.

Im Fall einer bekannten Anzahl von Nachkommastellen $s zur Basis $n kann
man exakt rechnen, indem man alle Zahlen mit $n**$s multipliziert:
Statt mit 2804.642 rechnet man dann mit 2804642. Wenn man das mit echten
Integerzahlen macht, ist das eine Fixkommadarstellung zur Basis $n. In
Perl bleibt es eine Fließkommadarstellung, nur mit anderer Einheit
(Zehntelcent statt Euro, Millimeter statt Meter, ...).

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

On 2006-09-07 09:57, Ingo Menger wrote:
> Peter J. Holzer schrieb:
>> On 2006-09-07 01:40, Achim Grolms wrote:
>> > Peter J. Holzer wrote:
>> >> Das hat überhaupt nichts mit Fließkomma zu tun.
>> >
>> > Weshalb argumentierst Du dann mit IEEE-754?
[...]
>> Das Argument bleibt bei jeder binären Darstellung das gleiche.
>
> Das Argument bleibt bei jeder Fliesskommadarstellung zu einer
> beliebigen Basis b dasselbe.
[...]

Bitte lies mein Posting, von dem Achim nur eine einzige Zeile zitiert
hat, noch einmal. Da habe ich das im Wesentlichen auch schon
geschrieben.

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

Peter J. Holzer wrote:
> On 2006-09-07 09:57, Ingo Menger wrote:
>> Peter J. Holzer schrieb:
>>> On 2006-09-07 01:40, Achim Grolms wrote:
>>> > Peter J. Holzer wrote:
>>> >> Das hat überhaupt nichts mit Fließkomma zu tun.
>>> >
>>> > Weshalb argumentierst Du dann mit IEEE-754?
> [...]
>>> Das Argument bleibt bei jeder binären Darstellung das gleiche.
>>
>> Das Argument bleibt bei jeder Fliesskommadarstellung zu einer
>> beliebigen Basis b dasselbe.
> [...]
>
> Bitte lies mein Posting, von dem Achim nur eine einzige Zeile zitiert
> hat,

Weil da bereits die Kausalkette kaputt ist.
Im Rest des Postings schreibst Du von der Basis 2 und
ihren Auswirkungen.
Die Basis 2 aber wird benutzt *weil* Fließkommarechnung
verwendet wird. (Die Basis 2 ist in IEEE 754)
vorgegeben.

Re: Vergleich auf 0

On 2006-09-07 17:13, Achim Grolms wrote:
> Peter J. Holzer wrote:
>> On 2006-09-07 09:57, Ingo Menger wrote:
>>> Peter J. Holzer schrieb:
>>>> On 2006-09-07 01:40, Achim Grolms wrote:
>>>> > Peter J. Holzer wrote:
>>>> >> Das hat überhaupt nichts mit Fließkomma zu tun.
>>>> >
>>>> > Weshalb argumentierst Du dann mit IEEE-754?
>> [...]
>>>> Das Argument bleibt bei jeder binären Darstellung das gleiche.
>>>
>>> Das Argument bleibt bei jeder Fliesskommadarstellung zu einer
>>> beliebigen Basis b dasselbe.
>> [...]
>>
>> Bitte lies mein Posting, von dem Achim nur eine einzige Zeile zitiert
>> hat,
>
> Weil da bereits die Kausalkette kaputt ist.
> Im Rest des Postings schreibst Du von der Basis 2 und
> ihren Auswirkungen.

Und um genau die geht es im Problem des OP. (Ja, bei Basis 37 hätte er
das gleiche Problem. Sein Rechner rechnet aber nicht mit Basis 37.)

> Die Basis 2 aber wird benutzt *weil* Fließkommarechnung
> verwendet wird.

Jetzt wird's aber wirklich abstrus. Fließkommarechnung bedingt in keiner
Weise Basis 2: Meine Taschenrechner verwenden alle Fließkommaarithmetik
zur Basis 10. Oracle verwendet ein Fließkommaformat zur Basis 100.
U.s.w.

Umgekehrt bedeutet Fixkommaarithmetik nicht, dass eine andere Basis als
2 verwendet wird. Integer-Arithmetik (was ja nichts anderes ist als
Fixkommaarithmetik mit 0 Nachkommastellen) ist in praktisch allen
Programmiersprachen auf praktisch allen Plattformen binär.

> (Die Basis 2 ist in IEEE 754) vorgegeben.

Äh ja, und? Ist es wirklich so schwer, die beiden Aspekte
"Fließkommaarithmetik" und "Binäre Darstellung" zu trennen? Das Problem
das OP hat *nichts* mit Fließkommaarithmetik zu tun, sondern damit, dass
der Perl in einer anderen Basis rechnet (2) als der OP (10), und daher
Zahlen, die der OP als exakt darstellbar ansieht, nicht exakt
darstellbar sind. Eine Umstellung von Fließkommadarstellung auf
Fixkommadarstellung ändert daran nichts: 1/10 ist nun mal im
Zahlensystem 2 eine periodische Zahl und nicht in endlich vielen Stellen
repräsentierbar, völlig unabhängig davon, ob der Exponent fix oder
variabel ist. Da hilft nur eine Änderung der Zahlenbasis auf ein
Vielfaches von 10.

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

* Daniel Fischer:

> Mit einer bekannten maximalen Anzahl von Nachkommastellen ist die
> Fixkommarechnung genauer.

Nein, der entscheidende Punkt ist, ob man zur Basis zwei oder zehn
rechnet. Im ersten Fall kannst Du beliebig viele Stellen spendieren,
Du wirst ein Fünftel trotzdem nicht genau darstellen können. Zur Basis
zehn ist das gar kein Problem.

Re: Vergleich auf 0

Peter J. Holzer schrieb:

> On 2006-09-07 17:13, Achim Grolms wrote:
> > Peter J. Holzer wrote:
> >> On 2006-09-07 09:57, Ingo Menger wrote:
> >>> Peter J. Holzer schrieb:
> >>>> On 2006-09-07 01:40, Achim Grolms wrote:
> >>>> > Peter J. Holzer wrote:
> >>>> >> Das hat überhaupt nichts mit Fließkomma zu tun.
> >>>> >
> >>>> > Weshalb argumentierst Du dann mit IEEE-754?
> >> [...]
> >>>> Das Argument bleibt bei jeder binären Darstellung das gleiche.
> >>>
> >>> Das Argument bleibt bei jeder Fliesskommadarstellung zu einer
> >>> beliebigen Basis b dasselbe.
> >> [...]
> >>
> >> Bitte lies mein Posting, von dem Achim nur eine einzige Zeile zitiert
> >> hat,
> >
> > Weil da bereits die Kausalkette kaputt ist.
> > Im Rest des Postings schreibst Du von der Basis 2 und
> > ihren Auswirkungen.
>
> Und um genau die geht es im Problem des OP. (Ja, bei Basis 37 hätte er
> das gleiche Problem. Sein Rechner rechnet aber nicht mit Basis 37.)
>
> > Die Basis 2 aber wird benutzt *weil* Fließkommarechnung
> > verwendet wird.
>
> Jetzt wird's aber wirklich abstrus. Fließkommarechnung bedingt in keiner
> Weise Basis 2: Meine Taschenrechner verwenden alle Fließkommaarithmetik
> zur Basis 10. Oracle verwendet ein Fließkommaformat zur Basis 100.
> U.s.w.
>
> Umgekehrt bedeutet Fixkommaarithmetik nicht, dass eine andere Basis als
> 2 verwendet wird. Integer-Arithmetik (was ja nichts anderes ist als
> Fixkommaarithmetik mit 0 Nachkommastellen) ist in praktisch allen
> Programmiersprachen auf praktisch allen Plattformen binär.
>
> > (Die Basis 2 ist in IEEE 754) vorgegeben.
>
> Äh ja, und? Ist es wirklich so schwer, die beiden Aspekte
> "Fließkommaarithmetik" und "Binäre Darstellung" zu trennen? Das Probl=
em
> das OP hat *nichts* mit Fließkommaarithmetik zu tun, sondern damit, dass
> der Perl in einer anderen Basis rechnet (2) als der OP (10), und daher
> Zahlen, die der OP als exakt darstellbar ansieht, nicht exakt
> darstellbar sind. Eine Umstellung von Fließkommadarstellung auf
> Fixkommadarstellung ändert daran nichts: 1/10 ist nun mal im
> Zahlensystem 2 eine periodische Zahl und nicht in endlich vielen Stellen
> repräsentierbar, völlig unabhängig davon, ob der Exponent fix oder
> variabel ist. Da hilft nur eine Änderung der Zahlenbasis auf ein
> Vielfaches von 10.

Wahrscheinlich meinen wir dasselbe, drücken es nur unterschiedlich
aus.
Aber nach dem was Du sagts, hast Du dennoch unrecht. Die Basis des
Zahlensystems spielt keine Rolle, sondern *nur* die Darstellungsform.
Man kann im Binärsystem 1/10 sehr wohl genau darstellen, z.B. durch
das Tupel (zaehler=3D1b, nenner=3D1010b). Nur eben nicht in Gleitkomma.
Du hast natürlich recht, daß der OP sein spezielles Problem (Addition
von Dezimalzahlen) nicht bemerken würde, wenn zufällig das
Floating-Point-Unit seines Rechners zur Basis 10 arbeiten würde. Das
heißt aber nicht, daß nicht Gleitkomma das Problem ist. Bei Basis 10
fällt das Problem bei Addition von Dezimalzahlen halt nur nicht auf.
Im übrigen, rein praktisch betrachtet, ist auch dies nicht viel wert,
denn man kann sich halt die Zahlenbasis nicht recht aussuchen, wohl
hingegen die Darstellungsform.
Deshalb: willst Du exakt rechnen, benutze kein Gleitkomma, egal welcher
Basis. Gleitkomma ist für Physiker da, die ohnehin mit
Näherungswerten (und Fehlerbetrachtung und entsprechenden numerischen
Methoden) arbeiten.

Re: Vergleich auf 0

On 2006-09-08 14:51, Ingo Menger wrote:
> Wahrscheinlich meinen wir dasselbe, drücken es nur unterschiedlich
> aus. Aber nach dem was Du sagts, hast Du dennoch unrecht. Die Basis
> des Zahlensystems spielt keine Rolle, sondern *nur* die
> Darstellungsform.

Das hängt vom Problem ab. Wenn das Problem darin besteht, ganzzahlige
Vielfache von Potenzen von 10 (innerhalb eines bestimmten Bereichs)
exakt darzustellen, dann dann ist Gleitkommaformat zur Basis 10 eine
korrekte Lösung des Problems. Wenn das Problem darin besteht, beliebige
rationale Zahlen (innerhalb eines bestimmten Bereichs) exakt
darzustellen, dann ist eine Darstellung als Tupel von zwei ganzen Zahlen
eine korrekte Lösung. Wenn beliebige reelle Zahlen exakt dargestellt
werden sollen, fällt mir keine Lösung für das Problem ein.

Prinzipiell hat ein Computer nur endlich viel RAM und kann daher nur
endlich viele Zahlen darstellen. Somit können in jeder Zahlendarstellung
fast alle Zahlen nicht exakt dargestellt werden.

> Man kann im Binärsystem 1/10 sehr wohl genau darstellen, z.B. durch
> das Tupel (zaehler=1b, nenner=1010b). Nur eben nicht in Gleitkomma.

Das ist richtig, allerdings hat in diesem Thread nie jemand eine
Bruchdarstellung als Alternative vorgeschlagen, sondern es war immer von
Fixkommadarstellung die Rede. Das löst das Problem aber nicht, da
Fixkommadarstellung die gleichen Probleme wie Gleitkommadarstellung hat
(wie schon jemand festgestellt hat, ist eine Gleitkommazahl ein Bruch,
bei dem der Nenner eine ganzzahlige Potenz der Basis ist. Eine
Fixkommadarstellung ist ein Bruch, bei dem der Nenner konstant ist).

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

On 2006-09-08 17:36, Peter J. Holzer wrote:
> Das hängt vom Problem ab. Wenn das Problem darin besteht, ganzzahlige
> Vielfache von Potenzen von 10 (innerhalb eines bestimmten Bereichs)
> exakt darzustellen, dann dann ist Gleitkommaformat zur Basis 10 eine
> korrekte Lösung des Problems. Wenn das Problem darin besteht, beliebige
> rationale Zahlen (innerhalb eines bestimmten Bereichs) exakt
> darzustellen, dann ist eine Darstellung als Tupel von zwei ganzen Zahlen
> eine korrekte Lösung.

Ich habe da zweimal "Bereich" geschrieben. Das ist kein Intervall,
sondern einfach eine Teilmenge, deren Elemente durch Details der
Repräsentation mehr oder weniger kompliziert festgelegt werden.

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

Peter J. Holzer wrote:

> Das ist richtig, allerdings hat in diesem Thread nie jemand eine
> Bruchdarstellung als Alternative vorgeschlagen, sondern es war immer von
> Fixkommadarstellung die Rede. Das löst das Problem aber nicht, da
> Fixkommadarstellung die gleichen Probleme wie Gleitkommadarstellung hat

Punkt für Dich, ich hatte "Fixkomma" fälschlicherweise
automatisch mit einer sicheren Darstellung assoziiert,
z.B. in BCD (da wäre 10 die Basis).
Selbstverständlich bedeutet "Fixkomma"
nicht automatisch eine Festlegung einer
angemessenen Basis, das war mein
Denkfehler beim vorschnellen Schreiben.

Aaaaaaaaaaaber...
.....da wir hier ja Fließkommadarstellung
im Kontext "Perl" behandeln (der OP will sein
Problem ja nicht auf Deinen Taschenrechnern lösen)
ist die Basis sehr wohl bereits durch Wahl von "Fließkomma"
implizit auf 2 festgenagelt...
....und damit ist mein Posting doch richtig.

;-)

Re: Vergleich auf 0

Peter J. Holzer schrieb:

> On 2006-09-08 14:51, Ingo Menger wrote:

> Prinzipiell hat ein Computer nur endlich viel RAM und kann daher nur
> endlich viele Zahlen darstellen. Somit können in jeder Zahlendarstellung
> fast alle Zahlen nicht exakt dargestellt werden.

:)


> > Man kann im Binärsystem 1/10 sehr wohl genau darstellen, z.B. durch
> > das Tupel (zaehler=3D1b, nenner=3D1010b). Nur eben nicht in Gleitkomma.
>
> Das ist richtig, allerdings hat in diesem Thread nie jemand eine
> Bruchdarstellung als Alternative vorgeschlagen, sondern es war immer von
> Fixkommadarstellung die Rede. Das löst das Problem aber nicht, da
> Fixkommadarstellung die gleichen Probleme wie Gleitkommadarstellung hat

Jein.
Das Problem A "Addieren von Zahlen, die 3 Stellen nach dem Komma haben"
läßt sich abbilden auf ein equivalentes Problem A' "Addieren von
ganzen Zahlen" mit entsprechender Skalierung der Ein- und Ausgaben.
"Skalierung" ist hier eine typographische Operation (wegnehmen bzw.
einfügen des Dezmalpunkts), die nichts an der Genauigkeit der Zahlen
ändert.
Zweifellos ist aber die Ganzzahldarstellung eine Fixkommadarstellung.

Re: Vergleich auf 0

On 2006-09-11 08:35, Ingo Menger wrote:
> Peter J. Holzer schrieb:
>> On 2006-09-08 14:51, Ingo Menger wrote:
>> > Man kann im Binärsystem 1/10 sehr wohl genau darstellen, z.B. durch
>> > das Tupel (zaehler=1b, nenner=1010b). Nur eben nicht in Gleitkomma.
>>
>> Das ist richtig, allerdings hat in diesem Thread nie jemand eine
>> Bruchdarstellung als Alternative vorgeschlagen, sondern es war immer von
>> Fixkommadarstellung die Rede. Das löst das Problem aber nicht, da
>> Fixkommadarstellung die gleichen Probleme wie Gleitkommadarstellung hat
>
> Jein.
> Das Problem A "Addieren von Zahlen, die 3 Stellen nach dem Komma haben"
> läßt sich abbilden auf ein equivalentes Problem A' "Addieren von
> ganzen Zahlen" mit entsprechender Skalierung der Ein- und Ausgaben.

Genau das habe ich in
vorgeschlagen.

> "Skalierung" ist hier eine typographische Operation (wegnehmen bzw.
> einfügen des Dezmalpunkts), die nichts an der Genauigkeit der Zahlen
> ändert.

Ein "Dezimalpunkt" exististiert nur in Dezimaldarstellung. Sofern die
Zahlen nicht tatsächlich als String von Dezimalziffern dargestellt
werden, kann man diesen also weder entfernen noch hinzufügen. Abstrakt
betrachtet, ist es eine arithmetische Operation, nämlich eine
Multiplikation mit 1000.

> Zweifellos ist aber die Ganzzahldarstellung eine Fixkommadarstellung.

Ja, allerdings wird hier der Wert $x durch den Wert $x*10**3
repräsentiert. Es ist also eine Fixkommadarstellung zur Basis 10. Und
damit sind wir wieder bei dem Punkt angelangt, den ich in diesem Thread
gebetsmühlenartig wiederhole: Entscheidend ist der Wechsel der Basis von
2 auf 10, nicht der Wechsel von Fließkomma auf Fixkomma.

(Der Wert $x*10**3 kann dann auf jede beliebige Art repräsentiert
werden, die jeden benötigten Darstellen kann, z.B. als 32-Bit-Integer,
wenn der $x im Bereich [-2147483.648, 2147483.647], IEEE-754 Double
Precision Float, wenn $x im Bereich +/- 9E12 ist, als COBOL
packed-decimal, als Base-36-String, ...)

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: Vergleich auf 0

Peter J. Holzer wrote:

> als COBOL packed-decimal,

Darauf hat COBOL wohl kein Monopol, denn 360/370/390-Architekturen haben
das im Instruktionssatz, und dafür gebaute Compiler wohl auch
(3xx-Assembler und PL/I definitiv).

Helmut Wollmersdorfer

Re: Vergleich auf 0

Helmut Wollmersdorfer wrote:
> Peter J. Holzer wrote:
>
> > als COBOL packed-decimal,
>
> Darauf hat COBOL wohl kein Monopol, denn 360/370/390-Architekturen haben
> das im Instruktionssatz, und dafür gebaute Compiler wohl auch
> (3xx-Assembler und PL/I definitiv).

Siehe dazu auch das CPAN-Modul "Convert::IBM390" (Funktion "packeb",
parameter "p" kann packed-decimal verarbeiten):

http://search.cpan.org/~grommel/Convert-IBM390-0.22/IBM390.p od

Zitat: "...By the way, this module is called "IBM390" because it will
deal with data from any mainframe operating system...."

Re: Vergleich auf 0

Peter J. Holzer schrieb:

> On 2006-09-11 08:35, Ingo Menger wrote:

> > Zweifellos ist aber die Ganzzahldarstellung eine Fixkommadarstellung.
>
> Ja, allerdings wird hier der Wert $x durch den Wert $x*10**3
> repräsentiert. Es ist also eine Fixkommadarstellung zur Basis 10. Und
> damit sind wir wieder bei dem Punkt angelangt, den ich in diesem Thread
> gebetsmühlenartig wiederhole: Entscheidend ist der Wechsel der Basis von
> 2 auf 10, nicht der Wechsel von Fließkomma auf Fixkomma.

Da drehen wir uns im Kreis.
Entscheidend ist doch, daß jede ganze Zahl in einem Positionssystem zu
beliebiger Basis dargestellt werden kann, wenn der Speicher genügend
groß ist, während bei Gleitkommadarstellung in *jeder* Basis nur
einige wenige rationale Zahlen genau dargestellt werden könnten,
selbst wenn der Speicher unbegrenzt wäre.
Wenn man also eine Berechnung hat, die sich in eine Ganzzahlberechnung
abbilden läßt, sollte man dies tun. Zumal man die Zahlenbasis, in der
gerechnet wird, eben selten explizit bestimmen kann.
(Es ist natürlich richtig, daß das Problem des OP mit Hilfe eines
dezimalen Gleitkommapakets wahrscheinlich ebenfalls gelöst werden
kann, da er "zufällig" nur Werte verwendet, die dezimal darstellbar
sind.)