CDbl will Komma statt Punkt zur Dezimalentrennung???

[Gandhi]

Hallo,
jetzt bin ich baff.
CDbl wandelt "0.5" in 5 und "0,5" in ,5 um.
Kann man irgendwo auf dem Server einstellen, wie die Dezimalen beim Script verwendet werden sollen??
Oder ist es schon zu spät für mich heute...
Btw: Version ist 8.5.1 - Client wie Server - interessanterweise englisch.

[Gandhi]

Nur mal so mein Script, das ich hier testweise aufgesetzt habe:

Code

Dim d1 As Double, d2 As Double, d3 As Double, d4 As Double
	d1=CDbl("0,5")
	d2=CDbl(".5")
	d3=CDbl("1.5")
	d4=CDbl("1.5E1")

liefert:
,5
5
15
150

[m3]

Dazu hatte ich schon mal einen PMR offen. Das ist alles eher zaaaach. Ich schaus Dir am Montag in meiner Büromail nach.

Was sagt denn international.DecimalSep ?

Welches OS mit welchen Language settings ist unter dem Domino bzw. Notes? AFAIK wird der DecimalSeperator über die OS-Einstellungen definiert. Wenn dort alles auf Deutsch ist hast Du, nach einem Server-Restart, auch das richtige Komma.

[koehlerbv]

Strings sind kein "Aufbewahrungsort" für Zahlen oder Datumswerte. Das sieht man hier wieder sehr deutlich. Wenn im OS das Komma als Dezimalseparator vereinbart ist, passiert genau das, was hier beschrieben wird. LotusScript (wie auch andere Programmiersprachen) versuchen dann bei der Konvertierung, andere eliminierbare / vverzichtbare Zeichen zu ignorieren - in diesem Falle eben den Punkt.

Meines Erachtens ist das Beobachtete normal und regelkonform und nachvollziehbar.

Bernhard

[Gandhi]

Mit Verlaub Bernhard: Das ist Blödsinn:

Der Text ist da drin, weil ich das als String über einen Webagenten - aus dem Netz erhalte. Soweit ich weiß kann http (in dem Fall post) nur text - den ich dann an der ersten möglichen Stelle umwandle.
Und dass in ALLEN Programmierumgebungen IMMER Dezimalen mit '.' getrennt werden - ist schlicht ein stillschweigender Standard.

Ganz abgesehen davon, was das für Probleme bereitet (denn soweit beachtet war das bislang nicht der Fall):
Ich habe eine Applikation, die seit - sagen wir Version 6.5 wunderbar arbeitet.
Jetzt date ich auf 8.5.1 auf - und schwupps sind die Zahlen (bei zwei Dezimalen) hundertmal so groß. Dann überweise ich mal schnell hundert mal so viel Geld wie vorher....

Danke. Wenn ich jetzt vor der Wahl stehen würde Domino oder überhaupt IBM Software einzuführen - würde ich ganz klar abwinken.

Die Client Einstellungen gehen übrigens tatsächlich über das BS - vielen Dank für den Hinweis! (wie ist das eigentlich, wenn da unterschiedliche Einstellungen aufeinandertreffen? In den Dokumenteneigenschaften steht auch ein Komma - wird das dann anders dargestellt?) - wegen der Servereinstellungen suche ich noch (das ist ein Testsystem, dass auf einem VM-Ware Client läuft - zum Glück Test System).

Ich stehe hier ob dieses Fehlers wirklich fassungslos (nicht weil es ein großes Problem wäre) vor dem Rechner und glaube einfach mal wieder nicht, was für einen SCHEISS die IBM hier wieder gemacht hat. Das ist doch wohl ganz klar das Produkt eines Hirnlosen!

Sorry - solche Internationalisierung - an dieser Stelle - hilft garniemandem.

Werde jetzt meine eigene CDbl Funktion schreiben - vermutlich gucke ich, was pi für einen Trenner hat - und agiere dann entsprechend.

[koehlerbv]

Marco, das ist kein Blödsinn, sondern einfache Realität. Es gibt ein Trennzeichen. Das wird lokal definiert. Du bekommst Text. Das ist bei HTTP normal, aber trotzdem bescheiden. LS ist abstrakt und weiss von all diesen Problemen nichts.

Ich habe daher auch eigene Konvertierungsroutinen für Zahlen und Datumswerte. Und dass der Punkt in *allen* Programmiersprachen der fixe Dezimalstellen-Separator ist, kann ich nicht bestätigen.

Bernhard

[Gandhi]

Er war es bislang immer - was zu vollkommen unklaren Problemen führen kann.
Wenn er wenigstens einen Fehler schmeißen würde...

[koehlerbv]

Ich habe Deinen Code eben mit 7.0.2 (locale: German) nachvollzogen: Gleiches Ergebnis wie bei Dir. Eine Versionsabhängigkeit kann ich erstmal nicht nachvollziehen. Ich probiere das auch gerne mit 5.0.8 ...

Es ist doch wie bei "09.12.2010" und Cdat. Was hinten dabei herauskommen kann, ist doch bekannt. Und solange HTTP mit dem Textwert eines Nicht-Text-Datentyps keine weiteren Infos mitliefert, hilft doch nur ein Parser oder eine vor dem Datenaustausch verbindliche Übereinkunft der Systeme. Ich verstehe insofern das Problem wirklich nicht, weil es alltäglich ist.

Bernhard

[Gandhi]

Tja, die Idee mit dem Pi war auch nicht so toll - DAS IST NÄMLICH LT MEINEM SERVER 3.14
Während CDBL Munter in 0,... umwandelt.

Haben wir jetzt einen Bug?

[Glombi]

Und dass in ALLEN Programmierumgebungen IMMER Dezimalen mit '.' getrennt werden - ist schlicht ein stillschweigender Standard.

Das ist auch in LotusScript so.
Dim d1 as Double

d1 = 1,5   liefert beim Speichern des Scripts einen Fehler - egal wie die BS Einstellung ist!
d1 = 1.5 funktioniert - egal wie die BS Einstellung ist!

d1 = cdbl(".5")
Wird ja zur Laufzeit interpretiert. Der Interpretor greift korrekterweise auf die BS Einstellung zurück und findet bei mir bspw. das "." als Tausendertrennzeichen. Also ist d1 = 5.

Ich kann hier nicht das Produkt eines Hirnlosen erkennen.


Andreas

[flaite]

Mein Vorgesetzter hatte genau damit große Probleme in einer Webanwendung mit dojo.
Es hing von sehr vielen Faktoren ab wie Domino Strings internationalisierte. Ich bekomme es nicht mehr hin. Vermutlich sollte er darüber bloggen. Es war nämlich echt  kompliziert, was er da herausgefunden hat.
a h
Es stimmt natürlich, dass die meisten Programmiersprachen intern die englischen Regeln verwenden. Nur ist das hier irrelevant. Sobald du die Zahl über http schickst mußt du sie erst in einem String umwandeln, um sie dann im empfangenen wieder in einen Double umzuwandeln. Das hat nicht einmal etwas mit http zu tun, sondern mit verteilten Systemen. Zahlen werden auf diesem Planeten jede Zehntelsekunde tausendfach als Strings an andere Systeme verschickt, die sie dann als Zahlen weiterverarbeiten. Hier halte ich Bernhards Aussage für einfach nicht realistisch.

Du wirst es ja an nicht so wahnsinnig viel Stellen benötigen, Marco. Du kannst vorher eine Funktion aufrufen, die dir ermittelt mit welchem Trennzeichen CDouble auf dem System heute funktioniert:
zu Not halt auch so:

Code

function getTrenner() As String
String nmbr = "4,2"
double res = CDouble(nmbr)
if (res = 4.2) then 
return ","
else  
nmbr = "4.2"
res = CDouble (nmbr)
if (res = 4.2) then 
return "."
else 
return "?"
end if 
end if 
end if
end function 

So ungefähr, nur ohne Syntaxfehler und eleganter  

Oder vielleicht bekommst du das einfacher aus dem von Martin erwähnten international.DecimalSep.
Nun musst du im zu CDoublenden String nur das Trennzeichen in das richtige replacen.

[heini_schwammerl]

Dann überweise ich mal schnell hundert mal so viel Geld wie vorher....

Wird schon einen Grund haben das z.B. beim Online Banking immer 2 Felder (Euro- und Centbetrag) definiert sind.
Bei kleinen Projekten im deutschsprachigen Raum filtere ich in der einfachen Lösung den Punkt in der Regel vorher einfach raus. Da ich das schon ein paar Jahre mache kann die Problematik nicht neu sein. Allerdings haben sich Windows Server hier bei mir deutlich angenehmer verhalten während z.B. Linux Server früher immer rumgezickt haben und ich tw. Definitionen über die notes.ini mitgeben musste.

[Gandhi]

Ich habe das mit NotesInternational.DecimalSeparator gelöst, insofern ist das akute Problem damit für mich gelöst.
Dennoch halte ich das ganze für höchstproblematisch.
Wenn CDbl abhängig von den lokalen Einstellungen unterschiedliche Ergebnisse liefert, bedeutet das, dass jeder HTTP Transfer, also z.B. auch jeder Webservice, der mit  Zahlen arbeitet das handhaben muss - vor allem muss man erst mal wissen, dass man das handhaben muss (wenn man nur auf englischen System arbeitet wird einem das vermutlich nie ins Bewusstsein kommen - bis das System dann auf einem nicht englischen System ausgerollt wird).
Der Nutzen des Ganzen erschließt sich mir nach wie vor nicht.
Der Aufwand das zu lösen ist nicht groß und ich brauche es tatsächlich nur an 2 Stellen - aber dass das Problem existiert muss man erst mal wissen.
Ich werde mir das am Montag auf jeden Fall noch mal auf alten Versionen anschauen - mir ist das noch nie aufgefallen - und ich arbeite ja auch schon ein paar Jahre mit dem Produkt.  Ggf. ist das ein echter Fallstrick für das Upgrade auf höhere Serverversionen (wie gesagt, im Moment nur eine Vermutung).



Und nur mal so das Zitat aus der Designer Hilfe:
Datatype Doule - LotusScript:

The range of Double values is -1.7976931348623158E+308 to 1.7976931348623158E+308, inclusive.
On UNIX platforms, the range is -1.7976931348623156E+308 to 1.797693134862315E+308, inclusive.

Da steht mal gerade gar nichts darüber, dass hier unterschiedliche Dezimaltrennzeichen Anwendung finden können.
Zu cdbl steht auch nichts von Dezimaltrennzeichen.
Ich glaube also nicht, dass sich z.B. ein amerikanischer Entwickler, der ja durchaus auch für den Weltmarkt Anwendungen entwickeln kann darüber bewusst ist.

Und noch eine eindringliche Warnung:
   CStr(CDbl(CStr(PI)))
   "" & CDbl("" & PI)
kommt nicht zum gleichen Ergebnis!

Ich bin mir vollkommen bewusst, dass "" & NUMBER nicht abgesichert ist - benutzte das aber selbst häufiger im guten Glauben, dass das funktioniert (was es auch abgesehen von den Länderdezimalen bislang tat) und habe das auch schon sehr oft in fremden Code gesehen.
Mit dem nun gefundenen "Verhalten" ist das eine Bombe.

[Glombi]

Es sind schon Raumsonden ungebremst in den Marsboden geknallt, weil die Programmierer ft und m verwechselt haben.

Soweit zum Thema

Ich glaube also nicht, dass sich z.B. ein amerikanischer Entwickler, der ja durchaus auch für den Weltmarkt Anwendungen entwickeln kann darüber bewusst ist.

Bei der KW-Formatformel gibts ja auch nur die amerikanische Sichtweise. Zum Glück fahren die rechts...


Den Vorschlag, zwei getrennte Felder für EUR und Cent zu nehmen, halte ich für sehr sinnvoll. Da gibt es dann keine Missverständnisse.

Andreas

[Pyewacket]

Das böse Spiel geht noch weiter, auch bei Ucase/Lcase kann es Unterschiede geben,
je nachdem wie die aktuelle Plattform eingestellt ist.

Mit der Einstellung Deutsch oder Englisch gilt:

Ucase("i") = "I"

Ist die Ländereinstellung auf Türkisch eingestellt stimmt das nicht mehr, im
türkischen gibt es zusätzlich zu unserem grossen I noch ein grosses I mit Punkt drauf (İ).


Peter

[koehlerbv]

Wieso "böses Spiel"? Genau dafür gibt es doch die länderspezifischen Einstellungen.

Dass man dann bei Zahlen und Datumswerten in Strings auf Herausforderungen stösst, ist auch normal und fast immer ganz leicht zu vermeiden.
Die Primitivität von HTML ist eine Herausforderung, die sich aber nicht verhindern lässt.

Das Verhalten ist von Anbeginn an so und Bestandteil der Sprachdefinition(en) und ihrer Umsetzung. Mit Versionen hat das nichts zu tun.

Marco hat also nichts anderes als eine späte Erkenntnis gewonnen: Finger weg von Zahlen und Datums-/Zeitwerten in Strings, wo immer es sich nicht vermeiden lässt. Ist es nicht zu vermeiden, muss man sich der Herausforderung stellen und entsprechenden Aufwand betreiben.

Bernhard

[Gandhi]

Länderspezifische Einstellungen sind gut, solange sie nur die Interaktion mit dem Benutzer betreffen, also wenn zur Ausgabe spezielle Formate angezeigt werden und zur Eingabe bestimmte Formate angenommen werden.
Alles andere ist in meinen Augen MURKS. Meine Designerhilfe z.B. sagt etwas anderes als mein Client als mein Server.
Und bestimmte Funktionen (s.o.) funktionieren durch diese Form der Internationalisierung nicht mehr konsistent, vermutlich weil IBM da auch das eine oder andere vergessen hat. Solche Spiränzchen erhöhen das Risiko von Fehlern enorm - und noch mal die Frage: zu welchem Nutzen?

Am schlimmsten ist in der Hinsicht Excel, bei denen die Makrobefehle in unterschiedlichen Sprachen verwendet werden. Wenigstens ist es dort aber so offensichtlich, dass es niemand lange übersehen kann.
Ansonsten hat eine Programmiersprache konsistent zu sein - das sehe ich hier ganz klar nicht. Ob die Dezimale mit ., oder sonst was getrennt wird ist wurst - solange es konsistent ist.

Die Zeit im Domino wird ja auch (soweit ich weiß) als Millisekunden nach dd.mm.1950 GMT abgespeichert und nicht im Format des jeweiligen Ortes.

[koehlerbv]

Marco, irgendwo verwechselst Du da was.

In einen String kannst Du "Tante Frieda" oder "1,5" schreiben. Oder einen Roman. Das ist so in jeder Programmiersprache.

Wie dann bei einer Konvertierung (die - wie gesagt - idealerweise gar nicht erforderlich sein sollte) eine Zahl identifiziert wird und wie diese dann zu deuten ist, bestimmen die lokalen Settings. Auch das ist Standard. Und kein Murks. "Vierundvierzigkommafünf" versteht auch kein System - wenn es nicht speziell dafür programmiert wurde.

Bernhard

[Gandhi]

Mit ein bisschen Glück versteht JavaScript das....

[m3]

Und dass in ALLEN Programmierumgebungen IMMER Dezimalen mit '.' getrennt werden - ist schlicht ein stillschweigender Standard.

Nein, das ist von der Sprache abhängig.