[32995] in Perl-Users-Digest
Perl-Users Digest, Issue: 4271 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 17 14:09:18 2014
Date: Sun, 17 Aug 2014 11: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: 4271
Today's topics:
New topic: time flow simulation <gamo@telecable.es>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <rweikusat@mobileactivedefense.com>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <whynot@pozharski.name>
Re: Perl bug ; <gamo@telecable.es>
Re: Sorting Keys in Tie::IxHash::Easy <rweikusat@mobileactivedefense.com>
Re: Sorting Keys in Tie::IxHash::Easy <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 17 Aug 2014 20:06:26 +0200
From: gamo <gamo@telecable.es>
Subject: New topic: time flow simulation
Message-Id: <lsqqvl$mf8$1@speranza.aioe.org>
I consider two scenarios for 1 week planning.
#!/usr/bin/perl -w
use Time::HiRes qw(time);
$t0 = time;
for my $day (0..6){
for my $hour (0..23){
for my $minute (0..59){
for my $second (0..59){
for my $milisecond (0..999){
$timer++;
}
}
}
}
}
print "$timer\n";
$t1 = time;
$days=$hours=$minutes=$seconds=$timer=0;
while (1){
$timer++;
$miliseconds = $timer;
if ($miliseconds % 1000 ==0) {
$miliseconds =0;
$seconds++;
if ($seconds % 60 ==0) {
$seconds =0;
$minutes++;
if ($minutes % 60 ==0) {
$minutes =0;
$hours++;
if ($hours % 24 ==0) {
$hours =0;
$days++;
if ($days % 7 ==0) {
last;
}
}
}
}
}
}
print "$timer\n";
$t2 = time;
print "Time with loops is ", $t1-$t0, " s \n";
print "Time with if's is ", $t2-$t1, " s \n";
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sun, 17 Aug 2014 09:25:30 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnlv0m7a.qjg.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-16 15:23, Jürgen Exner <jurgenex@hotmail.com> wrote:
> "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.
No, time is continuous[1]. The POSIX time_t type is an integer, but for
many real world applications you need finer resolution. For this
purpose, POSIX defines two fixed point representations of time: struct
timeval (seconds and microseconds) and struct timespec (seconds and
nanoseconds). It doesn't define a floating point representation of time,
but that doesn't mean that an application can't do that. When I have to
deal with times in Perl I almost always use a floating point format. It
is convenient (I can store it in a single scalar, I can perform normal
arithmetic, and Time::HiRes::time() even returns the time of the day as
an fp number) and I am aware of the limitations and I know that they
usually don't matter (I don't need a finer resolution than 0.24 µs) or
how to work around them (choose a zero point close to now).
But you missed my point. My point was that when measuring time (as
opposed to identifying an arbitrary point of time on a calendar) you
very rarely need a lot of precision. If you measure a process which
takes about an hour, does it matter whether it's 3456.789012 seconds or
3456.789013 seconds?
hp
[1] It may actually be quantized, but if it is, the quantum is less than
1E-35 seconds, so for any practical purposes it is continuous.
--
_ | 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 09:27:10 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnlv0mae.qjg.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-17 05:01, gamo <gamo@telecable.es> wrote:
> 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.
The good thing abour search engines is that you can look up any quotes
from movies, books, etc. if you don't recognize them.
This one is from Dirty Harry.
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 09:29:39 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnlv0mf3.qjg.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-16 18:17, Jürgen Exner <jurgenex@hotmail.com> wrote:
> My point is that your $eps is irrelevant.
It is certainly not irrelevant. If you are doing serious numerical
work, you have to consider how it propagates through your computation
and affects the result.
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 09:37:33 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnlv0mtt.qjg.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-16 16:47, gamo <gamo@telecable.es> wrote:
> 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.
>
> Search in my web something like analogic.pl
>
> Real world aplications with fails of floating point unties,
That sentence doesn't parse.
> there are a lot. I had one with a job shop scheduling problem.
With double precision floating point numbers you can schedule any job
over a year with 10 ns precision. Did you really have to schedule them
more precisely? Was the system even able to keep time with such
precision (normally system clocks are only accurate to a few
milliseconds). Alternatively, you could schedule jobs over 100 years to
1 µs. It you schedule a job for 2114, will it matter whether it starts
at 2114-08-17T09:36:35.1234567 or 2114-08-17T09:36:35.1234562?
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 10:31:23 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lspp9f$77f$1@speranza.aioe.org>
El 17/08/14 a las 09:37, Peter J. Holzer escribió:
>> there are a lot. I had one with a job shop scheduling problem.
> With double precision floating point numbers you can schedule any job
> over a year with 10 ns precision. Did you really have to schedule them
> more precisely? Was the system even able to keep time with such
> precision (normally system clocks are only accurate to a few
> milliseconds). Alternatively, you could schedule jobs over 100 years to
> 1 µs. It you schedule a job for 2114, will it matter whether it starts
> at 2114-08-17T09:36:35.1234567 or 2114-08-17T09:36:35.1234562?
>
> hp
I can't remember the problem in detail, but was related with simulated
time, that is, adding 1/60 many times. The problem was solved both
using sprintf() to round or using bignum with a certain precision.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sun, 17 Aug 2014 10:53:52 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lspqjk$9vs$1@speranza.aioe.org>
El 17/08/14 a las 10:31, gamo escribió:
> El 17/08/14 a las 09:37, Peter J. Holzer escribió:
>>> there are a lot. I had one with a job shop scheduling problem.
>
>> With double precision floating point numbers you can schedule any job
>> over a year with 10 ns precision. Did you really have to schedule them
>> more precisely? Was the system even able to keep time with such
>> precision (normally system clocks are only accurate to a few
>> milliseconds). Alternatively, you could schedule jobs over 100 years to
>> 1 µs. It you schedule a job for 2114, will it matter whether it starts
>> at 2114-08-17T09:36:35.1234567 or 2114-08-17T09:36:35.1234562?
>>
>> hp
>
> I can't remember the problem in detail, but was related with simulated
> time, that is, adding 1/60 many times. The problem was solved both
> using sprintf() to round or using bignum with a certain precision.
>
>
Ah! and the problem does not appear if only one task is scheduled,
the problem arises when two tasks which must be in tie (or not)
depends incorrectly in the criteria of the fp over a more correct
criteria (FIFO, i.e.).
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sun, 17 Aug 2014 11:14:31 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnlv0sjn.u80.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-17 08:31, gamo <gamo@telecable.es> wrote:
> El 17/08/14 a las 09:37, Peter J. Holzer escribió:
>>> there are a lot. I had one with a job shop scheduling problem.
>
>> With double precision floating point numbers you can schedule any job
>> over a year with 10 ns precision. Did you really have to schedule them
>> more precisely? Was the system even able to keep time with such
>> precision (normally system clocks are only accurate to a few
>> milliseconds). Alternatively, you could schedule jobs over 100 years to
>> 1 µs. It you schedule a job for 2114, will it matter whether it starts
>> at 2114-08-17T09:36:35.1234567 or 2114-08-17T09:36:35.1234562?
>>
>> hp
>
> I can't remember the problem in detail, but was related with simulated
> time, that is, adding 1/60 many times.
This can NOT be solved by using a longer binary floating point type.
1/60 cannot be represented in any binary floating point type, no matter
how many digits you have. Another 12 bits of precision may make the
error small enough that you won't notice it during testing, but it is
still there and might bite you in production.
> The problem was solved both using sprintf() to round or using bignum
> with a certain precision.
Counting ticks would probably have been a better solution. If you were
rounding it is unlikely that you needed more than 52 bits of precision.
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 11:52:45 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lspu21$hvq$1@speranza.aioe.org>
El 17/08/14 a las 11:14, Peter J. Holzer escribió:
>> The problem was solved both using sprintf() to round or using bignum
>> >with a certain precision.
> Counting ticks would probably have been a better solution. If you were
> rounding it is unlikely that you needed more than 52 bits of precision.
>
> hp
Probably if I rewrite now the problem, I use miliseconds as a integer
unit, and solve _after_ the problem of translate to a decimal
representation of time or a date-time encoding which is readable.
But, this needs to simulate time flow and do it as faster as it can.
If task A is processed, $timeA += $timeofprocess, but if task B is
waiting, I need to simulate time passing and checking i.e. for a empty
machine every each tick.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sun, 17 Aug 2014 13:46:04 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnlv15fv.iv.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-17 09:52, gamo <gamo@telecable.es> wrote:
> El 17/08/14 a las 11:14, Peter J. Holzer escribió:
>>> The problem was solved both using sprintf() to round or using bignum
>>> >with a certain precision.
>
>> Counting ticks would probably have been a better solution. If you were
>> rounding it is unlikely that you needed more than 52 bits of precision.
>
> Probably if I rewrite now the problem, I use miliseconds as a integer
> unit,
1/60 second is not an integral number of milliseconds. If you need for
some reason to represent 1/60 second exactly, you have the same problem
with a decimal fixed point representation as with a binary floating
point representation. Except that now the error is much larger:
60 × 17 ms - 1 s = 20 ms.
60 × 0.0166666666666666664353702032030923874117434024810791015625 s - 1 s ≅ 1.33 fs.
(× stands for repeated addition here)
(That's another pet peeve of mine: People claiming that binary floating
point is "not precise" and blindly replacing it with an integer or
(decimal) fixed point representation whithout understanding the math.)
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 17:03:11 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl bug ;
Message-Id: <87egwf2jeo.fsf@sable.mobileactivedefense.com>
Richard Nicholas <richardn@nospam.com> writes:
> In article <87mwb6olnf.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
> says...
>>
>> 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.
>
> Perl does not let you tell it if a scalar is an int or a float so
> what's going on here?
Devel::Peek::Dump will do this. Whats happens here type-wise is roughly
that $d starts out as scalar with an integer value. It acquires a
floating-point value when the division is performed. Since the
following subtraction is again an integer operation, the floating point
flags of the scalar are cleared and the integer value updated. This
integer value is then again converted to a floating point value for the
division and so on.
> Does Perl treat $d as an int whenever it can and use a float format
> only when it must?
Yes. That's not irrelevant here because the whole idea behind this is to
scale the values the calculation is performed with such that floating
point arithmetic can be avoided.
Integers also have an exact representation (within the limit available
by the number of bits) in floating-point format because every integer
can be expressed as a sum of powers of 2 and a floating-point numbers is
encode as 1 + a sum of negative powers of 2 times some power of
two. Logically, this amounts to doing a left-shift of the bits in the
significant until they're all 'above the point' (x * (2 ** n) == x <<
n).
------------------------------
Date: Sun, 17 Aug 2014 09:52:35 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <45n1v9htlhokskj75bqrn46hlbnrfp3t1v@4ax.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>On 2014-08-17 08:31, gamo <gamo@telecable.es> wrote:
>> El 17/08/14 a las 09:37, Peter J. Holzer escribió:
>>>> there are a lot. I had one with a job shop scheduling problem.
>>
>>> With double precision floating point numbers you can schedule any job
>>> over a year with 10 ns precision. Did you really have to schedule them
>>> more precisely? Was the system even able to keep time with such
>>> precision (normally system clocks are only accurate to a few
>>> milliseconds). Alternatively, you could schedule jobs over 100 years to
>>> 1 µs. It you schedule a job for 2114, will it matter whether it starts
>>> at 2114-08-17T09:36:35.1234567 or 2114-08-17T09:36:35.1234562?
>>
>> I can't remember the problem in detail, but was related with simulated
>> time, that is, adding 1/60 many times.
>
>This can NOT be solved by using a longer binary floating point type.
>1/60 cannot be represented in any binary floating point type, no matter
>how many digits you have. Another 12 bits of precision may make the
>error small enough that you won't notice it during testing, but it is
>still there and might bite you in production.
ACK!
On the other hand it can be trivially solved by using 1/60 of whatever
as the base unit and then simpy counting those 1/60 of whatever using
INT (or bigint if necessary for range). That would be 100% accurate.
>> The problem was solved both using sprintf() to round or using bignum
>> with a certain precision.
>
>Counting ticks would probably have been a better solution. If you were
>rounding it is unlikely that you needed more than 52 bits of precision.
Ah, ok, I guess that's what you meant by counting ticks.
But to do that Mr. gamo would have had to acknowledge that floating
point has inherent limitations by design.
jue
------------------------------
Date: Sun, 17 Aug 2014 10:01:30 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <dhn1v9hftii1tj4i0dt71mhja8souv2b0r@4ax.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>On 2014-08-16 15:23, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> "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.
>
>No, time is continuous[1]. The POSIX time_t type is an integer, but for
>many real world applications you need finer resolution.
Quite true.
But for those you can use 1/10 of a second or milliseconds or
nanoseconds as your base unit.
Clocks driven by GPS have an accuracy of about 50 nanoseconds. If you
need even finer resolution then we are talking about atomic clocks and a
whole different game anyway.
[Advantages of time in FP format snipped]
>I am aware of the limitations and I know that they
>usually don't matter (I don't need a finer resolution than 0.24 µs) or
>how to work around them (choose a zero point close to now).
And this is the key! _You_ are aware of the limitation and you know how
to determine if those limitations are relevant for your problem at hand
and how to avoid them if needed. Mr. gamo is not.
>But you missed my point. My point was that when measuring time (as
>opposed to identifying an arbitrary point of time on a calendar) you
>very rarely need a lot of precision. If you measure a process which
>takes about an hour, does it matter whether it's 3456.789012 seconds or
>3456.789013 seconds?
I agree 100%. That's why I included the little joke about the age of the
dinosaur skeleton.
jue
------------------------------
Date: Sun, 17 Aug 2014 10:13:14 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <hvn1v9175mav7ghecbmq6j962518kmnkm8@4ax.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>On 2014-08-16 18:17, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> My point is that your $eps is irrelevant.
>
>It is certainly not irrelevant. If you are doing serious numerical
>work, you have to consider how it propagates through your computation
>and affects the result.
Hmmm, yes and no. I guess I worded this poorly.
This particular value is useful to give you a very general idea of how
large a range your FP numbers will cover and as a measure to compare one
computer/compiler/library against another. Kind of a normative baseline.
But for your actual programming it is insufficient because the truly
relevant value of $eps will change with the magnitude of the other
numbers that are involved in your calculations.
If your largest FP number is one million, then your $eps will be roughly
10^-11 insteda of 10^-15. And if the largest number in calculation is
something like 10^12 then your $eps will be somewhere around one million
(assuming the original $eps as previously stated as ~10^-15).
That's what I meant with "irrelevant". But of course you are absolutely
right that you need to consider what the actual $eps value is for your
actual calculations and how it propagates in your application.
jue
------------------------------
Date: Sun, 17 Aug 2014 12:55:42 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Perl bug ;
Message-Id: <slrnlv0v0u.shf.whynot@orphan.zombinet>
with <lso7hv$5sd$1@speranza.aioe.org> gamo wrote:
> 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?
> Time is continuous, a real variable. A realistic film, made of a integer
> number of photograms, could serve to some purposes, others don't.
Schedule in frames. Sure thing, dealing with variable frame rate would
be PITA but it is same-balls-profile-view otherwise either.
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Sun, 17 Aug 2014 20:00:15 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lsqqk2$lkl$1@speranza.aioe.org>
El 17/08/14 a las 19:01, jurgenex@hotmail.com escribió:
> [Advantages of time in FP format snipped]
>> >I am aware of the limitations and I know that they
>> >usually don't matter (I don't need a finer resolution than 0.24 µs) or
>> >how to work around them (choose a zero point close to now).
> And this is the key!_You_ are aware of the limitation and you know how
> to determine if those limitations are relevant for your problem at hand
> and how to avoid them if needed. Mr. gamo is not.
>
How do you know of what am I capable or incapable?
We are family, friends or something?
You are the one that say that epsilon is irrelevant.
Do you think you are qualified?
*I* give you a 4/10 for the joke of the dinosaur.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sun, 17 Aug 2014 17:05:28 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Sorting Keys in Tie::IxHash::Easy
Message-Id: <87a9732jav.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 15/8/2014 11:26 ¦Ì¦Ì, George Mpouras wrote:
>>>
>>> I have to admit that I've no idea what you're talking about. AFAICT, the
>>> output is as expected/ intended.
>>>
>>> ?
>>>
>>
>> [k1d/k2c/0] p20
>> [k1d/k2c/1] p22
>> [k1d/k2c/2] p23
>>
>> At data there are not any 0 1 or 2 keys
>
> I mean if you change the
> walk($it->[$_], $cb, @rest, $_) for 0 .. $#$data
> to
> walk($it->[$_], $cb, @rest) for 0 .. $#$data
> the result will be, which looks fine.
I intentionally included the array indices, too.
------------------------------
Date: Sun, 17 Aug 2014 17:21:43 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Sorting Keys in Tie::IxHash::Easy
Message-Id: <8761hr2ijs.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 15/8/2014 11:26 ¦Ì¦Ì, George Mpouras wrote:
>
> The following equivelant syntax is more familiar to me. It can written
> smaller but it become too much abstructed
>
>
> walk(\%data, sub {
> my ($data, @rest) = @_;
> printf('[%s] ', join('/', @rest)) if @rest;
> print("$data\n")
> });
>
> sub walk
> {
> my ($data, $cb) = (shift,shift);
>
> if ('ARRAY' eq ref $data)
> {
> walk($data->[$_], $cb, @_) for 0 .. $#$data
> }
> elsif ('HASH' eq ref $data)
> {
> walk($data->{$_}, $cb, @_, $_) for sort keys %$data
> }
> else
> {
> $cb->($data, @_)
> }
> }
Since this is a switching construct based on sequences of string
comparisons, it can be replaced with a hash lookup returning a reference
to a subroutine supposed to be executed. This means less code because
the explicit switching logic isn't needed anymore.
------------------------------
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 4271
***************************************
