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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Sunday December 10, 2006
06:41 AM

Python and Ruby Silently Discard Information?

[ #31872 ]

Any Python or Ruby programmers out there able to explain the following?

$ python -c 'print 7/2'
3

$ ruby -e 'puts 7/2'
3

$ perl -le 'print 7/2'
3.5

Apparently Python and Ruby default to integer math unless you explicitly use a float. For example:

$ python -c 'print 7.0/2'
3.5

By default Python and Ruby silently discard information? Now I can understand that in C. For example, run gcc -Wall on the following:

#include <stdio.h>

int main(int argc, char *argv[]) {
    printf("%f\n", 7/2);
    return 0;
}

You'll get the following warning (is this something I could enable in Python or Ruby?):

divide.c: In function 'main':
divide.c:4: warning: format '%f' expects type 'double', but argument 2 has type 'int'

C pretends to be a statically styped language and if you get confused about types, your language will misbehave. So you either want to be explicit and cast the result, (float)7/2, or better still, use floats in the first place (some argue that the ability to cast data types means a type system is broken). If you use integers in division, it will give you an integer result. If you use more than one data type, the result of the expression is the one which loses the least information:

#include <stdio.h>

int main(int argc, char *argv[]) {
    double numerator   = 7.0;
    int    denomenator = 2;

    // no warnings with -Wall because the result is a double
    printf("%f\n", numerator/denomenator);
    return 0;
}

In Perl, because it's dynamically typed, the result of an mathematical expression is simply whatever result has the most information (er, that's an oversimplification):

$ perl -le 'print 7/2'
3.5

That strikes me as far more intuitive for a 'dynamic' programming language. Do I have some fundamental misunderstanding about Python, Ruby, or C?

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 :-)