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
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
--
Posted via http://www.ruby-forum.com/.
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 headhttp://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 = fromycan 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.new(:x, :y)
ComponentVector = Struct.new(:x, :y)
# Assume bearing stored in radians (360 degrees = 2 * Pi radians)
BearingVector = Struct.new(:bearing, :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
On 13 Nov 2009, at 23:33, Thijs Leeflang wrote:
----
raise ArgumentError unless @reality.responds_to? :reason
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 headhttp://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 = fromycan 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
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.
That rather depends on the required level of precision...
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
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.
----
raise ArgumentError unless @reality.responds_to? :reason
Eleanor McHugh 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,
On 14 Nov 2009, at 23:40, Marnen Laibow-Koser wrote:
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.
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/.
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
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?
----
raise ArgumentError unless @reality.responds_to? :reason
Eleanor McHugh 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,
On 15 Nov 2009, at 00:42, Marnen Laibow-Koser wrote:
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.
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
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-pointWhy? 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.
----
raise ArgumentError unless @reality.responds_to? :reason
Why? unless you've done benchmarks and are absolutely certain it's causing a
precision problem.
On Sat, Nov 14, 2009 at 7:19 PM, Marnen Laibow-Koser <marnen@marnen.org>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
disadvantages. I
just don't see them as being even slightly appropriate or useful for
math.
Eleanor McHugh 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-pointWhy? 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.
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
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.
On Sat, Nov 14, 2009 at 8:19 PM, Marnen Laibow-Koser <marnen@marnen.org> wrote:
On 15 Nov 2009, at 00:42, Marnen Laibow-Koser wrote:
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Eleanor McHugh wrote:
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.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,
On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.
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
On 15 Nov 2009, at 19:13, Rick DeNatale wrote:
----
raise ArgumentError unless @reality.responds_to? :reason
Rick Denatale 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 DeNataleBlog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Best,
On Sat, Nov 14, 2009 at 8:19 PM, Marnen Laibow-Koser <marnen@marnen.org> > wrote:
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.
I took numerical analysis, but ironically, only after dropping my CS
major and going for a math major.
Also, I'll content that abstract algebra was about the best course
I've taken for helping the way I think about programming.
Too bad the CS students are all too busy trying to get their Java/C++
projects to compile
On Sun, Nov 15, 2009 at 2:13 PM, Rick DeNatale <rick.denatale@gmail.com> 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.
If you put BigDecimal against Float, I'm pretty darn certain you will notice a very real speed difference.
James Edward Gray II
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
Eleanor McHugh wrote:
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.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.
Well currency is an interesting problem. It can be viewed as a scalar floating-point system, or as an N-dimensional integral system (conventionally 2D but £/s/d was a clear example of a 3D currency 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 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 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 if I only need to be precise to a certain number of decimal places, which is the reason for the existence of floating-point in the first place. One of the dirty secrets of computational physics is that floating-point math is used all over the place...
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
On 15 Nov 2009, at 01:41, Marnen Laibow-Koser wrote:
On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
----
raise ArgumentError unless @reality.responds_to? :reason
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
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?
----
raise ArgumentError unless @reality.responds_to? :reason
I can't find who first said this, but a quote I've used - with success - is:
"It is better to be approximately right than precisely wrong."
(Unfortunately I had *very* little success in persuading people to
replace figures like $10,563.27 with $10,563. And that was
deliberately limiting my intention knowing the likely resistance: what
I really wanted to get them to do was use $10,560 to make it clear
that the $10,563.27 was approximate, not exact.)
I don't know much about Numerical Analysis, but I do know enough to be
very wary about just increasing precision.
Never hire a computer scientist if you can get a maths, physics or philosophy grad instead 
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
On 17 Nov 2009, at 19:55, Gregory Brown wrote:
On Sun, Nov 15, 2009 at 2:13 PM, Rick DeNatale <rick.denatale@gmail.com> 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.
I took numerical analysis, but ironically, only after dropping my CS
major and going for a math major.
Also, I'll content that abstract algebra was about the best course
I've taken for helping the way I think about programming.Too bad the CS students are all too busy trying to get their Java/C++
projects to compile
----
raise ArgumentError unless @reality.responds_to? :reason