Draft

Three Body Problem

18 of 19Mo0dy
Description
Loading description...
Algorithms
View
AllIssues4Questions4SuggestionsShow Resolved
  • Please sign in or sign up to leave a comment.
  • monadius Avatar

    This comment has been hidden.

  • Voile Avatar

    This comment has been hidden.

  • Mo0dy Avatar

    What other tags would this belong to?

    • Blind4Basics Avatar

      that's not really important. Tags behave the same way than the search engine, on CW: weird & inconsistent... x) Moreover, you'll see that sometimes, tags you set in the edit panel don't even show up in the kata/detail pages. So just choose what you think is appropriate and don't bother with that... ;)

  • Mo0dy Avatar

    This comment has been hidden.

  • Blind4Basics Avatar

    Mmmmh, what did you change? because crazy things are here again, even with 15000 steps :/

    Time: 5658ms Passed: 3 Failed: 3 Exit Code: 1
Test Results:
Three Body Problem:
Example Test Cases:
'(1287.2478641781288, 733.8146853368041) == [1298, 757]+-10' should equal True
random tests
Test Passed
'(-416.74548987091987, 1123.2132947959797) == [594.18300157783324, 3345.7657282275586]+-10' should equal True
Test Passed
'(285.4809647916991, -32.93197832215975) == [756.62838279746973, 631.7669266783264]+-10' should equal True
Test Passed

    EDIT; note that you can use test.asser_approx_equals rather than building your assertion like you did. (doc)

  • Blind4Basics Avatar

    well, that's not really funny anymore, now... x) Trying using different sizes of steps, but even rounding to the unit seems not enough to allow correct solutions, if the rounding/computations aren't done exactly the same way than you do:

    Time: 4181ms Passed: 0 Failed: 6 Exit Code: 1
Test Results:
Three Body Problem:
Example Test Cases:
[1288, 734] should equal [1287, 734]
random tests
[-54, 465] should equal [-54, 464]
[-251, 124] should equal [-252, 123]
[142, 411] should equal [142, 410]
[535, -103] should equal [535, -104]
[-11, -109] should equal [-11, -110]

    I tried several values from 1000 to 30000 and the general behavior feels like very chaotic. Even with large precisions, I can end up with input where my final p1 as completely nothing in commom with the expected one. I didn't prospect yet on the input side, but I fear that the task itself is too much "unsafe" about the precision so that it's possible to get the same result than yours without having the almost exact same implementation.

    Btw, are you sure that your random generator cannot generate a "choatic" system? Because when I see that:

    Time: 6170ms Passed: 1 Failed: 5 Exit Code: 1
Test Results:
Three Body Problem:
Example Test Cases:
[1288, 734] should equal [1287, 734]
random tests
[-323, -372] should equal [-323, -373]
Test Passed
[6943, -9459] should equal [50, 8606]      <<<< Doooo!
[377, 1150] should equal [376, 1150]
[490, 42] should equal [490, 41]

    I feel like there is a problem somewhere :o

    Not even sure that the task is completable as it currently is (though, seems someone already completed it? :o Maybe my computations are actually wrong...? x) )

    • Blind4Basics Avatar

      XD lol... just found what to change. x)

      Small mistake in the description: rounded to the next natural number implies to use ceil while you actually just wanna a round operation => nearest, not next integer.

    • Mo0dy Avatar

      I might have to add a stability analysis for the inputs. It is possible that the equations lay outside of the region of stability that my euler-cauchy solver operates in.

    • Mo0dy Avatar

      I'll change the description.

    • Blind4Basics Avatar

      ok, I poked at it a bit more and here is what I found:

      • 5000 steps doesn't pass most of the time
      • 10000 steps passes almost all the time
      • 15000 is like 5000 (just a bit less failed tests but still, passes one time over 2, I'd say)

      Meaning, either you have to give the number of steps you want or... I don't know, but keeping it like that means the user will have to do a trail/error process a bit weird (and rather without that much of an interest), where too much steps lead to troubles too. :/ Could become cumbersome in a useless manner.

    • Mo0dy Avatar

      A quick Idea might be to check if the total energy of the system stays bounded in the numerical solution if not discard the random inputs

    • Blind4Basics Avatar

      Well, there I'd be completely off my charts to even try to answer to/comment that. x))

    • Mo0dy Avatar

      Just giving the number of steps won't work because different integrators will have different order of consistencies. Maybe I have to use RK3 or something like that and if I only allow for stable systems the error might be small enough to match the correct solution close enough. which means that potential warriors will have to write a solver good enough to have a small enough error. (which would make sense). Would you recommend leaving this in the beta program or closing this kata for now?

    • Blind4Basics Avatar

      I honestly don't know (about putting it in draft again or not). Since it's actually doable, I believe you can leave it here, to get other feebacks. But if you prefer to unpublish it for now, to have the time to do the modification, it's totally up to you.

      btw, some last things:

      • G=10000 -> you doesn't provide the set of units used for the problem, but I usually see that constant as 6,67e-11 x). So if it's an arbitrary value, just say "we will use...", if not, might be sympathetic to tell about the context (damn metric system, right? x) )
      • I'm not familiar at all with all the underlying maths but one thing is bothering me: Doing the computations, I compute the position t+dt using the velocity at t+dt. But why not using the one at t? Or "even better" (?), a mean of the two values? Does that make sense? are these only different possible approaches? If so, might be that some people chose one of these ways, ending with completely different outputs, couldn't they?
    • Mo0dy Avatar

      G is arbitrary Choosing the mean (to be correct something similar with weights resulting by comparison with a tayler expansion) is used in different approaches. If both solvers are stable and use sufficiently small timesteps they will produce extremely close results. I just wanted to use the simplest method possible. By that philosophy I should probably increment the position first then the velocity (this would also be technically more correct) can you check if the instability problems still persist?

    • Blind4Basics Avatar

      can you check if the instability problems still persist?

      Sounds perfect! \o/

      • 15000 always passes
      • 5000 passes most of the time too (sometimes one failure)
      • no crazy values showing up anymore.

      great work!

      Question marked resolved by Blind4Basics 7 years ago
    • Mo0dy Avatar

      ok I know I added something that should work yet i'm suprised it did

    • Mo0dy Avatar

      I think the only thing left is adding a Runge Rutta 3 solution or something comparable and checking if this will work as well

    • Blind4Basics Avatar

      (there I cannot do anything for you: I don't even know what you're talking about! x) )

    • fenring76 Avatar

      This comment has been hidden.

  • Blind4Basics Avatar

    there is something I don't follow about dt: are we supposed to return the result of a one step calculation? Usually, dt is used for an infinitesimal time duration, tho, reading further in the description, it seems you actually expect it as being an amount of "total elapsed time". That's it? If so, might be good to change the notation.

  • Blind4Basics Avatar

    hi,

    'just poking at it for now:

    • suggestion: you should put a pass statement in the body of the function, in the solution setup. That ofc changes nothing to the task but that makes the code runnable (...for a user who is just poking at the test suite... x) )
    • Issue: seems you forgot some imports in the test suite (classic mistake when authoring, because you already did the import in your "solution" file.
    Traceback (most recent call last):
  File "main.py", line 68, in <module>
    res, sol = random_test()
  File "main.py", line 63, in random_test
    sol = solution_integration(d2[0], d2[1], d2[2], d2[3], d2[4], d2[5], d2[6], d2[7], d2[8], d2[9])
  File "main.py", line 25, in solution_integration
    my_dist_cubed = dist(positions[i], positions[j]) ** 3
  File "main.py", line 9, in dist
    return sqrt((p1[0] - p2[0]) ** 2 + (p1[1] - p2[1]) ** 2)
NameError: name 'sqrt' is not defined

    EDIT: bigger troubles here, about the description:

    • you have a lot of x in there, those should be p
    • I just understood that those are actually vectors (in the calculations). Might be worth to be clarified.
    • Mo0dy Avatar

      Thanks for the comment. I will fix it now.

    • Mo0dy Avatar

      Fixed the erros and incorporated your proposal about clarifying that these are vector equations. Thanks for the input.

      Issue marked resolved by Mo0dy 7 years ago
  • Mo0dy Avatar

    This is my first Kata. I would appreciate all feedback :D