|
-
Jan 20th, 2004, 02:54 PM
#1
Number series.....
If you have the numbers 2, 8, 16...
What will the next number be?? Am I dumb or can't I see this?
-
Jan 20th, 2004, 06:16 PM
#2
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
-
Jan 20th, 2004, 07:19 PM
#3
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....
-
Jan 21st, 2004, 04:15 PM
#4
Member
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?
-
Jan 21st, 2004, 04:28 PM
#5
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/
-
Jan 21st, 2004, 07:18 PM
#6
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.
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.
Last edited by NotLKH; Jan 21st, 2004 at 07:36 PM.
-
Jan 21st, 2004, 07:58 PM
#7
-
Jan 21st, 2004, 09:25 PM
#8
transcendental analytic
give it up note, that in no way is going to be faster than newton raphson
Use  
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jan 22nd, 2004, 12:10 PM
#9
There is so many fun sites out there....
-
Jan 22nd, 2004, 12:12 PM
#10
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++
-
Jan 22nd, 2004, 12:14 PM
#11
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....
-
Jan 23rd, 2004, 01:49 AM
#12
transcendental analytic
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++
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 
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jan 24th, 2004, 01:35 PM
#13
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
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...
-
Jan 25th, 2004, 11:30 AM
#14
Fanatic Member
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.
Don't pay attention to this signature, it's contradictory.
-
Jan 25th, 2004, 12:35 PM
#15
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...
-
Jan 25th, 2004, 01:02 PM
#16
transcendental analytic
CB's example isn't timecritical
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jan 25th, 2004, 01:11 PM
#17
OF course it is....you have change the number in every freeken frame change, and there could be more then one of them.,...
-
Jan 25th, 2004, 01:18 PM
#18
transcendental analytic
now you have lost the proportions totally note, how fast is one sqrt? how long time should a frame take?
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jan 25th, 2004, 01:22 PM
#19
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.....
-
Jan 26th, 2004, 03:26 AM
#20
transcendental analytic
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.
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jan 26th, 2004, 05:50 AM
#21
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...
-
Jan 26th, 2004, 04:34 PM
#22
transcendental analytic
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
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jan 27th, 2004, 03:55 AM
#23
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...
-
Jan 27th, 2004, 10:49 AM
#24
transcendental analytic
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
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jan 27th, 2004, 03:23 PM
#25
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*..
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|
Reply With Quote