[32990] in Perl-Users-Digest
Perl-Users Digest, Issue: 4266 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 13 18:09:19 2014
Date: Wed, 13 Aug 2014 15:09:05 -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 Wed, 13 Aug 2014 Volume: 11 Number: 4266
Today's topics:
Perl bug ; <gravitalsun@hotmail.foo>
Re: Perl bug ; <gravitalsun@hotmail.foo>
Re: Perl bug ; <m@rtij.nl.invlalid>
Re: Perl bug ; <gravitalsun@hotmail.foo>
Re: Perl bug ; <justin.1401@purestblue.com>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <news@lawshouse.org>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <justin.1401@purestblue.com>
Re: Perl bug ; <kkeller-usenet@wombat.san-francisco.ca.us>
Re: Perl bug ; <rweikusat@mobileactivedefense.com>
Re: Perl bug ; <ben.usenet@bsb.me.uk>
Re: perl6 too much pointless functionality <richardn@nospam.com>
Re: perl6 too much pointless functionality <rweikusat@mobileactivedefense.com>
Re: perl6 too much pointless functionality <kaz@kylheku.com>
Re: perl6 too much pointless functionality <rweikusat@mobileactivedefense.com>
Re: Sorting Keys in Tie::IxHash::Easy <gravitalsun@hotmail.foo>
Re: Sorting Keys in Tie::IxHash::Easy <derykus@gmail.com>
Re: Sorting Keys in Tie::IxHash::Easy <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 13 Aug 2014 13:33:27 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Perl bug ;
Message-Id: <lsfesm$bc3$1@news.ntua.gr>
#!/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
-2.79
-4.79
-6.79
-8.79
-10.79
-12.79
------------------------------
Date: Wed, 13 Aug 2014 13:38:48 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Perl bug ;
Message-Id: <lsff6n$c3v$1@news.ntua.gr>
#!/usr/bin/perl
my $i=0;
my $diff = 88.21;
while ($i++ <= 50) {
$diff -= 2;
print "$diff\n" }
12.21
10.21
8.20999999999999
6.20999999999999
4.20999999999999
2.20999999999999
0.209999999999994
-1.79000000000001
-3.79000000000001
-5.79000000000001
-7.79000000000001
-9.79000000000001
-11.79
------------------------------
Date: Wed, 13 Aug 2014 12:44:05 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Perl bug ;
Message-Id: <l4srbb-2dp.ln1@news.rtij.nl>
On Wed, 13 Aug 2014 13:33:27 +0300, George Mpouras wrote:
> #!/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 -2.79 -4.79 -6.79 -8.79 -10.79
> -12.79
The output is not wrong. Read up on floating point and why it is
inherently inprecise.
M4
------------------------------
Date: Wed, 13 Aug 2014 13:47:16 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Perl bug ;
Message-Id: <lsffmi$d0m$1@news.ntua.gr>
On 13/8/2014 13:44, Martijn Lievaart wrote:
> The output is not wrong. Read up on floating point and why it is
> inherently inprecise.
the behavior is not consistent. it is a bug.
------------------------------
Date: Wed, 13 Aug 2014 12:51:08 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: Perl bug ;
Message-Id: <c20sbb-2o7.ln1@zem.masonsmusic.co.uk>
On 2014-08-13, George Mpouras <gravitalsun@hotmail.foo> wrote:
> On 13/8/2014 13:44, Martijn Lievaart wrote:
>> The output is not wrong. Read up on floating point and why it is
>> inherently inprecise.
>
>
> the behavior is not consistent. it is a bug.
Did you actually read up on floating point arithmetic?
Here's an interesting document[1] from those nice (FSVO) people at
Oracle:
<URL:http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html>
Python have this:
<URL:https://docs.python.org/2/tutorial/floatingpoint.html>
Justin.
1. Seeing as you're too lazy to look yourself and would rather blame
perl than do what was suggested.
--
Justin C, by the sea.
------------------------------
Date: Wed, 13 Aug 2014 07:49:18 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <7lumu9hph33b9105fh3r5vefucrh1hb65e@4ax.com>
George Mpouras <gravitalsun@hotmail.foo> wrote:
>On 13/8/2014 13:44, Martijn Lievaart wrote:
>> The output is not wrong. Read up on floating point and why it is
>> inherently inprecise.
>
>
>the behavior is not consistent. it is a bug.
What output did you expect instead?
Or are you another victim of not reading Introduction into Fundamentals
of Floating Point Arithmetic for Beginners?
If you professor hasn't covered this in the Computer Numerics 101 class
then you should ask for you money back.
jue
------------------------------
Date: Wed, 13 Aug 2014 15:56:51 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Perl bug ;
Message-Id: <6-Wdne9K7Iwu4XbOnZ2dnUVZ8mCdnZ2d@giganews.com>
On 13/08/14 12:51, Justin C wrote:
> Did you actually read up on floating point arithmetic?
I doubt it; that's why George is in my kill file. I must find a
newsreader that will kill a whole thread if started by someone in the
kill file.
--
Henry Law Manchester, England
------------------------------
Date: Wed, 13 Aug 2014 08:38:26 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <2h1nu91q2lq2ke5q3etrbc95mtif1p5fv2@4ax.com>
Jürgen Exner <jurgenex@hotmail.com> wrote:
>George Mpouras <gravitalsun@hotmail.foo> wrote:
>>On 13/8/2014 13:44, Martijn Lievaart wrote:
>>> The output is not wrong. Read up on floating point and why it is
>>> inherently inprecise.
>>
>>
>>the behavior is not consistent. it is a bug.
>
>What output did you expect instead?
>
>Or are you another victim of not reading Introduction into Fundamentals
>of Floating Point Arithmetic for Beginners?
>If you professor hasn't covered this in the Computer Numerics 101 class
>then you should ask for you money back.
Ooohhh, and please check out the FAQ: "perldoc -q 99999"
Thanks
jue
------------------------------
Date: Wed, 13 Aug 2014 16:51:59 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: Perl bug ;
Message-Id: <v5esbb-ruh.ln1@zem.masonsmusic.co.uk>
On 2014-08-13, Henry Law <news@lawshouse.org> wrote:
> On 13/08/14 12:51, Justin C wrote:
>> Did you actually read up on floating point arithmetic?
>
> I doubt it; that's why George is in my kill file. I must find a
> newsreader that will kill a whole thread if started by someone in the
> kill file.
slrn does that, maybe yours does if you set the right rules, IIRC
you want to kill on references that include the OPs details.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 13 Aug 2014 10:19:05 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: Perl bug ;
Message-Id: <99jsbbxfqa.ln2@goaway.wombat.san-francisco.ca.us>
FWIW, any time I see a subject like "Perl bug" I usually assume that the
author was too lazy to use a useful Subject: line, and therefore was
almost certainly too lazy to determine whether it is in fact a bug in
Perl or simply a misunderstanding. I am gratified to see that view
validated by this OP.
On 2014-08-13, Justin C <justin.1401@purestblue.com> wrote:
> On 2014-08-13, Henry Law <news@lawshouse.org> wrote:
>>
>> I doubt it; that's why George is in my kill file. I must find a
>> newsreader that will kill a whole thread if started by someone in the
>> kill file.
>
> slrn does that, maybe yours does if you set the right rules, IIRC
> you want to kill on references that include the OPs details.
If the target's Message-Id pattern is reasonably unique this is a good
strategy, but for users posting from popular nntp gateways using this
strategy can result in too many false positives. I've seen both
scenarios occur, and have had to adjust my scorefile after finding too
many false positives in some cases.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Wed, 13 Aug 2014 20:48:00 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl bug ;
Message-Id: <87egwki32n.fsf@sable.mobileactivedefense.com>
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 which becomes visible here because you're
converting the NV (floating point value) to a string using the 'Perl
default conversion settings' which means using sprintf with a %g format
string and a precision set to the maximum number of significant digits
in the C data type being used here. Hence, you'll get to see a rounding error
<= .000000000000001. You could try a more reasonable precision:
----------
#!/usr/bin/perl
use Devel::Peek;
my $i=0;
my $diff = 9.21;
while ($i++ <= 10) {
$diff -= 2;
printf("%f\n", $diff);
}
-----------
BTW, the same output is produced by a C program performing the
conversion-to-string in the same way:
-----------
#include <stdio.h>
int main(void)
{
double d;
unsigned n;
d = 9.21;
n = 10;
do {
d -= 2;
printf("%.15g\n", d);
} while (--n);
return 0;
}
------------------------------
Date: Wed, 13 Aug 2014 21:46:44 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Perl bug ;
Message-Id: <87zjf8ce2z.fsf@bsb.me.uk>
Henry Law <news@lawshouse.org> writes:
> On 13/08/14 12:51, Justin C wrote:
>> Did you actually read up on floating point arithmetic?
>
> I doubt it; that's why George is in my kill file. I must find a
> newsreader that will kill a whole thread if started by someone in the
> kill file.
Gnus can do that[1], though it prefers a numeric score rather than a
hard killed/not killed distinction. Just tried it and it works fine,
though you also have to score down posts by the author in question or
the head post remains. That seems logical and, presumably, you'd be
doing that anyway. Thanks for prompting me to investigate this.
[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".
--
Ben.
------------------------------
Date: Tue, 12 Aug 2014 22:25:45 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <MPG.2e5496b77d1f99469897f0@news.eternal-september.org>
In article <877g2d4vxk.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
says...
> OTOH, perl6 is no serious contender, anyway, because it also uses
> McCarthy's "don't care about that, can dump this on some student later
> on" hack to work around limitations of the word size of an IBM 704
> computer instead of a reasonable system for automatic resource
> management, so "who friggin' cares"?
>
Any chance you could explain what this is all about? Thanks.
Richard Nicholas
------------------------------
Date: Wed, 13 Aug 2014 17:32:56 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <87y4usic3r.fsf@sable.mobileactivedefense.com>
Richard Nicholas <richardn@nospam.com> writes:
> In article <877g2d4vxk.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
> says...
>> OTOH, perl6 is no serious contender, anyway, because it also uses
>> McCarthy's "don't care about that, can dump this on some student later
>> on" hack to work around limitations of the word size of an IBM 704
>> computer instead of a reasonable system for automatic resource
>> management, so "who friggin' cares"?
>>
>
> Any chance you could explain what this is all about?
There's a text available on the web title 'History of Lisp' (John
McCarthy),
http://www-formal.stanford.edu/jmc/history/lisp/lisp.html
The section 'Implementation of LISP' contains the following statement:
The erasure problem [freeing allocated memory] also had to be
considered [...] There were two alternatives. The first was to
erase the old contents of a program variable whenever it was
updated. Since the car and cdr operations were not to copy
structure, merging list structure would occur, and erasure would
require a system of reference counts. Since there were only six
bits left in a word, and these were in separated parts of the
word, reference counts seemed infeasible without a drastic
change in the way list structures were represented.
The 'word' mentioned in 'there were only six bit left in a word' refers
to a 'natural' data type of an IBM 704 computer, as mentioned in the
earlier 'LISP prehistory' section: McCarthy intially considered using
reference counts but abandoned the idea because of limitation of the
hardware which happened to be used and (same section) because
only toy examples were being done
hence,
its [tracing GC] actual implementation could be postponed
According to Wikipedia,
http://en.wikipedia.org/wiki/Lisp_%28programming_language%29#History
it was later implemented by a graduate student named Daniel Edwards.
While the motivations for this scheme were "reference counts can't be
used on our hardware" and "we don't need to implement this right now",
there's an underlying assumption which has also never been true since
the end of batch processing as universal computing model, namely, "code
is being executed in a closed system, it doesn't have access to 'machine
addresses' and even if it had access to machine addresses, they couldn't
be stored anywhere outside of main memory, hence, every object which
presently can't be reached by following a chain of pointers in main
memory cannot ever be used anymore".
An example where this assumption breaks down[*] would be the Linux epoll I/O
multiplexing mechanism where the kernel stores a pointer to some
userspace object such that it can be provided to the application if
events on a certain file descriptor occur.
[*] A second one would be a particular task queue implementation I'm
using in a certain program. The program is structured around an I/O
event processing loop and this queue is used when some operation has to
be performed 'soon' but outside of the context of the current
event. This basically works by sending a pointer to a closure/ callback
through a socketpair. Some time later, the handler for the receiving
socket reads the pointer back into process memory and uses it to access
the Perl object holding the information necessary for performing the
task. While the pointer is in flight, the object is unreachable for the
process (the corresponding reference count is incremented and
decremented as necessary to make this work).
There are, of course, workarounds for such scenarios, as is wont to
happen when starting out with a simple, stupid idea: Whenever realizing
that it doesn't work can't be avoided anymore, another special case is
added to prevent some consequences of the 'simple, stupid idea' in
certain circumstances, until the whole thing has turned into a
horrendously complicated mess nobody understands anymore. At this point,
it is connected to a speech synthesizer and registered for Turing tests
in the hope that it will suddenly 'become intelligent' in line with the
Marxist theory of large enough quantitative changes turning into
qualitative changes and nobody will ever have to rig those tests for a
flashy headline anymore.
------------------------------
Date: Wed, 13 Aug 2014 19:28:03 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <20140813121344.63@kylheku.com>
On 2014-08-13, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> While the motivations for this scheme were "reference counts can't be
> used on our hardware" and "we don't need to implement this right now",
> there's an underlying assumption which has also never been true since
> the end of batch processing as universal computing model, namely, "code
> is being executed in a closed system, it doesn't have access to 'machine
> addresses' and even if it had access to machine addresses, they couldn't
> be stored anywhere outside of main memory, hence, every object which
> presently can't be reached by following a chain of pointers in main
> memory cannot ever be used anymore".
The assumption works fine in practice and is implemented in many
programming languages. It is pretty much a non-issue.
(The assumption which *is* an issue is a different one, namely
the assumption that "all resources are internal memory objects of some kind,
and their recycling is not an externally visible event", which breaks
for things like open files.)
> An example where this assumption breaks down[*] would be the Linux epoll I/O
> multiplexing mechanism where the kernel stores a pointer to some
> userspace object such that it can be provided to the application if
> events on a certain file descriptor occur.
Two observations:
One is that dividing the system into kernel and user is the obsolete dinosaur
here. If a aystem is based on secure semantics from the ground up, you dont't
need this artificial barrier. Operating system objects and application
objects can all be in one address space.
Secondly, it's not difficult to protect objects from the garbage collector
when necessary, in a general way.
> There are, of course, workarounds for such scenarios, as is wont to
There is basically one: put such objects into a big lookup structure,
in which an object can be a member with a multiplicity > 1 if necessary:
if it is inserted N times, it must be removed N times to be actualy gone. For
instance, a hash table associating each object with a refcount will serve
this purpose just fine. The garbage collector walks this structure and marks
all those objects as reachable.
All APIs which can smuggle pointers outside of the address space
can share this registry and no object type has to be modified to incorporate
a refcount.
------------------------------
Date: Wed, 13 Aug 2014 21:03:01 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <87a978i2dm.fsf@sable.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2014-08-13, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> While the motivations for this scheme were "reference counts can't be
>> used on our hardware" and "we don't need to implement this right now",
>> there's an underlying assumption which has also never been true since
>> the end of batch processing as universal computing model, namely, "code
>> is being executed in a closed system, it doesn't have access to 'machine
>> addresses' and even if it had access to machine addresses, they couldn't
>> be stored anywhere outside of main memory, hence, every object which
>> presently can't be reached by following a chain of pointers in main
>> memory cannot ever be used anymore".
>
> The assumption works fine in practice and is implemented in many
> programming languages. It is pretty much a non-issue.
It doesn't really work anywhere except when concertedly looking into
another direction. The reason for this is "It is wrong". Pointers are
ordinary data and can be kept anywhere where other data can be kept and
then 'suddenly reappear'.
[...]
>> An example where this assumption breaks down[*] would be the Linux epoll I/O
>> multiplexing mechanism where the kernel stores a pointer to some
>> userspace object such that it can be provided to the application if
>> events on a certain file descriptor occur.
>
> Two observations:
>
> One is that dividing the system into kernel and user is the obsolete dinosaur
> here. If a aystem is based on secure semantics from the ground up, you dont't
> need this artificial barrier. Operating system objects and application
> objects can all be in one address space.
Some people believe that emulating 'hardware memory protection' in
software is a good idea, hence, they could go 'back in time' to the point where the
assumption was less untrue. Practically, systems working in this way
have been 'obsolete' since the end of the 1970s.
But this is really a digression because this wouldn't even theoretically
solve the problem and I trust that you know that.
------------------------------
Date: Wed, 13 Aug 2014 01:51:33 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Sorting Keys in Tie::IxHash::Easy
Message-Id: <lse5qm$7a7$1@news.ntua.gr>
On 13/8/2014 12:00 ¦Ð¦Ì, Rainer Weikusat wrote:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>> On 12/8/2014 11:40 ¦Ì¦Ì, Rainer Weikusat wrote:
>>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>>
>>> [sort a hash]
>>>
>>>>>>
>>>>>>
>>>>>> accomplish this task directly
>>>>>>
>>>>
>>>> # An example that may help
>>>>
>>>>
>>>> use strict; use warnings; use feature 'say';
>>>>
>>>> my %hash = (
>>>> 'A1' => { c1 => 3, c2 => 2, c0 => 1 },
>>>> 'A2' => { a2 => 1, a0 => 2, a1 => 3 },
>>>> 'A0' => { b1 => 3, b0 => 2, b2 => 1 } );
>>>>
>>>> # sort by keys desc AND
>>>> # sort by subkeys asc AND
>>>> foreach my $key (sort {$b cmp $a} keys %hash)
>>>> {
>>>> foreach my $subkey (sort {$a cmp $b} keys %{$hash{$key}})
>>>> {
>>>> say "$key , $subkey , $hash{$key}->{$subkey}"
>>>> }
>>>> }
>>>>
>>>> say '--------------';
>>>>
>>>> # sort by keys asc AND
>>>> # sort by subvalues asc
>>>> foreach my $key (sort {$a cmp $b} keys %hash)
>>>> {
>>>> foreach my $subkey (sort {$hash{$key}->{$b} cmp $hash{$key}->{$a}}
>>>> keys %{$hash{$key}})
>>>> {
>>>> say "$key , $subkey , $hash{$key}->{$subkey}"
>>>> }
>>>> }
>>>
>>> This doesn't really 'sort a hash of hashes', it performs a specific
>>> operation on all key/value pairs which are members of an anonymous hash
>>> which itself a member of a 'top-level' hash. Assuming that it is OK to
>>> restrict the operation to hashes, ie, without dealing with hash-based
>>> objects (anonymous hashes blessed into some class) and hash-like objects
>>> (instances of a classes overloading %{}), a generalization of that could
>>> look like this:
>>>
>>> ----------------
>>> my %h = (
>>> c => {qw(c 3 b 2 a 1)},
>>> b => {qw(f 3 e 2 d 1)},
>>> a => {
>>> m => {qw(p 3 o 2 n 1)},
>>> l => {qw(t 3 s 2 r 1)}}
>>> );
>>>
>>> sub traverse_sorted
>>> {
>>> my ($h, $cb, @ks) = @_;
>>> my $v;
>>>
>>> for (sort(keys(%$h))) {
>>> $v = $h->{$_};
>>> traverse_sorted($v, $cb, @ks, $_), next if ref($v) eq 'HASH';
>>> $cb->($v, @ks, $_);
>>> }
>>> }
>>>
>>> sub path_print
>>> {
>>> my ($v, @ks) = @_;
>>>
>>> print(join(',', @ks), "\t$v\n");
>>> }
>>>
>>> traverse_sorted(\%h, \&path_print);
>>>
>>
>>
>>
>> if you want to follow this path, then do it correctly using the
>> recursive data walker
>>
>> use Data::Rmap;
>> ...
>
> 'Correct' actually has a formal definition[*] and that's not 'includes
> every conceivable feature which is at least loosely/ theoretically'
> related to a given problem. [**]
>
> [**] Data::Rmap[***] is supposed to produce a list of values. The code above
> isn't.
>
> [***] And who told you that J. Random Abandonware would be correct just
> because J. Random Dontcareaboutthatanymore dumped it (and his very
> important name) on a publically accessible web server?
>
> [*] As translation from German (which might or might not make sense in
> English), this would be "code is said to be correct if the
> postconditions will be true after execution provided the preconditions
> were true before execution started and the invariant conditions remained
> true during execution". It follows that every given code can be 'proven
> correct' or 'proven incorrect' by inventing suitable condition sets.
>
# here is an idea of traversing the values
rmap_to {
if ('HASH' eq ref $_)
{
foreach my $k (sort keys %{$_})
{
print "$k $_->{$k}\n" unless ref $_->{$k}
}
}
} HASH, \%h;
------------------------------
Date: Tue, 12 Aug 2014 21:26:21 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Sorting Keys in Tie::IxHash::Easy
Message-Id: <lsepe7$iej$1@speranza.aioe.org>
On 8/12/2014 9:50 AM, Ben Switala wrote:
> I meant to say, "I think at that point I realized I was dealing with a hash of hashes"
>
> ...
>> Today I'm simply trying to print out the hash of hashes that I have, and find out what
>> various kinds of sorting (i.e. sorting the "inner keys" versus
sorting the "outer keys"
>>versus sorting both) would look like.
>> ...
One quick way to print out the hash sorted:
use Clone qw(clone);
use Data::Dumper;
use feature 'say';
tie my %h, 'Tie::IxHash::Easy';
...
$Data::Dumper::Sortkeys= 1;
say Dumper( clone(\%h) );
--
Charles DeRykus
------------------------------
Date: Wed, 13 Aug 2014 16:36:18 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Sorting Keys in Tie::IxHash::Easy
Message-Id: <874mxgjtal.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 13/8/2014 12:00 ¦Ð¦Ì, Rainer Weikusat wrote:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>> On 12/8/2014 11:40 ¦Ì¦Ì, Rainer Weikusat wrote:
>>>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>>>
>>>> [sort a hash]
>>>>
>>>>>>>
>>>>>>>
>>>>>>> accomplish this task directly
>>>>>>>
>>>>>
>>>>> # An example that may help
>>>>>
>>>>>
>>>>> use strict; use warnings; use feature 'say';
>>>>>
>>>>> my %hash = (
>>>>> 'A1' => { c1 => 3, c2 => 2, c0 => 1 },
>>>>> 'A2' => { a2 => 1, a0 => 2, a1 => 3 },
>>>>> 'A0' => { b1 => 3, b0 => 2, b2 => 1 } );
>>>>>
>>>>> # sort by keys desc AND
>>>>> # sort by subkeys asc AND
>>>>> foreach my $key (sort {$b cmp $a} keys %hash)
>>>>> {
>>>>> foreach my $subkey (sort {$a cmp $b} keys %{$hash{$key}})
>>>>> {
>>>>> say "$key , $subkey , $hash{$key}->{$subkey}"
>>>>> }
[...]
>>>> sub traverse_sorted
>>>> {
>>>> my ($h, $cb, @ks) = @_;
>>>> my $v;
>>>>
>>>> for (sort(keys(%$h))) {
>>>> $v = $h->{$_};
>>>> traverse_sorted($v, $cb, @ks, $_), next if ref($v) eq 'HASH';
>>>> $cb->($v, @ks, $_);
[Download Data::RMap instead!]
> # here is an idea of traversing the values
>
> rmap_to {
> if ('HASH' eq ref $_)
> {
> foreach my $k (sort keys %{$_})
> {
> print "$k $_->{$k}\n" unless ref $_->{$k}
> }
> }
> } HASH, \%h;
Judging from the code, this will do something rather different from the
example I posted. In particular, it will dive into objects as if they
were passive containers and it will also find references to hashes in
objects which aren't themselves hashes, eg, process the content of an
array of hash references or, assuming a reference to a glob supposed to
be used as a file handle is found, it will also recurse into arrays or
hashes bound to the symbol table entry of the same name.
------------------------------
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 4266
***************************************
