Darren New wrote:
> Orchid XP v8 wrote:
>> Well, if you wanted to go that far you could. 
> 
> Well, now you know why people do, when it's important to be correct. :-)
> 
> Isn't it pretty trivial to do that in Haskell, tho?

Yeah, something along the lines of

   newtype Position = Position Vector2 deriving (Eq, Show, Vector, Num)
   newtype Velocity = Velocity Vector2 deriving (Eq, Show, Vector, Num)

Now just replace all occurrances of Vector2 with Position or Velocity as 
appropriate.

The only problem is that *now* you can't say

   p1 = p0 * dt v0

without sprinkling it with typecasts.

Actually, what you'd *probably* do is define

   step :: TimeStep -> Velocity -> Position
   step dt (Velocity v) = Position (dt * v)

and then have

   p1 = p0 + step dt v0

Only problem now is that you'd have to define another such function for 
acceleration - assuming you're going to have a seperate type for that.

There's probably some better way of encoding all this. (Possibly 
assosiated types, or maybe just phantom types...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Nicolas Alvarez wrote:

> A clearer (for a human) way to see the speed is to show the inverse of that:
> seconds per frame.

Well, I can run the program and count the number of frames rendered per 
minute (approximately). The number of seconds per frame isn't something 
I can directly measure. (Of course, you can compute it yourself from my 
numbers quite easily...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:
> scott wrote:
>> I think the key point is that most things have a force that acts in 
>> the opposite direction of the movement, 
> 
> I've always found this to be quite fascinating. Why should that be?

It seems like conservation of energy and the second law of 
thermodynamics would essentially require this (barring situations where 
there's some external source of energy).

If you had an effect that reinforced itself without using some external 
source of energy then any measurable consequence of this effect would 
have to increase as a system approached a high-entropy state.  Since 
there's generally not much interesting to measure in a maximal entropy 
state it shouldn't be a surprise that there's dampening forces everywhere.

Post a reply to this message

Orchid XP v8 wrote:
> Nicolas Alvarez wrote:
> 
>> A clearer (for a human) way to see the speed is to show the inverse of
>> that: seconds per frame.
> 
> Well, I can run the program and count the number of frames rendered per
> minute (approximately). The number of seconds per frame isn't something
> I can directly measure. (Of course, you can compute it yourself from my
> numbers quite easily...)

Imagine a 3D renderer. You put one sphere: 500fps. You add a second sphere:
250fps. What? It dropped a *lot* by just adding one more sphere! How is
this going to scale to a hundred objects?

Now, you put one sphere, it takes 2 milliseconds. You add another, 4
milliseconds. That sounds better.

Even though it's the *same numbers*.

Time per frame is clearer than frames per second because the brain can't get
around the inverse curve so easily.

Post a reply to this message

> The only problem is that *now* you can't say
>
>   p1 = p0 * dt v0
>
> without sprinkling it with typecasts.
>
> Actually, what you'd *probably* do is define
>
>   step :: TimeStep -> Velocity -> Position
>   step dt (Velocity v) = Position (dt * v)
>
> and then have
>
>   p1 = p0 + step dt v0

Couldn't you just define a * function that takes a velocity and a time and 
returns a position?  You can do the same for one that takes an acceleration 
and a time and returns velocity.  Then you wouldn't need to change the code, 
and * looks better than "step".

In fact, maybe it's possible to do all this automatically if you keep track 
of the units somehow?  Could you do this in Haskell?  Somehow tell it that 
distance is units L, velocity is units L*T, etc, and then it would work it 
all out automatically when you did multiplication and division.  Would be 
pretty cool for phyical simulations.

Post a reply to this message

> Of course, now I'm trying to comprehend how this *explicit* method 
> differs from the more accurate *implicit* method I keep hearing about...

Useful link:

http://www.pixar.com/companyinfo/research/pbm2001/

Post a reply to this message

scott wrote:
> In fact, maybe it's possible to do all this automatically if you keep 
> track of the units somehow?  

Yes.

> Could you do this in Haskell?  

That was kind of what I'd meant to ask. How easy is it? Is Haskell high 
level enough to make a library for units that works like physical units?

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

scott wrote:

> Couldn't you just define a * function that takes a velocity and a time 
> and returns a position?

No.

I rephrase: Not if you want those to be different types.

The functions +, -, * and / are only defined to operate on values of the 
exact same type (and return a result of the same type also).

You can, however, define new functions with the appropriate types. (Say, 
have functions named |+|, |-|, etc. or something like that.) 
Alternatively, you can provide new definitions for +, -, etc., but then 
you have to manually remove access to the standard versions every time 
you want to use them.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:

> That was kind of what I'd meant to ask. How easy is it? Is Haskell high 
> level enough to make a library for units that works like physical units?

I know that several such libraries exist. I've never tried to use one, 
so I couldn't say how they work.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

scott wrote:
>> Of course, now I'm trying to comprehend how this *explicit* method 
>> differs from the more accurate *implicit* method I keep hearing about...
> 
> Useful link:
> 
> http://www.pixar.com/companyinfo/research/pbm2001/

...those guys! o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message