123 -> 123.00 bzw. 1.2 -> 1.20 (Allgemeines zu Perl)

[thread]14624[/thread]

123 -> 123.00 bzw. 1.2 -> 1.20

Leser: 21

Articles: hide open all | hide show old branches

+20 replies
Gast Thomas

2010-02-10 13:59
Hallo zusammen,

für einen Vergleich in einem Perl-Skript lese ich Zahlen (EUR-Werte) aus einem Textdokument aus, die ich aus der deutschen in die Perl-Schreibweise bringe (z.B. 12.345,67 in 12345.67). Das funktioniert auch wunderbar.
Jetzt berechne ich Summen aus diesen Zahlen und vergleiche diese wieder mit anderen, aus einer Datei eingelesenen Zahlen. Das Problem ist, dass die ausgelesenen Zahlen z.B. 234.00 lauten, die berechneten Werte aber 234 sind und der Vergleich damit fehlschlägt.
Ich versuche mich gerade an einer Funktion, die aus 234 dann 234.00 macht, aber irgendwas scheine ich falsch zu machen. Sieht jemand den Fehler in dieser Sub?
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

# Zahlen der Form 12345 bzw. 77.9 in für Vergleich notwendige Schreibweise 12345.00 bzw. 77.90 umwandeln sub toVolleZahl { my $wert = $_[0]; # ALLE " " (Leerzeichen) entfernen $wert =~ s/\s//g; # falls in der Form: (beliebig viele Zahlen von 0-9).(zwei Zahlen von 0-9) --> bereits richtig if ($wert =~ /\d*\.\d\d/) { return $wert; } # falls $wert gleich: (beliebig viele Zahlen von 0-9) kein Punkt elsif ($wert =~ /\d+^\./) { $wert .= ".00"; return $wert; } # falls $wert gleich: (beliebig viele Zahlen von 0-9).(eine Zahl von 0-9) elsif ($wert =~ /\d+\.\d/) { $wert .= "0"; return $wert; } }
Danke!
- renee
  
  2010-02-10 14:06
  User since
  2003-08-04
  14371 Artikel
  ModeratorIn
  Schau Dir mal sprintf an...
  
  Code (perl): (dl )
  
  1 2
  
  my $zahl = sprintf "%.2f", 123; my $zahl2 = sprintf "%.2f", 1.2;
  
  OTRS-Erweiterungen (http://feature-addons.de/)
  Frankfurt Perlmongers (http://frankfurt.pm/)
  --
  
  Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
  Perl-Entwicklung: http://perl-services.de/
- +6 replies
- bianca
  
  2010-02-10 14:06
  
  User since
  2009-09-13
  6978 Artikel
  BenutzerIn
  
  Guest Thomas
  Das Problem ist, dass die ausgelesenen Zahlen z.B. 234.00 lauten, die berechneten Werte aber 234 sind und der Vergleich damit fehlschlägt.
  
  Nummerische Werte vergleicht man in Perl mit ==
  Und 234.00 == 234 ist true.
  Probier mal aus: print "OK" if 234.00 == 234;
  Regex würde ich nur zum entfernen des Dezimalpunktes und Wandlung des Kommas verwenden. Ansonsten mit == vergleichen.
  10 print "Hallo"
  20 goto 10
  - +5 replies
  - betterworld
    
    2010-02-10 14:08
    
    User since
    2003-08-21
    2613 Artikel
    ModeratorIn
    
    2010-02-10T13:06:52 bianca
    Und 234.00 == 234 ist true.
    
    Quizfrage: Warum ist auch 234.00 eq 234 true?
    Lieblingsmodule: IPC::System::Simple, Path::Class
    - bianca
      
      2010-02-10 14:08
      
      User since
      2009-09-13
      6978 Artikel
      BenutzerIn
      
      2010-02-10T13:08:14 betterworld
      Quizfrage: Warum ist auch 234.00 eq 234 true?
      
      Weil es in der Syntax nicht als String verglichen wird?
      10 print "Hallo"
      20 goto 10
    - +3 replies
    - sid burn
      
      2010-02-10 14:29
      
      User since
      2006-03-29
      1520 Artikel
      BenutzerIn
      
      Weil dort die gleichen zahlen stehen und die String Repräsentation von beiden die gleiche ist.
      Dein Vorposter hätte für einen besseren vergleich wohl
      
      Code: (dl )
      
      "234.00" eq "234"
      
      schreiben sollen. Bzw hat er das wohl auch gemeint.
      Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
      - +2 replies
      - bianca
        
        2010-02-10 14:37
        
        User since
        2009-09-13
        6978 Artikel
        BenutzerIn
        
        2010-02-10T13:29:47 sid burn
        Dein Vorposter hätte für einen besseren vergleich wohl
        
        Code: (dl )
        
        "234.00" eq "234"
        
        schreiben sollen.
        
        Nö, wollte ich eigentlich nicht. Ich wollte zeigen, dass unterschiedlich aussehende Werte bei einem == Vergleich trotzdem true sind.
        Du zeigst hier, dass gleiche nummerische Werte bei einem Stringvergleich mit eq false sind.
        Last edited: 2010-02-10 14:38:43 +0100 (CET)
        10 print "Hallo"
        20 goto 10
        
        sid burn
        
        2010-02-10 15:00
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Hmm, okay anstatt dem "eq" meinte ich aber "==" in meinen Beispiel. Durch die ganzen aussagen wer wie was meinte kommt man selber durcheinander!
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
- betterworld
  
  2010-02-10 14:06
  
  User since
  2003-08-21
  2613 Artikel
  ModeratorIn
  
  Du musst die Zahlen nicht in eine bestimmte Form umwandeln, um sie zu vergleichen.
  
  Wenn Du die Zahlen mit "==" vergleichst, ist es egal, ob sie mit ".00" am Ende da stehen oder nicht, weil "==" numerisch vergleicht. Vermutlich hast du "eq" benutzt. Das vergleicht Strings, achtet daher auch auf Sachen wie ".00".
  
  Der Tausenderpunkt und das Komma sind hingegen für "==" nicht gut, das muss man schon von "12.345,67" nach "12345.67" umwandeln vorher. Aber das geht ja leicht.
  Lieblingsmodule: IPC::System::Simple, Path::Class
- +11 replies
- renee
  
  2010-02-10 14:07
  
  User since
  2003-08-04
  14371 Artikel
  ModeratorIn
  
  Guest Thomas
  Zahlen. Das Problem ist, dass die ausgelesenen Zahlen z.B. 234.00 lauten, die berechneten Werte aber 234 sind und der Vergleich damit fehlschlägt.
  Wie sieht Dein Vergleich denn aus?
  OTRS-Erweiterungen (http://feature-addons.de/)
  Frankfurt Perlmongers (http://frankfurt.pm/)
  --
  
  Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
  Perl-Entwicklung: http://perl-services.de/
  - +10 replies
  - Gast Thomas
    
    2010-02-10 14:34
    Mein Vergleich sieht so aus (vereinfacht):
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8
    
    if ($summe_berechnet == $summe_ausgelesen) { print "richtig"; } else { print "Fehler"; }
    
    Das Seltsame ist, ich hatte den Vergleich schon vorher mit == probiert, bekomme da aber Fehlermeldungen, wenn die Werte scheinbar genau gleich (!) sind.
    
    Also z.B.
    (18262.94) stimmt NICHT mit errechnetem Wert (18262.94) überein.
    Aber dafür klappt es mit:
    (77.90) stimmt mit errechnetem Wert (77.9) überein.
    
    Das kann doch nicht sein, oder gibt Perl mir da nicht die ganze Variable aus?
    - +3 replies
    - murphy
      
      2010-02-10 15:56
      
      User since
      2004-07-19
      1776 Artikel
      HausmeisterIn
      
      Es ist gut möglich, dass Du hier auf das altbekannte Problem stößt, dass nicht jeder Dezimalbruch exakt als binäre Fließkommazahl repräsentiert werden kann, Berechnungen mit Fließkommazahlen meist mit einer gewissen Ungenauigkeit behaftet sind und Vergleiche zwischen Fließkommazahlen auf Gleichheit daher im Allgemeinen keine gute Idee sind.
      
      Man sollte entweder auf "Fastgleichheit" mit passender Toleranz prüfen (z.B. abs($x - $y) < 0.001) oder, wenn man exakte Ergebnisse braucht, nicht nur exakt vergleichen sondern auch exakt rechnen, also mit Ganzzahlen oder exakten Brüchen.
      When C++ is your hammer, every problem looks like your thumb.
      - +2 replies
      - Gast Thomas
        
        2010-02-10 16:06
        
        Komisch ist doch aber, dass ich ja mit Euro-Werten rechne, die nur zwei Nachkommastellen haben und diese auch nur addiere, kann es in diesem Fall auch zu solchen Ungenauigkeiten kommen? Ich beantworte das mal selbst mit "ja". :-)
        
        Dann könnte ich ja wieder auf meine Eingangsidee mit den Stringvergleichen zurückkommen, oder?
        
        murphy
        
        2010-02-10 16:21
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        Ja, es kann auch in diesem Falle zu Ungenauigkeiten kommen, nämlich dann, wenn Du mit Werten hantierst, deren fraktionaler Anteil nicht exakt binär darstellbar ist.
        
        Zum Beispiel ist für Perl 0.30 != 0.20 + 0.10, denn auf die maximale Genauigkeit der Fließkommazahlen gerundet bedeutet dieser Vergleich eigentlich 0.29999999999999999 != 0.20000000000000001 + 0.10000000000000001 == 0.30000000000000002.
        
        Wenn Du jetzt mittels sprintf auf eine feste Anzahl von Stellen rundest und dann Strings vergleichst, wirst Du manche der möglichen Fehler bei Fließkommaoperationen vermeiden, aber nicht alle. Es gibt in diesem Forum dutzende alter Threads die sich mit der Problematik von Rundungsfehlern und Währungsberechnungen auseinandersetzen. Suche einfach mal danach, wenn Du mehr Informationen haben willst. Die kurze Antwort ist aber die, die ich Dir schon gegeben habe: Willst Du mit exakten Dezimalbrüchen rechnen, dann tue das auch. Benutze keine Fließkommazahlen sondern Ganzzahlen oder Brüche.
        When C++ is your hammer, every problem looks like your thumb.
    - +6 replies
    - betterworld
      
      2010-02-10 16:14
      
      User since
      2003-08-21
      2613 Artikel
      ModeratorIn
      
      Lass die Werte mal direkt vor dem Vergleich mit Devel::Peek ausgeben, also so:
      
      Code: (dl )
      
      1 2
      
      use Devel::Peek; Dump($x);
      
      Edit: Sorry, das bringt wohl auch nichts bei dem von murphy beschriebenen Floating-Point-Problem. Identifizieren koennte man es vielleicht, in dem man zudem noch unpack "H*", pack "F", $x ausgibt.
      
      Edit2: Oder mit printf, wie in diesem Beispiel:
      
      Code: (dl )
      
      1 2 3 4 5 6 7 8 9
      
      $ perl -lwe 'use Devel::Peek; my $x = 15; $x += .1 for 1..10; Dump $x; print $x; printf "%.20f\n", $x' SV = PVNV(0x8151ff0) at 0x814f69c REFCNT = 1 FLAGS = (PADBUSY,PADMY,NOK,pNOK) IV = 15 NV = 16 PV = 0 16 15.99999999999999644729
      
      Last edited: 2010-02-10 16:33:16 +0100 (CET)
      Lieblingsmodule: IPC::System::Simple, Path::Class
      - +5 replies
      - Gast Thomas
        
        2010-02-10 16:24
        
        Das sollte die berechnete Variable sein:
        
        Code: (dl )
        
        1 2 3 4 5 6
        
        SV = PVNV(0x3e85e4) at 0x9bb754 REFCNT = 1 FLAGS = (PADMY,NOK,pNOK) IV = 18035 NV = 18262.94 PV = 0
        
        und das die ausgelesene:
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8
        
        SV = PVNV(0x3e862c) at 0x980e1c REFCNT = 1 FLAGS = (PADMY,POK,pPOK) IV = 0 NV = 0 PV = 0x9806e4 "18262.94"\0 CUR = 8 LEN = 12
        
        +4 replies
        
        betterworld
        
        2010-02-10 16:28
        
        User since
        2003-08-21
        2613 Artikel
        ModeratorIn
        
        Guest Thomas
        Das sollte die berechnete Variable sein:
        
        Code: (dl )
        
        1 2 3
        
        IV = 18035 NV = 18262.94
        
        OK, da IV und NV sich offenbar unterscheiden, nehme ich mal an, dass Du mit dieser Variable Berechnungen durchgefuehrt hast (etwa mit "+="). Dadurch kann sehr gut ein Rundungsfehler entstanden sein. Wie ich schon im Edit oben schrieb, sieht man das ansonsten leider nicht genau in der Devel::Peek-Ausgabe.
        Lieblingsmodule: IPC::System::Simple, Path::Class
        
        +3 replies
        
        Gast Thomas
        
        2010-02-10 16:40
        
        Genau, mit der berechneten Variablen hab ich Berechnungen ausgeführt (wie Du richtig erkannt hast verschiedene Werte aufsummiert), die ausgelesene Variable wurde aus dem Textfile so übernommen.
        
        Ein
        
        Code (perl): (dl )
        
        print (unpack "H*", pack "F", $summe_berechnet);
        
        gibt
        
        Code: (dl )
        
        90c2f528bcd5d140
        
        aus, ein
        
        Code (perl): (dl )
        
        print (unpack "H*", pack "F", $summe_ausgelesen);
        
        dagegen ein
        
        Code: (dl )
        
        8fc2f528bcd5d140
        
        .
        
        Was hat das denn zu bedeuten?
        
        +2 replies
        
        betterworld
        
        2010-02-10 17:01
        
        User since
        2003-08-21
        2613 Artikel
        ModeratorIn
        
        Ja, 90c2f528bcd5d140 entspricht 18262.94000000000232830644, da ist also hinten noch was los, was bei der gewoehnlichen Stringdarstellung nicht mit ausgegeben wird. Sorry wegen der pack- und Dump-Geschichten, ich haette mal gleich auf printf kommen sollen, das ist wohl die einfachste Moeglichkeit, den Unterschied zu sehen.
        
        murphy's abs()-Trick sollte auf jeden Fall helfen.
        Lieblingsmodule: IPC::System::Simple, Path::Class
        
        Gast Thomas
        
        2010-02-11 09:01
        
        Ja, vielen Dank, das funktioniert wunderbar.
        Danke für Eure Hilfe!

View all threads created 2010-02-10 13:59.