Anomalien und Bugs - XppBUG : int()

[CRT]

Anomalie der Funktion int() in Xpp 1.9.355

Code: Alles auswählen

round(71.1,2)*100 = 7110.00
int(round(71.1,2)*100) = 7109 statt 7110

lg
CRT

[Werner_Bayern]

auch in 2.0 (CTP4R3).

[brandelh]

Das liegt am verwendeten von Xbase++ verwendeten numerischen Datentyp DOUBLE

Oft beschrieben ist es so ärgerlich wie eine Tatsache, der Computer rechnet nicht mit den Zahlen die er uns anzeigt, sondern den internen bits.
Um das Problem zu beseitigen müsste Alaska die DOUBLE (8 Byte) durch EXTENDED (10 Byte) ersetzen
PowerBasic hat das getan und dort gibt es die Diskussionen nicht mehr
Bei WinDev kann man sich den Typ aussuchen (bei PowerBasic auch), Xbase++ nutzt DOUBLE, wenn Nachkommastellen nötig sind.

Was passiert genau ?

71.1 ist eine DOUBLE, da ein Nachkommastellen bzw. der Punkt angegeben wurde. Somit sind alle Berechnungen ungenau !
round(71.1,2 ) eine Rundung auf die 2. Nachkommastelle macht es nicht besser ! Auch dieses Ergebnis ist ungenau ... 71.09??????? * 100 ...
wenn nun INT() die Nachkommastellen abschneidet, bleibt 71.09 bzw. 7109 über ...
Nur wenn man intern mit LONG rechnet (also keine Nachkommastellen angibt oder nach ROUND(x,0) ) stimmt das Ergebnis.

Code: Alles auswählen

round(71.1,2 ) * 100              7110,00
round(711,0  ) *  10              7110
int( round(71.1,2 ) * 100 )       7109
int( round(711,0  ) *  10 )       7110

http://de.wikipedia.org/wiki/Doppelte_Genauigkeit

Wie kann man das umgehen ?

Je nach Berechnungsart kann man z.B. alle Beträge in CENT berechnen :

nBetrag := 7110 // CENT statt 71.10 Euro
... alle möglichen Berechungen mit INTEGER Variablen oder ROUND( , 0) korrigierten Ergebnissen
? "Die Rechnung beträgt ",TransForm( nBetrag/100 , "###,###.##" ), nBetrag/100

[CRT]

Eigentlich erwarte ich von int() nur das abtrennen der Nachkommastellen eines existierenden korrekten Wertes.
Aber trotzdem danke für die Erklärung.
Da gibt es in Xbase noch einige solcher Anomalien und auch inkompatibles Verhalten zu Clipper bzw. den CT-III.

[brandelh]

ich bin mir 100% sicher, dass Clipper genau das gleiche Ergebnis liefert, einfach weil es beim gleichen Datentyp die Nachkommastellen wegnimmt.
Aber natürlich vom INTERNEN Wert der Variablen, nicht dem was angezeigt oder im Hirn (dezimal) gedacht wird

[brandelh]

... und sicherheitshalber habe ich meinen alten XP Rechner gestartet und es ausprobiert:

Code: Alles auswählen

Clipper (R) 5.2e
Copyright (c) 1985-1995, Computer Associates International, Inc.
Microsoft C Floating Point Support Routines
Copyright (c) Microsoft Corp 1984-1987.  All Rights Reserved.
306K available
Compiling TEST.PRG
Code size 176, Symbols 64, Constants 192
 __   __
(«») («»)      BLINKER Dynamic Overlay / Windows Linker 3.10
    ¦                        + DOS Extender
   ___                 Blink and you'll miss it !!

Copyright (c) Assembler Software Manufacturers, Inc. 1990-94
Alle Rechte vorbehalten. Serien-Nr. ER-....... Deutsche Version.

BLINKER : Linken war erfolgreich

TEST.EXE (156 Kb) (0.1 Sekunden)
D:\TEMP>test

round(71.1,2 ) * 100              7110.00
round(711,0  ) *  10              7110
int( round(71.1,2 ) * 100 )       7109                                          
int( (round(71.1,2 ) * 100) )       7109                                        
int( round(711,0  ) *  10 )       7110                                          

ich würde es auch vorziehen, wenn Xbase++ dieses Verhalten mit EXTENDED Variablen verbessern würde, das wäre dann aber nicht mehr Clipper Kompatibel

[CRT]

Blinker
Die Inkompatibilität habe ich bei anderen Funktionen festgestellt. Müsste mal nachschauen welche das waren.

[Tom]

Die philosophische Frage an dieser Stelle lautet: Geht Kompatibilität zu weit, wenn sie auch die Fehler des Originals abbildet?

[CRT]

@Tom: Besser darf es werden, schlechter nicht

[Herbert]

Eigentlich erwarte ich von int() nur das abtrennen der Nachkommastellen eines existierenden korrekten Wertes.
Aber trotzdem danke für die Erklärung.
Da gibt es in Xbase noch einige solcher Anomalien und auch inkompatibles Verhalten zu Clipper bzw. den CT-III.

Genau das macht INT() ja.

Man muss unter den gegebenen Umständen die Formeln passend definieren.
int(round(71.1,2)*100)
macht keinen Sinn.
int(round(71.1,2))*100
ist logischer - und dann auch "korrekt"

@Hubert: Variablen derart in den internen Platzansprüchen aufzublasen, ist nicht gut. Trotz heute fast endlos Adressraum würde dies die Programme entsprechend vergrössern. Insbesondere weil wir hier als Ergebnis eine simple Integer erhalten welche mit einer anderen Integerzahl und einer kleinen Real-Zahl berechnet wird.

Eine Variable mit 10 Bytes gibt dir 23 signifikante Ziffern. 8 Byte Real benutzen maximal "nur" 15, und eine 4 Byte Real bis zu 6.
Zählt eure numerischen Varialben zusammen und ihr würdet auf einen recht hohen zusätzlichen Speicherbedarf kommen.

Deshalb wird empfohlen, nur bei hochgenauen Berechnungen die 10-byte-Speichervariablen zu verwenden (vorausgesetzt es gibt sie).

[Herbert]

PowerBasic hat das getan und dort gibt es die Diskussionen nicht mehr

Interessant, dass Manfred deine Verweise auf Fremdprodukte toleriert aber bei mir dann gleich ausrastet, wenn ich das Wort W... erwähne. Gut dein Programm ist keine Konkurrenz zu Alaska

[Manfred]

Das habe ich gelesen, Herbert.

Aber wenn Du meine Kommentare dsbzgl. als Ausrasten ansiehst, dann sei bloß sehr weit weg, wenn ich mich mal wirklich aufrege.

[brandelh]

Interessant, dass Manfred deine Verweise auf Fremdprodukte toleriert aber bei mir dann gleich ausrastet, wenn ich das Wort W... erwähne.

Manfred, wer ist Manfred ... ach ja der, der immer die Icons vergisst wenn er einen Scherz macht

Du darfst auch schreiben was du willst ... ab und zu klingt es halt etwas spöttisch warum wir Deppen (meine Interpretation) noch bei Xbase++ geblieben sind
Der eine oder andere liest etwas mehr und fühlt sich angegriffen ... aber hier darf man schreiben was man will

PS: 10 Byte EXTENDED gegen 8 Byte DOUBLE ...

da muss ich dir wirklich widersprechen, die 2 Byte je Fließkommazahl machen den Bock nicht fett !
Selbstverständlich hat man selten so große Zahlen, aber 15 Stellen bei DOUBLE bedeuten eben auch, dass die Nachkommastellen schon bei kleineren Beträgen gerundet werden müssen.
Ich habe vor langen Jahren eine Zinsberechnung programmiert (im Sozialversicherungsrecht geht das anders als bei der Bank), die monatlich die Zinsen berechnet und gedruckt hat.
Bei jedem Monat musste ich runden damit das Endergebnis stimmte, diesen Ärger hätte ich mir ersparen können ...

Und selbstverständlich nimmt man INTEGER (LONG 32 bit) bei aktuellen Betriebssystemen wenn man keine Fließkommazahlen braucht, aber schon die Verwendung von 1 (BYTE) oder 2 Byte (INT) Variablen ist langsamer als 4 Byte LONG und natürlich bläht das ein altes 8 bit Programm auf, wenn es jetzt 32 bit LONG nutzen muss ...
und 64 Bit Compiler rücken näher, dann haben wir 8 Byte Integer ... aber so ist das nunmal.

Alles wäre besser als die ewigen Diskussionen warum 17/3*3 nicht 17 ergibt

[brandelh]

und ausgerechnet bei dem Beispiel zeigt Xbase++ auch noch tatsächlich 17 an

[Herbert]

Das habe ich gelesen, Herbert.

Aber wenn Du meine Kommentare dsbzgl. als Ausrasten ansiehst, dann sei bloß sehr weit weg, wenn ich mich mal wirklich aufrege.

Ok hab ich verstanden =D>

[Jan]

Hey Jungs,

seid mal wieder lieb zueinander.

Herbert lobt in diesem Forum ja seine jetzige Programmierumgebung garnicht nicht mehr über den Klee und denunziert dabei seine vorige. Im Gegenteil, wie gewohnt gibt er zielgerichtete Hinweise bei Problemen, die Entwickler hier schildern. Und wenn Manfred jetzt sein dünnes Fell in dieser Angelegenheit wieder etwas dicker wachsen läßt, können wir alle wieder Freunde sein.

Sachlich kann man über andere Sprachen immer reden. Egal ob direkte Wettbewerber zu der Sprache, deren Namen dieses Forum trägt, oder ganz was anderes. Das darf nur bei keiner der beteiligten Parteien in Pseudo-Fanatismus mit entsprechenden bösen Worten, Anschuldigungen, Beleidigungen, Kränkungen, oder sonstigen Nettigkeiten enden.

Jan

[brandelh]

Genau JAN

darum sind wir hier ja auch gerade KEIN HERSTELLER Forum ... Im PowerBasic Forum wurden schon einige meiner Meldungen gelöscht,
weil ich z.B. erwähnte, dass Basic4Android für Android Geräte eine passable Entwicklungsumgebung ist. PowerBasic IST ein Win32 Compiler wie Xbase++, der KANN NIE auf Android laufen ...
Andere durften Ihr Basic4PHP erwähnen, sogar verkaufen ohne Rüffel ...

Fanatiker sind immer ein Übel, wenn man seine EINBILDUNG (nichts anderes ist Fanatismus in meinen Augen) über alles andere stellt, kann nur Übles daraus entstehen.

[Herbert]

Hey Jungs, seid mal wieder lieb zueinander.

Sind wir doch, Jan. Das war doch nur ein wenig auf die Schippe genommen (von beiden).

[Herbert]

Um nochmals auf das eigentliche Problem zurück zu kommen:
Man könnte auch auf eigene Art runden (als Idee):

Code: Alles auswählen

IF val-INT(nval) < -0.04
  nval := INT(nval)+1 
ELSE
  nval:=INT(nval)
END

[Manfred]

Sind wir doch, Jan. Das war doch nur ein wenig auf die Schippe genommen (von beiden).

wo er Recht hat, hat er Recht.

[CRT]

Anomalie der Funktion directory() in Xpp 1.9.355

Code: Alles auswählen

Directory("LM*.DBF") 
--> liest fälschlicher Weise auch z.B. "LÖM*.DBF"

[Leon]

Um nochmals auf das eigentliche Problem zurück zu kommen:
Man könnte auch auf eigene Art runden (als Idee):

Code: Alles auswählen

IF val-INT(nval) < -0.04
  nval := INT(nval)+1 
ELSE
  nval:=INT(nval)
END

Ich löse das mit einer eigenen Funktion:

Code: Alles auswählen

FUNCTION INTEGER(nZahl)
RETURN VAL(LEFT(STR(nZahl, 21, 10), 10))

round(71.1,2)*100 = 7110.00
int(round(71.1,2)*100) = 7109 statt 7110
integer(round(71.1,2)*100) = 7110

[CRT]

So ähnlich habe ich das auch gelöst, nur nicht als funktion.
lg