Float als ProcedureReturn Wert

[DerMeister]

Hallo
Ich habe versucht eine Procedure zu schreiben, die den Sinuswert eines Winkels berechnet, ohne dass ich ihn vorher in Radiant umberechnen muss.

Code: Alles auswählen

Procedure Sinus(Zahl.f)
  Ergebnis.f = Sin(Zahl.f / 57.29577951)
  ProcedureReturn Ergebnis
EndProcedure  

Debug Sinus(45)

Jedoch wird der ausgegebene Wert immer auf oder abgerundet zu einem ganzzahligen Wert.
Wie kann ich es schaffen, dass ein Floatwert von der Funktion zurückgegeben wird?

[Kaeru Gaman]

ach Kollege, da muss man doch nun wirklich mal sagen!

häng den gewünschten Typ des Rückgabewertes an die "Procedure" Deklaration:

Code: Alles auswählen

Procedure.f Sinus(Zahl.f)

... außerdem werd ichs nach "Anfänger" verschieben, wo's hingehört.

[Josh]

Hallo

es ist halt noch kein meister vom himmel gefallen

[STARGÅTE]

im übrigen ist es besser (und schneller)
wenn du nicht
Sin(Zahl.f / 57.29577951)
rechen lässt, sonden dir eine Konstante definierst:
#DegToRad = #PI/180
und dann in deiner Procedure multiplizierst:
Sin(Zahl.f * #DegToRad)

das mag n Kleinigkeit sein, aber viele kleinigkeiten wirken zusammen und beschleuinigen ein Programm später enorm

[Kaeru Gaman]

@STARGÅTE

deinen Einwand verstehe ich jetzt nicht - wo soll der qualitative Unterschied sein, ob du die Konstante literal oder tokenized hinschreibst?

wesentlich performancekritischer ist der Call, hier würde sich ein Macro statt der Procedure anbieten, falls es zeitkritisch ist.

[ts-soft]

Hab zwar keine Ahnung von sinus usw., aber wenn ich erst teile und dann multipliziere erhöhen sich die Rundungsfehler.
Somit sollte die erste Variante genauer sein, jedenfalls nach meinem mathematischem Verständnis.

Gruß
Thomas

[STARGÅTE]

es geht um das Multiplizieren, statt Dividieren !

das man dann n Konstante statt der Zahl nimmt ist reine Formsache ... umd man weiß später noch was 0.01745329252 bedeutet ...

@TS

Das macht er ja auch, er Teilt erst 180/#Pi "per Hand" und nutzt diesen Wert, der damit auch fehler behaftet ist, auch noch mal zum dividieren seines Winkels...

Es werden also so oder so mehrere Schritte gemacht und PI in PB ist sowieso nur gerundet (inzwischen zum glück als Double)

[Kaeru Gaman]

es geht um das Multiplizieren, statt Dividieren !

interessant... worauf basierst du diese Aussage?

trotzdem kann man ganz easy hinschreiben

Code: Alles auswählen

Ergebnis.f = Sin(Zahl.f * #PI / 180)

weil PB die Konstanten und Literale zur Compilezeit zusammenzieht.

... außerdem wäre es wohl erwägenswert, hier beiderseitig mit Double zu arbeiten.

... letzteres fällt beim Macro flach:

Code: Alles auswählen

Macro Sinus( _expr_ )
  Sin( ( _expr_ ) * #PI / 180 )
EndMacro

[ts-soft]

Weiß jetzt nicht in welcher Reihenfolge PB es macht, habe also extra Klammern gesetzt:

Code: Alles auswählen

Ergebnis.f = Sin((Zahl.f * #PI) / 180)

Somit wird die Multiplikation vor der Division ausgeführt und die Genauigkeit erhöht sich gegenüber
dem vorher Teilen. Double könnten auch hilfreich sein
(Gottseidank brauch ich sowas so gut wie nie)

[Kaeru Gaman]

Somit wird die Multiplikation vor der Division ausgeführt und die Genauigkeit erhöht sich gegenüber
dem vorher Teilen.

damit erschaffst du aber einen performance einbruch, weil das Programm zur Laufzeit beide Operationen durchführen muss.
ohne die Klammern wird PB zur Compilezeit die beiden Konstanten #PI und 180 verrechnen, und als eine einzige Konstante in die EXE übernehmen.


wenn es sich hier nicht um zwei Konstanten handeln würde sondern um Variablen, wäre dein Einwand natürlich berechtigt.
allerdings muss man dann wieder aufpassen, dass man keinen Overflow bekommt,
bei manchen Zahlenbereichen ist es besser, erst zu teilen dann zu multiplizieren, damit man nicht oben anstößt.