modulo

[helmsklamm]

der knob liefert 10ner stellen hinterm komma und wenn ich den nun mit 1 "modulo" ist die reihe wie folgt 0, 0.1, 02.... 0,8, 0,9 und wieder 0.

sofern aber die vorkammastelle des eingespeisten knobs > 0 ist, möchte ich aber, als "letzte" stelle des moduloausgangs ne 1 anstelle der 0.
ich weiß, mit router, compair etc. verbund is das zu machen, gehts nich aber irgendwie einfacher, vielleicht modulo-intern?

[herw]

der knob liefert 10ner stellen hinterm komma und wenn ich den nun mit 1 "modulo" ist die reihe wie folgt 0, 0.1, 02.... 0,8, 0,9 und wieder 0.

sofern aber die vorkammastelle des eingespeisten knobs > 0 ist, möchte ich aber, als "letzte" stelle des moduloausgangs ne 1 anstelle der 0.
ich weiß, mit router, compair etc. verbund is das zu machen, gehts nich aber irgendwie einfacher, vielleicht modulo-intern?

ohne Struktur viel zu aufwändig zu durchdenken. (screenshot?)

[helmsklamm]

das is nich dein ernst?

ein modulo und an B die konstante 1 an A n knob mit stepsize 0.1 (range beliebig).

[herw]

das is nich dein ernst?

ein modulo und an B die konstante 1 an A n knob mit stepsize 0.1 (range beliebig).

meine Bemerkung bezog sich auf den letzten Satz:

"ich weiß, mit router, compair etc. verbund is das zu machen, gehts nich aber irgendwie einfacher, vielleicht modulo-intern?"
Außerdem ist mir nicht klar, ob Du für Werte größer als 1 immer nur den Wert 1 bekommen möchtest, oder ob zum Beispiel der Reglerwert 2.8 als Ausgabe 1.8 erhält (der Rest 0.8 und die 1 als Kennzeichen für einen Wert größer als 1).
Ein Bildchen hätte das einfach geklärt.

[herw]

ciao herw

[herw]

im primary level

allerdings liefert dies drei events, d.h. es wäre eventuell noch ein stepfilter nötig

Die Primary-Version ist nicht unproblematisch, je nachdem, was für eine Logik danach folgt. Beim Übergang von z.B. 0.9 auf 1.0 gibt es wegen der Eventverarbeitung auf dem primary level jeweils drei Events, dort sogar mit unterschiedlichen Werten. Wenn man zum Beispiel hier eine increment/decrement-Logik folgen läßt, dann liefert dies zunächst wegen des Wechsels von 0.9 auf 0 eine -1, dann wegen des zweiten 0-Events eine 0 und wegen des dritten (eigentlichen Werteevents) eine +1. Berücksichtigt man alle drei Events, so würde also die increment/decrement Logik überhaupt nicht funktionieren.
Auf der Core-Ebene dagegen ist dies völlig unproblematisch; wegen der Gleichzeitigkeits-Regel liefert es - wie gedacht - nur den Endwert.
So sieht's zum Vergleich mit dem core-Makro aus:

Dieses "einfache" Eventproblem ist in dieser Hinsicht sehr interessant und veranschaulicht schön die Unterschiede in der Eventverarbeitung auf beiden Levels.

cetero censeo: Die core-Ebene entspricht unserem logischen Denken!

ciao herw

[helmsklamm]

vielen dank. insbesondere für das eventwacther-bild.
sehr schönes beispielchen das. eigentlich ist auch die prim-variante völlig logisch: der modulo-out sendet, und jeder compair out ebenfalls, also insgesamt 2mal - deshalb das event-trio bei jedem "trigger". und bei der 0 ist das auch klar: modulo sendet 0, der eine vergleich ist falsch = die 2te 0 und der andre wahr, also dann erst die 1.
man muss diese "unsichtbare" ebene nur im hinterkopf behalten. oder eben vielleicht doch core


wenn man sich in deiner core-struktur die "zusatzsachen" wegdenkt - sehen wir da ein modulo intern?

[herw]

vielen dank. insbesondere für das eventwacther-bild.
sehr schönes beispielchen das. eigentlich ist auch die prim-variante völlig logisch: der modulo-out sendet, und jeder compair out ebenfalls, also insgesamt 2mal - deshalb das event-trio bei jedem "trigger". und bei der 0 ist das auch klar: modulo sendet 0, der eine vergleich ist falsch = die 2te 0 und der andre wahr, also dann erst die 1.
man muss diese "unsichtbare" ebene nur im hinterkopf behalten. oder eben vielleicht doch core

zusätzlich zu der Tatsache, dass drei Events zu beachten sind, kommt noch hinzu, dass die Reihenfolge, in der die einzelnen Elemente eingefügt und verkabelt wurden, auch noch eine andere Reihenfolge der Zwischenwerte liefern würde.

wenn man sich in deiner core-struktur die "zusatzsachen" wegdenkt - sehen wir da ein modulo intern?

ja richtig, die Struktur habe ich dem IMod-Makro entnommen. Dadurch, dass der Divisor 10 bekannt ist, kann ich auch das Ergebnis der Ganzzahl-Division mit übernehmen. Ich hatte auch erst vor, das IMod-Makro mit einzubauen, aber ich hätte dann das Ergebnis der Division sowieso extra herausführen müssen. So ist es einfacher zu durchschauen. Interessant ist auch die Benutzung des Vergleichers GT (greater-than). Wenn man dieses Makro mal öffnet, kann man sich auch die anderen logischen Module selbst leicht basteln. Wenn man den EventMerger weglässt, kann man dieses Modul auch so umändern, dass es nur auf die Werteänderung eines der beiden Eingänge reagiert.

[helmsklamm]

warum ein GT und kein simples compir?

und wenn wir schon dabei sind - was macht das GE? was ist mit verhältniss gemeint?

und noch 2 sachen: was machen (math) min/max eigentlich genau?

[herw]

warum ein GT und kein simples compir?

GT in core Ebene entspricht dem compare auf primary-Ebene, da es die Werte 1 oder 0 liefert; ein compare in der core-Ebene ergibt nur ein logic-signal, das man z.B. mit einem Router weiterverarbeiten muss; dies geschieht ja auch im Innern von GT.

und wenn wir schon dabei sind - was macht das GE? was ist mit verhältniss gemeint?

GE = greater or equal;
Verhältnis? worauf nimmst Du Bezug?

und noch 2 sachen: was machen (math) min/max eigentlich genau?

die mathematischen Funktion min und max geben jeweils den kleineren oder den größeren der beiden Eingangswerte aus.

[helmsklamm]

äh, compair vs. GT, resp. "logic" - wieso "konvertiert" man das logic gerade mit nem router?

"verhältniss" bezog sich auf den modul-beschreinungstext, aber mit greater/eqaul isses jetzt klar.


min/max - ah, gut zu wissen, kann man bestimmt mal braucehn.

[herw]

äh, compair vs. GT, resp. "logic" - wieso "konvertiert" man das logic gerade mit nem router?
...

wie sonst?

[helmsklamm]

na, nem logic2normal oder so;)

aber ehrlich gesagt leuchtet mir die notwendigkeit eines EXPLIZITEN logic-signals soweiso nicht ganz ein. schlussendlich besteht doch soweiso alles aus ner kette ja/neins, ergo zusammengesetzen logic-zuständen. oder gehts genau darum? den unterschied zwischen ner kette 0/1 zu den Einzelzustand wahr/falsch abzugrenzen?

[herw]

na, nem logic2normal oder so;)

aber ehrlich gesagt leuchtet mir die notwendigkeit eines EXPLIZITEN logic-signals soweiso nicht ganz ein. schlussendlich besteht doch soweiso alles aus ner kette ja/neins, ergo zusammengesetzen logic-zuständen. oder gehts genau darum? den unterschied zwischen ner kette 0/1 zu den Einzelzustand wahr/falsch abzugrenzen?

mit einer kleinen Änderung in deiner Signatur antworte ich mal, da ich es nicht besser beschreiben kann:

bitte vor jeder frage zu den BootCtl-Signalen erstmal überprüfen, ob das kapitel "6 Bedingte Verarbeitung" S. 116ff im Core-hnadbuch, schon gelesen wurde.

ciao herw

[helmsklamm]

gggg - aber deine analogie stimmt nur bedingt:
A - is das schon etwas fortgeschritten und "fragwürdig" und B wird dort nur das DAS und das WIE erklärt, nicht das WARUM.
ich bleib mal bei meiner vermutung: bool/logic ist wirklich tiefes "lowlevel", nach dem kompilen ein direktbefehl für die maschine, gewissermassen die anführungszeichen der maschinensprache.

natürlich lass ich mich hier gerne eines bessren belehren.