Trajectories
Thijs Leeflang
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/.
Eleanor McHugh
> 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.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
----
raise ArgumentError unless @reality.responds_to? :reason
Marnen Laibow-Koser
> 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
mar...@marnen.org
Eleanor McHugh
> 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...
Marnen Laibow-Koser
> 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,
Thijs Leeflang
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 :D
Eleanor McHugh
> 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 :)
Marnen Laibow-Koser
> 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,
Eleanor McHugh
> Eleanor McHugh wrote:
>> 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.
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.
Marnen Laibow-Koser
> On 15 Nov 2009, at 01:19, Marnen Laibow-Koser 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,
James Edward Gray II
> 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.
James Edward Gray II
Marnen Laibow-Koser
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
Marnen Laibow-Koser
[...]
> 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 =
> 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
Marnen Laibow-Koser
> 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.
>
> 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.
Josh Cheek
On Sat, Nov 14, 2009 at 7:19 PM, Marnen Laibow-Koser <mar...@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.
>
>
Why? unless you've done benchmarks and are absolutely certain it's causing a
precision problem.
Rick DeNatale
> 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.)
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.
--
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
> 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
>>> 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...
Eleanor McHugh
> 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 :)
Marnen Laibow-Koser
> On Sat, Nov 14, 2009 at 8:19 PM, Marnen Laibow-Koser <mar...@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. (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
>
> 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
Best,
Eleanor McHugh
> 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.
Colin Bartlett
"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.
Todd Benson
<ele...@games-with-brains.com> wrote:
> 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.
I think Marnen originally was suggesting that the imprecisions will
stack, like an arrow at a target going more and more off course during
its flight, of course depending on the application. For some apps,
it's totally reasonable to see something go chaotic because of these
things.
For a short and unimportant game I'm playing, I wouldn't be upset.
But, for a game that takes 10's of hours and have it ride my butt
later at a crucial moment, I might just call that a bug.
Does the imprecision in the calculation stack in ballistic calcs? A
virtual magic bullet as it were? I'm not sure, but I'm guessing it
doesn't to great effect.
Todd
Eleanor McHugh
> On Sun, Nov 15, 2009 at 5:32 PM, Eleanor McHugh
>> computation
>> by binary representation are something you should know *before*
>> arguing that
>> one representation is better than another.
>
> I think Marnen originally was suggesting that the imprecisions will
> stack, like an arrow at a target going more and more off course during
> its flight, of course depending on the application. For some apps,
> it's totally reasonable to see something go chaotic because of these
> things.
This isn't an issue of chaotic behaviour (that has a very fixed
meaning mathematically) but of unnoticeable error. The difference
between 1e10-13 and 2e10-13 matters a lot when working on a system
which needs to be accurate to a resolution of 1e10-14 but not when
working to a resolution of 1e10-4. The additional nine decimal places
tell us nothing meaningful in this latter case as we'll still end up
rounding the result to zero.
> For a short and unimportant game I'm playing, I wouldn't be upset.
> But, for a game that takes 10's of hours and have it ride my butt
> later at a crucial moment, I might just call that a bug.
That's not a bug but a fundamental outcome of the nature of binary
coded non-integral numbers. Many rational non-integral numbers cannot
be expressed accurately in binary representations, whilst binary coded
decimal brings a whole host of other problems: lower information
density, higher memory usage, and heavier processing load. BCD also
does nothing to resolve the problem of how to represent irrational
numbers such as π.
> Does the imprecision in the calculation stack in ballistic calcs? A
> virtual magic bullet as it were? I'm not sure, but I'm guessing it
> doesn't to great effect.
The imprecision can indeed stack for complex ballistics systems,
depending on the complexity of the forces involved. However to the
extent of the precision chosen for performing these calculations the
resultant inaccuracy is irrelevant.
http://en.wikipedia.org/wiki/Accuracy_and_precision explains all of
this in reasonable detail.
Marnen Laibow-Koser
> On 15 Nov 2009, at 23:02, Marnen Laibow-Koser wrote:
>> 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.
I am aware of the limitations. I believe I'm even fully aware of them.
:) What do you think I have failed to take into account?
>
>
> Ellie
>
> Eleanor McHugh
> Games With Brains
> http://slides.games-with-brains.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason
Best,
Marnen Laibow-Koser
> On 16 Nov 2009, at 01:12, Todd Benson wrote:
>> it's totally reasonable to see something go chaotic because of these
>> things.
>
> This isn't an issue of chaotic behaviour (that has a very fixed
> meaning mathematically) but of unnoticeable error. The difference
> between 1e10-13 and 2e10-13 matters a lot when working on a system
> which needs to be accurate to a resolution of 1e10-14 but not when
> working to a resolution of 1e10-4. The additional nine decimal places
> tell us nothing meaningful in this latter case as we'll still end up
> rounding the result to zero.
>
>> For a short and unimportant game I'm playing, I wouldn't be upset.
>> But, for a game that takes 10's of hours and have it ride my butt
>> later at a crucial moment, I might just call that a bug.
>
> That's not a bug but a fundamental outcome of the nature of binary
> coded non-integral numbers.
If it gives you the wrong answer, it's a bug. Period. If your
representation cannot give you the precision you need for the task at
hand, then you need a different representation. Period. The end user
doesn't care about your representation -- he cares about getting the
right answer.
[...]
> BCD also
> does nothing to resolve the problem of how to represent irrational
> numbers such as π.
No, becuase that's impossible to do with a finite representation AFAIK.
If I'm wrong, I would love to know how this can be done.
[...]
>
> Ellie
>
> Eleanor McHugh
> Games With Brains
> http://slides.games-with-brains.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason
Best,
Paul Smith
Your above two points appear to be in conflict with each other.
> [...]
>>
>> 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
> mar...@marnen.org
> --
> Posted via http://www.ruby-forum.com/.
>
>
--
Paul Smith
http://www.nomadicfun.co.uk
Marnen Laibow-Koser
> On Mon, Nov 16, 2009 at 2:57 AM, Marnen Laibow-Koser <mar...@marnen.org>
> wrote:
>>> tell us nothing meaningful in this latter case as we'll still end up
>>
Well, they're not "my" two points -- Eleanor wrote the first line, and I
think you missed the "if" on the second one.
Paul Smith
> Paul Smith wrote:
>> On Mon, Nov 16, 2009 at 2:57 AM, Marnen Laibow-Koser <mar...@marnen.org>
>> wrote:
>>>> tell us nothing meaningful in this latter case as we'll still end up
>>> representation cannot give you the precision you need for the task at
>>>
>> Your above two points appear to be in conflict with each other.
>
> Well, they're not "my" two points -- Eleanor wrote the first line, and I
> think you missed the "if" on the second one.
No, I really mean your two points.
On the one hand, you say "If it gives you the wrong answer, it's a
bug. Period. If your representation cannot give you the precision
you need for the task at hand, then you need a different
representation. Period."
Then you say "No, becuase [representing irrational numbers is]
impossible to do with a finite representation AFAIK. If I'm wrong, I
would love to know how this can be done."
>
>>
Marnen Laibow-Koser
[...]
> No, I really mean your two points.
>
> On the one hand, you say "If it gives you the wrong answer, it's a
> bug. Period. If your representation cannot give you the precision
> you need for the task at hand, then you need a different
> representation. Period."
>
> Then you say "No, becuase [representing irrational numbers is]
> impossible to do with a finite representation AFAIK. If I'm wrong, I
> would love to know how this can be done."
Interesting question. I don't think that's a contradiction so much as
an acknowledgement of the fundamental limitations of digital computing.
With data structures like BigDecimal and Rational, we can exactly
represent any rational number we like in a finite amount of storage.
Irrational numbers are different. We could represent them exactly on an
analog computer such as a slide rule, but there is no general method
that I am aware of for doing so in a finite amount of digital storage.
Certain numbers, such as square roots, can be represented with tricks
like quadratic equations to which they are the root, but that won't work
for transcendental numbers like e or π. We can calculate those numbers
to millions of decimal places if we need to -- but unlike rational
numbers, we can never store them exactly.
So we do the best we can. Since rational numbers can be represented
exactly, it makes sense to do so. Since (many) irrational numbers
cannot be represented exactly, we get as close as we can.
Caleb Clausen
> Certain numbers, such as square roots, can be represented with tricks
> like quadratic equations to which they are the root, but that won't work
> for transcendental numbers like e or π. We can calculate those numbers
> to millions of decimal places if we need to -- but unlike rational
> numbers, we can never store them exactly.
transcendentals can also be represented exactly by formulae with a
finite number of bits:
pi/4 = 1 - 1/3 + 1/5 - 1/7 + ....
#that might not be the exact right formula, but you get the idea
this can also be represented by a (fairly short) program:
def pi_over_4
result=0
sign=1
for i in 0..Infinity do
result+= Rational.new(sign,2*i+1)
sign=-sign
end
return result
end
of course, this would take an infinite amount of time to execute, and
require an infinite amount of memory to store the result, but in a
lazy functional language like haskell, that would not be true. also,
in a functional language, I _believe_ you can manipulate programs like
the one above as if they were numbers. how often is that capability
really needed? maybe mathematica actually works this way, but it's
probably the only one.
on the other hand, there is another class of (real) numbers, the
incomputables, beyond the transcendentals, for which there is no
(finite length) formula or program possible.... but how often do you
need to write a program which deals with (an exact representation of)
those?
Marnen Laibow-Koser
> On 11/16/09, Marnen Laibow-Koser <mar...@marnen.org> wrote:
>> Certain numbers, such as square roots, can be represented with tricks
>> like quadratic equations to which they are the root, but that won't work
>> to millions of decimal places if we need to -- but unlike rational
>> numbers, we can never store them exactly.
>
> transcendentals can also be represented exactly by formulae with a
> finite number of bits:
>
> pi/4 = 1 - 1/3 + 1/5 - 1/7 + ....
> #that might not be the exact right formula, but you get the idea
Oh, good point. Hadn't thought about that.
>
> this can also be represented by a (fairly short) program:
>
> def pi_over_4
> result=0
> sign=1
> for i in 0..Infinity do
> result+= Rational.new(sign,2*i+1)
> sign=-sign
> end
> return result
> end
>
> of course, this would take an infinite amount of time to execute, and
> require an infinite amount of memory to store the result, but in a
> lazy functional language like haskell, that would not be true. also,
> in a functional language, I _believe_ you can manipulate programs like
> the one above as if they were numbers.
To some extent, you can do that in Ruby. Proc and Method are
first-class objects.
> how often is that capability
> really needed?
Which capability? Functional programming? It can be useful.
> maybe mathematica actually works this way, but it's
> probably the only one.
I'm not sure.
>
> on the other hand, there is another class of (real) numbers, the
> incomputables, beyond the transcendentals, for which there is no
> (finite length) formula or program possible.... but how often do you
> need to write a program which deals with (an exact representation of)
> those?
I don't know. Are any important constants incomputable?
Colin Bartlett
> ... transcendentals can also be represented exactly by formulae with a
> finite number of bits:
Doesn't that depend on the transcendental?
> ... on the other hand, there is another class of (real) numbers, the
> incomputables, beyond the transcendentals, for which there is no
> (finite length) formula or program possible.... but how often do you
> need to write a program which deals with (an exact representation of)
> those?
"Most" real numbers are both transcendental and non computable.
http://en.wikipedia.org/wiki/Transcendental_number
... almost all real and complex numbers are transcendental ...
http://en.wikipedia.org/wiki/Computable_number
... almost all real numbers are not computable ...
Marnen Laibow-Koser <mar...@marnen.org> wrote:
> ... Are any important constants incomputable?
An interesting question. There are, for example Chaitin's constants:
http://en.wikipedia.org/wiki/Chaitin's_constant
http://mathworld.wolfram.com/ChaitinsConstant.html
which are (I assume) important in computation theory
but (very?) unlikely to be useful in normal problems!
(Although it's slightly risky to make that statement
about anything: even obscure mathematics
sometimes turns out to have "real world" importance.)
Returning to the original question(s) in this thread:
* From years ago I recall Fractint being written using integers
for speed (and possibly also for precision). But now:
http://en.wikipedia.org/wiki/Fractint
"... the first versions of it computed fractals by using only
integer arithmetic (also known as fixed-point arithmetic),
which led to much faster rendering on x86 computers
without math coprocessors. Since then, floating-point arithmetic
and "arbitrary-precision" modes have been added,
the latter of which emulates an arbitrarily large mantissa in RAM.
The arbitrary-precision mode is slow even on modern computers. ..."
* Depending on the problem, inherent uncertainty in the data
may make the notion of an "exact" number misleading.
I'm not arguing against using "precise" representations,
I'm just saying that before using more precise representations
one should ask whether what that gives (and costs,
in terms of performance) is worth having. There may well
be "wrong" answers without there being unique "right" answers,
just degrees of "rightness".
For example, using 22/7 for pi is an error of about 0.04%.
(Using Ruby Math::PI = 3.14159265358979 as an approximation to pi.)
Using 355/113 is an error of less than (10 ** -7)%.
The circumference of the Earth is about 40,000 km, and depending on
where and how you measure it, the "actual" figure is +/- about 75 km.
Using 22/7 instead of pi for the circumference gives an "error" of 16 km,
which may be "reasonable" given the inherent "uncertainty"
in the circumference (depending on what you want to do).
Using 355/113 instead of pi gives an "error" of about 4 metres,
which for most(?) purposes is insignificant compared with
the inherent "uncertainty" in the circumference.
I'm to some extent guilty of not following my own precepts:
for financial calculations I mostly use double precision floats,
and I suspect that for much of those calculations
using single precision floats would be sufficiently accurate.
I don't do that because double precision floats are fast,
and with double precision I don't need to worry so much
about "rounding errors". But I do try to present the results
in ways which do not give an impression of "spurious accuracy".
Caleb Clausen
> Caleb Clausen wrote:
>> ... transcendentals can also be represented exactly by formulae with a
>> finite number of bits:
>
> Doesn't that depend on the transcendental?
> "Most" real numbers are both transcendental and non computable.
> http://en.wikipedia.org/wiki/Transcendental_number
> ... almost all real and complex numbers are transcendental ...
> http://en.wikipedia.org/wiki/Computable_number
> ... almost all real numbers are not computable ...
When I said 'transcendental', I meant a transcendental which is not
incomputable. Just as when Marnen said 'irrational', he meant an
irrational which is not transcendental.
Caleb Clausen
>> of course, this would take an infinite amount of time to execute, and
>> require an infinite amount of memory to store the result, but in a
>> lazy functional language like haskell, that would not be true. also,
>> in a functional language, I _believe_ you can manipulate programs like
>> the one above as if they were numbers.
>
> To some extent, you can do that in Ruby. Proc and Method are
> first-class objects.
Yeah, but you can't manipulate their results when they return one if
they ever do as if they were numbers.
>> how often is that capability
>> really needed?
>
> Which capability? Functional programming? It can be useful.
The capability to represent transcendental numbers exactly. I mean,
how much precision do you really need?
Marnen Laibow-Koser
[...]
>> To some extent, you can do that in Ruby. Proc and Method are
>> first-class objects.
>
> Yeah, but you can't manipulate their results when they return one if
> they ever do as if they were numbers.
>
Of course you can, unless I'm totally misunderstanding. Got a concrete
example
>>> how often is that capability
>>> really needed?
>>
>> Which capability? Functional programming? It can be useful.
>
> The capability to represent transcendental numbers exactly. I mean,
> how much precision do you really need?
Depends on the task. I suspect a couple hundred decimals would be the
most you'd ever really need, and a couple of decades of decimals would
probably suffice for most cases.
Caleb Clausen
>> Yeah, but you can't manipulate their results when they return one if
>> they ever do as if they were numbers.
>
> Of course you can, unless I'm totally misunderstanding. Got a concrete
> example
The pi_over_4 method I posted earlier is a good one. You can't
manipulate the _future_ result of that as if it were a number, because
(among other things) it never returns. Need a lazy functional language
for that kind of thing. (If that even suffices....)
_Maybe_ you could write a futures library and implement the pi_over_4
formula within that in some kind of useful way, but idunno.... I kind
of think you need laziness built into the core language for something
like that to be useful.
Marnen Laibow-Koser
> On 11/17/09, Marnen Laibow-Koser <mar...@marnen.org> wrote:
>>> Yeah, but you can't manipulate their results when they return one if
>>> they ever do as if they were numbers.
>>
>> Of course you can, unless I'm totally misunderstanding. Got a concrete
>> example
>
> The pi_over_4 method I posted earlier is a good one. You can't
> manipulate the _future_ result of that as if it were a number, because
> (among other things) it never returns. Need a lazy functional language
> for that kind of thing. (If that even suffices....)
You can't manipulate the future in any language that I'm aware of --
it's not there to manipulate yet! Are you thinking of lisp's
tail-recursion optimization?
Aldric Giacomoni
Well, we -can- make laziness work.. Look at this:
http://innig.net/software/ruby/closures-in-ruby.rb
Do a search for 'fibonacci' and check out the lazy implementation.
Eleanor McHugh
Aldric Giacomoni
Looks like there's no gem for this.
Yet.
James Edward Gray II
> Eleanor McHugh wrote:
>>
>> Yes you can: http://en.wikipedia.org/wiki/Futures_and_promises
>
> Looks like there's no gem for this.
> Yet.
http://moonbase.rydia.net/software/lazy.rb/
James Edward Gray II
Marnen Laibow-Koser
> Eleanor McHugh wrote:
>>
>> Yes you can: http://en.wikipedia.org/wiki/Futures_and_promises
Wow, that's very interesting -- thanks for the reference.
>
> Looks like there's no gem for this.
> Yet.
But there will be in the future. Perhaps we can require it now, and
block evaluation until the future is resolved. :D
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
Aldric Giacomoni
Well, that'll teach me. How did you find it, out of sheer curiosity? I
did not use lazy as a keyword, so maybe that was it..
Gregory Brown
> 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 :)
James Edward Gray II
I've just been reading this list forever and knew it existed. I had an unfair advantage. ;)
Lazy evaluation was a popular topic in Ruby circles sometime back. That was when Lazy.rb was invented. I looked into it quite a bit while writing this old blog post:
http://blog.grayproductions.net/articles/infinite_streams
James Edward Gray II
Todd Benson
<ele...@games-with-brains.com> wrote:
> On 16 Nov 2009, at 01:12, Todd Benson wrote:
>>
>> On Sun, Nov 15, 2009 at 5:32 PM, Eleanor McHugh
> mathematically) but of unnoticeable error.
I'm talking about result. A small difference in initial conditions
causes big problem.
> The difference between 1e10-13
> and 2e10-13 matters a lot when working on a system which needs to be
> accurate to a resolution of 1e10-14 but not when working to a resolution of
> 1e10-4. The additional nine decimal places tell us nothing meaningful in
> this latter case as we'll still end up rounding the result to zero.
Right, sort of. See below.
> That's not a bug but a fundamental outcome of the nature of binary coded
> non-integral numbers. Many rational non-integral numbers cannot be expressed
> accurately in binary representations, whilst binary coded decimal brings a
> whole host of other problems: lower information density, higher memory
> usage, and heavier processing load. BCD also does nothing to resolve the
> problem of how to represent irrational numbers such as π.
Ok, not a bug. Just makes you want to scream at somebody (yes the
game thing happened to me recently). The binary inaccuracy thing has
been beaten to death on this list, but you're right.
> The imprecision can indeed stack for complex ballistics systems, depending
> on the complexity of the forces involved. However to the extent of the
> precision chosen for performing these calculations the resultant inaccuracy
> is irrelevant.
I agree. I thought we were talking about a simple game. In any case,
small perversions in data (i.e. rounding beforehand) can cause certain
systems to go haywire. If you stay, for example, at 1e10-4 from the
beginning, you could end up with errors several orders of magnitude
higher, so the "just rounding to zero anyway" argument doesn't make
sense. This probably doesn't apply so much in a simple parabolic
equation, but the equation is still nonlinear, so one must be terribly
wary. Error analysis class was way too long ago, otherwise I'd give
an example. If somebody wants to step in, please do.
>
> http://en.wikipedia.org/wiki/Accuracy_and_precision explains all of this in
> reasonable detail.
Ah, yes, the first thing you learn when studying engineering. I'm
guessing the only thing affected in the result would be accuracy.
Just a guess.
Todd
Eleanor McHugh
Never hire a computer scientist if you can get a maths, physics or philosophy grad instead ;)
Marnen Laibow-Koser
> On 17 Nov 2009, at 19:55, Gregory Brown wrote:
>> 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 :)
>
> Never hire a computer scientist if you can get a maths, physics or
> philosophy grad instead ;)
Yup. Or music. :D
>
> Ellie
>
Best,
--
Marnen Laibow-Koser
Composer / Web developer
http://www.marnen.org
mar...@marnen.org
Eleanor McHugh
> Eleanor McHugh wrote:
>> On 17 Nov 2009, at 19:55, Gregory Brown wrote:
>>> 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 :)
>>
>> Never hire a computer scientist if you can get a maths, physics or
>> philosophy grad instead ;)
>
> Yup. Or music. :D
Well I've known very few serious coders who didn't have a strong interest in music of one sort or another :)
Aldric Giacomoni
Time to get some more reading underway. Oh... And did you know that the
lazy.rb file/gem is actually mentioned in "Ruby Best Practices" ?
Figures that ruby-forum and the book would act synchronistically for
me.. :)
Todd Benson
<ele...@games-with-brains.com> wrote:
> On 17 Nov 2009, at 19:55, Gregory Brown wrote:
>> On Sun, Nov 15, 2009 at 2:13 PM, Rick DeNatale <rick.d...@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 :)
>
> Never hire a computer scientist if you can get a maths, physics or philosophy grad instead ;)
Don't want to hijack (these are all good qualities by the way, but
with a sardonic tone :)
Maths grad: F equals MA if the axioms are founded
Phys grad: F does in "fact" equal MA no matter what
Philosophy grad: F equals MA only when it must
Engineering grad: F sometimes equals MA, but that's not the crux of the issue
Rosalind Mitchell
Cultural studies graduate: Bourgeois hegemony constructs F as an
arbitrary signifier of MA.
I'll get my coat.
Rosie
Eleanor McHugh
Ah, so that's what cultural studies is ;)
Marnen Laibow-Koser
Hmmm...
Computer science: F = MA, but simple multiplication isn't OO enough, so
let's make an AbstractForceFactory...
XP: F = 3 always. When I need F to equal MA, I'll write a different
test.
Music: F is a M3rd below A.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
--
Posted via http://www.ruby-forum.com/.
Todd Benson
> Hmmm...
>
> Computer science: F = MA, but simple multiplication isn't OO enough, so
> let's make an AbstractForceFactory...
> XP: F = 3 always. When I need F to equal MA, I'll write a different
> test.
> Music: F is a M3rd below A.
>
>
> Best,
You should include differences in frequency :) That was a pretty cool
spot, though.
Todd
Gregory Brown
James does know that because the chapter in RBP was based off the blog
series he just linked to :)
Aldric Giacomoni
> On Tue, Nov 17, 2009 at 10:33 PM, Aldric Giacomoni <ald...@trevoke.net>
> wrote:
>>> James Edward Gray II
>>
>> lazy.rb file/gem is actually mentioned in "Ruby Best Practices" ?
>> Figures that ruby-forum and the book would act synchronistically for
>> me.. :)
>
> James does know that because the chapter in RBP was based off the blog
> series he just linked to :)
Alright, so I'm a n00b ;-) I turned two more pages to see his name show
up.. I'll just be quiet until I'm done with the book :-)
SAMINA
Language performs an essentially social function: It helps us get
along together, communicate, and achieve a great measure of concerted
action. Words are signs that have significance by convention, and
those people who do not adopt the conventions simply fail to communicate.
They do not "get along," and a social force arises that encourages them
to achieve the correct associations. By "correct," we mean as used by
other members of the social group. A better education leads to a better job, a better job leads to a successful career, a successful career leads to higher income, and higher income leads to a better quality of life.
--- On Wed, 11/18/09, Rosalind Mitchell <enith...@golgonooza.co.uk> wrote: