[reactive] Status of Reactive "feedback" (recursive integral, etc)
Creighton Hogg
wchogg at gmail.com
Sat Dec 6 10:49:27 EST 2008
Well, actually testing any of these out seems to eat all the RAM on my
box & I have to kill it...I don't think that I'm 'morally' doing
anything wrong, so I guess I've just been assuming it's related to the
other ticket I filed where the same thing happened. That might not be
a safe assumption though...
As for physics. One person on #haskell (can't remember who...)
suggested making a pure interface to chipmunk similar to FieldTrip's
interface to OpenGL. That seems like a good & pragmatic idea. Being
a bit of a physics nerd, I think it'd be really cool to make an entire
2d or 3d engine to go with Reactive from the ground up. It'd probably
be a lot of fun to work on but it might not be the fastest way to the
finish.
Cheers,
Creighton
On Sat, Dec 6, 2008 at 7:30 AM, Peter Verswyvelen <bugfact at gmail.com> wrote:
> Nice. I haven't been able yet to test any of these, anyone?
> What is your opinion about physics in Reactive? Should we try to make an
> adapter to an optimized imperative physics engine, or should we write one in
> Haskell?
>
>
> On Wed, Dec 3, 2008 at 10:38 PM, Creighton Hogg <wchogg at gmail.com> wrote:
>>
>> So this is a bit of a brainstorming post. I did a little thinking
>> earlier about different simple ODE solving techniques, and tried to
>> translate them fairly directly into Reactive. The result isn't pretty
>> & I'd like to talk about that.
>>
>> The naive definitions, to me, of the Euler, Euler-Cromer, and Midpoint
>> methods should look like the following. Each takes in an Event (),
>> initial positions & velocities, and a Behavior (v -> v -> v) that is
>> the acceleration as a function of time. We want to be general since
>> the acceleration may be an explicit function of time as well as as
>> position & velocity.
>>
>> euler tau x0 v0 a = liftA2 (,) x v
>> where x = accumB x0 (fmap (^+^) (liftA2 (^*) (prev vi) deltaTs))
>> v = accumB v0 (fmap (^+^) (liftA2 (^*) ai deltaTs))
>> ai = (snapshot_ tau a) <*> (prev xi) <*> (prev vi)
>> xi = (snapshot_ tau x)
>> vi = (snapshot_ tau v)
>> deltaTs = diffE (tau `snapshot_` time)
>>
>> eulerCromer tau x0 v0 a = liftA2 (,) x v
>> where x = accumB x0 (fmap (^+^) (liftA2 (^*) vi deltaTs))
>> v = accumB v0 (fmap (^+^) (liftA2 (^*) ai deltaTs))
>> ai = (snapshot_ tau a) <*> (prev xi) <*> (prev vi)
>> xi = snapshot_ tau x
>> vi = snapshot_ tau v
>> deltaTs = diffE (tau `snapshot_` time)
>>
>> midpoint tau x0 v0 a = liftA2 (,) x v
>> where x = accumB x0 (fmap (^+^) (liftA2 (^*) vavg deltaTs))
>> v = accumB v0 (fmap (^+^) (liftA2 (^*) ai deltaTs))
>> ai = (snapshot_ tau a) <*> (prev xi) <*> (prev vi)
>> xi = snapshot_ tau x
>> vi = snapshot_ tau v
>> deltaTs = diffE (tau `snapshot_` time)
>> vavg = fmap (^/2) $ liftA2 (^+^) vi (prev vi)
>>
>> prev :: Event a -> Event a
>> prev = fmap snd . withPrevE
>>
>> this code is fairly verbose, but that's because I'm trying to be very
>> explicit about the ordering of the sampling & how the new values at
>> each time step are created. The problem is that I feel like I'm
>> wrestling very hard against Reactive rather than working with it. I
>> was hoping that I could get some feedback on a way to write these very
>> simple algorithms that is more inline with the spirit of the API.
>
>
More information about the Reactive
mailing list