[32991] in Perl-Users-Digest
Perl-Users Digest, Issue: 4267 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 14 21:09:19 2014
Date: Thu, 14 Aug 2014 18:09:08 -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 Thu, 14 Aug 2014 Volume: 11 Number: 4267
Today's topics:
Can't locate object method "requirements_for_module" vi <benswitala@gmail.com>
Re: Can't locate object method "requirements_for_module <rweikusat@mobileactivedefense.com>
Re: Can't locate object method "requirements_for_module <benswitala@gmail.com>
Re: Can't locate object method "requirements_for_module <benswitala@gmail.com>
Re: Can't locate object method "requirements_for_module <justin.1401@purestblue.com>
Re: Perl bug ; (hymie!)
Re: Perl bug ; <rweikusat@mobileactivedefense.com>
Re: Perl bug ; <gravitalsun@hotmail.foo>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <rweikusat@mobileactivedefense.com>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <mvdwege@mail.com>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <richardn@nospam.com>
Re: Perl bug ; <gamo@telecable.es>
Re: perl6 too much pointless functionality <bauhaus@futureapps.invalid>
Re: Sorting Keys in Tie::IxHash::Easy <benswitala@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 13 Aug 2014 16:31:55 -0700 (PDT)
From: Ben Switala <benswitala@gmail.com>
Subject: Can't locate object method "requirements_for_module" via package "CPAN::Meta::Requirements"
Message-Id: <495816d9-8c47-4439-8506-f4ed86551b48@googlegroups.com>
Hi Everyone,
I'm blocked from installing modules by this problem:
Can't locate object method "requirements_for_module" via package "CPAN::Met=
a::Requirements" at /usr/lib/perl5/5.8.8/CPAN/Distribution.pm line 2802.
The command I had run was
cpan -if Business::ISBN
I've taken a look at a closely related thread: https://groups.google.com/fo=
rum/#!topic/perl.perl5.porters/GmmtAoaHhbc . It seems to me that the solut=
ion was to uninstall and reinstall perl. Have I read that correctly, and/o=
r can anyone give me other guidance out of this problem?
Some more background: I'm trying to work through the O'Reilly book Intermed=
iate Perl by Schwartz et al. I think that something I did with regard to t=
he exercises in the book led to this situation.
Thanks in advance. Happy Wednesday.
Ben
------------------------------
Date: Thu, 14 Aug 2014 11:31:15 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can't locate object method "requirements_for_module" via package "CPAN::Meta::Requirements"
Message-Id: <874mxfuzv0.fsf@sable.mobileactivedefense.com>
Ben Switala <benswitala@gmail.com> writes:
> Hi Everyone,
>
> I'm blocked from installing modules by this problem:
>
> Can't locate object method "requirements_for_module" via package
> "CPAN::Meta::Requirements" at
> /usr/lib/perl5/5.8.8/CPAN/Distribution.pm line 2802.
>
> The command I had run was
> cpan -if Business::ISBN
>
> I've taken a look at a closely related thread:
> https://groups.google.com/forum/#!topic/perl.perl5.porters/GmmtAoaHhbc. It
> seems to me that the solution was to uninstall and reinstall perl.
> Have I read that correctly, and/or can anyone give me other guidance
> out of this problem?
The error message tells you that some code in Distribution.pm tried to
call a method requirements_for_module using a reference blessed into
CPAN::Meta::Requirements but no such method was found (neither in the
symbol table of the package itself nor in any declared
superclasses). While it is not impossible that the method was supposed
to be created at runtime and this didn't happen for some reason, it
seems more likely that the CPAN::Meta::Requirements you have is not
compatible with the Distribution.pm you also have, ie, the latter tries
to call a method in the former which doesn't yet exist (but will become
available in a newer version) or doesn't exist anymore (newer version
which was installed removed the method).
The general solution is that you need to remedy the version mismatch,
ie, either use a cpan (I'm assuming Distribution.pm is a part of that)
which doesn't try to call this method or install a
CPAN::Meta::Requirements providing it. This seems to be a very popular
problem this year and all of the 'solutions' I read through so far
accomplish that by either reverting to an older cpan or installing a
newer CPAN::Meta::Requirements.
------------------------------
Date: Thu, 14 Aug 2014 09:37:12 -0700 (PDT)
From: Ben Switala <benswitala@gmail.com>
Subject: Re: Can't locate object method "requirements_for_module" via package "CPAN::Meta::Requirements"
Message-Id: <ba7e40c1-6bbf-4811-9bce-4b1d2ec968c9@googlegroups.com>
Thanks Justin and Rainer for the replies. Justin, I've taken your suggesti=
on and asked a sysadmin for help in installing the most recent version of p=
erl.
I've heard of perlbrew and installing a version of perl in one of my own di=
rectories, but I guess I'm lazy and would like someone else to install the =
latest version for me. :D
I tried doing the "upgrade cpan" commands, just to see what would happen, e=
ven though the the latest perl has been installed, and I received a message=
stating that cpan is up to date.
I didn't mean to blame Randall or his co-authors; I meant to say that I thi=
nk this was caused by something I did wrong.
I'll post more when I hear back from a sysadmin (hopefully soon).
On Wednesday, August 13, 2014 4:31:55 PM UTC-7, Ben Switala wrote:
> Hi Everyone,
>=20
>=20
>=20
> I'm blocked from installing modules by this problem:
>=20
>=20
>=20
> Can't locate object method "requirements_for_module" via package "CPAN::M=
eta::Requirements" at /usr/lib/perl5/5.8.8/CPAN/Distribution.pm line 2802.
>=20
>=20
>=20
> The command I had run was
>=20
> cpan -if Business::ISBN
>=20
>=20
>=20
> I've taken a look at a closely related thread: https://groups.google.com/=
forum/#!topic/perl.perl5.porters/GmmtAoaHhbc . It seems to me that the sol=
ution was to uninstall and reinstall perl. Have I read that correctly, and=
/or can anyone give me other guidance out of this problem?
>=20
>=20
>=20
> Some more background: I'm trying to work through the O'Reilly book Interm=
ediate Perl by Schwartz et al. I think that something I did with regard to=
the exercises in the book led to this situation.
>=20
>=20
>=20
> Thanks in advance. Happy Wednesday.
>=20
>=20
>=20
> Ben
------------------------------
Date: Thu, 14 Aug 2014 10:32:45 -0700 (PDT)
From: Ben Switala <benswitala@gmail.com>
Subject: Re: Can't locate object method "requirements_for_module" via package "CPAN::Meta::Requirements"
Message-Id: <ae9c93d0-0032-4da8-aaae-a530e63aaa79@googlegroups.com>
Hi Everyone,
So it looks like my problem has been resolved with the help of my sysadmin.=
=20
One issue seems to have been that I was not running the "cpan Business::ISB=
N" command as sudo. I had previously done "sudo -s" and entered my passwor=
d, switching my command prompt to "root", but I found out that prefixing "s=
udo" in front of a "cpan <some module>" command makes the installation work=
.
Then, I found that specifying the module's path in the PERL5LIB environment=
variable let me use that module in my script.
So it looks like part of the problem was my usage or mis-usage of "sudo". =
=20
Not sure why installing modules has suddenly become so difficult; three day=
s ago module installation was a breeze.
Could anyone contribute more insights?
Thanks,
Ben
On Wednesday, August 13, 2014 4:31:55 PM UTC-7, Ben Switala wrote:
> Hi Everyone,
>=20
>=20
>=20
> I'm blocked from installing modules by this problem:
>=20
>=20
>=20
> Can't locate object method "requirements_for_module" via package "CPAN::M=
eta::Requirements" at /usr/lib/perl5/5.8.8/CPAN/Distribution.pm line 2802.
>=20
>=20
>=20
> The command I had run was
>=20
> cpan -if Business::ISBN
>=20
>=20
>=20
> I've taken a look at a closely related thread: https://groups.google.com/=
forum/#!topic/perl.perl5.porters/GmmtAoaHhbc . It seems to me that the sol=
ution was to uninstall and reinstall perl. Have I read that correctly, and=
/or can anyone give me other guidance out of this problem?
>=20
>=20
>=20
> Some more background: I'm trying to work through the O'Reilly book Interm=
ediate Perl by Schwartz et al. I think that something I did with regard to=
the exercises in the book led to this situation.
>=20
>=20
>=20
> Thanks in advance. Happy Wednesday.
>=20
>=20
>=20
> Ben
------------------------------
Date: Thu, 14 Aug 2014 09:40:51 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: Can't locate object method "requirements_for_module" via package "CPAN::Meta::Requirements"
Message-Id: <j99ubb-7l7.ln1@zem.masonsmusic.co.uk>
On 2014-08-13, Ben Switala <benswitala@gmail.com> wrote:
> Hi Everyone,
>
> I'm blocked from installing modules by this problem:
>
> Can't locate object method "requirements_for_module" via package
> "CPAN::Meta::Requirements" at
> /usr/lib/perl5/5.8.8/CPAN/Distribution.pm line 2802.
>
> The command I had run was
> cpan -if Business::ISBN
>
> I've taken a look at a closely related thread:
> https://groups.google.com/forum/#!topic/perl.perl5.porters/GmmtAoaHhbc.
> It seems to me that the solution was to uninstall and reinstall
> perl.
This should never be a solution to any perl problem.
Your Perl is very old. Try upgrading to a more recent version. Once
you've upgraded perl upgrade your CPAN:
[hostname] ~ $ sudo cpan
this starts a cpan shell where you can run:
cpan[1]> upgrade cpan
cpan[2]> reload cpan
cpan[3]> upgrade all
cpan[4]> install Business::ISBN
(in the above, the text "cpan[3]>" is the command prompt in the
cpan shell, the number is a count)
The 'upgrade all' line may take quite a while to run if you have
installed a lot of modules from CPAN.
The link you posted mentions Darwin, are you on OS X? If so, upgrade!
Mavericks has 5.16.
> Some more background: I'm trying to work through the O'Reilly book
> Intermediate Perl by Schwartz et al. I think that something I did
> with regard to the exercises in the book led to this situation.
I would expect the book to tell you the version of perl they're using,
can you upgrade to at least that version? (I'm pretty sure
Intermediate Perl is more recent than 5.8.8).
Running through exercises in Randall's books (or books he's
co-authored) should not cause you to break Perl. I've not finished IP
myself but IME I'm pretty sure they don't give you dangerous things to
do!
If, after upgrading to at least the verion of perl they're using in
the book, and upgrading your cpan and modules, you still have this
problem please ask again.
Justin.
--
Justin C, by the sea.
------------------------------
Date: 14 Aug 2014 14:10:01 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: Re: Perl bug ;
Message-Id: <53ecc339$0$24011$882e7ee2@usenet-news.net>
In our last episode, the evil Dr. Lacto had captured our hero,
Ben Bacarisse <ben.usenet@bsb.me.uk>, who said:
>[1] Gnus, being what it is, can do anything, but I mean that there's a
>standard key binding to lower the score of all followups to an author
>available "out of the box".
Emacs is a fine operating system, although its built-in text editor
leaves a lot to be desired.
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
-------------------------------------------------------------------------------
------------------------------
Date: Thu, 14 Aug 2014 16:02:55 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl bug ;
Message-Id: <878umrp10g.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>> #!/usr/bin/perl
>> my $i=0;
>> my $diff = 9.21;
>> while ($i++ <= 10) {
>> $diff -= 2;
>> print "$diff\n" }
>>
>>
>> I get the following completely wrong output. What is this ?
>>
>>
>> 7.21
>> 5.21
>> 3.21
>> 1.21
>> -0.789999999999999
>
> An accumulated rounding error
Since the web page mentioned elsewhere is positively unintelligible
(except for someone who has the time to work through all of the
calculations), some ultra-condensed information could be:
An infinite number of so-called real numbers have to be represented with
a finite number of bits for 'floating point arithmetic'. This implies
that a given 'real number' has to represented as the closest, other real
number which can be encoded in the floating point format which happens
to be used. The difference between the original 'real number' and the
number actually represented by a given encoded value is called 'rounding
error' (in this context).
Because of this, a real number n actually becomes a sum n + r, r being
the rounding error, when represented as 'floating point value'. Assuming
two numbers n0 and n1 are dealt with in this way, one will get two sums,
n0 + r0 and n1 + r1 instead. Adding these two doesn't result in n0 + n1
but int n0 + r0 + n1 + r1, ie, the rounding errors add up. Things are
even more interesting for multplication because the product
n0 * n1
really ends up as
(n0 + r0) * (n1 + r1) =
n0 * n1 + n0 * r1 + r0 * n1 + r0 * r1
ie, the errors multiply.
The actual, binary format being used is 'slightly bizarre'. The
following program can be used to convert a 'real number' provided as
string to the double-equivalent of the actually encoded number if
single-prescision floats were being used (whoever notices an error in
there is entitled to keep it).
-------------
sub float_2_uint
{
return unpack('L', pack('f', $_[0]));
}
sub sign
{
return 1 - (($_[0] >> 31) & 1) * 2;
}
sub expn
{
my $x;
$x = ($_[0] >> 23) & 0xff;
return $x - 127;
}
sub mant
{
my ($m, $bit, $v);
my $x;
$m = $_[0] & ((1 << 23) - 1);
$bit = 1 << 22;
$v = 1;
do {
$v /= 2;
$x += $v * (($m & $bit) != 0);
} while $bit >>= 1;
return $x + 1;
}
sub fiction_2_fact
{
my $x;
$x = float_2_uint($_[0]);
return sign($x) * mant($x) * (2 ** expn($x));
}
print(fiction_2_fact($_), "\n") while <>;
------------------------------
Date: Thu, 14 Aug 2014 20:45:03 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Perl bug ;
Message-Id: <lsisk5$1jsv$1@news.ntua.gr>
On 14/8/2014 6:02 μμ, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>> #!/usr/bin/perl
>>> my $i=0;
>>> my $diff = 9.21;
>>> while ($i++ <= 10) {
>>> $diff -= 2;
>>> print "$diff\n" }
>>>
>>>
>>> I get the following completely wrong output. What is this ?
>>>
>>>
>>> 7.21
>>> 5.21
>>> 3.21
>>> 1.21
>>> -0.789999999999999
>>
>> An accumulated rounding error
>
> Since the web page mentioned elsewhere is positively unintelligible
> (except for someone who has the time to work through all of the
> calculations), some ultra-condensed information could be:
>
> An infinite number of so-called real numbers have to be represented with
> a finite number of bits for 'floating point arithmetic'. This implies
> that a given 'real number' has to represented as the closest, other real
> number which can be encoded in the floating point format which happens
> to be used. The difference between the original 'real number' and the
> number actually represented by a given encoded value is called 'rounding
> error' (in this context).
>
> Because of this, a real number n actually becomes a sum n + r, r being
> the rounding error, when represented as 'floating point value'. Assuming
> two numbers n0 and n1 are dealt with in this way, one will get two sums,
> n0 + r0 and n1 + r1 instead. Adding these two doesn't result in n0 + n1
> but int n0 + r0 + n1 + r1, ie, the rounding errors add up. Things are
> even more interesting for multplication because the product
>
> n0 * n1
>
> really ends up as
>
> (n0 + r0) * (n1 + r1) =
> n0 * n1 + n0 * r1 + r0 * n1 + r0 * r1
>
> ie, the errors multiply.
>
> The actual, binary format being used is 'slightly bizarre'. The
> following program can be used to convert a 'real number' provided as
> string to the double-equivalent of the actually encoded number if
> single-prescision floats were being used (whoever notices an error in
> there is entitled to keep it).
>
> -------------
> sub float_2_uint
> {
> return unpack('L', pack('f', $_[0]));
> }
>
> sub sign
> {
> return 1 - (($_[0] >> 31) & 1) * 2;
> }
>
> sub expn
> {
> my $x;
>
> $x = ($_[0] >> 23) & 0xff;
> return $x - 127;
> }
>
> sub mant
> {
> my ($m, $bit, $v);
> my $x;
>
> $m = $_[0] & ((1 << 23) - 1);
> $bit = 1 << 22;
> $v = 1;
> do {
> $v /= 2;
> $x += $v * (($m & $bit) != 0);
> } while $bit >>= 1;
>
> return $x + 1;
> }
>
> sub fiction_2_fact
> {
> my $x;
>
> $x = float_2_uint($_[0]);
> return sign($x) * mant($x) * (2 ** expn($x));
> }
>
> print(fiction_2_fact($_), "\n") while <>;
>
I have lost any interest, at all, to contribute to this thread or any
similar thread, it is pointless.
I am here (from time to time) to help anyone who ask for help and what
gets from here is a variaton of the RTFM , and reply to one or two other
guys (like you are)
Thanks, G.Mpouras
------------------------------
Date: Thu, 14 Aug 2014 22:15:28 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lsj5dd$s9f$1@speranza.aioe.org>
El 14/08/14 a las 19:45, George Mpouras escribió:
> I have lost any interest, at all, to contribute to this thread or any
> similar thread, it is pointless.
You lost interest in recognize an error (*), which is the base of this
thread. If you are interested in minimizing floating point errors, you
could compile perl with support for long doubles (which I don't know
why it's not done by default) or use arbitrary precision.
If you are interested in monetary values, treating every amount as an
integer in cents, is another trick.
> I am here (from time to time) to help anyone who ask for help and what
> gets from here is a variaton of the RTFM , and reply to one or two other
> guys (like you are)
> Thanks, G.Mpouras
PS: (*) I made the same error, years ago. Almost nobody killfile me, nor
I killfiled anyone. :-)
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Thu, 14 Aug 2014 21:34:44 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl bug ;
Message-Id: <87mwb6olnf.fsf@sable.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
[floating point rounding errors]
> If you are interested in monetary values, treating every amount as an
> integer in cents, is another trick.
This is more generally applicable. Eg, the original algorithm could be
rewritten as
my $d = 921;
my $n = 10;
do {
$d -= 200;
print($d / 100, "\n");
} while --$n;
to prevent error accumulation.
------------------------------
Date: Thu, 14 Aug 2014 22:58:38 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lsj7uc$24g$1@speranza.aioe.org>
El 14/08/14 a las 22:34, Rainer Weikusat escribió:
> gamo <gamo@telecable.es> writes:
>
> [floating point rounding errors]
>
>> If you are interested in monetary values, treating every amount as an
>> integer in cents, is another trick.
>
> This is more generally applicable. Eg, the original algorithm could be
> rewritten as
>
> my $d = 921;
> my $n = 10;
> do {
> $d -= 200;
> print($d / 100, "\n");
> } while --$n;
>
> to prevent error accumulation.
>
Sure, I reply the problem and the solution in fortran,
which as a reputation of scientific
:~/src/fortran$ cat errorf.f90
program errorf
integer :: cents, k, n
real :: d, euros
d = 9.21
n = 10
do k = n,0,-1
d = d - 2
write (*,*) d
end do
write (*,*) "AFTER"
cents = 921
do k = n,0,-1
cents = cents - 200
euros = cents/100
write (*,*) euros
end do
end program
$ gfortran -Wall errorf.f90 -o errorf
$ ./errorf
7.21000004
5.21000004
3.21000004
1.21000004
-0.789999962
-2.78999996
-4.78999996
-6.78999996
-8.78999996
-10.7900000
-12.7900000
AFTER
7.00000000
5.00000000
3.00000000
1.00000000
0.00000000
-2.00000000
-4.00000000
-6.00000000
-8.00000000
-10.0000000
-12.0000000
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Thu, 14 Aug 2014 23:05:46 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Perl bug ;
Message-Id: <864mxepys5.fsf@gaheris.avalon.lan>
George Mpouras <gravitalsun@hotmail.foo> writes:
> I have lost any interest, at all, to contribute to this thread or any
> similar thread, it is pointless.
> I am here (from time to time) to help anyone who ask for help and what
> gets from here is a variaton of the RTFM , and reply to one or two
> other guys (like you are)
> Thanks, G.Mpouras
>
It is your problem that you want to participate in a cargo cult by just
hacking out code without understanding.
RTFM is completely applicable here.
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Thu, 14 Aug 2014 23:17:05 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lsj90u$4h7$1@speranza.aioe.org>
El 14/08/14 a las 22:58, gamo escribió:
> El 14/08/14 a las 22:34, Rainer Weikusat escribió:
>> gamo <gamo@telecable.es> writes:
>>
>> [floating point rounding errors]
>>
>>> If you are interested in monetary values, treating every amount as an
>>> integer in cents, is another trick.
>>
>> This is more generally applicable. Eg, the original algorithm could be
>> rewritten as
>>
>> my $d = 921;
>> my $n = 10;
>> do {
>> $d -= 200;
>> print($d / 100, "\n");
>> } while --$n;
>>
>> to prevent error accumulation.
>>
>
> Sure, I reply the problem and the solution in fortran,
> which as a reputation of scientific
>
> :~/src/fortran$ cat errorf.f90
> program errorf
> integer :: cents, k, n
> real :: d, euros
>
> d = 9.21
> n = 10
> do k = n,0,-1
> d = d - 2
> write (*,*) d
> end do
>
> write (*,*) "AFTER"
> cents = 921
> do k = n,0,-1
> cents = cents - 200
> euros = cents/100
> write (*,*) euros
> end do
>
> end program
>
> $ gfortran -Wall errorf.f90 -o errorf
> $ ./errorf
> 7.21000004
> 5.21000004
> 3.21000004
> 1.21000004
> -0.789999962
> -2.78999996
> -4.78999996
> -6.78999996
> -8.78999996
> -10.7900000
> -12.7900000
> AFTER
> 7.00000000
> 5.00000000
> 3.00000000
> 1.00000000
> 0.00000000
> -2.00000000
> -4.00000000
> -6.00000000
> -8.00000000
> -10.0000000
> -12.0000000
>
Excuses, in fortran there are problems :-)
program errorf
integer :: cents, k, n
real :: d, euros
d = 9.21
n = 10
do k = n,0,-1
d = d - 2
write (*,*) d
end do
write (*,*) "AFTER"
cents = 921
do k = n,0,-1
cents = cents - 200
euros = real (cents/100.0)
! write (*,*) euros
print "(f15.2)", euros
end do
This will do fine, after conversion.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Thu, 14 Aug 2014 15:46:12 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <miequ9dums6lpq7mojgavc7saj4b1340nn@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 14/08/14 a las 19:45, George Mpouras escribió:
>> I have lost any interest, at all, to contribute to this thread or any
>> similar thread, it is pointless.
>
>You lost interest in recognize an error (*), which is the base of this
>thread. If you are interested in minimizing floating point errors, you
>could compile perl with support for long doubles (which I don't know
>why it's not done by default)
Because it wouldn't solve anything. There are many more rational numbers
than floating point numbers and that is not going to change, no matter
how many digits you are using.
Example from the dezimal world:
0.3333333333 + 0.3333333333 + 0.3333333333 = 0.9999999999
It doesn't matter if you are using 3 digits or 10 digits or 500 digits.
>or use arbitrary precision.
If you meant "use a specific precision", then I agree. That is the
standard solution.
>If you are interested in monetary values, treating every amount as an
>integer in cents, is another trick.
Yes, this is the other standard solution for exact results.
>> I am here (from time to time) to help anyone who ask for help and what
>> gets from here is a variaton of the RTFM ,
Well, what do you expect when asking a questions that _is_ asked
frequently?
And should be very well-known anyway because it _REALLY_ has nothing to
do with Perl but is inherent to modern computers and applies to any
common programming language on any common computer using any common OS.
jue
------------------------------
Date: Fri, 15 Aug 2014 01:00:37 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lsjf37$hug$1@speranza.aioe.org>
El 15/08/14 a las 00:46, jurgenex@hotmail.com escribió:
>> could compile perl with support for long doubles (which I don't know
>> >why it's not done by default)
> Because it wouldn't solve anything. There are many more rational numbers
> than floating point numbers and that is not going to change, no matter
> how many digits you are using.
>
> Example from the dezimal world:
> 0.3333333333 + 0.3333333333 + 0.3333333333 = 0.9999999999
> It doesn't matter if you are using 3 digits or 10 digits or 500 digits.
>
Well, I expect more a response like because "are slower" or that
long doubles "take more space" but not the exceptions. The thing
is that a 32-bit computer using long doubles could be more
precise than a 64-bit computer. The better, must be the best.
But thanks for the explanation.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Thu, 14 Aug 2014 19:18:27 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: Perl bug ;
Message-Id: <MPG.2e570dd32d5c8ab79897f1@news.eternal-september.org>
In article <878umrp10g.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
says...
> Since the web page mentioned elsewhere is positively unintelligible
> (except for someone who has the time to work through all of the
> calculations), some ultra-condensed information could be:
>
> An infinite number of so-called real numbers have to be represented with
> a finite number of bits for 'floating point arithmetic'. This implies
> that a given 'real number' has to represented as the closest, other real
> number which can be encoded in the floating point format which happens
> to be used. The difference between the original 'real number' and the
> number actually represented by a given encoded value is called 'rounding
> error' (in this context).
>
> Because of this, a real number n actually becomes a sum n + r, r being
> the rounding error, when represented as 'floating point value'. Assuming
> two numbers n0 and n1 are dealt with in this way, one will get two sums,
> n0 + r0 and n1 + r1 instead. Adding these two doesn't result in n0 + n1
> but int n0 + r0 + n1 + r1, ie, the rounding errors add up. Things are
> even more interesting for multplication because the product
>
> n0 * n1
>
> really ends up as
>
> (n0 + r0) * (n1 + r1) =
> n0 * n1 + n0 * r1 + r0 * n1 + r0 * r1
Great explanation. Thanks Rainer!
Richard Nicholas
------------------------------
Date: Fri, 15 Aug 2014 02:26:49 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lsjk4q$r6f$1@speranza.aioe.org>
El 15/08/14 a las 01:00, gamo escribió:
> El 15/08/14 a las 00:46, jurgenex@hotmail.com escribió:
>>> could compile perl with support for long doubles (which I don't know
>>> >why it's not done by default)
>
>> Because it wouldn't solve anything. There are many more rational numbers
>> than floating point numbers and that is not going to change, no matter
>> how many digits you are using.
>>
>> Example from the dezimal world:
>> 0.3333333333 + 0.3333333333 + 0.3333333333 = 0.9999999999
>> It doesn't matter if you are using 3 digits or 10 digits or 500 digits.
>>
>
> Well, I expect more a response like because "are slower" or that
> long doubles "take more space" but not the exceptions. The thing
> is that a 32-bit computer using long doubles could be more
> precise than a 64-bit computer. The better, must be the best.
>
> But thanks for the explanation.
>
More on reasons: standarization of results between versions and
machines. OK. It could be all debatable. But despite all, the
advantage is clear: the error is less important. Take your example
with decimals.
case a) 2 digits of precision
1/3 + 1/3 + 1/3 = 0.33 * 3 = 0.99 -> error = 0.01
case b) 3 digits of precision
1/3 + 1/3 + 1/3 = 0.333 * 3 = 0.999 -> error = 0.001
That's a big deal if for every digit we use, one digit less in error.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Thu, 14 Aug 2014 13:02:00 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: perl6 too much pointless functionality
Message-Id: <lsi4v6$6v4$1@dont-email.me>
On 13.08.14 22:03, Rainer Weikusat wrote:
> It doesn't really work anywhere except when concertedly looking into
> another direction.
=head2 RANT
Perl 6 also doesn't really work anymore since everyone who is
considering languages and libraries is concertedly looking into
other directions, for reasons of rational business, or mental
health. (Or following the crowd, but I grant you that wouldn't
be specific to Perl.)
While there appears to be some concerted work on some
libraries, the creative people still behind Perl 6 seem to spend
more energy on mixing more 7 bit ASCII ideographs with the current
syntax, ergo they have found so eagerly needed semantics not
otherwise expressible, and it sure is going to save keystrokes
and will supply greatly for the arcane---which of course is
justified by way of very fancifully telling a formal story.
Of course, this does not happen because they add to Perl whatever
can be added once you have seen it somewhere else. But surely, they
create an opportunity for the reader of Perl 6 programs to acquire
even more skills in disambiguating another surplus of sophisticated
punctuation and (at last!) acquire more knowledge of diversified
basic data structures and iteration facilities. There have never
been enough ways to do it!
Besides all that, the ROI is certain to be without any doubt since
what really matters is programmers who feel like they know what they
are doing rather than the result of having solved a problem.
=head3 Why?
Is there anything in Perl 6 besides some bunch of ants having fun?
=cut
------------------------------
Date: Wed, 13 Aug 2014 16:23:11 -0700 (PDT)
From: Ben Switala <benswitala@gmail.com>
Subject: Re: Sorting Keys in Tie::IxHash::Easy
Message-Id: <405a9c36-c7e8-4bf3-9205-2fa59a9b555b@googlegroups.com>
Thanks everyone for the suggestions. Before I received them, though, I wound up basically copying something from a perldoc about hashes of hashes.
http://perldoc.perl.org/perldsc.html#HASHES-OF-HASHES
I guess the code I've written is good enough until a supervisor or co-worker tells me otherwise.
On Monday, August 11, 2014 4:55:08 PM UTC-7, Ben Switala wrote:
> Hi,
>
>
>
> How can I sort the keys in a multi-dimensional hash using Tie::IxHash::Easy?
>
>
>
> It seems that SortByKey is what I want, but wouldn't that just sort the outer layer of keys?
>
>
>
> Thanks,
>
> Ben
>
>
>
> http://search.cpan.org/~pinyan/Tie-IxHash-Easy-0.01/lib/Tie/IxHash/Easy.pm
>
>
>
> http://search.cpan.org/~chorny/Tie-IxHash-1.23/lib/Tie/IxHash.pm#Standard_TIEHASH_Interface
------------------------------
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 4267
***************************************
