Kleine Anomalie bei Typ real schreiben in Sysvar in wissenschaftlicher Notation

[Black]

es sei eine Systemvariable Typ Zahl gegeben (intern eine Gleitkommazahl) (hier bei mir mit ID 3478)

gemäß Kapitel 6.4 Anleitung ist in HMScript eine Gletkommazahl mit +-1.7e+-308 definiert

nun folgede kleinen Programme:

Code: Alles auswählen

object o1= dom.GetObject (3478);
o1.State (3.76);  !- Geht ergibt 3.76
WriteLine (o1.State () );   

Das nächste:

Code: Alles auswählen

object o1= dom.GetObject (3478);
o1.State ("37.6e-1".ToFloat ());  !- Geht ergibt 3.76
WriteLine (o1.State () );   

nun wirds skurill:

Code: Alles auswählen

object o1= dom.GetObject (3478);
o1.State (37.6e-1);   // Script Runtime Error egal ob grosses oder kleines e
WriteLine (o1.State () );   

Die wissenschaftliche Notation kann dieses Konstrukt nicht ab.

Black

[alchy]

zu spät.

viewtopic.php?f=26&t=36623&p=385762#p385761


Alchy

[Black]

aber anscheinend immer noch aktuell.. über sowas fällt man halt beim programmieren

[jmaus]

Ich sage mal so: Der Syntax Parser in Rega ist eine Bitch

Und das "Problem" mit der Formatierung von floating point werten mittels wissenschaftlicher Notation ist in der Tat nichts neues. Es ist nämlich genauso wie du es bemerkt hast, das der Parser mit solchen real werten in wiss. Notation nichts anfangen kann wenn diese nicht in Anführungszeichen gesetzt sind, d.h. also zuerst einmal ein String waren. Genau deshalb wurde ja auch die Skriptdokumentation entsprechend angepasst (siehe https://www.eq-3.com/Downloads/eq3/down ... g_V2.2.pdf) und dahingehend repariert, das das dort vorkommende Beispiel wie folgt aussieht (Siehe Kapitel 6.4):

Code: Alles auswählen

real r = "-1.0E-1".ToFloat(); ! -0.1

D.h. der real wert mittels wiss. Notation muss zwingend in Anführungszeichen gesetzt werden. Folglich müsste dein Beispiel wie folgt (wie du schon gezeigt hattest) aussehen:

Code: Alles auswählen

object o1 = dom.GetObject(3478);
o1.State("37.6e-1".ToFloat());  !- Geht ergibt 3.76
WriteLine(o1.State());

Nun mag das vielleicht unschön sein und in der Tat würde ich gerne das in der Skriptsprache auch reparieren. Die Frage ist nur ob sich hierfür der Aufwand wirklich lohnt und ob das auch nicht dazu führen würde das es dann in naher Zukunft Skripte gibt die die wiss. Notation ohne Anführungszeichen nutzt und damit zu älteren Versionen inkompatibel sind. Nun kann man natürlich prinzipiell bei vielen Änderungen so argumentieren, aber das hier erscheint mir IMHO ein verschmerzbarer Kompromiss zu sein – real werte eben in Strings zu verpacken wenn man unbedingt die wiss. Notation einsetzen will/muss.

[Black]

wie du schon schriebst, das problem ist unschön, aver umschiffbar mit vertretbarem aufwand.

Drüber gefallen bin ich, als mein Systemvariablenbackup script zu bestimmten Bedingungen scriptfehler warf. Was im Nachhinein daran lag, dass die Ausgabe einer Fliesskommazahl je nach Wert in e-Notation erfolgt. die gleiche e-Notation aber wieder zurückspielen fürht dann zu Fehler.
Gut, ätzend aber umschiffbar.

Relevanter finde ich die geschichte mit den inkosistenten Zeitstempeln

[jmaus]

Relevanter finde ich die geschichte mit den inkosistenten Zeitstempeln

Du meinst das hier?
viewtopic.php?f=65&t=47544#p475977

Da kommen wir aber leider nicht so richtig weiter denn wie ich dort schon geschrieben hatte (und wir sollten dort weiterdiskutierten) kann ich schwer einschätzen welches der beiden Verhalten richtig sein soll und welches falsch. Und die Chance ist leider zu groß wenn man das jetzt ändert, das dann einem alles auf die Füße fällt.