Kein Casten von Konstanten ab PB 4.50 Beta3 ?

[Jilocasin]

Mir ist aber der 4.50 Beta3 aufgefallen, dass es scheinbar nicht mehr so einfach möglich ist Konstanten irgendeinen errechneten Fließkommawert von "Haus aus" einzuhämmern. Ich hoffe mal folgendes Beispiel zeigt die Problematik:

Früher wurden Konstanten auch problemlos per Berechnung Float/Double Werte zugewiesen.. oder nicht?

Code: Alles auswählen

#VerticalSizeRatio = (4 / 3)
; -> Rundet auf auf 1

#VerticalSizeRatio = (2 / 3)
; -> Geht nicht (rundet ab auf 0)

#VerticalSizeRatio = 0.70707070
; -> Geht mit fester Fließkommazahl

#VerticalSizeRatio.d = (210 / 297)
; -> Geht nicht, eine Konstante "kann keinen Typ haben"

#VerticalSizeRatio = Round(210 / 297, #PB_Round_Nearest)
; -> Geht nicht, wegen "Keine-Procedure-Bei-Konstante"

Debug #VerticalSizeRatio

#Map_ResolutionX = 250
#Map_ResolutionY = (#Map_ResolutionX * #VerticalSizeRatio)

Debug #Map_ResolutionY

[CSHW89]

machs doch einfach mit einem Punkt, als anzeige einer Fließkommazahl:

Code: Alles auswählen

#VerticalSizeRatio = (210. / 297)

lg kevin

[Jilocasin]

Ah lustig, das geht interessanterweise, danke

[ts-soft]

Ah lustig, das geht interessanterweise, danke

Ist doch logisch
Da sich der Wert einer Konstanten nicht ändern kann, wird der Typ genommen,
der dem Wert entspricht. Eine Zahl ohne Kommastellen kann konstant kein Float sein!

[c4s]

Der Konstante per Prozedur einen Wert zuzuweisen ging sowieso nie (bzw. nicht seit ~PB 4.0) und das man klarmachen muss um welchen wert es sich handelt (eben Fließkomma oder nicht) ist auch nichts neues.

[Jilocasin]

Wäre praktisch, wenn solche Sachen als Hinweis in der Hilfe bei Konstanten stehen würden, denn normalerweise ergibt z.B. 4 / 3 nicht wirklich 1. Vielleicht sollte ich das bei der nächsten Mathematikprüfung auch mal so schreiben und damit rechtfertigen, dass in der Aufgabe ja keine Kommatrennung stand