Snake Arithmetic

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.

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.

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.

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 Question

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.

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.

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. :-/

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.

	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...

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.

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? Smile

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?

try adding 1 to your solution

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

	honze wrote:
	a) x.xxxxxxxxxxxe+xx b) xxxxxxxxxxxxx.xxx

c) xxxxxxxxxxxxx