Hi Leute,
ja, wie kann ich mit perl anständig rechnen. Ich muß Prozente, Währungen,
etc. verrechnen...
Es wäre nett, mich mal in die richtige Richtung zu stoßen - Kommandos,
Routinen, Packages.
Wichtig wäre halt kaufmännisches Runden, evtl. das man "mit Komma" rechnen
kann, etc.
Oliver Bleckmann wrote:
> ja, wie kann ich mit perl anständig rechnen. Ich muß Prozente, Währungen,
> etc. verrechnen...
> Es wäre nett, mich mal in die richtige Richtung zu stoßen - Kommandos,
> Routinen, Packages.
> Wichtig wäre halt kaufmännisches Runden, evtl. das man "mit Komma" rechnen
> kann, etc.
Kaufmännisches Runden ist sprintf '%.2f' - wenn ich nicht irre.
Komma statt Punkt ist eine Sache der Ausgabe (triviale Ersetzung).
Wenn Du über die eingebauten Operatoren und Funktionen
weitere mathematische Unterstützung brauchst,
könntest Du in der Liste der Mathematikpakete fündig werden:
http://cpan.uwinnipeg.ca/search?query=Math&mode=dist
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Frank Seitz
> Kaufmännisches Runden ist sprintf '%.2f' - wenn ich nicht irre.
Das ist seltsam inkonsistent:
| $ perl -e 'printf "%.2f\n", 0.005;'
| 0.01
| $ perl -e 'printf "%.2f\n", 1.005;'
| 1.00
| $
Oder stehe ich jetzt gerade auf dem Schlauch?
Paul
"Oliver Bleckmann"
news:dfd2cr$8lh$1@newsserver.rz.tu-ilmenau.de...
> Hi Leute,
>
> ja, wie kann ich mit perl anständig rechnen. Ich muß Prozente, Währungen,
> etc. verrechnen...
> Es wäre nett, mich mal in die richtige Richtung zu stoßen - Kommandos,
> Routinen, Packages.
> Wichtig wäre halt kaufmännisches Runden, evtl. das man "mit Komma" rechnen
> kann, etc.
>
>
Hallo Oliver
falls Du mit printf zum Runden nicht glücklich wirst,
probiere mal das Modul:
Number::Format;
Tschööö Thomas
* Paul Hink [2005-09-04]:
Hallo Paul,
> Das ist seltsam inkonsistent:
>| $ perl -e 'printf "%.2f\n", 0.005;'
>| 0.01
>| $ perl -e 'printf "%.2f\n", 1.005;'
>| 1.00
>| $
heutige Computer können die Zahl 1.005 nicht exakt (in einem IEEE Float)
speichern. Wenn du dir das mal genauer anschaust
$ perl -e 'printf "%.16f\n", $_ for 0.005, 1.005;'
0.0050000000000000
1.0049999999999999
dann wird es direkt offensichtlich wo das Problem beim Runden liegt.
Ich empfehle auch die Lektüre von
perldoc -q round
Das Beispiel dort ist auch sehr interessant:
for ($i = 0; $i < 1.01; $i += 0.05) { printf "%.1f ",$i}
0.0 0.1 0.1 0.2 0.2 0.2 0.3 0.3 0.4 0.4 0.5 0.5 0.6 0.7 0.7 0.8 0.8 0.9 0.9 1.0 1.0
Gruss
Christian
--
Leichen sind wie du und ich -- nur tot.
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
Christian Lackas skribis:
> heutige Computer können die Zahl 1.005 nicht exakt (in einem IEEE Float)
> speichern. Wenn du dir das mal genauer anschaust
>
> $ perl -e 'printf "%.16f\n", $_ for 0.005, 1.005;'
> 0.0050000000000000
> 1.0049999999999999
Das ist auch der Grund, warum im kaufmännischen Bereich mit Dezimalzahlen
gerechnet wird.
Nochmal Danke.
printf rundet gerade nicht dachte ich. Und, was das Ersetzen angeht, mache
ich doch schon...
"Frank Seitz"
news:3nvplrF3huj3U1@individual.net...
> Oliver Bleckmann wrote:
>
>> ja, wie kann ich mit perl anständig rechnen. Ich muß Prozente, Währungen,
>> etc. verrechnen...
>> Es wäre nett, mich mal in die richtige Richtung zu stoßen - Kommandos,
>> Routinen, Packages.
>> Wichtig wäre halt kaufmännisches Runden, evtl. das man "mit Komma"
>> rechnen
>> kann, etc.
>
> Kaufmännisches Runden ist sprintf '%.2f' - wenn ich nicht irre.
> Komma statt Punkt ist eine Sache der Ausgabe (triviale Ersetzung).
> Wenn Du über die eingebauten Operatoren und Funktionen
> weitere mathematische Unterstützung brauchst,
> könntest Du in der Liste der Mathematikpakete fündig werden:
> http://cpan.uwinnipeg.ca/search?query=Math&mode=dist
>
> Grüße
> Frank
> --
> Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
> Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Matthias Peick wrote:
> Christian Lackas skribis:
>>
>>heutige Computer können die Zahl 1.005 nicht exakt (in einem IEEE Float)
>>speichern. Wenn du dir das mal genauer anschaust
>>
>> $ perl -e 'printf "%.16f\n", $_ for 0.005, 1.005;'
>> 0.0050000000000000
>> 1.0049999999999999
>
> Das ist auch der Grund, warum im kaufmännischen Bereich mit Dezimalzahlen
> gerechnet wird.
Du meinst wohl Ganze Zahlen (Integer). Das da oben
sind auch Dezimalzahlen.
GrüÃe
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
"Christian Lackas"
news:20050904T122708@lackas.net...
> heutige Computer können die Zahl 1.005 nicht exakt (in einem IEEE Float)
Ach sieh mal an! Das ist ja interessant. In anderen Sprachen geht es doch
(das Runden), wie ist es denn da gelöst?
Apropos, mein Taschenrechner hat das selbe Problem (TI), der Casio nicht...
"Thomas Rudy"
news:dfep0o$lqs$1@newsreader3.netcologne.de...
> falls Du mit printf zum Runden nicht glücklich wirst,
> probiere mal das Modul:
>
> Number::Format;
OK. Mal schauen.
* Oliver Bleckmann [2005-09-05]:
Hallo Oliver,
> > heutige Computer können die Zahl 1.005 nicht exakt (in einem IEEE Float)
> Ach sieh mal an! Das ist ja interessant. In anderen Sprachen geht es doch
> (das Runden), wie ist es denn da gelöst?
welche Sprachen sollen das sein?
Die Berechnungen führt ja nicht Perl selbst durch, sondern der
(Hardware-)Prozessor. Daher verhält sich Perl hier exakt so wie auch C,
C++, Ruby, Python, Pascal und Co es für ein float tun.
Und in all diesen Sprachen wird es auch Bibliotheken geben, die es
erlauben mit beliebiger (und trotzdem immer endlicher) Genauigkeit zu
rechnen. Unter Perl kann man dafür z.B. Math::BigFloat nehmen. Da man
hier allerdings mehr Auswand treiben muss, um dem Prozessor die
Berechnungen wieder in für ihn verdauliche Stücke aufzuteilen ist das
deutlich langsamer.
Und für Berechnungen in der Finanzmathematik bieten sich andere Lösungen
an, z.B. das Verlustfreie rechnen mit ganzen oder auch rationalen
Zahlen.
> Apropos, mein Taschenrechner hat das selbe Problem (TI), der Casio
> nicht...
Das glaube ich nicht. Die Zahl 1.5 läßt sich (im Gegensatz zu 0.5)
schlicht nicht in dem Format exakt in einem Computer speichern wie
Computer das heute nunmal tun (Binärformat mit Mantisse und Exponent).
Die beiden werden sich vermutlich nur in der Präzision unterscheiden.
Gruss
Christian
--
#!/usr/bin/perl -sp0777i
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
Christian Lackas wrote:
> welche Sprachen sollen das sein?
> Die Berechnungen führt ja nicht Perl selbst durch, sondern der
> (Hardware-)Prozessor.
Es gibt durchaus Prozessoren, welche Dezimalformate unterstützen
(dezimal gepackt auf IBM-Mainframes) und Compiler dazu.
> Und für Berechnungen in der Finanzmathematik bieten sich andere Lösungen
> an, z.B. das Verlustfreie rechnen mit ganzen oder auch rationalen
> Zahlen.
Eben. In buchhaltungsnahen Anwendungen sollte man float aus dem Weg
gehen. Da kann es schon mal vorkommen, dass man mehr als 14
Dezimalstellen Genauigkeit braucht. Und auch in der Wissenschaft gibt es
Anwendungen, wo 'bignum' (sehr grosse Integer) gebraucht wird.
Helmut Wollmersdorfer
* Helmut Wollmersdorfer [2005-09-05]:
Hallo Helmut,
> > welche Sprachen sollen das sein?
> > Die Berechnungen führt ja nicht Perl selbst durch, sondern der
> > (Hardware-)Prozessor.
> Es gibt durchaus Prozessoren, welche Dezimalformate unterstützen
> (dezimal gepackt auf IBM-Mainframes) und Compiler dazu.
der OP sprach von Programmiersprachen die das angeblich anders machen
würden als Perl. Da die Berechnung aber von der Hardware übernommen
wird, habe ich diese Aussage einfach mal in Zweifel gezogen.
Auch eine dezimale Speicherung hilft nicht immer weiter (mal abgesehen
davon das es sehr ineffizient ist). Damit kann man dann vielleicht alle
Dezimalbrüche verlustfrei speichern, aber die rationalen Zahlen oder gar
die reellen lassen sich im Allgemeinen immer noch nicht ohne Fehler
nutzen.
Gruss
Christian
--
Was lange zippt wird endlich kurz.
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
Christian Lackas wrote:
> Auch eine dezimale Speicherung hilft nicht immer weiter (mal abgesehen
> davon das es sehr ineffizient ist). Damit kann man dann vielleicht alle
> Dezimalbrüche verlustfrei speichern, aber die rationalen Zahlen oder gar
> die reellen lassen sich im Allgemeinen immer noch nicht ohne Fehler
> nutzen.
In kaufmännischen Anwendungen kommen eh nur die Grundrechnungsarten vor.
Und wenn mal Kommastellen anfallen, dann wird nach Regeln gerundet.
Fehler sind trotzdem häufig, weil die Programmierer die richtige
Reihenfolge nicht einhalten - zuerst addieren und dann runden oder
umgekehrt. Typisches Beispiel: 1000 Rechnungspositionen zu 0.01 EUR.
Wenn davon einzeln die Mehrwertsteuer berechnet und gerundet wird, dann
ist die gesamte Mehrwertsteuer dieser Rechnung 0.-. Gesetzlich richtig
ist natürlich, alle Positionen zuerst zu addieren und von den EUR 10,-
dann die Mehrwertseuer zu berechnen und danach auf ganze Cent zu runden.
Effizienz? Bei kaufmännischen Anwendungen ist das ziemlich egal, weil
der Berechnungsanteil verschwindend gering ist im Vergleich zum
CPU-Aufwand für Datenmengen hin- und herschaufeln.
Helmut Wollmersdorfer
Frank Seitz skribis:
>> Das ist auch der Grund, warum im kaufmännischen Bereich mit Dezimalzahlen
>> gerechnet wird.
>
> Du meinst wohl Ganze Zahlen (Integer). Das da oben
> sind auch Dezimalzahlen.
Nein, ich meine Dezimalzahlen, die byte- oder nibble-weise (BCD) kodiert sind.
Dadurch kann ebenfalls mit beliebiger Genauigkeit gerechnet werden, ohne dass
die Basis eine Fehlerquelle ist.
"Christian Lackas"
news:20050905T055854@lackas.net...
> Das glaube ich nicht. Die Zahl 1.5 läßt sich (im Gegensatz zu 0.5)
> schlicht nicht in dem Format exakt in einem Computer speichern wie
> Computer das heute nunmal tun (Binärformat mit Mantisse und Exponent).
> Die beiden werden sich vermutlich nur in der Präzision unterscheiden.
Gut, falls Dir mal ein alter TI (meiner TI-36 eco RS, haben aber alle dieser
Generation) über den Weg läuft, versuch mal damit bißchen zu rechnen, z.B.
Zinsformeln, Grenzwertprobleme, etc. Meine spinnt bei manchen Sachen, weiß
nicht mehr genau, glaube wenn ich e berechne z.B., oder ein einem Newton
Nährwert, wenn ich Pech habe. Manchmal ist auch Null x^-99 oder so. Das hat
der Casio aber nicht!!! Das ist amtlich! Also ist doch eindeutig die
Arithmetik von Casio besser als die der TI (heute hoffentlich nicht mehr).
Nur damit Du mich richtig verstehst, ich liebe TI, rechne bis heute damit
überwiegend, außer er spuckt Mist aus dann muß der Casio rann. Aber gerade
weil ich mit zwei Taschenrechnern arbeite kann ich das so gut beurteilen.
Leider finde ich den Zettel mit den fehlerhaften Berechnungen nicht mehr.
Damals wollte ich mir einen neuen TI kaufen (wie gesagt, bin Fan), und hab'
in diversen Läden die TIs durchgetestet (ca. 4 Modelle), alle machten die
selben Fehler. Die Selben Berechnungen macht der Computer und der jetzige
Casio ohne Probleme und der Casio im Vergleich zum TI sogar schneller!
* Oliver Bleckmann [2005-09-06]:
Hallo Oliver,
> Gut, falls Dir mal ein alter TI (meiner TI-36 eco RS, haben aber alle
> dieser Generation) über den Weg läuft, versuch mal damit bißchen zu
> rechnen
das hat nichts mit der Berechnung zu tun, sondern damit wie Computer
normalerweise Fließkommazahlen speichern. Nach dem von der IEEE
standardisierten Verfahren ist es nicht möglich z.B. die Zahl 1.5
fehlerfrei zu speichen, weil sie sich schlicht nicht exakt darstellen
läßt. Der Fehler kann durch Verwendung von mehr Speicher verringert
werden, aber er verschwindet grundsätzlich nicht.
Und ich kenne jetzt keinen Taschenrechner, der nicht eine binäre
Darstellung von Exponent und Mantisse für seine Zahlen verwendet.
Gruss
Christian
--
Nichts ist anstrengender, als wenn es immer bergauf geht.
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
On 2005-09-06 17:11:55 +0200, Christian Lackas wrote:
> * Oliver Bleckmann [2005-09-06]:
> > Gut, falls Dir mal ein alter TI (meiner TI-36 eco RS, haben aber alle
> > dieser Generation) über den Weg läuft, versuch mal damit bißchen zu
> > rechnen
>
> das hat nichts mit der Berechnung zu tun, sondern damit wie Computer
> normalerweise Fließkommazahlen speichern.
Nein, das hat schon auch mit der Berechnung zu tun. Taschenrechner (vor
allem alte) sind üblichweise langsam und haben sehr begrenzten Speicher.
Wenn man damit "Nährwerte" (SCNR) berechnen will, werden nicht immer
die exaktesten Algorithmen verwendet.
> Nach dem von der IEEE standardisierten Verfahren ist es nicht möglich
> z.B. die Zahl 1.5 fehlerfrei zu speichen, weil sie sich schlicht nicht
> exakt darstellen läßt.
Unsinn. 1.5 ist 3 * 2^-1, das lässt sich problemlos darstellen.
> Der Fehler kann durch Verwendung von mehr Speicher verringert
> werden, aber er verschwindet grundsätzlich nicht.
>
> Und ich kenne jetzt keinen Taschenrechner, der nicht eine binäre
> Darstellung von Exponent und Mantisse für seine Zahlen verwendet.
Meinen letzten Taschenrechner habe ich mir vor ca. 15 Jahren gekauft,
daher bin ich da nicht mehr so ganz auf dem laufenden. Die von mir
verwendeten Modelle (TI-30(?), TI-57, HP-28, HP-48) haben aber sicher
alle eine dezimale Darstellung verwendet.
hp
--
This is not a signature
* Peter J. Holzer [2005-09-12]:
Hallo Peter,
> > das hat nichts mit der Berechnung zu tun, sondern damit wie Computer
> > normalerweise Fließkommazahlen speichern.
> Nein, das hat schon auch mit der Berechnung zu tun. Taschenrechner
> (vor allem alte) sind üblichweise langsam und haben sehr begrenzten
> Speicher. Wenn man damit "Nährwerte" (SCNR) berechnen will, werden
> nicht immer die exaktesten Algorithmen verwendet.
ich weiss nicht was du mit 'Nährwerte' meinst, aber es werden in
Taschenrechnern fast nirgendwo exakte Algorithmen (z.B. für Funktionen
wie sin, exp, ... falls du das meinst) verwendet.
> > Nach dem von der IEEE standardisierten Verfahren ist es nicht
> > möglich z.B. die Zahl 1.5 fehlerfrei zu speichen, weil sie sich
> > schlicht nicht exakt darstellen läßt.
> Unsinn. 1.5 ist 3 * 2^-1, das lässt sich problemlos darstellen.
Ja, sorry, da habe ich mich vertippt. Es ging um (siehe Rest des
Threads) 1.005.
> > Und ich kenne jetzt keinen Taschenrechner, der nicht eine binäre
> > Darstellung von Exponent und Mantisse für seine Zahlen verwendet.
> Meinen letzten Taschenrechner habe ich mir vor ca. 15 Jahren gekauft,
> daher bin ich da nicht mehr so ganz auf dem laufenden. Die von mir
> verwendeten Modelle (TI-30(?), TI-57, HP-28, HP-48) haben aber sicher
> alle eine dezimale Darstellung verwendet.
Er mag dir Ergebnisse so angezeigt haben, benutzt hat er das aber für
Berechnungen nicht.
Wenn du das weiter diskutieren willst, dann bitte passenden Fup2 setzen.
Danke.
Gruss
Christian
--
Auf frischer Tat ertappt: Dunkelheit bei Einbruch verhaftet!
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
On 2005-09-12 09:09:28 +0200, Christian Lackas wrote:
> * Peter J. Holzer [2005-09-12]:
> > > das hat nichts mit der Berechnung zu tun, sondern damit wie Computer
> > > normalerweise Fließkommazahlen speichern.
> > Nein, das hat schon auch mit der Berechnung zu tun. Taschenrechner
> > (vor allem alte) sind üblichweise langsam und haben sehr begrenzten
> > Speicher. Wenn man damit "Nährwerte" (SCNR) berechnen will, werden
> > nicht immer die exaktesten Algorithmen verwendet.
>
> ich weiss nicht was du mit 'Nährwerte' meinst,
Das musst Du Oliver fragen, aber ich nehme an, er meinte "Näherungswerte".
> aber es werden in Taschenrechnern fast nirgendwo exakte Algorithmen
> (z.B. für Funktionen wie sin, exp, ... falls du das meinst) verwendet.
Und verschiedene Taschenrechner verwenden verschiedene Algorithmen. Es
ist durchaus möglich, dass bei der gleichen Berechnung zwei
Taschenrechner mit nominell gleicher Genauigkeit zu unterschiedlichen
Ergebnissen gelangen.
> > > Und ich kenne jetzt keinen Taschenrechner, der nicht eine binäre
> > > Darstellung von Exponent und Mantisse für seine Zahlen verwendet.
> > Meinen letzten Taschenrechner habe ich mir vor ca. 15 Jahren gekauft,
> > daher bin ich da nicht mehr so ganz auf dem laufenden. Die von mir
> > verwendeten Modelle (TI-30(?), TI-57, HP-28, HP-48) haben aber sicher
> > alle eine dezimale Darstellung verwendet.
>
> Er mag dir Ergebnisse so angezeigt haben, benutzt hat er das aber für
> Berechnungen nicht.
Bei der Saturn-CPU, die im HP-28 und HP-48 verbaut war, bin ich mir sehr
sicher, dass die intern BCD-Darstellung für Floating-Point-Zahlen
verwendet hat: 1 Nibble für das Vorzeichen, 12 Nibble für die Mantisse,
bleiben 3 Nibble für den Exponenenten im Bereich +/- 499.
Von den TI-Taschenrechnern habe ich nie eine Hardwarebeschreibung
gesehen. Ich kann daher nicht ausschließen, dass sie intern binär
gerechnet haben - das Rundungs- und Fehlerverhalten sprechen aber aber
für eine BCD-Darstellung. Da das wahrscheinlich eine 4-Bit-
oder maximal 8-Bit-CPU war, erscheint mir BCD-Darstellung ebenfalls
wahrscheinlicher, vor allem, wenn man bedenkt, dass diese Taschenrechner
jedes Ergebnis sofort angezeigt haben, eine dauernde Konversion zwischen
dezimaler und binär Darstellung also ein erheblicher Overhead gewesen
wäre.
> Wenn du das weiter diskutieren willst, dann bitte passenden Fup2 setzen.
Done. (Handhelds kann man wohl als Obermenge von Taschenrechnern sehen)
hp
--
This is not a signature