If you have the numbers 2, 8, 16...
What will the next number be?? Am I dumb or can't I see this?
Printable View
If you have the numbers 2, 8, 16...
What will the next number be?? Am I dumb or can't I see this?
Hmmm,
Lets see:
2==>8, seperated by 6
8==>16, seperated by 8
We could assume the seperations continually increase by 2, which means
the next one would be seperated from 16 by 10, which gives us
26
However, it could also be:
2==>8, multiply by 4
8==>16, multiply by 2
We could assume the multiplybys continually are the brevious multiplyby divided by 2, which means the next multiplyby would be 1, which means the next answer is 16*1 or
16
Or, well we could make many different assumptins and have many different nextnumbers.
But I'll bet the most common answer is 26
-Lou
That was what I guessed too. Not sure what the right answer is at the moment, but I will tell you if I find out.....if I just had one more number to go after it would be so much simpler....
I think that it is impossible to find out a single solution for sucha problem if only 3 terms are given which are distinct.
What do U all think?
Got it from here....I think I just have to test it to see what is right.....
http://functions.wolfram.com/Element...06/01/01/0005/
They sure did a lousy job of documentation there!
Looking around for a better representation, {which I haven't found yet} I stumbled across this interesting method:
http://www.hpmuseum.org/root.htm
Its a nice peice of brain candy.
:wave:
Also, the series perhaps could be:
Odd Term
(2)^0, (2)^3, ==> Implying (2)^6, 2^9, 2^12...
Even Term
2^1, 2^4, ==> Implying 2^7, 2^10, 2^13, ...
Which looks more like:
1 , 2, 8, 16 , 64 , 128, 512,1024...
But of course this is just a guess at this moment.
give it up note, that in no way is going to be faster than newton raphson
Quote:
There is so many fun sites out there....:D
Quote:
Originally posted by kedaman
give it up note, that in no way is going to be faster than newton raphson
Didn't you see that I implemented a test for a not that presise way, and it was really really slow.....not the slowest one, but slow...
I am still wondering what way they have done it in VC++
Quote:
Originally posted by NotLKH
They sure did a lousy job of documentation there!
Yeah I can't understand why they didn't write the n part in the series at the end....:(
dunno, I still think you won't be needing sqrt, at least not in any time critical processes, but you still haven't told me, so thats why I haven't bothered looking at your statistics ;)Quote:
Originally posted by NoteMe
Didn't you see that I implemented a test for a not that presise way, and it was really really slow.....not the slowest one, but slow...
I am still wondering what way they have done it in VC++
My GF never left that night....so I didn't bother to look for it in the book...but I saw Cornedbee posted an example....so I thought that I was off the hook, at least for a couple of more days...;)Quote:
Originally posted by kedaman
dunno, I still think you won't be needing sqrt, at least not in any time critical processes, but you still haven't told me, so thats why I haven't bothered looking at your statistics ;)
2^1 = 2, 2^3 = 8, 2^4 = 16 (next number is 8, then 2, then 1/4)
Oh, and I noticed that 2*8 = 16.
Hehe...there is a lot of options here...and I have no time to test it..maybe if I get some time I could mail them about it...:D
CB's example isn't timecritical ;)
OF course it is....you have change the number in every freeken frame change, and there could be more then one of them.,...;)
now you have lost the proportions totally note, how fast is one sqrt? how long time should a frame take?
A frame should never take more then 16-35 ms....but Sqrt() is much faster then the graphics drawing....so you have to use as little time on calculations before you are starting to draw....and that is all AI, collision detection, key presses, music and so on.....
yeah, and how much time do you think collission detection is giong to consume, not to forget the AI compared to showing the proximity of an incoming missile.
Not much time, but that is not the point here....you are missing ouy my point.....the drawing and the AI and stuff like that will nearly use up all the time there is in the loop. So the rest has to be minimized as HELL. So Sqrt() has to be omitted as much as it can, and if you use it, it should be optimized...;)
note you are prioritising things the wrong way, you should first make sure that the most time critical parts are optimised, the rest doesn't make much of a difference anyway
The point is that you get to a limit where the rendering and AI and stuff can't be optimzed anymore, at least without redoing the whole engine. But optimizing a square function and stuff you can do with little changes all the time...thats my point...;)
Well i think at least you have already spent way too much time on this function compared to how much difference is going to do in the game, instead of getting the engine to work in the first place so you can see what is most time critical and try to optimize it ;)
I just wanted to see if I could make it faster then the sqrt() in C++, it would be so reusable...and we did manage to make it faster then using the ASM code for it...;).....so VC++ must have a pretty fast Sqrt() function....*me runs to see if I can do it faster in VB*..:D