Seite 2 von 2

Verfasst: 26.09.2007 21:03
von Captn. Jinguji
Hmnja,.... der Ton des Norwegers hätte mich auch geärgert.

Ich frage mich gerade, ob die Lösung schlicht darin liegen könnte,
dass Fred zur Compile time erkennt, wenn es sich um einen puren Integerausdruck handelt und den dann gesondert behandelt (nämlich alle promotions rauslässt) - und damit aber erheblich speed in der Run time gewinnt. Anders ist mbMn nicht zu erklären, dass eine beliebige der drei Zahlen dazu führt, dass dann wirklich wie von dem Lappen beschrieben der Funktionstyp zum Casting-Quast über alles wird...

Re: Wieso 'Division by 0 forbidden'

Verfasst: 27.09.2007 12:53
von Little John
Jilocasin hat geschrieben:Moin :)
Hab wiedermal ein .. naja, kein Problem, vielmehr eine Frage:


Ein einzeiliges...

Code: Alles auswählen

Debug StrF(3 / (3/4))
(selbes auch ohne StrF(...) hab ich gerade festgestellt)

Gibt bei mir ein Division by 0 forbidden beim Kompilieren aus :?
Wieso denn das wenn ich mal fragen darf.. ?
Als Ergänzung zu den bisherigen Antworten:

Code: Alles auswählen

Debug StrF(3 / (3.0/4.0))
funktioniert bei mir (PB 4.10 Beta 3 Windows) wie erwartet.
Das Notieren des Dezimalpunktes veranlasst PB offenbar, die betreffenden Zahlen als Fließkommawerte zu behandeln.

Gruß, Little John

Verfasst: 27.09.2007 13:16
von #NULL
yo is klar, hatte KG auch schon angedeutet
Kaeru Gaman hat geschrieben:es genügt, wenn eine der zahlen explizit als Float hingeschrieben wird.

Verfasst: 27.09.2007 13:18
von Little John
Ooops, sorry. Das hatte ich wohl überlesen.

Gruß, Little John

Verfasst: 27.09.2007 15:25
von hardfalcon
Es ist doch durchaus denkbar, dass jemand bei so einem Ausdruck nur das Ergebnis der Ausdrucks als Float behandelt haben möchte, die einzelnen Operanden jedoch z.B. aus Gründen der Genauigkeit als Integer behandelt haben möchte. IMHO fehlt da ganz schlicht ne möglichkeit, um ganz explizit ein Typecasting vorzunehmen ohne den Umweg über eine Variable nehmen zu müssen. Aus meiner Sicht erschiene mir ganz spontan z.B. folgendes Konstrukt (den zu castenden Ausdruck zwischen geschweiften Klammern, die vom Suffix für den gewünschen Datentyp gefolgt sind) recht sinnvoll:

Code: Alles auswählen

{expression}.type

;Example: Cast the expression "57/(3*4)" to a float value
{57/(3*4)}.f
Vielleicht sollte mal jemand Fred nen entsprechenden Vorschlag unterbreiten, ich selber werde sowas nicht tun, weil ich 1. kaum noch programmiere und 2. nicht soviel Erfahrung auf diesem Gebiet habe wie einige andere Forenmitglieder hier (z.B. freak, Kaeru Gaman, bobobo, um nur einige zu nennen).

//EDIT: Vielleicht wären aus Gründen der Lesbarkeit auch eckige Klammern besser geeignet (ab Schriftgrösse 10 und abwärts sind je nach Schriftart geschweifte von runden Klammern kaum noch zu unterscheiden), soweit ich sehe sollte man ja eigentlich jeden der 3 Klammerntypen verwenden können, ohne an der bestehenden PB-Syntax etwas ändern zu müssen...

Verfasst: 16.10.2007 19:09
von ZeHa
Ist aber schon in Ordnung so, wie das abläuft. In anderen Programmiersprachen wäre es genau gleich - der Ausdruck wird erstmal komplett ausgewertet und gibt dann einen Wert zurück. Dieser Rückgabewert wird dann erst in die Funktion eingesetzt, das ist ja ein Aufruf - der Wert wird also auf den Stack gepusht. Und wenn die Funktion das dann auf 'nen anderen Typ castet, geschieht das erst, wenn der eigentliche Wert schon längst ausgerechnet wurde.

Verfasst: 20.10.2007 17:52
von Kaeru Gaman
so wäre es logisch, funktioniert aber nicht für

Code: Alles auswählen

PermSin2 = Sin(#PI/ 64 * (counter & 127))
und das finde ich echt zum kotzen...

...wenn mein rechner wieder läuft, sollte ich wohl doch mal wieder C++ installieren...