> OK, so I did all of that, and I *still* have the problem of the forces in 
> RK4 appearing to be a different scale from the forces using the Newtonian 
> method.
>
> Shouldn't I be able to just swap out the two, choosing Newtonian for 
> speed, or RK4 for accuracy, and see relatively equal* results?

Yes, if your time-step is small enough for Newton to work roughly correctly. 
Do you still get the same difference if you reduce the time step by a factor 
of 100?  If you do, then it's a coding error, if you don't then it's simply 
the fact the Newton is not doing very well at your previous time step 
amount.

Did you try a simple system first, eg constant force or very soft spring 
from one point?  With a constant force you should be able to calculate the 
exact velocity and position by hand and compare with what your algorithm 
gives out.

Post a reply to this message

scott wrote:
>> OK, so I did all of that, and I *still* have the problem of the forces 
>> in RK4 appearing to be a different scale from the forces using the 
>> Newtonian method.
>>
>> Shouldn't I be able to just swap out the two, choosing Newtonian for 
>> speed, or RK4 for accuracy, and see relatively equal* results?
> 
> Yes, if your time-step is small enough for Newton to work roughly 
> correctly. Do you still get the same difference if you reduce the time 
> step by a factor of 100?  If you do, then it's a coding error, if you 
> don't then it's simply the fact the Newton is not doing very well at 
> your previous time step amount.
> 
> Did you try a simple system first, eg constant force or very soft spring 
> from one point?  With a constant force you should be able to calculate 
> the exact velocity and position by hand and compare with what your 
> algorithm gives out.

OK, I "fixed" the timestep at 1/200th of a second, and removed all 
particle collisions - now the only force is that of gravity.

Using the two integrators, the particles follow roughly the same path, 
but using RK4 they appear to have an increased velocity - they follow 
the same path much more quickly.

Which means I've got an error somewhere in my code...

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

> OK, I "fixed" the timestep at 1/200th of a second, and removed all 
> particle collisions - now the only force is that of gravity.
>
> Using the two integrators, the particles follow roughly the same path, but 
> using RK4 they appear to have an increased velocity - they follow the same 
> path much more quickly.
>
> Which means I've got an error somewhere in my code...

It should be very easy to debug, simply print out (to a file?) the "state" 
and "derivative of state" information at each step of RK4 for one particle 
(that starts at zero velocity would make things simpler).  eg Just print out 
position and velocity in the gravity direciton.

Attached is a spreadsheet I made that matches up with the code I posted 
before, it shows you the values at each step for a constant acceleration, 
and compares the results with the Euler method and the exact solution. 
Hopefully you can spot the mistake in your code...

Post a reply to this message

Attachments:
Download 'rk4.xls.dat' (44 KB)

scott wrote:
> It should be very easy to debug, simply print out (to a file?) the 
> "state" and "derivative of state" information at each step of RK4 for 
> one particle (that starts at zero velocity would make things simpler).  
> eg Just print out position and velocity in the gravity direciton.

Thanks, I got it sorted out.  I still don't know what the error was, but 
switching from preallocating the arrays to allocating new ones every 
step & throwing them away when done solved the problem.

So there must have been some carryover somewhere that I missed.

Anyway, I'll post a binary soon.  I've been going through the forums for 
XNA studio, and apparently there's no easy way to distribute games for 
windows yet (the whole thing is a work in progress, and they're about to 
release yet another version of it).

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:

> Thanks, I got it sorted out.  I still don't know what the error was, but 
> switching from preallocating the arrays to allocating new ones every 
> step & throwing them away when done solved the problem.
> 
> So there must have been some carryover somewhere that I missed.

Ah, the evils of mutable state...


...er, wait, ignore me. [Oh, you already are...]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Chambers wrote:
> 
>> Thanks, I got it sorted out.  I still don't know what the error was, 
>> but switching from preallocating the arrays to allocating new ones 
>> every step & throwing them away when done solved the problem.
>>
>> So there must have been some carryover somewhere that I missed.
> 
> Ah, the evils of mutable state...
> ....er, wait, ignore me. [Oh, you already are...]

You know, it's not all that hard to accidentally carry over incorrect 
state in a language without mutable state, too. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Orchid XP v8 wrote:
> Chambers wrote:
> 
>> Thanks, I got it sorted out.  I still don't know what the error was, 
>> but switching from preallocating the arrays to allocating new ones 
>> every step & throwing them away when done solved the problem.
>>
>> So there must have been some carryover somewhere that I missed.
> 
> Ah, the evils of mutable state...
> 
> 
> ...er, wait, ignore me. [Oh, you already are...]
> 

I'm not ignoring you.  It was from reading all your posts on Haskell 
that I got interested in immutable values to begin with.  While I'm 
still not using them very much, at least now they're in the back of my 
mind :)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

> Thanks, I got it sorted out.  

Cool :-)

Post a reply to this message

Darren New wrote:

> You know, it's not all that hard to accidentally carry over incorrect 
> state in a language without mutable state, too. :-)

Heh. Do you have *any idea* how long it took me to finish debugging this 
JavaScript snippet?

function Bindings_Lookup(key)
{
   if (this.Key  == key) return this.Value;
   this.Next.Lookup(key);
}

It took an absurd amount of time to figure this out - especially given 
the strange way Firefox responded to it...

Sure, they'll never make a programming language where mistakes are 
impossible. But mutable state just offers *so many* ways to shoot 
yourself in the foot. :-/

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> Sure, they'll never make a programming language where mistakes are 
> impossible. But mutable state just offers *so many* ways to shoot 
> yourself in the foot. :-/

I don't understand what that has to do with mutable state, since you're 
not mutating anything there. It looks like you have the bug of too much 
recursion and the bug of not checking for the end of the list, assuming 
I'm reading it right.

And yes, firefox seems to crash my machine at least once a day, which is 
rather annoying. I've taking to running anything on a remote machine 
that takes more than 5 minutes as a nohup job, just in case my machine 
locks up.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message