Personally, I've always favored the simplicity of the inclined plane, however lately the lever has had its merits.

11/1/2008 1:57:27 PM

Either a pulley or a screw.

11/1/2008 2:05:48 PM

Screws can be useful in LEGO form

11/1/2008 2:16:34 PM

i love worm gears

so let's say screw

11/1/2008 2:29:34 PM

levers




pulleys never appealed to me

11/1/2008 2:30:28 PM

screws are just inclined planes that are twisted

11/1/2008 2:35:31 PM

Quote :

"screws are just inclined planes that are twisted"

11/1/2008 3:02:26 PM

first thing i thought of when i saw this thread

11/1/2008 3:05:05 PM

i have always been a fan of the pulley

Quote :

"screws are just inclined planes that are twisted"

in terms of construction, yes, a screw is a helical inclined plane. some people say a screw is not a simple machine because of this. that's simply not the case because a screw simultaneously converts a rotational force (torque) to a linear force

^ i loved that game

11/1/2008 3:13:20 PM

^assuming no energy is dissipated (ie the balls bounce the same height every time) why do they eventually change trajectory once the loop gets going?

pulleys ftw (and their cousin, the gear)

11/1/2008 4:00:24 PM

the bowling balls eventually destabilize because of chaos theory and ill-conditioned floating-point math. you do the same thing over and over to a number and small irregularities amplify.

consider you have two approximations of phi, 1.6180339 and 1.6180340. phi is defined as: phi^2=phi+1, so if you square it and subtract 1 you should get the same thing, right? but if you do this just 5 times to each, you have 1.61802426 and 1.61803522 respectively. every iteration, the difference seems to increase by nearly an order of magnitude (and would do so for every decimal approximation of phi).

11/1/2008 5:39:41 PM

My favorite is the rail gun. It might be complex to you simpletons, but it's simple to me.



I'll go with the screw.

11/1/2008 5:48:44 PM

I, too, am a fan of the lever

11/1/2008 6:17:26 PM

GO BANANA!

11/1/2008 7:07:40 PM

Quote :

"^assuming no energy is dissipated (ie the balls bounce the same height every time) why do they eventually change trajectory once the loop gets going?"

Watch the ball on the right at the very beginning. Its final height (after bounce) is much higher than its initial height (beginning of contraption). Seems to me like they just misprogrammed the trampolines.

11/1/2008 8:16:40 PM

Quote :

"the bowling balls eventually destabilize because of chaos theory and ill-conditioned floating-point math."

pwnt by programming.

11/1/2008 10:53:52 PM

Quote :

"Watch the ball on the right at the very beginning. Its final height (after bounce) is much higher than its initial height (beginning of contraption). Seems to me like they just misprogrammed the trampolines."

if i remember correctly, didn't the TIM trampolines add energy? there was the one level where you had to get the basketball through the hoop and you only had trampolines

11/2/2008 9:48:45 AM

im gonna say the wheel

11/2/2008 10:07:54 AM

Quote :

"pwnt by programming. fundamental limitations of computing"

it would require infinite time or infinite memory to perform the calculation in full precision

also, I just used a lever to tension a pulley system, omg simple machines

[Edited on November 2, 2008 at 6:41 PM. Reason : *]

11/2/2008 6:39:37 PM

^eh. he said ill-conditioned floating point math, so i figured there is probably some way around it. but what do i know, i'm just a glorified plumber.

11/2/2008 7:36:34 PM

she

You can eliminate the occurrence of such artifacts in many problem spaces by making assumptions that are logical in the context of your problem, but it's not possible to account for every eventuality in the library/hardware implementation. It's a cumulative rounding error at the limit of the type's precision and there is no way to avoid this entirely without more precision. Infinite precision would be the logical conclusion, and computations on such a quantity would require either infinite memory or infinite time.

--

You know, unless this game lets you input fractional pixel quantities the trajectories for every initial pixel position will probably diverge long before the floating point error ever becomes significant, it would require a freakin' ridiculous number of iterations for the error to become that large

IEEE-754 64-bit floating point values have 2^53 bits of precision, so assuming 2^10 x 2^10 the worst case scenario would require something like 2^43 iterations for a single pixel error to accumulate

[Edited on November 2, 2008 at 8:21 PM. Reason : -- further consideration]

11/2/2008 8:00:15 PM

TIM was a game on Windows 3.1, so it was 16-bit, so you have to assume pretty low precision on floating point numbers in the game anyway. And an operation on each object's vector is going to be done every frame, so 22 iterations of the bowling balls juggling is pretty impressive IMO.

11/2/2008 8:51:55 PM

I should think the wheel or it's distant offspring the pulley...is there anything that a pulley cannot do that a lever can?

11/2/2008 9:15:10 PM

^^At the risk of derailing the thread, I must point out that "16-bit" refers to the width of values used in API calls, not a limit on the width of a floating point type or even an integer type. I mean, common sense, you can use long long (64-bit ints) or doubles (64-bit floats) on Win32, can't you?

So at the least you're looking at a 32-bit floating point type, or a single float, with the same assumption of a 1024x1024 viewport, that has 24 bits of precision which yields 2^14 iterations before rounding results in a single pixel error. This is assuming that every single operation results in a significant rounding error, which is highly improbable. But even if we take the worst case and run with it, that every single operation results in a significant rounding error, at 60 frames per second and let's assume 20 calculations per frame, that's roughly 13 seconds before the first single pixel error could accumulate. Considering every object in the system appears to have a critical width larger than a single pixel, I maintain that there is no way floating point errors are responsible for the divergence here. The math alone can explain the divergence without the need for floating point errors. It only appears to be a stable system because it takes 22 bounces for it to diverge.

[Edited on November 2, 2008 at 10:28 PM. Reason : .]

11/2/2008 10:12:54 PM

my iPhone

11/3/2008 12:11:55 AM

^^ Win3.1 wasn't 32bit. It had some very limited 32bit Win32 support to co-mingle with NT.

I guarantee you that TIM was a 16bit protected mode DOS app. And it's overwhelmingly likely he used

Quote :

"32-bit floating point type, or a single float"

as it was likely written for an 80386 cpu, and while you could do 64bit math, it was REALLY expensive. Even 32bit floating point math was pretty taxing, but it was fast enough that it could have been used.

11/3/2008 12:52:08 AM

I wasn't trying to imply 3.1 was 32-bit if it reads that way. I was just using that anecdote as an example of the width of data types used by the compiler not being related to width of data types used in the system API.

Since the thread's already derailed, do you know what the native int type was on a Win 3.1 system? e.g. if you declared an "int" without "short" or "long" would you get a short since the system API is 16-bit, or would you get a long since the processor architecture is 32-bit?

[Edited on November 3, 2008 at 1:16 AM. Reason : .]

11/3/2008 1:15:08 AM

I can only vouch for DOS 6.22 on this (it may have been different with WinAPI in Win 3.11) but a declared int was 16bit by default with the MS C compiler at the time (it could be pretty easily changed obvious).

Back then it wasn't really what the system could do, it was what you could get by with in a reasonable amount of time. By the time the 80386 came out, and certainly with the 80486, you have pretty much every math transform you needed to do ANYTHING computationally. It was just BALLS slow (3mhz for the 386, and 12 for the 486 if I remember correctly?)

11/3/2008 2:56:43 AM

this is why no one respects tech talk

11/3/2008 8:28:19 AM

well a simple machine thread really should have been made in the Garage, imo

11/3/2008 1:20:10 PM