Page 1 of 3
Snake Arithmetic
Posted: Wed Nov 26, 2008 3:24 am
by Kikifax
Hey,
I have a very convincing looking solution for this challenge,
but it isnt accepted.
Just wondering if the challenge might be broken (ok, guess thats a remote hope)
or if that very convincing looking solution is simply wrong.
Thanks for any input.
Posted: Wed Nov 26, 2008 6:39 am
by MerickOWA
Your answer must be very exact. Depending on your method of calculation, you can get approximations which are close, but not close enough.
If you've simplifed the snake arithmetic into a solvable summation, it will still require some gymnastics to do this summation with enough precision.
If you've simplified the summation down to a basic equation, this could be easily done with no real gymnastics.
Posted: Wed Nov 26, 2008 8:06 pm
by therethinker
Wait, there was precision? Its python, and all the numbers are integers, so there should be no decimals, right?
As MerickOWA noted, this can be greatly simplified. At least as far as I got, it still would require a computer to solve, but its loads simpler/quicker than the origional problem.
Posted: Wed Nov 26, 2008 10:29 pm
by cyberwoozle
I'm short before getting crazy!
What i found (and still believe) is, that it's a linear, steadily increasing funtion. Correct?
I simplified it down to a solution, which doesn't even require a calculator - i think, it can be done with a piece of paper and a pen.
So what's the trick with the precision
Posted: Wed Nov 26, 2008 11:16 pm
by gfoot
Precision was an issue for me - it depends how you treat the division in the outer expression you're simplifying. But I didn't solve this challenge very well... I stopped thinking about it too early and just let a computer churn on it.
Posted: Thu Nov 27, 2008 12:56 am
by therethinker
Its *definitely* not linear. Plot out a graph for like b = 0 to b = 100. (I used python then imported into a spreadsheet program)
Be careful with precision though, python will round since they're ints. Add a ".0" to one of the constants: floats are infective.
Posted: Sun Nov 30, 2008 9:44 am
by Grammaton
I have the same problem. i analysed the first values, and programmed the iteration sequence. I did it on some diffrent way, with math (pen and paper) and with a calculation loop, i am always getting the same result. "...999...". I checked it more times, but i cannot find the problem. :-/
Posted: Mon Dec 01, 2008 1:35 am
by MerickOWA
You've got to be leaving something out of the equation then.
These values get very large very quick. Theres no way to directly calculate N(4*b) or D(4*b) out as integers for any sufficiently large value of b without a very very large amount of memory and time. This is the problem with all recursive functions.
You must simplify it. You can simplify it into an iterative equation which uses the calculation from the previous step to calculate it for the next step, and then repeat 1000000000000 times. Or, you must actually come up with an equation which describes the number the iterative / recursive equations are trying to give you.
Posted: Fri Dec 26, 2008 7:50 am
by osterlaus
MerickOWA wrote:Your answer must be very exact. Depending on your method of calculation, you can get approximations which are close, but not close enough.
Sorry, but I don't get that. How could there be precision? If I call this division for, lets say, b=100, I get a number without decimals. Same with b=1000...
Posted: Fri Dec 26, 2008 5:45 pm
by MerickOWA
I don't think this is too much of a give away, but this number goes on forever, larger values of b only return more of the number.
You don't get the decimals returned because all of the math is done with integer arithmetic. The division between N(4*b)*b and D(4*b) drops any remainder.
Posted: Fri Dec 26, 2008 9:08 pm
by m!nus
I like maths, but I'm not so good with this stuff (because I've never done anything alike (recursive)).
So, can someone lend me a supercomputer?
Posted: Fri Mar 05, 2010 10:16 pm
by honze
I figured out, what python means with "and" and "or".
I took the two recursive functions and transformed them into non-recursive functions.
I found an expression, that represents the (N(b*4)*b)/D(b*4) as a sum.
I found an expression, that represents the sum DIRECT. So I just have to type a few characters into python... And this answer is still wrong. I cross-checked my mathematical transformations with a math software. I even get the same result with the online python interpreter...
So, where I am wrong?
Posted: Sat Mar 06, 2010 4:20 pm
by cutter
try adding 1 to your solution
Posted: Mon Mar 08, 2010 7:29 pm
by honze
I added the 1 already to my solution. Didn't forget that.
Maybe there is an inaccuracy in the representation.
There two possibilities to display the number:
a) x.xxxxxxxxxxxe+xx
b) xxxxxxxxxxxxx.xxx
Posted: Tue Mar 09, 2010 7:25 am
by michuber
honze wrote:a) x.xxxxxxxxxxxe+xx
b) xxxxxxxxxxxxx.xxx
c) xxxxxxxxxxxxx