Hi Patai,<br><br>If I understand correctly, what you're describing is something that I intend Reactive to handle well, and it doesn't yet. In other words, I think the problem you ran into is just an implementation bug, not a problem with semantics or interface.<br>
<br>Regards, - Conal<br><br><div class="gmail_quote">On Wed, Mar 4, 2009 at 12:39 PM, Patai Gergely <span dir="ltr"><<a href="mailto:patai_gergely@fastmail.fm">patai_gergely@fastmail.fm</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> I would model this as the position being the integral of the ball's<br>
> velocity, and switch the velocity, this way, you don't need to do<br>
> complicated things with trying to grab the position from the last<br>
> section of the behavior.<br>
</div>I tried that too, but the result was the same. I don't see how that<br>
would help anyway, since integral is just a stepper over an accumE. I<br>
even tried a function-valued behaviour that had to be supplied time<br>
explicitly, which did move at least, but still <<loop>>-ed, so it never<br>
switched.<br>
<div class="im"><br>
> Re delayed switching, Reactive already has a kind of delayed<br>
> switching, that happens automatically when necessary. If you attempt<br>
> to take the value of a Reactive value at the exact moment of a switch,<br>
> you will receive the value from the previous step.<br>
</div>Oh yes, now I went back to the 'Simply efficient...' paper, and it says<br>
so indeed. I just misunderstood that part (off by one thinking, as<br>
always ;). However, the problem still remains, because it's not only the<br>
new value that depends on the current one but the time of switching as<br>
well. This knot is apparently too tight for the time being.<br>
<br>
Gergely<br>
<font color="#888888"><br></font></blockquote></div><br>