[32994] in Perl-Users-Digest
Perl-Users Digest, Issue: 4270 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 17 03:09:20 2014
Date: Sun, 17 Aug 2014 00:09:06 -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 Sun, 17 Aug 2014 Volume: 11 Number: 4270
Today's topics:
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <richardn@nospam.com>
Re: Perl bug ; (Tim McDaniel)
Re: Perl bug ; (Tim McDaniel)
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <gamo@telecable.es>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 16 Aug 2014 08:16:21 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <7lquu95pni4dssdvo36h1k9tass9gg8fek@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 15/08/14 a las 17:55, jurgenex@hotmail.com escribió:
>> I am truely hard pressed to find any everyday application where you need
>> more than maybe 5 valid digits and even that is a bit of a stretch
>> already. Science may be different but those people better know how to
>> handle computer numerics anyway.
>
>You have an example at hand: it's called clock.
How so? Are milliseconds sufficent or do you need nanoseconds?
In either case there is no need for floating point, just count them as
integers and be happy.
Also, please remember this story:
A museum's guide explaining to the visitors:
"And this dinosaur skeleton is 65.000.012 years old."
"That is impressive. How could they calculate the age
so accurate?"
"Well, it was 65 million years old when I started this
job. And that was 12 years ago"
You don't want to fall into the same trap.
>Any other
>analogic-digital conversion, simulation will need precision.
Again, as I wrote before: how many _VALID_ digits does your measuring
instrument give you? A tape measure about 2 to 3, callipers 3 (including
the venier), thermometers 2, better onces 3 with luck, high precision
maybe 4, scales 2-3, maybe 4-5 for very high precision scales, and the
list goes on and on.
Speedometers are allowed an incaccuracy of 5% of the scale end value,
i.e. their accuracy is only 1-2 digits and at some speeds not even that.
Disclaimer: obviously scientific research is a different story. But they
employ experts who are well versed in computer numerics and know how to
handle numbers with a large number of valid digits correctly.
The ordinary application developer will rarely venture into those
realms.
>There are
>cases
>in which the error could be measured and it happens must be 0.0
An impossible condition. Whoever demands a measuring error of 0 has no
clue what he is talking about, neither in his specific subject matter
area nor in computer numerics.
>For that, there are simple routines that calculate the EPS (epsilon)
>of error in your language/compiler/machine combination and the minimum
>it is, the better the computation. As expected, long doubles have
>better, minor EPS errors.
[algorithm snipped]
This algorithm computes an approximation of the smallest floating point
number on your computer. It is as useless as a visitor counter on a web
page.
What does that have to do with anything that is being discussed in this
thread? Try adding this number to e.g. one million a million times.
>Mine is EPS = 1.11022302462516e-16
Or to make it easier even use a number 10 times as large, i.e
EPS = 1.11022302462516e-15
my $eps=1;
do {
$eps /= 2;
} until (1+$eps == 1);
$eps *= 10;
print "$eps\n";
$s = 1000000;
print "$s\n";
foreach (1..1000000){
$s += $eps;
}
print "$s\n";
Surprised? You shouldn't be. And no, this is not another bug in Perl.
It is simply another instance of the well-known limitations of floating
point numbers.
And as I said before: if you don't understand at least the basics of
floating point numbers, then probably you should not be using them.
jue
------------------------------
Date: Sat, 16 Aug 2014 08:23:07 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <7otuu9d7ld1uupevm4ofmicgl9c45q2r0s@4ax.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>The time between the epoch and the posting of this article with 1 second
>precision? Yes, you need 10 digits for that, but:
Time since the epoch is a discrete value, you don't use floating point
for it but integer.
jue
------------------------------
Date: Sat, 16 Aug 2014 08:29:20 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <cftuu910t17chiqdih33o3qp7mae1oge7t@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 16/08/14 a las 14:35, Peter J. Holzer escribió:
>> But note that while 80 bit fp numbers (almost) always give more precise
>> results than 64 bit fp numbers, 128 bit fp numbers would give even more
>> precise results. So should we always use 128 bit fp numbers? Or 256 bit
>> fp numbers, since those given even better results? Where do we stop?
>
>We need to stop where technology stop us. The processor can handle
>well a certain amount of length of bits of a fp. Over this amount,
>it only can process a number with considerable overhead.
Or you could simply say: if you are using floating point numbers then
better learn how to use floating point numbers. It is an urban myth that
they are easy to deal with. And no, the number of bits for FP numbers
doesn't matter(*) because the issues are inherent in the very concept of
floating point numbers.
*: doesn't matter any more today where ~15 digits are standard. Of
course in the distant past with shorter data types it was a different
story.
>What? Perl is programmed in C, ergo I don't know a good reason why
>it need to be more imprecise added to more slowly. This kind of
>reason add another brick in the wall around Perl as a decent lenguage.
Still waiting for your real-world application that demands more than 15
valid digits.
jue
------------------------------
Date: Sat, 16 Aug 2014 18:35:18 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lso18o$l4p$1@speranza.aioe.org>
El 16/08/14 a las 17:16, jurgenex@hotmail.com escribió:
> $s = 1000000;
> print "$s\n";
> foreach (1..1000000){
> $s += $eps;
> }
> print "$s\n";
>
> Surprised? You shouldn't be. And no, this is not another bug in Perl.
> It is simply another instance of the well-known limitations of floating
> point numbers.
> And as I said before: if you don't understand at least the basics of
> floating point numbers, then probably you should not be using them.
>
> jue
It's the simple maths of print. You have 1e6 + 1e-15 * 1e6 = 1e6 + 1e-9
which must be printed as only 1e6. Do not try to repeat with printf(
"%.140f", $s);
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 16 Aug 2014 18:47:36 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lso1vp$mv7$1@speranza.aioe.org>
El 16/08/14 a las 17:29, jurgenex@hotmail.com escribió:
>> What? Perl is programmed in C, ergo I don't know a good reason why
>> >it need to be more imprecise added to more slowly. This kind of
>> >reason add another brick in the wall around Perl as a decent lenguage.
> Still waiting for your real-world application that demands more than 15
> valid digits.
>
> jue
Search in my web something like analogic.pl
Real world aplications with fails of floating point unties, there
are a lot. I had one with a job shop scheduling problem.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 16 Aug 2014 10:39:42 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <qc5vu9l2nonctdr6d0akp1n8qkfbknopju@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 16/08/14 a las 17:16, jurgenex@hotmail.com escribió:
>> $s = 1000000;
>> print "$s\n";
>> foreach (1..1000000){
>> $s += $eps;
>> }
>> print "$s\n";
>
>You have 1e6 + 1e-15 * 1e6
No, I don't. And that is exactly the point.
If you understand neither the effect of combining large and small
floating point numbers in a calculations nor the difference between
adding a value a million times and adding a value multiplied by one
million, then you should better not be using floating point numbers for
anything but trivial calculations.
Do you even understand what floating point numbers are?
jue
------------------------------
Date: Sat, 16 Aug 2014 10:41:54 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <dr5vu95jjur1s24ln3qqtp9hita0fq2btr@4ax.com>
gamo <gamo@telecable.es> wrote:
>Real world aplications with fails of floating point unties, there
>are a lot. I had one with a job shop scheduling problem.
Where would you use floating point numbers and arithmetic for
scheduling? Scheduling is about time, isn't it? What does time have to
do with floating point?
jue
------------------------------
Date: Sat, 16 Aug 2014 10:45:57 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <n16vu91f39rckl0btt29dfikmdt8gkkefa@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 16/08/14 a las 17:16, jurgenex@hotmail.com escribió:
>> $s = 1000000;
>> print "$s\n";
>> foreach (1..1000000){
>> $s += $eps;
>> }
>> print "$s\n";
>
>It's the simple maths of print. [..]. Do not try to repeat with printf(
>"%.140f", $s);
Why not? It prints
1000000.000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000
Which is perfectly as expected by anyone who is familiar with floating
point numbers.
jue
------------------------------
Date: Sat, 16 Aug 2014 20:01:48 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lso6at$2k9$1@speranza.aioe.org>
El 16/08/14 a las 19:39, jurgenex@hotmail.com escribió:
> gamo <gamo@telecable.es> wrote:
>> El 16/08/14 a las 17:16, jurgenex@hotmail.com escribió:
>>> $s = 1000000;
>>> print "$s\n";
>>> foreach (1..1000000){
>>> $s += $eps;
>>> }
>>> print "$s\n";
>>
>> You have 1e6 + 1e-15 * 1e6
>
> No, I don't. And that is exactly the point.
>
Ok, the $eps is discarded because don't fit in the $s fp.
So, what's your point?
> If you understand neither the effect of combining large and small
> floating point numbers in a calculations nor the difference between
> adding a value a million times and adding a value multiplied by one
> million, then you should better not be using floating point numbers for
> anything but trivial calculations.
>
Of course I do non trivial calculations, continue to do so,
with or without your permission.
> Do you even understand what floating point numbers are?
>
Yes, I do. That's why I want long doubles and you are in a
case lost.
> jue
>
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 16 Aug 2014 11:17:47 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <op7vu9tfu9ccr370k8vm2pcqjhdhs7e93v@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 16/08/14 a las 19:39, jurgenex@hotmail.com escribió:
>> gamo <gamo@telecable.es> wrote:
>>> El 16/08/14 a las 17:16, jurgenex@hotmail.com escribió:
>>>> $s = 1000000;
>>>> print "$s\n";
>>>> foreach (1..1000000){
>>>> $s += $eps;
>>>> }
>>>> print "$s\n";
>>>
>>> You have 1e6 + 1e-15 * 1e6
>>
>> No, I don't. And that is exactly the point.
>
>Ok, the $eps is discarded because don't fit in the $s fp.
>So, what's your point?
My point is that your $eps is irrelevant.
>> If you understand neither the effect of combining large and small
>> floating point numbers in a calculations nor the difference between
>> adding a value a million times and adding a value multiplied by one
>> million, then you should better not be using floating point numbers for
>> anything but trivial calculations.
>
>Of course I do non trivial calculations, continue to do so,
>with or without your permission.
Everyone has the freedom to shot himself in the foot as often as he
likes.
>> Do you even understand what floating point numbers are?
>
>Yes, I do.
This on the other hand I seriously doubt. You have proven otherwise.
EOD
jue
------------------------------
Date: Sat, 16 Aug 2014 20:22:38 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lso7hv$5sd$1@speranza.aioe.org>
El 16/08/14 a las 19:41, jurgenex@hotmail.com escribió:
> gamo <gamo@telecable.es> wrote:
>> Real world aplications with fails of floating point unties, there
>> are a lot. I had one with a job shop scheduling problem.
>
> Where would you use floating point numbers and arithmetic for
> scheduling? Scheduling is about time, isn't it? What does time have to
> do with floating point?
>
> jue
>
Time is continuous, a real variable. A realistic film, made of a integer
number of photograms, could serve to some purposes, others don't.
Call it lazyness but if you are scheduling in minutes, seconds are its
decimal numbers, which include miliseconds and so on. I don't know if
it's easy to expand the limited integer capacity and express all in its
integer version case by case. I doubt it.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 16 Aug 2014 20:33:36 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lso86h$7k3$1@speranza.aioe.org>
El 16/08/14 a las 20:17, jurgenex@hotmail.com escribió:
>> So, what's your point?
> My point is that your $eps is irrelevant.
>
Since this is my EOD, I don't invented that routine,
it figures in a IEEE document about fp. Surprise!
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 16 Aug 2014 21:42:55 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: Perl bug ;
Message-Id: <MPG.2e59d2a9bcbb1c99897f3@news.eternal-september.org>
In article <slrnluu6tn.hl4.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
>
> > Or is $d a float internally but there are no errors here because
> > integer "values" always have exact representations in floating point
> > format?
>
> Yes. Or rather, some integer values have exact representations in a
> floating point format, just like some integers can be represented in a
> fixed length int format (Since there are infinitely many integers, it is
> impossible to represent all of them in a finite number of bits).
>
> In both cases there is a contiguous range of representable integers. A
> 32 bit signed int can represent [-2147483648, 2147483647], a 32 bit
> unsigned int can represent [0, 4294967295]. A 64 bit IEEE 754 FP number
> can represent all integers in [-9007199254740992, +9007199254740992].
> For larger ranges, there are holes: For [-2**54, +2**54], it can
> represent all even integers, for [-2*55, +2**54] it can represent all
> integers divisible by 4, and so on. And for smaller ranges, it can
> represent non-integers: For [-1, +1] it can represent all multiples of
> 2**-53.
>
Thanks!
Richard Nicholas
------------------------------
Date: Sun, 17 Aug 2014 04:26:12 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Perl bug ;
Message-Id: <lspat4$rru$1@reader1.panix.com>
In article <slrnluujvq.7k2.hjp-usenet3@hrunkner.hjp.at>,
Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
>A double precision fp number has about 15 significant digits, so if you
>lose the last 9 to rounding errors, your result is still accurate to 6
>digits. An 80 bit "long double" has about 21 significant digits, so if
>you lose the last 9, your result is accurate to 12 digits. Now ask
>yourself: Are 6 digits enough or do you need 12?
I know what you're thinking, punk. You're thinking "does he have
twelve significant digits or only six?" Now to tell you the truth,
I forgot myself in all this roundoff. But being this is double
precision, the most powerful floating point in the world and will blow
away all your notions of precision, you've gotta ask yourself a
question: "Do I feel lucky?" Well, do ya, punk?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 17 Aug 2014 04:29:46 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Perl bug ;
Message-Id: <lspb3q$o4e$1@reader1.panix.com>
In article <7lquu95pni4dssdvo36h1k9tass9gg8fek@4ax.com>,
J_rgen Exner <jurgenex@hotmail.com> wrote:
>It is simply another instance of the well-known limitations of floating
>point numbers.
>And as I said before: if you don't understand at least the basics of
>floating point numbers, then probably you should not be using them.
What he said. There's a very good reason why a good computer-science
department has multiple courses in numerical analysis, including
detailed graduate-level classes.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 17 Aug 2014 07:01:44 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lspd0d$fbb$1@speranza.aioe.org>
El 17/08/14 a las 06:26, Tim McDaniel escribió:
> I know what you're thinking, punk. You're thinking "does he have
> twelve significant digits or only six?" Now to tell you the truth,
> I forgot myself in all this roundoff. But being this is double
> precision, the most powerful floating point in the world and will blow
> away all your notions of precision, you've gotta ask yourself a
> question: "Do I feel lucky?" Well, do ya, punk?
Wrong, Tim. If you type perl -V | less
you could see
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
that, apart that is compiler (gcc) and machine dependant, that
long double could cost you 16 bytes. But that doesn't mind that
if you type print $fp; will fill your screen with numbers, the
digits printed are just the same number of.
For resume, I have used perl with long doubles before and still alive.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sun, 17 Aug 2014 08:35:32 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnlv0j9k.qjg.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-16 12:56, gamo <gamo@telecable.es> wrote:
> El 16/08/14 a las 14:35, Peter J. Holzer escribió:
>> But note that while 80 bit fp numbers (almost) always give more precise
>> results than 64 bit fp numbers, 128 bit fp numbers would give even more
>> precise results. So should we always use 128 bit fp numbers? Or 256 bit
>> fp numbers, since those given even better results? Where do we stop?
>>
>
> We need to stop where technology stop us. The processor can handle
> well a certain amount of length of bits of a fp. Over this amount,
> it only can process a number with considerable overhead.
That's certainly a pragmatic viewpoint. But for any specific problem
it's the wrong way around: Instead of asking yourself "what do I need to
solve this problem", you say "this is what I can easily get, so I'll use
this, whether it solves the problem or not". You know the proverb about
the hammer and the nail?
>> In the end for any generic solution (such as hardware support in a
>> processore or the generic "number" type in a weakly typed language like
>> Perl or Javascript) you have to compromise between accuracy and cost.
>
> What? Perl is programmed in C, ergo I don't know a good reason why it
> need to be more imprecise added to more slowly.
The "default" fp type in C (i.e. the one smaller types are automatically
promoted to) is double. On many platforms long double is just an alias
for double. On others it is significantly slower.
On the x86/87 platform it isn't slower (all computations are done in 80
bit anyway), but it takes more memory (on Linux/x86_64 twice as much).
But the x87 is history and mostly included for backward compatibility
(and presumably for those who *need* an extended fp type). Newer
processors provide (and compilers use) the SSE instructions which are
limited to 64 bit.
So even on the x86 platform, there is a cost associated with using long
double: It is slower and it takes more memory. The speed is probably not
a problem for perl (the interpreter overhead is probably much larger),
but the increased memory requirements might be.
If you want to pay this price for increased precision, you can alwas
compile perl with long doubles.
> This kind of reason add another brick in the wall around Perl as a
> decent lenguage. And it is a decent one.
The length of the fp type is not a property of the Perl programming
language. It is a configurable property of the interpreter. You can
choose it yourself. If you use a binary compiled by someone else, ask
them to reconsider their choice.
But be prepared that they will ask you what you need the extra precision
for. And you still haven't answered that in this thread,
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 17 Aug 2014 08:54:28 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnlv0kd4.qjg.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-16 15:29, Jürgen Exner <jurgenex@hotmail.com> wrote:
> And no, the number of bits for FP numbers doesn't matter(*) because
> the issues are inherent in the very concept of floating point numbers.
Of course the number of bits in the mantissa does matter. For every problem
you need a specific precision to get acceptable results. If you use a
shorter type, you will not get an acceptable result. If you use a longer
type, you may waste time or memory (or both).
Of course no finite amount of bits will reduce the rounding error
to zero. But that isn't required.
> *: doesn't matter any more today where ~15 digits are standard. Of
> course in the distant past with shorter data types it was a different
> story.
The 32 bit fp type still exists and is very much in use. Not in (core)
perl, but everywhere where only low precision and high speed is
required. Think graphics programming, for example. Both CPUs (SSEx
instructions on intel) and GPUs are faster on 32 bit types than on 64
bit types (at least if they can parallelize instructions).
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 17 Aug 2014 08:58:21 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lspjr1$rcb$1@speranza.aioe.org>
El 17/08/14 a las 08:35, Peter J. Holzer escribió:
> The length of the fp type is not a property of the Perl programming
> language. It is a configurable property of the interpreter. You can
> choose it yourself. If you use a binary compiled by someone else, ask
> them to reconsider their choice.
>
> But be prepared that they will ask you what you need the extra precision
> for. And you still haven't answered that in this thread,
>
> hp
As I said I used long doubles before, ever since I remember compiled
perl, with 64 bit ints, no threads, etc. But if I were to answer that
kind of pentium bug question the answer could be:
"Because I want more precision on my desktop than in *this phone*"
--
http://www.telecable.es/personales/gamo/
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 4270
***************************************
