use Perl

• Cue the Mathematicians! (Score:2)

  by djberg96 (2603)

  Ruby and Python aren't discarding information. Perl is adding information, but only when it thinks it should be added. After all, if 5/2 returns 2.5, why doesn't 4/2 return 2.0? Or so one could argue.

  It boils down to a design decision. Guido and Matz decided that if you want integer division, you get integer division. Larry took a DWIM approach.

  As a guy who doesn't care one way or the other really, I think Perl's approach is better for simple cases, and worse as you get into more complex operations.
  • Re:Cue the Mathematicians! (Score:1)

    by rjbs (4671) on 2006.12.10 11:17 (#52181) Homepage Journal

    Ruby and Python aren't discarding information. Perl is adding information, but only when it thinks it should be added. After all, if 5/2 returns 2.5, why doesn't 4/2 return 2.0? Or so one could argue. One would be making a ridiculous argument. "2" does not mean "2 and maybe some fractional part." It means "2, exactly." "2.0" does not add information, unless your language has some sense of significant figures, which was not at issue here.

    It boils down to a design decision. Guido and Matz decided that if you want integer division, you get integer division. Larry took a DWIM approach.

    You're begging the question! Yes, they made this decision. Why?

    As a guy who doesn't care one way or the other really, I think Perl's approach is better for simple cases, and worse as you get into more complex operations. Obviously there are times when you don't want that behavior, which is why Perl offers the Integer() function (which I do see from time to time).

    You must not use it very often, or you'd know that it is "int" and not "Integer". Perhaps that's a bit of an indicator as to which division is used more often.

    From a standards point of view, the Ruby and Perl behavior is IEEE compliant, while Perl's behavior is not. Or so I'm told - I haven't verified that.

    IEEE 754, on floating points, refer to how floats are handled, not whether integer operations can produce floats.

    From a design point of view, Ruby uses immediate values for integers, but a complex data type for floats. Thus, it's more efficient for Ruby to stay with integers in this case.

    This is reasonable, I suppose. I'd like to see how much an impact it really has, but since I know it won't be "none," it is at least not ludicrous.

    From a practical point of view, I think it's 6 one way and half a dozen the other. For example, if I want to convert a time value into hours, minutes and seconds, I don't want floats.

    This is not a good argument. It's like saying that there's no reason that "2 + 3" should not be written as "integer_of_val(2) {plus_integer} integer_of_val(3)". One of them is more obnoxious , time consuming, and prone to introduce error, even if they are equivalent.

    Lastly, if you want your '/' operator to act as Perl does, Ruby's open classes let you do this:
    
            class Fixnum
                  def /(num)
                        self.to_f / num.to_f
                  end
            end

    Ha! You're kidding, right? Now any other module that you've loaded is going to get your modified division, and anyone else who is relying on int/int=int will be screwed.

    --
    rjbs

    Reply to This

    Parent

    • Re: (Score:2)

      by djberg96 (2603)

      You must not use it very often, or you'd know that it is "int" and not "Integer". Perhaps that's a bit of an indicator as to which division is used more often.

      You're right. I don't use it very often, because I don't use Perl very often any more, though I still maintain some old Perl code, and occasionally translate Perl modules into Ruby modules.

      This is not a good argument. It's like saying that there's no reason that "2 + 3" should not be written as "integer_of_val(2) {plus_integer} integer_of_val(3)". One of them is more obnoxious , time consuming, and prone to introduce error, even if they are equivalent.

      I find your analogy flawed. My point is simply that the default behavior you want may not always be what Perl provides. It may work to your benefit. It may not.

      I guess I'm asking what Perl's philosophy is on this issue. Is it merely trying to be useful vs correct? Or does Larry view the current behavior as corr
    • Question Begging (Score:1)

      by DAxelrod (4649)

      Very much tangential, but...

      You're begging the question!

      Thank you so much. I had started to think that there was nobody left on the internet who was able to use that phrase correctly. I salute you, rjbs.