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

    • > 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").
  • I'm sorry, but Perl also silently discards information [perl.org]. (Yes, I know that .9repeating is equal to 1, but perl's implementation only stores an imperfect representation of that).

    The problem is that processors are designed to do approximate math quickly, so most computer math ends up being approximate. Perl just happens to be using a closer approximation to what you expect, in this case.

    Personally, I would prefer that Perl's DWIM resulted in preserving all information available, like (IIRC) Haskell does (of

    • One thing to remember is that many compilers and operating systems may help you down to road to discard this information. Perl compiled Intel C++ on Linux, for example, failed several floating point tests in Perl. By removing optimizations (that is, making the compiler generate code to do the math correctly), the tests were made to pass. Various operating systems and compilers occasionally include "fast" math libraries as well that do a similarly good job of providing optimized approximations. I would s

      • This is a good point. I think the central problem here is that you have to be careful what guarantees you make. If a datatype is defined as a lower-level language's datatype, you can only assume the guarantees that the lower-level language makes. (And thanks to nonstandard compilers, sometimes not even those...)
  • Not a Python head, but on the Ruby front take a look at the (standard) 'mathn' module:

    % ruby -e "require 'mathn'; puts 7/2"
    7/2

    (and that's a proper rational too - none of that floating point nonsense :-)