Trajectories

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

  1. Thijs Leeflang, Nov 13, 2009
    #1
    1. Advertising

  2. 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.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
     
    Eleanor McHugh, Nov 14, 2009
    #2
    1. Advertising

  3. 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
    #3
  4. 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
    #4
  5. 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
    #5
  6. 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 :D
    --
    Posted via http://www.ruby-forum.com/.
     
    Thijs Leeflang, Nov 15, 2009
    #6
  7. 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
    #7
  8. 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
    #8
  9. 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
    > 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.


    Ellie

    Eleanor McHugh
    Games With Brains
    http://slides.games-with-brains.net
    ----
    raise ArgumentError unless @reality.responds_to? :reason
     
    Eleanor McHugh, Nov 15, 2009
    #9
  10. 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.

    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
    #10
  11. 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
    #11
  12. 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
    #12
  13. 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
    #13
  14. 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
    #14
  15. Thijs Leeflang

    Josh Cheek Guest

    [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
    > 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.
     
    Josh Cheek, Nov 15, 2009
    #15
  16. 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

    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
     
    Rick DeNatale, Nov 15, 2009
    #16
  17. 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
    >>> 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 =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
    #17
  18. 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
    #18
  19. 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
    >
    > 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,
    --
    Marnen Laibow-Koser
    http://www.marnen.org

    --
    Posted via http://www.ruby-forum.com/.
     
    Marnen Laibow-Koser, Nov 15, 2009
    #19
  20. 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
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page