All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(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.
Python and Ruby Silently Discard Information?
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?
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Cue the Mathematicians! (Score:2)
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: (Score:2)
I hope you mean the integer pragma.
Re: (Score:2)
Re: (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:1)
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
Re: (Score:2)
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)
Very much tangential, but...
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.
Re: (Score:1)
Computers Silently Discard Information (Score:1)
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
Re: (Score:1)
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
Re: (Score:1)
You can easily make Ruby work that way... (Score:1)
Not a Python head, but on the Ruby front take a look at the (standard) 'mathn' module:
(and that's a proper rational too - none of that floating point nonsense :-)