Seite 1 von 2
int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 00:29
von broozar
Code: Alles auswählen
Result$=Str(Int((ValF("0.7"))*100))
Debug (ValF("0.7"))
Debug ((ValF("0.7"))*100)
Debug Int((ValF("0.7"))*100)
MessageRequester ("ValF error!", "according to pb, Int ValF of 0.7 * 100 is "+Result$)
bei mir kommt da hinten 69 raus. bug oder soll das so sein?
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 00:38
von ts-soft
broozar hat geschrieben:bei mir kommt da hinten 69 raus. bug oder soll das so sein?
Ist doch kein Bug, ergebnis ist doch korrekt!
PC ist ja kein Taschenrechner und käufmännisches Runden ist ihm auch fremd.
Rundungsfunktionen findeste in der Math-Lib.
Gruß
Thomas
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 00:52
von broozar
das ergebnis ist korrekt.... ? schau dir mal die zwischenergebnisse an -
Debug (ValF("0.7")) --> 0.6999999irgendwas (damit kann ich ja noch leben)
Debug ((ValF("0.7"))*100) --> 70.0 (so soll's sein)
Debug Int((ValF("0.7"))*100) --> 69 (wie das? seit wann ist der ganzzahlige teil von 70.0 gleich 69?)
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 00:55
von Schlumpf
schau dir mal dieses Zwischenergebnis an:
und wenn du dort mit Int() die Nachkommastellen abschneidest, bekommst du das was du hast.
also, dein Ergebnis ist tatsächlich korrekt.
wenn du es einfach debuggst, ohne StrD() (oder StrF), dann wird der Inhalt der FPU an die Quad von Debug übertragen, dabei wird gerundet, deshalb hast du da ne 70.
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 00:58
von hjbremer
eine Frage der Reihenfolge, wie Ausdrücke ausgewertet werden.
Es ist, wie es ist und traue niemals einem Computer
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 01:01
von ts-soft
0.7 kann ein PC nicht speichern, es wird immer sowas wie 0.69999... sein.
Und automatische Aufrunden gibts auch nicht, somit ist 69 das einzig
logische Ergebnis.
Besser wäre es, mit Ganzzahlen zu rechnen und die Kommas einfügen.
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 01:14
von STARGÅTE
Aber auch bei ganzen zahlen auf die Reihenfolge achten !
Ist 0 ! denn Wert ist ganzzahlig, und wird dann duch 100 dividiert -> 20/100 = 0.2, kennt er aber nicht, also 0 : 0*1000 immer noch 0
Der Compiler macht also
nicht aus /100*1000 eine *10 !
also in diesem Fall wieder Float oder immer erst größer machen und dnan kleiner
Das gitl auf bei Abfragen unterschiedlicher Typen:
a steht ganz links wird also auch als VergleichsType angesehen also Ganzzahlig, damit wird b zu 2.
deswegen so:
Oder gleich mit gleichen Typen Auswerten !
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 02:02
von broozar
@brehmer - so werd ich das dann wohl machen. aber seltsam, dass er trotz ausführlichem klammersetzens die reihenfolge offensichtlich umstellt.
@ts - ganzzahlen stehen mir leider nicht zur verfügung, ich lese diese 0.7 aus eine config-datei ein (daher auch der spaß mit dem string).
@stargate - links-nach-rechts-auswertung ist klar. aber ich dachte, die reihenfolge würde durch meine klammern vorgegeben.
danke euch allen!
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 02:11
von Schlumpf
Reihenfolge etc... alles schon richtig.
aber du hast niemals eine 70, immer eine 69.9999988079
bei deinem zweiten Debug bekommst du nur deshalb eine 70 angezeigt, weil das Debug aus irgendwelchen gründen bei der Anzeige gerundet hat.
aber wenn du es als Argument für Int() verwendest, verwendest du wieder die 69.9999988079
Re: int rundungsfehler... in dem bereich?
Verfasst: 21.03.2010 02:14
von ts-soft
broozar hat geschrieben:@ts - ganzzahlen stehen mir leider nicht zur verfügung, ich lese diese 0.7 aus eine config-datei ein (daher auch der spaß mit dem string).
Naja, ist ja nicht das problem:
Code: Alles auswählen
value.s = "0.70"
kommazahlen.s = StringField(value, 2, ".")
lenght = Len(kommazahlen)
newvalue = Val(StringField(value, 1, ".") + kommazahlen)
Select lenght
Case 0 : multiplikator = 0
Case 1 : multiplikator = 10
Case 2 : multiplikator = 100
EndSelect
Debug newvalue
Debug multiplikator
geht bestimmt noch besser
