Snake Arithmetic

User avatar
Kikifax
Posts: 2
Joined: Tue Nov 18, 2008 1:30 am

Snake Arithmetic

Post 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.
MerickOWA
Posts: 182
Joined: Mon Apr 07, 2008 5:54 pm
Location: HkRkoz al KuwaiT 2019 HaCkEr 101

Post 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.
therethinker
Posts: 144
Joined: Fri Mar 28, 2008 11:29 pm
Location: #hacker.org on Freenode

Post 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.
cyberwoozle
Posts: 60
Joined: Fri Nov 07, 2008 10:43 am
Location: Germany

Post 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 :?:
gfoot
Posts: 269
Joined: Wed Sep 05, 2007 11:34 pm
Location: Brighton, UK

Post 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.
therethinker
Posts: 144
Joined: Fri Mar 28, 2008 11:29 pm
Location: #hacker.org on Freenode

Post 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.
Grammaton
Posts: 9
Joined: Tue Nov 04, 2008 11:32 am
Location: Bavaria, Germany

Post 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. :-/
MerickOWA
Posts: 182
Joined: Mon Apr 07, 2008 5:54 pm
Location: HkRkoz al KuwaiT 2019 HaCkEr 101

Post 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.
osterlaus
Posts: 20
Joined: Sun Nov 02, 2008 6:04 pm

Post 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...
MerickOWA
Posts: 182
Joined: Mon Apr 07, 2008 5:54 pm
Location: HkRkoz al KuwaiT 2019 HaCkEr 101

Post 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.
User avatar
m!nus
Posts: 202
Joined: Sat Jul 28, 2007 6:49 pm
Location: Germany

Post 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? :)
honze
Posts: 6
Joined: Mon Nov 03, 2008 7:20 am
Location: Munich, Germany
Contact:

Post 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?
cutter
Posts: 17
Joined: Mon Jan 12, 2009 12:50 pm

Post by cutter »

try adding 1 to your solution
honze
Posts: 6
Joined: Mon Nov 03, 2008 7:20 am
Location: Munich, Germany
Contact:

Post 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
michuber
Posts: 57
Joined: Sun Oct 26, 2008 3:30 pm

Post by michuber »

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