zwei Ganzzahlen zusammensetzen

[PrinzThomas]

Hallo,

ich überlege schon seit einer halben Stunde wie ich es schaffe zwei Ganzzahlen so zusammenzusetzen, dass es eine neue Zahl ergibt wie als würde man die Zahlen einfach nebeneinanderschreiben.
Also z.B. aus 7 und 9 wird 79 oder aus 23 und 15 wird 2315
Mir würde eine recht komplizierte Lösung mit Modulos einfallen, aber das ist imens aufwändig.
Man müsste für jeden 10er ein extra Modul zur Abfrage setzen.
Gibt es dafür evtl. eine elegante Lösung?

[herw]

Hallo,

ich überlege schon seit einer halben Stunde wie ich es schaffe zwei Ganzzahlen so zusammenzusetzen, dass es eine neue Zahl ergibt wie als würde man die Zahlen einfach nebeneinanderschreiben.
Also z.B. aus 7 und 9 wird 79 oder aus 23 und 15 wird 2315
Mir würde eine recht komplizierte Lösung mit Modulos einfallen, aber das ist imens aufwändig.
Man müsste für jeden 10er ein extra Modul zur Abfrage setzen.
Gibt es dafür evtl. eine elegante Lösung?

elegant ist relativ; du musst eine Abfrage zur hinteren Zahl erstellen, die die Anzahl der Stellen erfasst; das geht mit dem Zehnerlogarithmus und einer anschließenden Rundung nach oben.
Beispiel: Stellenzahl s(1234)=[(log(1234))]+1, wobei die eckige Klammer die [url=http://.de.wikipedia.org/wiki/Gaußklammer]Gaußklammer[/url] (siehe bei wikipedia) darstellt (Abschneiden der Nachkommastellen). Dann musst du die erste Zahl mit der entsprechenden Zehnerpotenz multiplizieren und anschließend beide Zahlen addieren. Das macht Spaß in Core

[PrinzThomas]

Ich sitz jetzt schon 30 Minuten an diesen dekadischen Logarithmen und versteh es immer noch nicht wirklich.
In Wikipedia wird ein Begriff mit dem selben erklärt, was für einen Ahnungslosen völlig sinnfrei ist.
Wenn ich wissen möchte wie ich log berechnen möchte kann man mir keine Formel mit "log" als Inhalt anbieten. ^^

Mal eine ganz einfache Frage:
Wie berechnest du in Reaktor z.B log10(25) sodass wie bei meinem Taschenrechner 1,39794... rauskommt?
Und wieso schreibst du mit Rundung nach oben, wenn eine Streichung der Nachkommastelle ja immer eine Rundung nach unten darstellt?
ODer wird innerhalb der log-Berechnung nach oben gerundet und für die Anzahl der Stellen eben nach unten + 1?
Ich bin etwas ratlos und vor allem kein Mathestudent. ^^

[herw]

Ich sitz jetzt schon 30 Minuten an diesen dekadischen Logarithmen und versteh es immer noch nicht wirklich.
In Wikipedia wird ein Begriff mit dem selben erklärt, was für einen Ahnungslosen völlig sinnfrei ist.
Wenn ich wissen möchte wie ich log berechnen möchte kann man mir keine Formel mit "log" als Inhalt anbieten. ^^

Mal eine ganz einfache Frage:
Wie berechnest du in Reaktor z.B log10(25) sodass wie bei meinem Taschenrechner 1,39794... rauskommt?
Und wieso schreibst du mit Rundung nach oben, wenn eine Streichung der Nachkommastelle ja immer eine Rundung nach unten darstellt?
ODer wird innerhalb der log-Berechnung nach oben gerundet und für die Anzahl der Stellen eben nach unten + 1?
Ich bin etwas ratlos und vor allem kein Mathestudent. ^^

ok, dessen war ich mir nicht bewusst;
auf der primary-Ebene bleibt einem da nichts anderes übrig, als einige Logarithmen- und Wurzelgesetze anzuwenden (sehr umständlich).
Dafür gibt's aber core:
Unter den Basismodulen <Built-in Module/math> findest du die Logarithmusfunktion ~log(x). Sie ist zur Basis 2 voreingestellt, kann man aber in den Properties auf jede andere Basis umstellen.
Wenn Du einigermaßen Taschenrechnergenauigkeit haben möchtest, dann solltest Du die Genauigkeit auf 32bit stellen; liegt leider noch nicht mit 64bit vor, habe ich aber schon angemahnt. Das verbraucht natürlich auch mehr Rechenpower in audio-cells. Das musst du dann selbst testen.

log10.jpg

Die Rundung nach oben geschieht, um die gewünschte Stellenzahl zu reservieren. Der Zehnerlogarithmus gibt immer eine Ziffer niedriger an, deshalb muss man 1 addieren oder die hintere Zahl zuvor mit 10 multiplizieren und dann den Logarithmus anwenden. Das Abschneiden der Nachkommastellen musst du noch implementieren. Die einfache Rundungsfunktion kannst Du dazu nicht benutzen. Auf der Primary-Ebene ist das der div-Ausgang der Modulo-Funktion. In Core muss man sich die Routine selbst schreiben oder eine eigene Gaußklammer, was nicht so schwer ist (beachte den unten angegebenen Link).
ciao herw

PS: hier ist Literatur zum mathematischen Runden (3. Regel beachten!)

[PrinzThomas]

Die "normale" LOG Funktion hatte ich jetzt auch schon in Core gefunden.
Ich hatte eher Probleme damit die LOG-Funktion ansich nachbilden zu wollen.
Aber da es ja dieses schöne Modul gibt braucht man sich nicht mehr darum zu kümmern.
Ganz so leicht wie du es schilderst ist es allerdings doch nicht.
Das bloße aufaddieren der 2ten Zahl am Schluss bringt nur das richtige Ergebniss, wenn beide Zahlen die gleiche Anzahl an Stellen haben.
Z.B. 87 und 55

87 --> x100 --> 8700 + 55 = 8755

Aber was ist mit 87 und 155 ?
Die zweite Zahl muss also auch die erste mit einer Stelle beeinflußen.
Dann wär richtig:

87 --> x1000 --> 87000 + 155 = 87155

Das Screenshot zeigt nochmal die fehlerhafte Lösung, die nur funktioniert, wenn beide Werte die gleiche Anzahl an Stellen aufweisen.

Ich muss also auch für die zweite Zahl den kompletten Weg gehen und beide Stellenanzahlen am Ende vergleichen ehe ich sie aufaddiere.
Ganz schön verzwickt so eine simple Sache. ^^

[PrinzThomas]

NACHTRAG
Ok, natürlich hast du recht ... ich hatte dummerweise die Stellen des 1. Wertes gezählt. ^^
Jetzt funktioniert es wie es soll.

[herw]

post-crossing

[...]
Aber was ist mit 87 und 155 ?
Die zweite Zahl muss also auch die erste mit einer Stelle beeinflußen.
Dann wär richtig:
87 --> x1000 --> 87000 + 155 = 87155
[...]

Da [log10(155)]=2 ist und ich 1 dazu addiere bekomme ich ja die Multiplikation von 87 mit 10^3 also 87000. Da ist kein Fehler, vielleicht in deiner Implementation?
Der einfachste Algorithmus lautet:

- multipliziere die „hintere” Zahl mit 10
- bilde davon den Zehnerlogarithmus
- schneide die Nachkommastellen ab (Ergebnis n)
- multipliziere die vordere Zahl mit 10^n
- addiere beide Zahlen

also in einer Formel (vordere Zahl v, hintere Zahl h):

vorne-hinten-Zahl.jpg

ciao herw

PS: jetzt wäre natürlich eine reine core- Lösung angesagt. Insbesondere schau mal bei deiner Lösung nach, wie viele Events schließlich bei einer Wertänderung herauskommen.

[PrinzThomas]

Insbesondere schau mal bei deiner Lösung nach, wie viele Events schließlich bei einer Wertänderung herauskommen.

Mit einem nachgeschalteten StepFilter genau 1.

[herw]

Insbesondere schau mal bei deiner Lösung nach, wie viele Events schließlich bei einer Wertänderung herauskommen.

Mit einem nachgeschalteten StepFilter genau 1.

das meine ich nicht, denn nach meiner Einschätzung werden bei jeder Berechnung in primary zwei verschiedene Werte gesendet. Da nützt ein Stepfilter gar nichts. Teste mal mit einem Event-Monitor.

[PrinzThomas]

Ja es sind immer 2, aber was ist daran so schlimm?
Der Ausgang soll jetzt nicht unbedingt als Trigger- oder Gatesignal herhalten.
Und, ob nun 2 Events oder nur 1 gesendet werden... ich glaube nicht, dass das der CPU irgendwas ausmacht oder meinst du etwas ganz anderes, was sich bei mehr als 1 Event negativ auf irgendwas auswirken könnte?

[herw]

Ja es sind immer 2, aber was ist daran so schlimm?
Der Ausgang soll jetzt nicht unbedingt als Trigger- oder Gatesignal herhalten.
Und, ob nun 2 Events oder nur 1 gesendet werden... ich glaube nicht, dass das der CPU irgendwas ausmacht oder meinst du etwas ganz anderes, was sich bei mehr als 1 Event negativ auf irgendwas auswirken könnte?

die CPU-Last ist völlig unerheblich (bei reinen Eventberechnungen ohnehin). Das Problem kann sein, dass du eventuell das Ergebnis als Trigger oder mit einem Vergleicher weiterverarbeiten möchtest. Doppelte Triggersignale sind eventuell nicht erwünscht oder führen zu Fehlinterpretationen. Das hängt davon ab, was Du mit deinen Werten anstellen möchtest. Aber das hast du ja oben schon erwähnt.
Aber da kann ich keine weiteren Tipps geben, ich weise immer nur mal darauf hin, dass man auch die Anzahl der ausgegebenen Werte immer im Kopf haben sollte, wenn man in primary arbeitet. In Core ist es etwas übersichtlicher, da dort die Regel gilt, dass alle Berechnungen, die aus einer Eventquelle kommen, logisch gleichzeitig erfolgen. Das gilt in primary nicht.
Mir fällt natürlich noch ein sehr wichtiges Argument ein:
Wenn du in größeren Ensembles mit vielen Ein- und Ausgängen arbeitest und einen Eventbus als Vereinfachung benutzt, eventuell mit Eventblöcken (vorgegebene Anzahl an zusammengehörigen Events), dann ist das nur noch in core zu schaffen. Mehrfachsenden einzelner Werte würde ein heilloses Chaos verursachen.

ciao herw