Daniel Fischer wrote:
If the algorithm - including dt - is prescribed, fine, but I wonder what sort
of deviation physicists would consider acceptable.
For dt = 0.01, k = 2000 we have a relative error of about 2*10^(-5), is that
within accepted bounds or not? (Any physicists hang about here?)
I
Am Montag, 9. Mai 2005 05:38 schrieb Greg Buchholz:
> Daniel Fischer wrote:
> > One question: the energy of the system should be constant - that little
> > physics I know. What I don't know is whether the change in energy in this
> > simulation is within usual, reasonable bounds or not. If not, is
Daniel Fischer wrote:
> One question: the energy of the system should be constant - that little
> physics I know. What I don't know is whether the change in energy in this
> simulation is within usual, reasonable bounds or not. If not, is it due to a
> too long time interval or should one use a
Am Freitag, 6. Mai 2005 16:58 schrieb Greg Buchholz:
> Daniel Fischer wrote:
> > The problem is that a prime crept in in Josef's code,
> > so to calculate the positions and velocities, the updated versions of the
> > planets are used, it should be
>
> Ah, yes, thanks for the correction.
>
> > B
Josef Svenningsson wrote:
> Devastating! Hence we will need a strict list to do this or some other
> strict data structure.
Seems like the relation between the planets is better described as a
graph, instead of a list. Maybe there's something in Data.Graph that'll
help us make a more straight
Josef Svenningsson wrote:
> Greg, you express the sequential computation of updating the set of
> planets as an iteration over a list. This is a sweet way of expressing
> it but doesn't work very well when an element of the list contain
> pointers to the previous element. This will force all the el
On 5/6/05, Daniel Fischer <[EMAIL PROTECTED]> wrote:
> Am Freitag, 6. Mai 2005 02:24 schrieb Greg Buchholz:
> > We're heading in the right direction anyway. I can now compute 1
> > million iteration in about 2 minutes (with +RTS -H750M -K100M). Well
> > almost, since it now doesn't compute th
Greg Buchholz <[EMAIL PROTECTED]> writes:
> I wasn't too worried about the energy function, since it only gets
> called twice, whereas the "advance" get called potentially millions of
> times (and must be the source of the space leak).
After running a few examples myself, it seems clear that
Daniel Fischer wrote:
> The problem is that a prime crept in in Josef's code,
> so to calculate the positions and velocities, the updated versions of the
> planets are used, it should be
Ah, yes, thanks for the correction.
> Besides, offset_momentum does not use the parameter n at all and I
Am Freitag, 6. Mai 2005 02:24 schrieb Greg Buchholz:
> Josef Svenningsson wrote:
> > I think the thing that really kills you is the way you shuffle around
> > the list in the advance function. Your commented out rotations
> > function has the same problem. Here is my attempt to solve the problem
>
Lennart Augustsson wrote:
> Have you tried heap profiling?
>
Not on the updated version from Josef Svenningsson, but you can look
at the heap profiles for the previous version at...
http://sleepingsquirrel.org/nbody
...the *.ps files are the ones you want.
Greg Buchholz
Have you tried heap profiling?
-- Lennart
Greg Buchholz wrote:
Josef Svenningsson wrote:
I think the thing that really kills you is the way you shuffle around
the list in the advance function. Your commented out rotations
function has the same problem. Here is my attempt to solve the proble
Josef Svenningsson wrote:
> I think the thing that really kills you is the way you shuffle around
> the list in the advance function. Your commented out rotations
> function has the same problem. Here is my attempt to solve the problem
> a little more efficiently:
We're heading in the right di
On 5/5/05, Greg Buchholz <[EMAIL PROTECTED]> wrote:
>
> I've been dabbling with implementing the "n-body" benchmark over at
> the "Great Computer Language Shootout"...
>
> http://shootout.alioth.debian.org/benchmark.php?test=nbody
>
> ...and I've stumbled on to a problem with space leaks. T
I've been dabbling with implementing the "n-body" benchmark over at
the "Great Computer Language Shootout"...
http://shootout.alioth.debian.org/benchmark.php?test=nbody
...and I've stumbled on to a problem with space leaks. The code below
works great for low numbers of iterations, but crash
15 matches
Mail list logo
