Opened by bianca at 2013-04-27 13:42
User since
2012-05-04
1054 Artikel
BenutzerIn
2012-05-04
1054 Artikel
BenutzerIn
Was ist denn das wieder für ein Code? Das Ergebnis ist völlig richtig, nämlich ungleich 0. Es gibt in Perl zu einem Skalar sowohl eine String- als auch eine Zahl-Repräsentation.
Wir haben hier:
100000 + -1.45519152283669e-011 (2 VZ ohne Klammer sieht irgendwie eklig aus)
Die Standard-Stringrepräsentation hat nur eine bestimmte Anzahl Stellen und ist 100000. Deine Zahl ist aber kleiner.
Deine Integer-Funktion ist falsch, die tut in diesem Fall gar nichts. Denn in der String-Repräsentation ist ja einfach kein . drin. Daher wird der Wert so returned wie er reinkommt.
Was spricht gegen die Perl-eigenen Funktionen zum (Ab-, Auf-)Runden?
Abgesehen davon, dass dein Code falsch ist, ist er auch noch ineffizient. Warum eine Zahl in einen String wandeln und dann ggf. wieder zurück, wenn man auch direkt mit der Zahl rechnen kann?
Last edited: 2013-04-27 14:05:47 +0200 (CEST)
Wir haben hier:
100000 + -1.45519152283669e-011 (2 VZ ohne Klammer sieht irgendwie eklig aus)
Die Standard-Stringrepräsentation hat nur eine bestimmte Anzahl Stellen und ist 100000. Deine Zahl ist aber kleiner.
Code: (dl
)
1
2
3
4
$ perl -wE'say 100000 + -1.45519152283669e-011'
100000
$ perl -wE'say sprintf("%.12f",100000 + -1.45519152283669e-011)'
99999.999999999985
Deine Integer-Funktion ist falsch, die tut in diesem Fall gar nichts. Denn in der String-Repräsentation ist ja einfach kein . drin. Daher wird der Wert so returned wie er reinkommt.
Was spricht gegen die Perl-eigenen Funktionen zum (Ab-, Auf-)Runden?
Abgesehen davon, dass dein Code falsch ist, ist er auch noch ineffizient. Warum eine Zahl in einen String wandeln und dann ggf. wieder zurück, wenn man auch direkt mit der Zahl rechnen kann?
Last edited: 2013-04-27 14:05:47 +0200 (CEST)