Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Python and Ruby Silently Discard Information? 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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. 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).

    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.

    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.

    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.

    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
    And now all of your integer division will return a float value. Just keep in mind that it will be slower than integer division. BTW, I'm not positive, but I don't think Python let's you do that.

    My final comment is that I think this is just one of those things you adapt to if/when you switch from Perl to Ruby, along with other conventions you're used to, such as 0 != false. But, that's another topic. :)

    • > Perl offers the Integer() function (which I do see from time to time)

      I hope you mean the integer pragma.
    • > From a standards point of view, the Ruby and Perl behavior is IEEE compliant, while Perl's behavior is not

      Huh? (I assume by IEEE we are talking IEEE 754, the floating point standard...) This has nothing to do with compliancy of languages since the IEEE 754 specifies the representation and behaviour of floating point, not how programming languages understand numeric constants (are they integer or float) and arithmetic operations (is division truncating or not).
      • I was definitely parroting things I had read elsewhere on that point (as I indicated). I couldn't begin to tell you the relationship between IEEE and computer programming languages.

        If it's not a valid point, then so be it. But, I thought I would at least bring it up for discussion. It's definitely something I wouldn't mind hearing more argument/philosophy on.

    • 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).

      --
      rjbs

      • 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

      • 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.

    • This is a known problem, initially built in because it's the way that C works. Guido acknowledges this as one of his mistakes. Python 3000 will fix this, but it won't be fixed before then because it would break existing programs. See http://www.python.org/doc/essays/foreword2/ [python.org] for some discussion of how we in the Python world think about things like this... (search for "integer division").
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.