[31312] in Perl-Users-Digest
Perl-Users Digest, Issue: 2557 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 17 18:09:44 2009
Date: Mon, 17 Aug 2009 15:09:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 17 Aug 2009 Volume: 11 Number: 2557
Today's topics:
Re: end-of-line conventions sln@netherlands.com
log timestamp a script is used <gerhard_ulrike@yahoo.de>
Re: log timestamp a script is used <ben@morrow.me.uk>
Re: python doc available in emacs info format? <xahlee@gmail.com>
Re: revisiting web development in Perl...where to start <cartercc@gmail.com>
Re: revisiting web development in Perl...where to start <hjp-usenet2@hjp.at>
Re: revisiting web development in Perl...where to start <cartercc@gmail.com>
Rounding issue <lehmannmapson@cnm.de>
Re: Rounding issue <jimsgibson@gmail.com>
Re: Rounding issue <ben@morrow.me.uk>
Re: Rounding issue <jurgenex@hotmail.com>
Re: Rounding issue <lehmannmapson@cnm.de>
Re: Rounding issue <jurgenex@hotmail.com>
Re: Rounding issue <tadmc@seesig.invalid>
Re: Rounding issue <ben@morrow.me.uk>
Re: Rounding issue (Jens Thoms Toerring)
Re: Rounding issue <lehmannmapson@cnm.de>
Re: Rounding issue <ben@morrow.me.uk>
Re: Rounding issue <tadmc@seesig.invalid>
Re: Rounding issue <hjp-usenet2@hjp.at>
Re: Rounding issue (Randal L. Schwartz)
Re: Rounding issue <ben@morrow.me.uk>
Re: Social problems of Python doc [was Re: Python docs <jon@ffconsultancy.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 17 Aug 2009 14:32:45 -0700
From: sln@netherlands.com
Subject: Re: end-of-line conventions
Message-Id: <siij85htvohn0ke76is2k6rhhmdavu73v2@4ax.com>
On 13 Aug 2009 21:13:17 GMT, Heiko Eißfeldt <heiko@hexco.de> wrote:
>kj wrote:
>
>> There are three major conventions for the end-of-line marker:
>> "\n", "\r\n", and "\r".
>
>These notations are not unambigious! See perlport documentation section
>newlines for details.
>
>> In a variety of situation, Perl must split strings into "lines",
>> and must therefore follow a particular convention to identify line
>> boundaries. There are three situations that interest me in
>> particular: 1. the splitting into lines that happens when one
>> iterates over a file using the <> operator; 2. the meaning of the
>> operation performed by chomp; and 3. the meaning of the $ anchor
>> in regular expressions.
>
><> and chomp use the $/ variable for line endings. Since $/ does not
>support regular expressions, you cannot use this mechanism for all
>types of line endings.
>
>The $ anchor normally is just the end of the string (with or without an
>line ending).
>
>> How can I change the script so that the output for unix.txt, dos.txt,
>> and mac.txt will be the same as the one shown above for unix.txt?
>
>use strict;
>use warnings;
>
>my $lines = my $matches = 0;
>{
> local $/ = undef;
> for (<> =~ m{\G([^\012\015]*) \015?\012?}xmsg) {
^^^^^^^^
This won't work, depending on the translation mode opened or
appended to before, opened now, etc.., 0d 0d 0a could be one, two
or 3 eol's.
In fact you don't even have, or couldn't create a reference anchor
to tell the difference.
-sln
------------------------------
Date: Mon, 17 Aug 2009 05:02:30 -0700 (PDT)
From: GU <gerhard_ulrike@yahoo.de>
Subject: log timestamp a script is used
Message-Id: <fa4bbbef-9fe4-49e4-93d4-8810d2c02515@e27g2000yqm.googlegroups.com>
Hi,
currently we've a lot of scripts, but don't know how often each one is
used.
To clean up those jumble of scripts i wanna log the timestamp a script
is used.
For that i like to do something like this:
system "echo $0 `date` >> /tmp/script_used.log";
but WITHOUT modifing each skript itself.
i would imagine two ways:
1) set of environment to tell perl to do something like that (but
which setting would do that?, alias would not work --> different users
- different shells)
2) recompilation of perl (but i havn't compiled perl jet and don't
know how to do that)
Is there a way to do this?
thx
Gerhard
------------------------------
Date: Mon, 17 Aug 2009 17:25:03 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: log timestamp a script is used
Message-Id: <vrcol6-78j.ln1@osiris.mauzo.dyndns.org>
Quoth GU <gerhard_ulrike@yahoo.de>:
>
> currently we've a lot of scripts, but don't know how often each one is
> used.
>
> To clean up those jumble of scripts i wanna log the timestamp a script
> is used.
>
> For that i like to do something like this:
> system "echo $0 `date` >> /tmp/script_used.log";
> but WITHOUT modifing each skript itself.
>
> i would imagine two ways:
> 1) set of environment to tell perl to do something like that (but
> which setting would do that?, alias would not work --> different users
> - different shells)
> 2) recompilation of perl (but i havn't compiled perl jet and don't
> know how to do that)
>
> Is there a way to do this?
If you can set a variable in everyone's environment, you can use
PERL5OPT. Set it to something like -MMy::ScriptUsed and then create a
My::ScriptUsed.pm that does whatever logging you want.
It would almost certainly be easier to do a
perl -0777 -pe's/^(#!.*\n)?/$1BEGIN {...}/'
over the whole lot.
Ben
------------------------------
Date: Mon, 17 Aug 2009 00:25:24 -0700 (PDT)
From: Xah Lee <xahlee@gmail.com>
Subject: Re: python doc available in emacs info format?
Message-Id: <4aba0b60-0aff-419a-877a-cac1e0e448ee@j21g2000yqe.googlegroups.com>
info format for Xah Lee writes:
> in programing elisp in emacs, i can press =E2=80=9CCtrl+h f=E2=80=9D to l=
ookup
> the doc for the function under cursor. is there such facility
> when coding in perl, python, php?
On Dec 11 2008, 6:56 am, Matthias <oron...@gmail.com> wrote:
> Yes, try C-h S (or similarly <f1> S):
> (info-lookup-symbol SYMBOL &optional MODE) Display the
> definition of SYMBOL, as found in the relevant manual. When this
> command is called interactively, it reads SYMBOL from the
> minibuffer.
> Note that `the relevant manual' means an info file. With recent
> emacsen on an Ubuntu distro, python arrives with info files and
> everything is well configured. It also works with bash, latex, perl,
> scheme, elisp, awk, texinfo, makefile, libc, or any info file with an
> index.
I noticed that Matthias actually mentioned that info docs is available
and bundled out of the box on Ubuntu linux for many popular langs, as
of 2008-12.
Is that true? Where can i download these info files? As far as i know,
a little google search or official doc sites usually don't have a
download for info format.
I'm interested in getting current version doc for perl, python, php,
and ruby.
Thanks.
Xah
=E2=88=91 http://xahlee.org/
=E2=98=84
------------------------------
Date: Mon, 17 Aug 2009 09:10:43 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: revisiting web development in Perl...where to start?
Message-Id: <0b9f6344-2de7-4be2-b505-af2787f8f0e4@g31g2000yqc.googlegroups.com>
On Aug 14, 12:38=A0am, TheGist <theg...@nospam.net> wrote:
> Surely CGIs are
> no longer widely used, right? What is the modern
> way to do dynamic web pages in Perl?
> I have noticed that O'Reilly hasn't updated
> the Perl CGI book since 2000! People still use
> Perl for web programming, right?
I have found that this is a controversial topic. Ask a question and
you'll get twenty different answers. People will also tell you are
insane to use any solution other than their pet solution.
I write web based front ends for databases for a living. I can tell
you how I do it, and can tell you that it works for me. I can also
tell you that this is specific for reading and writing to databases,
and that 'web programming' probably implies a lot of other
functionality than I will mention here.
I use mod_perl with Apache, writing scripts as standard CGI scripts. I
don't mess with generating HTML using CGI functions, although I do use
CGI.
I write an SQL module for my SQL queries and connection to the
database. I write an HTML module that contains templates for my
standard HTML, like menus, buttons, and so on. I write scripts that
output HTML pages, CSS, and JavaScript, calling HTML.pm and SQL.pm as
appropriate.
I don't do fancy Flex or Flash or anything like that. I produce basic
HTML. Most of my development effort goes into the database side. This
probably doesn't answer your question, and may not work for your
conception of 'web programming', but I can assure you that Perl is
alive and well for spitting out HTML, CSS, and JavaScript in August,
2009.
CC
------------------------------
Date: Mon, 17 Aug 2009 18:33:19 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: revisiting web development in Perl...where to start?
Message-Id: <slrnh8j1if.ejb.hjp-usenet2@hrunkner.hjp.at>
On 2009-08-17 16:10, ccc31807 <cartercc@gmail.com> wrote:
> I use mod_perl with Apache, writing scripts as standard CGI scripts.
If you use mod_perl to execute your scripts, they are *not* standard CGI
scripts. The CGI specification mandates that each invocation of a CGI
script creates a new process which uses the environment, stdin and
stdout to communicate with the server. mod_perl doesn't do this.
hp
------------------------------
Date: Mon, 17 Aug 2009 10:03:26 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: revisiting web development in Perl...where to start?
Message-Id: <2de9eac9-b367-4465-b5ea-62a96685d851@c29g2000yqd.googlegroups.com>
On Aug 14, 10:09=A0am, mer...@stonehenge.com (Randal L. Schwartz) wrote:
> Please don't confuse the CGI technology with the use of Perl.
There's no trick to this -- you use a programming language to spit out
HTML. What programming languages are popular now?
- Perl
- Python
- Ruby
- C#
- ASP (old)
- PHP
- JSP
- ColdFusion
- the .NET languages
New ones are coming online, such as Lisp and Erlang. Wrox will publish
Erlang Web Applications this year, and a couple of years ago Peter
Seibel came out with a wildly popular book that touches on generating
HTML with Common Lisp.
The issue of frameworks is separate. Look at
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
The Perl frameworks listed include Catalyst, Interchange, Mason, and
Maypole.
The issue of CGI is separate still. AFAIK, when people say CGI, they
usually mean some kind of embedded technology, such as mod_perl. I had
a JSP period and an ASP period, and found these wanting compared to
Perl in terms of speed -- although this was years ago and I'm sure
vast improvements have been made.
My advice is that the language you use and the framework you may
prefer are incidental. I use Perl because I know it well and it has
the tools to do the job. This doesn't mean that you can't use Scala,
Lua, Clojure, or even server-side JavaScript to do the same thing.
CC
------------------------------
Date: Mon, 17 Aug 2009 20:08:16 +0200
From: Marten Lehmann <lehmannmapson@cnm.de>
Subject: Rounding issue
Message-Id: <7etkkgF2hsuqoU1@mid.individual.net>
Hello,
I don't understand why
perl -e 'print sprintf("%.0f", 1.5). "\n"'
returns 2 as expected, but
perl -e 'print sprintf("%.1f", 0.15). "\n"'
returns 0.1, whereby I expected to get 0.2.
What am I doing wrong? What do I have to do to get 0.2?
Kind regards
Marten Lehmann
------------------------------
Date: Mon, 17 Aug 2009 11:29:34 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Rounding issue
Message-Id: <170820091129348087%jimsgibson@gmail.com>
In article <7etkkgF2hsuqoU1@mid.individual.net>, Marten Lehmann
<lehmannmapson@cnm.de> wrote:
> Hello,
>
> I don't understand why
>
> perl -e 'print sprintf("%.0f", 1.5). "\n"'
>
> returns 2 as expected, but
>
> perl -e 'print sprintf("%.1f", 0.15). "\n"'
>
> returns 0.1, whereby I expected to get 0.2.
>
> What am I doing wrong? What do I have to do to get 0.2?
See the advice in 'perldoc -q round'
Observe that
perl -e '$x=0.15; printf "%.20f\n", $x;'
produces:
0.14999999999999999445
so should round to 0.1.
--
Jim Gibson
------------------------------
Date: Mon, 17 Aug 2009 19:23:46 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Rounding issue
Message-Id: <iqjol6-dnk.ln1@osiris.mauzo.dyndns.org>
Quoth Marten Lehmann <lehmannmapson@cnm.de>:
>
> I don't understand why
>
> perl -e 'print sprintf("%.0f", 1.5). "\n"'
>
> returns 2 as expected, but
~% perl -E'say sprintf "%.40f", 1.5'
1.5000000000000000000000000000000000000000
> perl -e 'print sprintf("%.1f", 0.15). "\n"'
>
> returns 0.1, whereby I expected to get 0.2.
~% perl -E'say sprintf "%.40f", 0.15'
0.1499999999999999944488848768742172978818
This is less than 0.15, so it rounds to 0.1.
> What am I doing wrong? What do I have to do to get 0.2?
Where is this number coming from? Why do you need it to round to 0.2?
Ben
------------------------------
Date: Mon, 17 Aug 2009 11:37:23 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Rounding issue
Message-Id: <6h8j85lia2m16pcusctt758sk3si7fdug8@4ax.com>
Marten Lehmann <lehmannmapson@cnm.de> wrote:
>I don't understand why
>
>perl -e 'print sprintf("%.0f", 1.5). "\n"'
>
>returns 2 as expected, but
>
>perl -e 'print sprintf("%.1f", 0.15). "\n"'
>
>returns 0.1, whereby I expected to get 0.2.
>
>What am I doing wrong? What do I have to do to get 0.2?
Print both numbers with 20 digits and note the difference.
For further information please see 'perldoc -q 999' or revisit your
notes on your "Basics of Computer Numerics" class.
jue
PS: you could argue that 1.5 should have been rounded down to 1 because
the 1.5 is exactly 5 with all following digits being 0, but alas, that's
not how it's implemented.
jue
------------------------------
Date: Mon, 17 Aug 2009 20:42:37 +0200
From: Marten Lehmann <lehmannmapson@cnm.de>
Subject: Re: Rounding issue
Message-Id: <7etmkuF2hu206U1@mid.individual.net>
Hello,
> ~% perl -E'say sprintf "%.40f", 0.15'
> 0.1499999999999999944488848768742172978818
why isn't it stored as 0.150000000000000 internally?
> This is less than 0.15, so it rounds to 0.1.
This is explains why 0.149 doesn't round to 0.2, but it doesn't explain
why 1.5 works different than 0.15 wuth just one floating point digit
difference.
>> What am I doing wrong? What do I have to do to get 0.2?
>
> Where is this number coming from? Why do you need it to round to 0.2?
In this specific case I hardcoded it into the source. But in the real
application it is coming from a database and then some tax calculations
are done and in accounting every cent difference causes headaches.
Why does
perl -e 'print sprintf("%.1f", 0.10 + 0.05). "\n"'
work fine?
Kind regards
Marten
------------------------------
Date: Mon, 17 Aug 2009 11:58:38 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Rounding issue
Message-Id: <ij9j85tql508m5emnstnn6r0n50kj94eun@4ax.com>
Marten Lehmann <lehmannmapson@cnm.de> wrote:
>> ~% perl -E'say sprintf "%.40f", 0.15'
>> 0.1499999999999999944488848768742172978818
>
>why isn't it stored as 0.150000000000000 internally?
>
>> This is less than 0.15, so it rounds to 0.1.
>
>This is explains why 0.149 doesn't round to 0.2, but it doesn't explain
>why 1.5 works different than 0.15 wuth just one floating point digit
>difference.
Please re-read your notes from "Basics of Computer Numerics".
Hint: Typical computers are binary, they don't use the decimal system.
>In this specific case I hardcoded it into the source. But in the real
>application it is coming from a database and then some tax calculations
>are done and in accounting every cent difference causes headaches.
That is why using floating point numbers for accounting is A VERY Bad
Idea(TM) and very strongly discouraged. Didn't your computer numerics
teacher tell you so?
>Why does
>perl -e 'print sprintf("%.1f", 0.10 + 0.05). "\n"'
>work fine?
Again: print the result of that addition with 20 digits and you will see
why.
jue
------------------------------
Date: Mon, 17 Aug 2009 14:15:03 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Rounding issue
Message-Id: <slrnh8jah3.ea9.tadmc@tadmc30.sbcglobal.net>
Marten Lehmann <lehmannmapson@cnm.de> wrote:
> Hello,
>
>> ~% perl -E'say sprintf "%.40f", 0.15'
>> 0.1499999999999999944488848768742172978818
>
> why isn't it stored as 0.150000000000000 internally?
>
>> This is less than 0.15, so it rounds to 0.1.
>
> This is explains why 0.149 doesn't round to 0.2, but it doesn't explain
> why 1.5 works different than 0.15 wuth just one floating point digit
> difference.
Because it is not represented in base 10, it is represented in base 2 (binary).
>>> What am I doing wrong?
Using floating point numbers.
> In this specific case I hardcoded it into the source. But in the real
> application it is coming from a database and then some tax calculations
> are done and in accounting every cent difference causes headaches.
Do not work with floating point dollars, instead work with
integer cents (then convert to dollars only at the last output stage).
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 17 Aug 2009 20:20:15 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Rounding issue
Message-Id: <f4nol6-69n.ln1@osiris.mauzo.dyndns.org>
Quoth Marten Lehmann <lehmannmapson@cnm.de>:
>
> > ~% perl -E'say sprintf "%.40f", 0.15'
> > 0.1499999999999999944488848768742172978818
>
> why isn't it stored as 0.150000000000000 internally?
Because 0.15 is not representable in (finite) binary floating point.
(This is the same as asking why 1/3 is not exactly representable as a
percentage, except the numbers are different because computers use base
2 instead of base 10.)
> > This is less than 0.15, so it rounds to 0.1.
>
> This is explains why 0.149 doesn't round to 0.2, but it doesn't explain
> why 1.5 works different than 0.15 wuth just one floating point digit
> difference.
1.5 and 0.15 do not look particularly similar in binary. 1.5 is '1.1',
0.15 is a recurring 'binimal' that starts '0.001001100110011...'.
> >> What am I doing wrong? What do I have to do to get 0.2?
> >
> > Where is this number coming from? Why do you need it to round to 0.2?
>
> In this specific case I hardcoded it into the source. But in the real
> application it is coming from a database and then some tax calculations
> are done and in accounting every cent difference causes headaches.
Then don't use floating point. Store all your amounts in cents, and do
the necessary rounding yourself. I would expect that if this is a
financial application there are some very carefully-specified rounding
rules you must follow: you need to know what these are.
> Why does
>
> perl -e 'print sprintf("%.1f", 0.10 + 0.05). "\n"'
>
> work fine?
~% perl -E'say sprintf "%0.40f\n%0.40f\n%0.40f", 0.1, 0.05, 0.1+0.05'
0.1000000000000000055511151231257827021182
0.0500000000000000027755575615628913510591
0.1500000000000000222044604925031308084726
You could perfectly well have answered that question yourself.
Ben
------------------------------
Date: 17 Aug 2009 19:54:11 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: Rounding issue
Message-Id: <7etqr3F2hh38fU1@mid.uni-berlin.de>
Marten Lehmann <lehmannmapson@cnm.de> wrote:
> > ~% perl -E'say sprintf "%.40f", 0.15'
> > 0.1499999999999999944488848768742172978818
> why isn't it stored as 0.150000000000000 internally?
> > This is less than 0.15, so it rounds to 0.1.
> This is explains why 0.149 doesn't round to 0.2, but it doesn't explain
> why 1.5 works different than 0.15 wuth just one floating point digit
> difference.
Floating point numbers are stored as binary numbers. And, just
like you can't write a lot of numbers in a 10 based system
(e.g. one third) with a limited number of digits, you can't
store a lot of numbers in a binary system with a limited
number of bits. Thus the overwhelming majority of floating
point numbers are only approximations. For example 0.1 looks
like a simple number when written in a 10 based number system,
but when you would try to write it in a 2 based system you
would need an infinite number of bits. On the other hand,
a number like 1.0/3.0 would require an infinite number of
digits when written in a 10 based system but would be a
very "simple" number when you would write in base 3. (In
base 10 all rational numbers that are a fraction with the
denominator being the product of a power of 2 and a power
of 5 can be written with a limited number of digits, in
base 2 only those that have a power of 2 as the denominator.)
Thus, 1.5 can be stored precisely in base 2 with the limited
number of bits you have for a floating point number while
0.15 can't. Thus 0.15 can only be represented by an appro-
ximation which then leads to the problem you observed.
> >> What am I doing wrong? What do I have to do to get 0.2?
> > Where is this number coming from? Why do you need it to round to 0.2?
> In this specific case I hardcoded it into the source. But in the real
> application it is coming from a database and then some tax calculations
> are done and in accounting every cent difference causes headaches.
> Why does
> perl -e 'print sprintf("%.1f", 0.10 + 0.05). "\n"'
Here a further problem with using floating point numbers
is at work. Neither 0.1 nor 0.05 can be stored precisely.
So you are already starting of with imprecise numbers. And
when you add those imprecise numbers the errors can add up!
And the more calculations you do the larger the error can
become.
In your example one result is that 0.15 isn't equal to
0.1 + 0.05. Thus a rule of thumb is never to try to
compare floating point numbers for equality since the
result hardly ever is what you expect.
But even with numbers that can be represented exactly there
can be problems. On my machine I get
jens@cm:~$ perl -e 'print sprintf("%.1f", 0.25). "\n"'
0.2
jens@cm:~$ perl -e 'print sprintf("%.1f", 0.75). "\n"'
0.8
While the 0.8 result for 0.75 is what one would expect,
the 0.2 for 0.25 isn't. The explanation is probably that
it's the result of rounding errors introduced when the
digits to be displayed are calculated.
If you want the precision you're looking for you probably
shouldn't use floating point numbers at all! If you want
e.g. 2 digits after the decimal point then "scale" your
calculations by a factor of 100, so that everything can
be done with integers.
Welcome to the wonderful world of floating point calculations;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Mon, 17 Aug 2009 22:41:55 +0200
From: Marten Lehmann <lehmannmapson@cnm.de>
Subject: Re: Rounding issue
Message-Id: <7ettkkF2gp2kdU1@mid.individual.net>
Hello,
> Marten Lehmann <lehmannmapson@cnm.de> wrote:
>>> ~% perl -E'say sprintf "%.40f", 0.15'
>>> 0.1499999999999999944488848768742172978818
>> why isn't it stored as 0.150000000000000 internally?
>>
>>> This is less than 0.15, so it rounds to 0.1.
>> This is explains why 0.149 doesn't round to 0.2, but it doesn't explain
>> why 1.5 works different than 0.15 wuth just one floating point digit
>> difference.
>
> Please re-read your notes from "Basics of Computer Numerics".
although I know about the difference between an internal representation
and the number itself, I don't want to care about that the whole day.
All I'm expecting is the programming language to remember the precision
I used when a value was stored. 1.5 is not an infinite value as 1/3.
Kind regards
Marten
------------------------------
Date: Mon, 17 Aug 2009 21:38:25 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Rounding issue
Message-Id: <1nrol6-rkn.ln1@osiris.mauzo.dyndns.org>
Quoth jt@toerring.de (Jens Thoms Toerring):
>
> But even with numbers that can be represented exactly there
> can be problems. On my machine I get
>
> jens@cm:~$ perl -e 'print sprintf("%.1f", 0.25). "\n"'
> 0.2
> jens@cm:~$ perl -e 'print sprintf("%.1f", 0.75). "\n"'
> 0.8
>
> While the 0.8 result for 0.75 is what one would expect,
> the 0.2 for 0.25 isn't. The explanation is probably that
> it's the result of rounding errors introduced when the
> digits to be displayed are calculated.
No, it's exactly what you (ought to) expect. Most modern computers do
round-to-even by default, for good reasons.
Ben
------------------------------
Date: Mon, 17 Aug 2009 16:26:40 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Rounding issue
Message-Id: <slrnh8ji7r.fgo.tadmc@tadmc30.sbcglobal.net>
Marten Lehmann <lehmannmapson@cnm.de> wrote:
> Hello,
>
>> Marten Lehmann <lehmannmapson@cnm.de> wrote:
>>>> ~% perl -E'say sprintf "%.40f", 0.15'
>>>> 0.1499999999999999944488848768742172978818
>>> why isn't it stored as 0.150000000000000 internally?
>>>
>>>> This is less than 0.15, so it rounds to 0.1.
>>> This is explains why 0.149 doesn't round to 0.2, but it doesn't explain
>>> why 1.5 works different than 0.15 wuth just one floating point digit
>>> difference.
>>
>> Please re-read your notes from "Basics of Computer Numerics".
>
> although I know about the difference between an internal representation
> and the number itself, I don't want to care about that the whole day.
I hope you don't work at my bank...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 17 Aug 2009 23:58:41 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Rounding issue
Message-Id: <slrnh8jkki.gmm.hjp-usenet2@hrunkner.hjp.at>
On 2009-08-17 20:41, Marten Lehmann <lehmannmapson@cnm.de> wrote:
>> Marten Lehmann <lehmannmapson@cnm.de> wrote:
>>>> ~% perl -E'say sprintf "%.40f", 0.15'
>>>> 0.1499999999999999944488848768742172978818
>>> why isn't it stored as 0.150000000000000 internally?
>>>
>>>> This is less than 0.15, so it rounds to 0.1.
>>> This is explains why 0.149 doesn't round to 0.2, but it doesn't explain
>>> why 1.5 works different than 0.15 wuth just one floating point digit
>>> difference.
>>
>> Please re-read your notes from "Basics of Computer Numerics".
>
> although I know about the difference between an internal representation
> and the number itself, I don't want to care about that the whole day.
Then you shouldn't do numeric work.
> All I'm expecting is the programming language to remember the precision
> I used when a value was stored.
You'll be disappointed. Almost no programming language does this. At
least not for basic numeric types. Some programming languages may offer
a "rational" type (Perl has "BigRat").
> 1.5 is not an infinite value as 1/3.
You mean "periodic", not "infinite". Infinite is for example the number
of natural numbers.
1/3 is a periodic number in base 10 or base 2.
It is not a periodic number in base 3.
1/10 is a periodic number in base 2 or base 3.
It is not a periodic number in base 10.
1/2 is a periodic number in base 3.
It is not a periodic number in base 2 or 10.
hp
------------------------------
Date: Mon, 17 Aug 2009 14:49:35 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: Marten Lehmann <lehmannmapson@cnm.de>
Subject: Re: Rounding issue
Message-Id: <86skfq5cwg.fsf@blue.stonehenge.com>
>>>>> "Marten" == Marten Lehmann <lehmannmapson@cnm.de> writes:
Marten> All I'm expecting is the programming language to remember the
Marten> precision I used when a value was stored. 1.5 is not an infinite value
Marten> as 1/3.
But it is. The moment 0.15 is "stored", it's a truncation of an infinite
binary value, and is therefore not precisely 0.15 any more.
(And actually, 1.5 *can* be stored precisely, so you must've gotten mixed up
in this thread.)
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Mon, 17 Aug 2009 22:56:34 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Rounding issue
Message-Id: <i90pl6-15o.ln1@osiris.mauzo.dyndns.org>
Quoth Marten Lehmann <lehmannmapson@cnm.de>:
>
> although I know about the difference between an internal representation
> and the number itself, I don't want to care about that the whole day.
Tough. That's the price for using floating point. If you don't want to
pay it, don't use floating point.
> All I'm expecting is the programming language to remember the precision
> I used when a value was stored.
That concept is called 'bignums'. Perl supports bignums through the use
of the bignum pragma. They are (substantially) slower than native
floats, and cannot easily be passed to functions like sprintf that
expect a float. Nevertheless, feel free to use them if you like.
> 1.5 is not an infinite value as 1/3.
1.5 has a finite decimal representation in both base 10 and base 2.
0.15 does not.
Ben
------------------------------
Date: Mon, 17 Aug 2009 20:42:38 +0100
From: Jon Harrop <jon@ffconsultancy.com>
Subject: Re: Social problems of Python doc [was Re: Python docs disappointing]
Message-Id: <afadndsNrdixPxTXnZ2dnUVZ8kKdnZ2d@brightview.co.uk>
Xah Lee wrote:
> On Aug 12, 12:15 pm, Raymond Hettinger <pyt...@rcn.com> wrote:
>> * The reason for implementing the key= parameter had nothing to do
>> with limitations of Python's compiler. Instead, it was inspired by
>> the
>> decorate-sort-undecorate pattern.
>
> The decorate-sort-undecorate pattern is a compiler limitation, for
> most of today's langs. I'm not sure, but i think some of the fancy
> functional langs automatically detect such and optimize it away, to
> various degrees.
You mean people use that pattern as a fast alternative in languages where
user-defined functions are very slow, like Python and Mathematica?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2557
***************************************
