Deutsches Reaktor Forum

Hi!

Ich war schon oft von dem Round-Modul genervt, weil es bei allen x.5 Werten entweder auf- oder abrundet (genauer gesagt rundet es immer auf eine gerade Zahl). Jetzt habe ich versucht ein möglichst CPU sparendes Modul zu bauen, wo man selber festlegen kann, ob x.5 Werte auf- oder abgerundet werden. Hier ist meine Lösung: (In diesem Fall werden x.5 Werte aufgerundet, wenn sie abgerundet werden sollen, muss man die Quick Constant von dem Add Modul auf -0.5 setzen)
Vielleicht habt Ihr ja mal Verwendung dafür

Gruß

Sieht brauchbar aus !
Du findest übrigens diese und andere Lösungen, wenn Du in diesem und im internationalen Forum nach "modulo" suchst.
Was hältst Du hiervon (Gauss-Funktion) ? Weiter so, viele Grüße, Gerald.

fweth hat geschrieben:Hi!

Ich war schon oft von dem Round-Modul genervt, weil es bei allen x.5 Werten entweder auf- oder abrundet (genauer gesagt rundet es immer auf eine gerade Zahl). [...]

Gruß

Das ist keine Nerverei sondern international festgelegter Standard. Der Grund ist der, dass es andernfalls bei Zufallsverteilungen zu einem Ungleichgewicht kommt. Um das zu vermeiden, hat man dies in der Norm IEEE 754 festgelegt. Dies ist also kein Bug oder Irrtum, sondern exakte Implementierung einer Norm.
In dieser Norm (siehe Link) wird allerdings auch gefordert, dass andere Rundungsformen (wie Deine z.B.) ebenfalls implementiert sein müssen. Dies fehlt. Ohne Angabe, dass es sich bei dem unscheinbaren Macro round nur um eine für den Otto-Normalverbraucher uneinsichtige Rundungsform handelt, ist dies in der Tat ein Manko.
Ich habe die verschiedenen Formen der Grundfunktionen (siehe auch Krümelmonsters Beitrag) mal vor einigen Jahren implementiert. Vielleicht sollte ich sie mal wieder in der library anbieten.

ciao herw

herw hat geschrieben:Das ist keine Nerverei sondern international festgelegter Standard. Der Grund ist der, dass es andernfalls bei Zufallsverteilungen zu einem Ungleichgewicht kommt...

Danke für den Hinweis !

herw hat geschrieben: Ich habe die verschiedenen Formen der Grundfunktionen (siehe auch Krümelmonsters Beitrag) mal vor einigen Jahren implementiert. Vielleicht sollte ich sie mal wieder in der library anbieten.

Oh, ja !
Das war sehr schön. Wenn man nicht unter dem krankhaften Zwang leidet, alles selbst machen zu müssen, kann man das sehr gut gebrauchen.
Schön wäre auch eine Core-"Zuphall"-Version.
Gruß, Gerald.

krümelmonster hat geschrieben:Was hältst Du hiervon (Gauss-Funktion) ?
[...]

Ja, das is noch ökonomischer (habs getestet). Es verbraucht übrigends weniger CPU, wenn man die Module alle auf Float einstellt (außer natürlich das Round Modul). Hat Integer eigentlich irgendeinen Vorteil, außer wenn man einen Wert runden lassen möchte?

Was ist eigentlich genau das Gauss'sche an diesem Modul?

Gruß

fweth hat geschrieben: Ja, das is noch ökonomischer (habs getestet). Es verbraucht übrigends weniger CPU, wenn man die Module alle auf Float einstellt (außer natürlich das Round Modul). Hat Integer eigentlich irgendeinen Vorteil, außer wenn man einen Wert runden lassen möchte? ...

Freut mich. Ist allerdings auch eine etwas andere Anwendung: Weglassen des frac-Anteils = Rundung abwärts auf den Integerbestandteil. So ist die Funktion auch definiert.
Der geringere CPU-Verbrauch für den Fall, dass alles auf Integer eingestellt ist, erklärt sich dadurch, dass es dann keine Konvertierung float/integer gibt, die - s. Core-manual - nun mal mehr CPU kostet. Dann macht das Macro aber nicht mehr das, was es soll; schau mal nach.
Integer-Werte haben viele Vorteile. Zwei seien hier genannt:
- Solange die Werte nicht mit Dezimalbrüchen multipliziert werden, was ja wieder zu float-Werten führt, entfällt jegliche Rundungsfehler-Problematik.
- Integer-Counter "laufen" VIEL länger. Versuch mal, einen Counter im PrimaryLevel zu bauen. Bei (2^24)-1 ist Schluß. Mit Core-Integer-Zahlen geht es bis (2^31)-1 ! Das entspricht über 13,5 Stunden sauberen Laufes bei SR=44,1 kHz - auf anderem Wege komplett unmöglich.
Viele Grüße, Gerald.

krümelmonster hat geschrieben:[[...]Versuch mal, einen Counter im PrimaryLevel zu bauen. Bei (2^24)-1 ist Schluß. Mit Core-Integer-Zahlen geht es bis (2^31)-1 ! Das entspricht über 13,5 Stunden sauberen Laufes bei SR=44,1 kHz - auf anderem Wege komplett unmöglich.
Viele Grüße, Gerald.

Jetzt weiß ich auch, was Du den lieben langen Tag so machst _ eins, zwei, drei, vier, fünf, ...., achttausenddreihundertneunundachtzig Millionen fünfhundertdreiundziebzigtausendvierhundertfünfundzwanzig, achttausenddreihundertneunundachtzig Millionen fünfhundertdreiundziebzigtausendvierhundertsechsundzwanzig, ...

herw hat geschrieben:Jetzt weiß ich auch, was Du den lieben langen Tag so machst _ eins, zwei, drei, vier, fünf, ....

.. und weil dem nicht so ist lasset mich mein Loblied auf die oft gescholtenen Initialisierungs-Events anstimmen:

Ihr - und nur Ihr - seids, die mich bei 2.140.000.000 einsteigen und nach einer gemütlichen halben Zigarettenlänge beobachten lassen, wie die Schose durcheinander gerät.
Habt Dank !

Btw, hat´s jemand gewusst ?
Im Core-manual heißt es ja nur (Zitat sinngemäß): Die Darstellbarkeit von Integerzahlen reicht bis über 10^9.
Sie reicht tatsächlich mehr als doppelt so hoch.
Da hätten sie auch einfach die magische Zahl hinschreiben können.
Finde ich.

krümelmonster hat geschrieben: ...und nach einer gemütlichen halben Zigarettenlänge beobachten lassen, ...

44,1 kHz vorausgesetzt, bei 176,4 kHz sieht´s nach grobem Suchtverhalten aus

P.S.: Ich hätte sooooo gerne als nächsten Avatar "Stiller Brüter"

krümelmonster hat geschrieben: Freut mich. Ist allerdings auch eine etwas andere Anwendung: Weglassen des frac-Anteils = Rundung abwärts auf den Integerbestandteil. So ist die Funktion auch definiert.

Ähm hab ich vergessen zu schreiben, ich habs so umgeformt, dass es wie meins funktioniert (am Anfang 0.5 addiert)

krümelmonster hat geschrieben: Freut mich. Ist allerdings auch eine etwas andere Anwendung: Weglassen des frac-Anteils = Rundung abwärts auf den Integerbestandteil. So ist die Funktion auch definiert.
Der geringere CPU-Verbrauch für den Fall, dass alles auf Integer eingestellt ist, erklärt sich dadurch, dass es dann keine Konvertierung float/integer gibt, die - s. Core-manual - nun mal mehr CPU kostet [...]

Ahm, ich habe aber mein Macro gerade NICHT auf Integer gestellt (siehe Bild), und für mich wars auch unlogisch, ich dachte auch dass Integer CPU-sparender ist, aber da wars eben andersrum (beim Original Modul waren alle Teile bis auf das Compare auf Integer).

Aja, und welche Funktion von Hr. Gauss hat Dich zu diesem Modul inspiriert (sorry, ich kenn mich da noch nicht so aus, obwohl das ab Herbst mein Studium wird )?

Gruß

Oh,oh,
da muss mir jetzt etwas furchtbar peinlich sein:
NICHT Gauss-Funktion, ich weiß noch nicht einmal, wie man sie richtig nennt: "trunc"-Funktion.
http://www.eulanda.de/inside/entwickler ... /trunc.htm
Das kann Herwig wohl am allerbesten mit einem Satz erklären.

Zu Deiner Struktur:
Habe gerade leider keine Zeit, es auszuprobieren, aber ein wenig wundern würd mich das schon, wenn sie CPU-genügsamer wäre, hat sie doch bestimmt genauso viele float/int-Konvertierungen.
Ich muss das mal ausprobieren.
Schau auch mal hier rein:
http://www.reaktor.approx.de/phpbb3/vie ... f=17&t=419
Danach dürfte sich das Thema auch für Dich erschöpft haben!
Ich schau mir das aber noch mal an, ciao, Gerald.

Gauß-Funktion (Wahrscheinlichkeitsdichte)
Gauß-Klammer (floor function)

krümelmonster hat geschrieben:[...]

P.S.: Ich hätte sooooo gerne als nächsten Avatar "Stiller Brüter"

da musst du noch dreimal posten, um den nächsten avator zu bekommen

krümelmonster hat geschrieben:
... da waren´s nur noch zwei ...

dann musst Du aber auch dein Foto dazustellen!