# Trajectories

Discussion in 'Ruby' started by Thijs Leeflang, Nov 13, 2009.

1. ### Thijs LeeflangGuest

Thijs Leeflang, Nov 13, 2009

2. ### Eleanor McHughGuest

On 13 Nov 2009, at 23:33, Thijs Leeflang wrote:
> hello,
>
> im having a problem with trajectories,
> im trying to make an arrow like movement
> i did find this but it's way over my head
>
> http://www.gamedev.net/reference/programming/features/physicsch6/ch06.pdf

This is mostly for people who want to model the real-world movement of
projectiles, i.e. parabolic ballistic curves resulting from the action
of gravity. The math isn't hugely complicated, but it does assume a
basic familiarity with trigonometry.

> i have these values,
> @x and @y is the x and y the image is drawn
>
> @targetx = targetx
> @targety = targety
> @fromx = fromx
> @fromy = fromx
> @x = fromx
> @y = fromy
>
> can anybody help me with this?

I'm going to assume you want an OO solution that wraps stuff up in a
nice reusable fashion, so here's an example for what such a solution
might look like (it's not tested so treat with caution).

Point = Struct.newx, :y)
ComponentVector = Struct.newx, :y)

# Assume bearing stored in radians (360 degrees = 2 * Pi radians)
BearingVector = Struct.newbearing, :magnitude)

class Entity
attr_accessor :location, :forces

def initialize location = nil
@location = location || Point.new(0, 0)
@forces = {}
end

def move timeslices = 1
@forces.each do |f|
case
when f.bearing
@location.x += Math.cos(f.bearing) * f.magnitude * timeslices
@location.y += Math.sin(f.bearing) * f.magnitude * timeslices
when f.x && f.y
@location.x += f.x * timeslices
@location.y += f.y * timeslices
end
end
end
end

The solution is generalised to allow more than one force to be applied
to an individual entity, and to allow the force vector to be defined
as either (x, y) components or as an angle and a magnitude.

football = Entity.new(Point.new(100, 100)
football.forces[:gravity] = ComponentVector.new(0, -9.81)
football.forces[:kick] = BearingVector(0.5, 27)
football.forces[:wind] = BearingVector(5, 3)
football.move 3

Here I've set up a simple football scenario combining gravity, a kick
and a prevailing wind. The scenario for an arrow would look very
similar.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh, Nov 14, 2009

3. ### Marnen Laibow-KoserGuest

Thijs Leeflang wrote:
> hello,
>
> im having a problem with trajectories,
> im trying to make an arrow like movement
> i did find this but it's way over my head
>
> http://www.gamedev.net/reference/programming/features/physicsch6/ch06.pdf

Those algorithms look like they'd be fairly simple to implement, but as
Ellie said, you will need to review basic trigonometry.

>
> i have these values,
> @x and @y is the x and y the image is drawn
>
> @targetx = targetx
> @targety = targety
> @fromx = fromx
> @fromy = fromx
> @x = fromx
> @y = fromy
>
> can anybody help me with this?
> thanx

It should be fairly clear from the formulae. One thing that bears
repeating, though: never use the default floating-point numbers for
math; they're simply not precise enough. Use integers or BigDecimal.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org

--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser, Nov 14, 2009
4. ### Eleanor McHughGuest

On 14 Nov 2009, at 23:40, Marnen Laibow-Koser wrote:
> It should be fairly clear from the formulae. One thing that bears
> repeating, though: never use the default floating-point numbers for
> math; they're simply not precise enough. Use integers or BigDecimal.

That rather depends on the required level of precision...

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh, Nov 15, 2009
5. ### Marnen Laibow-KoserGuest

Eleanor McHugh wrote:
> On 14 Nov 2009, at 23:40, Marnen Laibow-Koser wrote:
>> It should be fairly clear from the formulae. One thing that bears
>> repeating, though: never use the default floating-point numbers for
>> math; they're simply not precise enough. Use integers or BigDecimal.

>
>
> That rather depends on the required level of precision...
>

Well, error accumulates pretty quickly in IEEE 754 floats, and
trajectories require lots of calculation. I wouldn't trust floats in a
situation like that -- would you?

>
> Ellie
>
> Eleanor McHugh
> Games With Brains
> http://slides.games-with-brains.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason

Best,
--
Marnen Laibow-Koser
http://www.marnen.org

--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser, Nov 15, 2009
6. ### Thijs LeeflangGuest

hey all,

i finally done it,
i set gravity to -10
then every x millisecs i added +1 to the gravity
this made a nice curve motion

after this i calculated the width between start and endpoint and voila

thanx for everything
--
Posted via http://www.ruby-forum.com/.

Thijs Leeflang, Nov 15, 2009
7. ### Eleanor McHughGuest

On 15 Nov 2009, at 00:42, Marnen Laibow-Koser wrote:
> Eleanor McHugh wrote:
>> On 14 Nov 2009, at 23:40, Marnen Laibow-Koser wrote:
>>> It should be fairly clear from the formulae. One thing that bears
>>> repeating, though: never use the default floating-point numbers for
>>> math; they're simply not precise enough. Use integers or
>>> BigDecimal.

>>
>>
>> That rather depends on the required level of precision...
>>

>
> Well, error accumulates pretty quickly in IEEE 754 floats, and
> trajectories require lots of calculation. I wouldn't trust floats
> in a
> situation like that -- would you?

In a hardcore physics simulation with many forces then no I wouldn't,
but in a simple game then yes I'd probably go with floating-point

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh, Nov 15, 2009
8. ### Marnen Laibow-KoserGuest

Eleanor McHugh wrote:
> On 15 Nov 2009, at 00:42, Marnen Laibow-Koser wrote:
>>
>> Well, error accumulates pretty quickly in IEEE 754 floats, and
>> trajectories require lots of calculation. I wouldn't trust floats
>> in a
>> situation like that -- would you?

>
> In a hardcore physics simulation with many forces then no I wouldn't,
> but in a simple game then yes I'd probably go with floating-point

Why? I can't see a single reason to use IEEE floats, unless you've done
benchmarks and are absolutely certain that it's causing a performance
problem. (Ward Cunningham did just that on a computationally intensive
Smalltalk application that used fixed-point for all math -- and found
that he couldn't even measure a difference in performance.)

IEEE floats have no advantages that I can see and huge disadvantages. I
just don't see them as being even slightly appropriate or useful for
math.

>
>
> Ellie
>
> Eleanor McHugh
> Games With Brains
> http://slides.games-with-brains.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason

Best,
--
Marnen Laibow-Koser
http://www.marnen.org

--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser, Nov 15, 2009
9. ### Eleanor McHughGuest

On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
> Eleanor McHugh wrote:
>> In a hardcore physics simulation with many forces then no I wouldn't,
>> but in a simple game then yes I'd probably go with floating-point

>
> Why? I can't see a single reason to use IEEE floats, unless you've
> done
> benchmarks and are absolutely certain that it's causing a performance
> problem. (Ward Cunningham did just that on a computationally intensive
> Smalltalk application that used fixed-point for all math -- and found
> that he couldn't even measure a difference in performance.)
>
> IEEE floats have no advantages that I can see and huge
> just don't see them as being even slightly appropriate or useful for
> math.

Because often expressing non-integral values as floating-point in code
better represents intent than using fixed-point math, and unless the
latter will have a performance or accuracy advantage for a given
problem I consider semantic simplicity to be my primary design
criterion.

That said I agree that floating-point sucks and that many programmers
use it in a carefree manner that suggests they're unaware of the
limitations it imposes.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh, Nov 15, 2009
10. ### Marnen Laibow-KoserGuest

Eleanor McHugh wrote:
> On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
>>
>> IEEE floats have no advantages that I can see and huge
>> just don't see them as being even slightly appropriate or useful for
>> math.

>
> Because often expressing non-integral values as floating-point in code
> better represents intent than using fixed-point math,

True, perhaps. Ward was doing fixed-point currency, so expressing
amounts as pennies is semantically clear.

But that's where BigDecimal comes in. It's clearly a floating-point
number, but it's actually accurate. Semantically clear, numerically
precise. What more could you want?

> and unless the
> latter will have a performance or accuracy advantage for a given
> problem I consider semantic simplicity to be my primary design
> criterion.

BigDecimal is no less semantically simple than Float (particularly when
coupled with Ruby's operator overloading), and it will always have an
accuracy advantage for any conceivable problem.

>
> That said I agree that floating-point sucks and that many programmers
> use it in a carefree manner that suggests they're unaware of the
> limitations it imposes.
>
>
> Ellie
>

Best,
--
Marnen Laibow-Koser
http://www.marnen.org

--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser, Nov 15, 2009
11. ### James Edward Gray IIGuest

On Nov 14, 2009, at 7:41 PM, Marnen Laibow-Koser wrote:

> But that's where BigDecimal comes in. It's clearly a floating-point=20=

> number, but it's actually accurate. Semantically clear, numerically=20=

If you put BigDecimal against Float, I'm pretty darn certain you will =
notice a very real speed difference.

James Edward Gray II=

James Edward Gray II, Nov 15, 2009
12. ### Marnen Laibow-KoserGuest

James Edward Gray II wrote:
> On Nov 14, 2009, at 7:41 PM, Marnen Laibow-Koser wrote:
>
>> But that's where BigDecimal comes in. It's clearly a floating-point
>> number, but it's actually accurate. Semantically clear, numerically

>
> If you put BigDecimal against Float, I'm pretty darn certain you will
> notice a very real speed difference.

Ruby 1.8.7p72 on Mac OS 10.6.1:

\$ time ruby -rbigdecimal -e "1000.times{x = BigDecimal.new('3.5') *
BigDecimal.new('4.2')}"

real 0m0.009s
user 0m0.005s
sys 0m0.003s

\$ time ruby -rbigdecimal -e "a = BigDecimal.new('3.5'); b =
BigDecimal.new('4.2'); 1000.times{x = a * b}"

real 0m0.007s
user 0m0.004s
sys 0m0.003s

\$ time ruby -e "1000.times{x = 3.5 * 4.2}"
real 0m0.008s
user 0m0.004s
sys 0m0.004s

Looks darn close to me.

> James Edward Gray II

Best,
--
Marnen Laibow-Koser
http://www.marnen.org

--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser, Nov 15, 2009
13. ### Marnen Laibow-KoserGuest

Shot (Piotr Szotkowski) wrote:
[...]
> When the time results are so small they donâ€™t really mean anything:
>
> shot@devielle:~\$ ruby -v
> ruby 1.9.1p243 (2009-07-16) [x86_64-linux]
>
> shot@devielle:~\$ time ruby -rbigdecimal -e "10_000_000.times{x =
> BigDecimal.new('3.5') * BigDecimal.new('4.2')}"
> real 0m50.280s
> user 0m47.719s
> sys 0m0.112s

[...]

Yeah, I tried longer runs as well and saw larger differences. I
question the applicability of those to actual programs, though; even
computationally intensive programs are going to be spending lots of time
doing things other than number crunching.

Besides, what good are fast calculations if they're wrong?

>
> â€” Shot

Best,
--
Marnen Laibow-Koser
http://www.marnen.org

--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser, Nov 15, 2009
14. ### Marnen Laibow-KoserGuest

Shot (Piotr Szotkowski) wrote:
> Marnen Laibow-Koser:
>
>> Yeah, I tried longer runs as well and saw larger differences.
>> I question the applicability of those to actual programs, though;
>> even computationally intensive programs are going to be spending lots
>> of time doing things other than number crunching.

>
> To clarify, I also believe BigDecimals should be used by default (when
> oneâ€™s serious about the resultsâ€™ acccuracy) until they are actually
> determined to be a performance bottleneck.

Yes, this is what I was trying to say.

> There even was a motion
> to make them the language default, but the resolution was that
> the performance cost was way too large, and that most (if not all)
> other general-purpose languages default to IEEE floats for exactly
> this reason.
>

Interesting.

>> Besides, what good are fast calculations if they're wrong?

>
> Well, if theyâ€™re slightly wrong, but a couple of times faster, they
> might be good enough; the previous example in this thread was IMHO
> a good one â€“ you donâ€™t usually need accurate float arithmetics in
> action games, but you do often care for the performance gain.

Perhaps. I would think you actually would want accurate math, but it
depends on the game.

>
> â€” Shot, who wouldnâ€™t mind if Ruby defaulted to BigDecimals

Likewise.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org

--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser, Nov 15, 2009
15. ### Josh CheekGuest

[Note: parts of this message were removed to make it a legal post.]

On Sat, Nov 14, 2009 at 7:19 PM, Marnen Laibow-Koser <>wrote:

>
> Why? I can't see a single reason to use IEEE floats, unless you've done
> benchmarks and are absolutely certain that it's causing a performance
> problem. [...] IEEE floats have no advantages that I can see and huge
> just don't see them as being even slightly appropriate or useful for
> math.
>
>

Why? unless you've done benchmarks and are absolutely certain it's causing a
precision problem.

Josh Cheek, Nov 15, 2009
16. ### Rick DeNataleGuest

On Sat, Nov 14, 2009 at 8:19 PM, Marnen Laibow-Koser <> wr=
ote:
> Eleanor McHugh wrote:
>> On 15 Nov 2009, at 00:42, Marnen Laibow-Koser wrote:
>>>
>>> Well, error accumulates pretty quickly in IEEE 754 floats, and
>>> trajectories require lots of calculation. =A0I wouldn't trust floats
>>> in a
>>> situation like that -- would you?

>>
>> In a hardcore physics simulation with many forces then no I wouldn't,
>> but in a simple game then yes I'd probably go with floating-point

>
> Why? =A0I can't see a single reason to use IEEE floats, unless you've don=

e
> benchmarks and are absolutely certain that it's causing a performance
> problem. (Ward Cunningham did just that on a computationally intensive
> Smalltalk application that used fixed-point for all math -- and found
> that he couldn't even measure a difference in performance.)

So Ward found that fixed point integers weren't SLOWER then floats,
what a surprise!

>
> IEEE floats have no advantages that I can see and huge disadvantages. =A0=

I
> just don't see them as being even slightly appropriate or useful for
> math.

That's just silly if you ask me.

First of all BigDecimals are still floats, with a decimal base and a
variable length, but floats nonetheless.

They aren't a magic bullet, and despite what you said in a slightly
later post, they are neither semantically clear:

>> "%.20f" % ((1.85 / 10.0) * 10.0)

=3D> "1.85000000000000008882"

but also

>> puts (BigDecimal.new("1.0") / 3) * 3

0.999999999999999999999999999999999999999999999999999999E0

Usually people flock to BigDecimal when they discover something like
the first example. But changing the base to 10 only
changes WHICH rational numbers can't be represented, it doesn't
eliminate the problem entirely.

or numerically precise.

Yes perhaps they are more precise but at an increasing cost of
performance as the 'need' to carry around extra digits increases.

I.E.E.E Floating point is just the culmination of the floating point
data types which got us to the moon in the 1960s. They are quite
usable as long as the programmer understands their properties and
limitations, BigDecimal has these limitations as well, just different
parameters on those limitations.

Engineers back then were very used to working with primitive computers
which used floating point numbers of extremely limited precision,
maybe 2 or 3 digits in the fractional part, those computers were
called slide rules.

When I was a young lad, it used to be that young programmers took a
semester long course on numerical analysis, which started with, and
continuously came back to dealing with the properties of floating
point numbers.

I guess that doesn't happen much anymore.

--=20
Rick DeNatale

WWR: http://www.workingwithrails.com/person/9021-rick-denatale

Rick DeNatale, Nov 15, 2009
17. ### Eleanor McHughGuest

On 15 Nov 2009, at 01:41, Marnen Laibow-Koser wrote:
> Eleanor McHugh wrote:
>> On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
>>>
>>> IEEE floats have no advantages that I can see and huge
>>> just don't see them as being even slightly appropriate or useful for
>>> math.

>>
>> Because often expressing non-integral values as floating-point in =20
>> code
>> better represents intent than using fixed-point math,

>
> True, perhaps. Ward was doing fixed-point currency, so expressing
> amounts as pennies is semantically clear.

Well currency is an interesting problem. It can be viewed as a scalar =20=

floating-point system, or as an N-dimensional integral system =20
(conventionally 2D but =A3/s/d was a clear example of a 3D currency =20
system and there's no reason why we shouldn't generalise further).

> But that's where BigDecimal comes in. It's clearly a floating-point
> number, but it's actually accurate. Semantically clear, numerically
> precise. What more could you want?

Something that for irrational numbers gives me a useful approximation =20=

without consuming all of the available memory would be nice

>> and unless the
>> latter will have a performance or accuracy advantage for a given
>> problem I consider semantic simplicity to be my primary design
>> criterion.

>
> BigDecimal is no less semantically simple than Float (particularly =20
> when
> coupled with Ruby's operator overloading), and it will always have an
> accuracy advantage for any conceivable problem.

Accuracy is not precision. It gives me little benefit to be accurate =20
if I only need to be precise to a certain number of decimal places, =20
which is the reason for the existence of floating-point in the first =20
place. One of the dirty secrets of computational physics is that =20
floating-point math is used all over the place...

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh, Nov 15, 2009
18. ### Eleanor McHughGuest

On 15 Nov 2009, at 19:13, Rick DeNatale wrote:
> I.E.E.E Floating point is just the culmination of the floating point
> data types which got us to the moon in the 1960s. They are quite
> usable as long as the programmer understands their properties and
> limitations, BigDecimal has these limitations as well, just different
> parameters on those limitations.
>
> Engineers back then were very used to working with primitive computers
> which used floating point numbers of extremely limited precision,
> maybe 2 or 3 digits in the fractional part, those computers were
> called slide rules.

Well there were books of log tables for greater precision, but the
funny thing about the physical world is that it rarely seems to need
precision higher than that.

> When I was a young lad, it used to be that young programmers took a
> semester long course on numerical analysis, which started with, and
> continuously came back to dealing with the properties of floating
> point numbers.

The fun of coding numerical methods in Fortran and Assembler. That's a
couple of hundred hours of my life I'll never see again

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh, Nov 15, 2009
19. ### Marnen Laibow-KoserGuest

Rick Denatale wrote:
> On Sat, Nov 14, 2009 at 8:19 PM, Marnen Laibow-Koser <>
> wrote:
>>
>> Why? ï¿½I can't see a single reason to use IEEE floats, unless you've done
>> benchmarks and are absolutely certain that it's causing a performance
>> problem. (Ward Cunningham did just that on a computationally intensive
>> Smalltalk application that used fixed-point for all math -- and found
>> that he couldn't even measure a difference in performance.)

>
> So Ward found that fixed point integers weren't SLOWER then floats,
> what a surprise!
>
>>
>> IEEE floats have no advantages that I can see and huge disadvantages. ï¿½I
>> just don't see them as being even slightly appropriate or useful for
>> math.

>
> That's just silly if you ask me.

Why? Sure, I could work around their problems, but I don't care to when
BigDecimals are available.

>
> First of all BigDecimals are still floats, with a decimal base and a
> variable length, but floats nonetheless.
>
> They aren't a magic bullet, and despite what you said in a slightly
> later post, they are neither semantically clear:
>
> >> "%.20f" % ((1.85 / 10.0) * 10.0)

> => "1.85000000000000008882"
>
> but also
>
> >> puts (BigDecimal.new("1.0") / 3) * 3

> 0.999999999999999999999999999999999999999999999999999999E0
>

That's not a question of semantics, but of accuracy. Anyway, it's
easily worked areound by using Rational.

> Usually people flock to BigDecimal when they discover something like
> the first example. But changing the base to 10 only
> changes WHICH rational numbers can't be represented, it doesn't
> eliminate the problem entirely.

I know. But BigDecimal + Rational *will* eliminate the problem insofar
as it's possible to do so.

>
> or numerically precise.
>
> Yes perhaps they are more precise but at an increasing cost of
> performance as the 'need' to carry around extra digits increases.
>

Of course. That's always the cost. I'd rather calculate as accurately
as possible and introduce performance hacks (such as IEEE floats) as
necessary.

>
> I.E.E.E Floating point is just the culmination of the floating point
> data types which got us to the moon in the 1960s. They are quite
> usable as long as the programmer understands their properties and
> limitations, BigDecimal has these limitations as well, just different
> parameters on those limitations.
>
> Engineers back then were very used to working with primitive computers
> which used floating point numbers of extremely limited precision,
> maybe 2 or 3 digits in the fractional part, those computers were
> called slide rules.

Yes. And you know what? We're not using slide rules any more. It is
silly in 2009 to be bound by the limitations of slide rules.

>
> When I was a young lad, it used to be that young programmers took a
> semester long course on numerical analysis, which started with, and
> continuously came back to dealing with the properties of floating
> point numbers.
>
> I guess that doesn't happen much anymore.

Again, I could do that or (more likely) find out how to do it. But why
bother when wise use of BigDecimal and Rational will completely obviate
the need?

>
> --
> Rick DeNatale
>
> WWR: http://www.workingwithrails.com/person/9021-rick-denatale

Best,
--
Marnen Laibow-Koser
http://www.marnen.org

--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser, Nov 15, 2009
20. ### Eleanor McHughGuest

On 15 Nov 2009, at 23:02, Marnen Laibow-Koser wrote:
> Rick Denatale wrote:
>> When I was a young lad, it used to be that young programmers took a
>> semester long course on numerical analysis, which started with, and
>> continuously came back to dealing with the properties of floating
>> point numbers.
>>
>> I guess that doesn't happen much anymore.

>
> Again, I could do that or (more likely) find out how to do it. But
> why
> bother when wise use of BigDecimal and Rational will completely
> obviate
> the need?

The physical limitations imposed on arbitrary-precision decimal
computation by binary representation are something you should know
*before* arguing that one representation is better than another.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh, Nov 15, 2009