[33082] in Perl-Users-Digest
Perl-Users Digest, Issue: 4358 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 00:09:20 2015
Date: Wed, 28 Jan 2015 21:09:05 -0800 (PST)
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, 28 Jan 2015 Volume: 11 Number: 4358
Today's topics:
Compare 2 Hash of Hashes using sub-hash values <fmassion@web.de>
Re: Compare 2 Hash of Hashes using sub-hash values <gravitalsun@hotmail.foo>
Re: Compare 2 Hash of Hashes using sub-hash values <ben.usenet@bsb.me.uk>
Re: Global, Local, Static <gravitalsun@hotmail.foo>
Multi-field sorting (general case) <hslee911@yahoo.com>
Re: Multi-field sorting (general case) <jurgenex@hotmail.com>
Re: Why are these brackets necessary? <hjp-usenet3@hjp.at>
Re: Why are these brackets necessary? <ben.usenet@bsb.me.uk>
Re: Why are these brackets necessary? <see.my.sig@for.my.address>
Re: Why are these brackets necessary? <see.my.sig@for.my.address>
Re: Why are these brackets necessary? <rweikusat@mobileactivedefense.com>
Re: Why are these brackets necessary? <hjp-usenet3@hjp.at>
Re: Why are these brackets necessary? <rweikusat@mobileactivedefense.com>
Re: Why are these brackets necessary? <bauhaus@futureapps.invalid>
Re: Why are these brackets necessary? <hjp-usenet3@hjp.at>
Re: Why are these brackets necessary? <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 28 Jan 2015 01:56:02 -0800 (PST)
From: F Massion <fmassion@web.de>
Subject: Compare 2 Hash of Hashes using sub-hash values
Message-Id: <a87a7bbf-5b95-4c3f-a501-a2bc7ecf79a7@googlegroups.com>
I am not particularly good at Perl and do not get any further with the following:
I want to compare 2 relatively large tables with tab-separated columns which I have imported each in a Hash of Hashes.
File #1:
RecordID Name Language Status
715 surface technology English
763 mineral abrasive English validated
796 Zinkstaubgrundierung German validated
File #2:
RecordID Name Language Status
763 mineral abrasive English not validated
813 2-component prime coat English not validated
815 finishing coat English
I would like to use the value of certain columns to find out what are the differences or the common entries between these 2 files.
My questions are (see comment in code):
(1) Why do I lose the variables from the 2 HoHs after I have read them (i.e. I cannot re-use $RecordID or $Name...)
(2) How can I access only certain variables from my table (to compare or print), e.g. $Language or $Status
This is my code:
#!/usr/bin/perl -w
use warnings; use strict;
open(FIRSTFILE, $ARGV[0]) || die("file $ARGV[0] cannot be opened!\n");
my %Firstfile = ();
while (<FIRSTFILE>)
{
chomp;
my ($RecordID, $Name, $Language, $Status) = split ('\t');
$Firstfile{$RecordID}{'Name'} = $Name;
$Firstfile{$RecordID}{'Language'} = $Language;
$Firstfile{$RecordID}{'Status'} = $Status;
print "$RecordID -- $Firstfile{$RecordID}{'Name'} :: $Firstfile{$RecordID}{'Language'}\n" ;
}
open(SECONDFILE, $ARGV[1]) || die("file $ARGV[1] cannot be opened!\n");
my %Secondfile = ();
while (<SECONDFILE>)
{
chomp;
my ($RecordID, $Name, $Language, $Status) = split ('\t');
$Secondfile{$RecordID}{'Name'} = $Name;
$Secondfile{$RecordID}{'Language'} = $Language;
$Secondfile{$RecordID}{'Status'} = $Status;
print "$RecordID -- $Secondfile{$RecordID}{'Name'} :: $Secondfile{$RecordID}{'Status'}\n";
}
#QUESTIONS
#(1) Why do I lose the variables from the 2 loops above? I.e. I cannot re-use $RecordID or $Name...
#(2) How can I access only certain variables from my table (to compare or print), e.g. $Language or $Status
my $innerkey;
my $outerkey;
foreach $innerkey ( keys %Firstfile ) {
if ($Firstfile{$innerkey}{'Status'} ne $Secondfile{$innerkey}{'Status'}){
print "$innerkey:\:" ;
foreach $outerkey ( keys %{$Firstfile{$innerkey}} ) {
print "$Firstfile{$innerkey}{$outerkey}::" ;
}
print "\n" ;
}}
close FIRSTFILE;
close SECONDFILE;
__END__
CURRENT OUTPUT:
?RecordID -- Name :: Language
715 -- surface technology :: English
763 -- mineral abrasive :: English
796 -- Zinkstaubgrundierung :: German
RecordID -- Name :: Status
763 -- mineral abrasive :: not validated
813 -- 2-component prime coat :: not validated
815 -- finishing coat ::
Use of uninitialized value in string ne at D:\Perl\loeschen_2.pl line 31, <SECONDFILE> line 4.
796::validated::German::Zinkstaubgrundierung::
763::validated::English::mineral abrasive::
Use of uninitialized value in string ne at D:\Perl\loeschen_2.pl line 31, <SECONDFILE> line 4.
715:: ::English::surface technology::
Use of uninitialized value in string ne at D:\Perl\loeschen_2.pl line 31, <SECONDFILE> line 4.
?RecordID::Status::Language::Name::
------------------------------
Date: Wed, 28 Jan 2015 17:12:28 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Compare 2 Hash of Hashes using sub-hash values
Message-Id: <maau7t$hl7$1@news.ntua.gr>
On 28/1/2015 11:56, F Massion wrote:
> I am not particularly good at Perl and do not get any further with the following:
> I want to compare 2 relatively large tables with tab-separated columns which I have imported each in a Hash of Hashes.
>
# done !
use Data::Dumper;$Data::Dumper::Sortkeys=1;
# Fill up the hashes
my %hash1;
my %hash2;
for my $k1 (1..100) {for('a'..'c') {$hash1{$k1}->{$_}=1}}
for my $k1 (1..100) {for('a'..'c') {$hash2{$k1}->{$_}=1}}
print "Hashes are ",
Dumper(\%hash1) eq Dumper(\%hash2) ? 'same':'different'
------------------------------
Date: Thu, 29 Jan 2015 01:20:27 +0000
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Compare 2 Hash of Hashes using sub-hash values
Message-Id: <87bnli8js4.fsf@bsb.me.uk>
F Massion <fmassion@web.de> writes:
> I am not particularly good at Perl and do not get any further with the
> following: I want to compare 2 relatively large tables with
> tab-separated columns which I have imported each in a Hash of Hashes.
>
> File #1:
> RecordID Name Language Status
> 715 surface technology English
> 763 mineral abrasive English validated
> 796 Zinkstaubgrundierung German validated
>
> File #2:
> RecordID Name Language Status
> 763 mineral abrasive English not validated
> 813 2-component prime coat English not validated
> 815 finishing coat English
>
> I would like to use the value of certain columns to find out what are
> the differences or the common entries between these 2 files.
<snip>
> This is my code:
> #!/usr/bin/perl -w
> use warnings; use strict;
> open(FIRSTFILE, $ARGV[0]) || die("file $ARGV[0] cannot be opened!\n");
> my %Firstfile = ();
> while (<FIRSTFILE>)
> {
> chomp;
> my ($RecordID, $Name, $Language, $Status) = split ('\t');
> $Firstfile{$RecordID}{'Name'} = $Name;
> $Firstfile{$RecordID}{'Language'} = $Language;
> $Firstfile{$RecordID}{'Status'} = $Status;
> print "$RecordID -- $Firstfile{$RecordID}{'Name'} :: $Firstfile{$RecordID}{'Language'}\n" ;
> }
> open(SECONDFILE, $ARGV[1]) || die("file $ARGV[1] cannot be opened!\n");
> my %Secondfile = ();
> while (<SECONDFILE>)
> {
> chomp;
> my ($RecordID, $Name, $Language, $Status) = split ('\t');
> $Secondfile{$RecordID}{'Name'} = $Name;
> $Secondfile{$RecordID}{'Language'} = $Language;
> $Secondfile{$RecordID}{'Status'} = $Status;
> print "$RecordID -- $Secondfile{$RecordID}{'Name'} :: $Secondfile{$RecordID}{'Status'}\n";
> }
> #QUESTIONS
> #(1) Why do I lose the variables from the 2 loops above? I.e. I cannot
> re-use $RecordID or $Name...
These are declared as local variables inside the body of the loop. You
do that because you don't want the variables to be available outside.
You could more the declaration to outside the loop, but why? What do
you want them for?
> #(2) How can I access only certain variables from my table (to compare
> or print), e.g. $Language or $Status
I don't understand "variables from my table". The table contains data
which you access using keys, and the code shows you know how to do this.
Can you give an example of what you want to to do and how you tried to
do it?
> my $innerkey;
> my $outerkey;
> foreach $innerkey ( keys %Firstfile ) {
> if ($Firstfile{$innerkey}{'Status'} ne $Secondfile{$innerkey}{'Status'}){
> print "$innerkey:\:" ;
> foreach $outerkey ( keys %{$Firstfile{$innerkey}} ) {
> print "$Firstfile{$innerkey}{$outerkey}::" ;
> }
> print "\n" ;
> }}
> close FIRSTFILE;
> close SECONDFILE;
<snip>
--
Ben.
------------------------------
Date: Tue, 27 Jan 2015 16:14:07 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Global, Local, Static
Message-Id: <ma86eg$gat$1@news.ntua.gr>
> So.... any way of doing that in Perl subroutines?
>
>
use feature qw/say state/;
&f1, sleep 1 for 1..3;
sub f1 {
my $var_normal = scalar localtime time;
state $var_persistant = scalar localtime time;
say "\$var_normal : $var_normal";
say "\$var_persistant : $var_persistant" }
# also you may like the
# use constant PI => 3.14;
# say PI ;
------------------------------
Date: Wed, 28 Jan 2015 17:50:39 -0800 (PST)
From: James <hslee911@yahoo.com>
Subject: Multi-field sorting (general case)
Message-Id: <209f688e-e03c-4c35-a551-11d55413f78f@googlegroups.com>
The goal is to sort by multiple fields. Got an idea from other post.
my-prog 0 1n 2
=> first alphabetically field-0, then numerically field-1, then alphabetically field-3
(1n means field-1 is numerically sorted)
See code below.
How can I generalize this for arbitrary N-fields? For example, for N=4 (0,1,2,3),
my-prog 2 3n 0 1n
etc.
(3 fields, hard-coded case)
==============================================
$re[$_] = qr/^(?:\S+\s+){$_}(\S+)/ for 0..2;
for (sort { ($a=~/$re[0]/)[0] cmp ($b=~/$re[0]/)[0] or
($a=~/$re[1]/)[0] <=> ($b=~/$re[1]/)[0] or
($a=~/$re[2]/)[0] cmp ($b=~/$re[2]/)[0] } <DATA> ) { print; }
__DATA__
yy 7 perl
xx 101 hello
yy 33 world
xx 33 world
yy 101 hello
yy 7 hello
===============================================
Output:
xx 33 world
xx 101 hello
yy 7 hello
yy 7 perl
yy 33 world
yy 101 hello
James
------------------------------
Date: Wed, 28 Jan 2015 18:24:46 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Multi-field sorting (general case)
Message-Id: <t36jcah64jn87tkhcoke5jkd47rmv8qbas@4ax.com>
James <hslee911@yahoo.com> wrote:
>The goal is to sort by multiple fields. Got an idea from other post.
>
>my-prog 0 1n 2
>=> first alphabetically field-0, then numerically field-1, then alphabetically field-3
>(1n means field-1 is numerically sorted)
>See code below.
>
>How can I generalize this for arbitrary N-fields? For example, for N=4 (0,1,2,3),
>my-prog 2 3n 0 1n
Perl's sort() is stable. That means if you have a sorted array A1 and
you sort if again by a new criteria, then those elements which have the
same priority by the new criteria will among themself stay in the old
order as previously established in A1.
Therefore all you have to do is to loop over your criteria, one after
the other, as many as you like, starting with the least significant.
jue
------------------------------
Date: Tue, 27 Jan 2015 17:03:36 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Why are these brackets necessary?
Message-Id: <slrnmcfdmp.k8h.hjp-usenet3@hrunkner.hjp.at>
On 2015-01-27 12:06, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Robbie Hatley <see.my.sig@for.my.address> writes:
>> But wait, this is starting to look like a cyclic Abelian
>> group. It's screaming "use modular arithmetic" at 120dB.
>> But how? This is tricky because of the 12s. Hmmm. AH! Yes:
>>
>> $hour=($L_hour-1)%12+1;
>
> Yes, I thought of suggesting that, but not all languages choose the same
> meaning for % with negative numbers so I've learned to be wary of it in
> such situations (and I was too lazy to read the documentation). But,
> having now read it, I'd say it is arguably best avoided for negative
> operands. Perl defines % exactly as you want it *except* that a "use
> integer" declaration will switch it to a less well-defined meaning,
I don't think I have ever used 'use integer' except in test programs. As
such I would rather suggest "avoid 'use integer'" than "avoid % with a
negative first operand", given that Perl (unlike C) actually defines
the result.
In C (or Perl if you don't trust the docs) I have often found it
convenient to add the modulus to force the first operand to be positive.
I.e., instead of
(a - b) % n
write
(a + (n - b)) % n
So the code above would be changed to:
$hour=($L_hour+(12-1))%12+1;
or
$hour=($L_hour+11)%12+1;
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: Tue, 27 Jan 2015 22:15:39 +0000
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Why are these brackets necessary?
Message-Id: <87oapjdg50.fsf@bsb.me.uk>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2015-01-27 12:06, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Robbie Hatley <see.my.sig@for.my.address> writes:
>>> But wait, this is starting to look like a cyclic Abelian
>>> group. It's screaming "use modular arithmetic" at 120dB.
>>> But how? This is tricky because of the 12s. Hmmm. AH! Yes:
>>>
>>> $hour=($L_hour-1)%12+1;
>>
>> Yes, I thought of suggesting that, but not all languages choose the same
>> meaning for % with negative numbers so I've learned to be wary of it in
>> such situations (and I was too lazy to read the documentation). But,
>> having now read it, I'd say it is arguably best avoided for negative
>> operands. Perl defines % exactly as you want it *except* that a "use
>> integer" declaration will switch it to a less well-defined meaning,
>
> I don't think I have ever used 'use integer' except in test programs. As
> such I would rather suggest "avoid 'use integer'" than "avoid % with a
> negative first operand", given that Perl (unlike C) actually defines
> the result.
Yes, I can see that, but I can't help feeling uneasy about code whose
meaning can be changed like this. I shall try to move my unease to "use
integer" and away form negative operands to %.
By the way, C does now define the result of % (in this case), but it
defines it the other way. Of course, due to the nature of the language,
there are probably enough programs using old versions of C that it's
worth being aware of the old problems.
> In C (or Perl if you don't trust the docs) I have often found it
> convenient to add the modulus to force the first operand to be positive.
> I.e., instead of
>
> (a - b) % n
>
> write
>
> (a + (n - b)) % n
>
> So the code above would be changed to:
>
> $hour=($L_hour+(12-1))%12+1;
> or
> $hour=($L_hour+11)%12+1;
That's a good point. Kind of obvious, but I'd overlooked it here or I
would have gone for % as the simplest and best option. Thanks.
--
Ben.
------------------------------
Date: Tue, 27 Jan 2015 16:21:33 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Why are these brackets necessary?
Message-Id: <mMudndyte_QQtlXJnZ2dnUVZ572dnZ2d@giganews.com>
On 01/27/2015 08:03 AM, Peter J. Holzer wrote:
> ... I have often found it convenient to add the modulus to
> force the first operand to be positive. I.e., instead of
>
> (a - b) % n
>
> write
>
> (a + (n - b)) % n
>
> So the code above would be changed to:
>
> $hour=($L_hour+(12-1))%12+1;
> or
> $hour=($L_hour+11)%12+1;
Ah, excellent thinking! Yep, going around the circle one more
time brings one back to effective the same point, one octave
up so to speak. And avoids any doubt as to what might happen
with negative numbers. Thanks for the tip!
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
https://www.facebook.com/robbie.hatley
------------------------------
Date: Tue, 27 Jan 2015 17:10:46 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Why are these brackets necessary?
Message-Id: <D_CdnZWihcyKqlXJnZ2dnUVZ572dnZ2d@giganews.com>
On 01/27/2015 05:50 AM, Rainer Weikusat wrote:
> > my $hour = ($L_hour-1)%12+1;
>
> This can also be expressed as
>
> $L_hour % 12 || 12
That works. But I think I prefer
my $hour = ($L_hour + 11) % 12 + 1;
because it's purely formulaic rather than (a or b).
> > my $meri = ('AM','PM')[$L_hour/12];
>
> and this as
>
> ('AM', 'PM')[$L_hour > 12]
Well, almost. Actually, would have to be:
$my $meri = ('AM', 'PM')[$L_hour > 11];
because any time over "11:59:59" on the 24HR scale is PM.
(12:00:00AM is midnight, 12:00:00PM is noon.)
>
> or
>
> qw(AM PM)[$L_hour > 12]
Actually,
qw(AM PM)[$L_hour > 11]
but yep, that's pretty clean.
> or (what I'd prefer without having tested what's
> faster as it shouldn't really matter here)
>
> $L_hour > 12 ? 'PM' : 'AM;
The 12 needs to be 11, but yep, I like that one best
because it's the most concise, and avoids the floating-point
calculations of my original version.
Or better yet, put the AM and PM in the correct order:
my $meri = $L_hour < 12 ? 'AM' : 'PM';
I'll put that version in my script.
> As a curiosity,
>
> $L_hour > 12 && 'PM' || 'AM'
Actually,
$L_hour > 11 && 'PM' || 'PM'
or
$L_hour < 12 && 'AM' || 'PM'
That's cool, but I'd be tempted to write it using the
low-precedence operators because it looks more like
idiomatic English:
my $meri = $L_hour < 12 and 'AM' or 'PM';
I gotta love how Perl phrases things:
GoToMemphis and PlayTheBlues or die "heartbroken";
:-)
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
https://www.facebook.com/robbie.hatley
------------------------------
Date: Wed, 28 Jan 2015 01:29:11 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Why are these brackets necessary?
Message-Id: <877fw7itg8.fsf@doppelsaurus.mobileactivedefense.com>
Robbie Hatley <see.my.sig@for.my.address> writes:
[...]
>> ('AM', 'PM')[$L_hour > 12]
>
> Well, almost. Actually, would have to be:
> $my $meri = ('AM', 'PM')[$L_hour > 11];
> because any time over "11:59:59" on the 24HR scale is PM.
> (12:00:00AM is midnight, 12:00:00PM is noon.)
Without claiming to have any expert knowledge on this: Why does it count
12 - 1 - 2 ... - 11 instead of 1 - 2 ... - 12?
------------------------------
Date: Wed, 28 Jan 2015 08:25:18 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Why are these brackets necessary?
Message-Id: <slrnmch3mu.qia.hjp-usenet3@hrunkner.hjp.at>
On 2015-01-27 22:15, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
>> On 2015-01-27 12:06, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Yes, I thought of suggesting that, but not all languages choose the same
>>> meaning for % with negative numbers so I've learned to be wary of it in
>>> such situations (and I was too lazy to read the documentation). But,
>>> having now read it, I'd say it is arguably best avoided for negative
>>> operands. Perl defines % exactly as you want it *except* that a "use
>>> integer" declaration will switch it to a less well-defined meaning,
>>
>> I don't think I have ever used 'use integer' except in test programs. As
>> such I would rather suggest "avoid 'use integer'" than "avoid % with a
>> negative first operand", given that Perl (unlike C) actually defines
>> the result.
>
> Yes, I can see that, but I can't help feeling uneasy about code whose
> meaning can be changed like this. I shall try to move my unease to "use
> integer" and away form negative operands to %.
>
> By the way, C does now define the result of % (in this case), but it
> defines it the other way.
You are right. C99 and later define integer division as truncating
towards zero.
In C89 it was implementation-defined:
| If either operand is negative, whether the result of the / operator is
| the largest integer less than or equal to the algebraic quotient or
| the smallest integer greater than or equal to the algebraic quotient
| is implementation-defined, as is the sign of the result of the %
| operator.
> Of course, due to the nature of the language, there are probably
> enough programs using old versions of C that it's worth being aware of
> the old problems.
In this particular case I'm not worried about portability. I'm convinced
that the WG made the behaviour more strict because by 1999 there was no
hardware left that computed an integer division the other way.
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: Wed, 28 Jan 2015 12:03:31 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Why are these brackets necessary?
Message-Id: <87pp9z9koc.fsf@doppelsaurus.mobileactivedefense.com>
Robbie Hatley <see.my.sig@for.my.address> writes:
> On 01/27/2015 05:50 AM, Rainer Weikusat wrote:
>> > my $hour = ($L_hour-1)%12+1;
>>
>> This can also be expressed as
>>
>> $L_hour % 12 || 12
>
> That works. But I think I prefer
> my $hour = ($L_hour + 11) % 12 + 1;
> because it's purely formulaic rather than (a or b).
You're using a computer and it's not restricted to 'algebraic
expressions' supposed to enable formalization of everything but control
flow since 'control flow' is 'obviously' provided implicitly by 'a guy
working through the calculation(s) back to front'. Considering this,
a || b
whose meaning is defined as 'Evaluate a. If the result counts as true,
return it. Otherwise, evaluate b and return the result' is as
'formulaic' as working around adverse properties of the the input data
with calculation tricks. 'Case distinction' is actually even a
mathematical concept, just one usually (meaning, wherever I encountered
it) expression in informal language.
The input data set is 0 .. 23. It can naively partitioned into three
subsets:
1. 0, needs to be mapped to 12
2. 1 .. 12, map to themselves
3. 13 .. 23, have to be mapped to 1 .. 11
But a more clever way of looking at this is this:
1. For the set 1 .. 11, 13 .. 23, x % 12 (x denoting a member of the
set) results in the desired number
2. For both 0 and 12, x % 12 == 0
Hence,
$L_hour % 12
deals with the first case and
|| 12
with the second. The complete expression
$Lhour % 12 || 12
expresses these two cases directly: Working around limitations in
the formal language with the help of 'strange transformations' is not
necessary because the formal language 'we' are using doesn't have these
limitations anymore.
I'm not argueing against "But I'm a fan of vintage algebra!" (Remember
the good old times when men where real mean and control only floweth
insofar they dit it!) but I prefer calling this spade a spade.
------------------------------
Date: Wed, 28 Jan 2015 14:06:12 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: Why are these brackets necessary?
Message-Id: <maamr4$61v$1@dont-email.me>
On 28.01.15 02:10, Robbie Hatley wrote:
> On 01/27/2015 05:50 AM, Rainer Weikusat wrote:
> > > my $hour = ($L_hour-1)%12+1;
> >
> > This can also be expressed as
> >
> > $L_hour % 12 || 12
>
> That works. But I think I prefer
> my $hour = ($L_hour + 11) % 12 + 1;
> because it's purely formulaic rather than (a or b).
Fortunately, there are not so many hours in the day;
otherwise, any computations involving + or - will
increase the risk of seeing strange results near
the numeric bounds ;-)
------------------------------
Date: Wed, 28 Jan 2015 21:06:49 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Why are these brackets necessary?
Message-Id: <slrnmcigap.efb.hjp-usenet3@hrunkner.hjp.at>
On 2015-01-28 01:29, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> Robbie Hatley <see.my.sig@for.my.address> writes:
>>> ('AM', 'PM')[$L_hour > 12]
>>
>> Well, almost. Actually, would have to be:
>> $my $meri = ('AM', 'PM')[$L_hour > 11];
>> because any time over "11:59:59" on the 24HR scale is PM.
>> (12:00:00AM is midnight, 12:00:00PM is noon.)
>
> Without claiming to have any expert knowledge on this: Why does it count
> 12 - 1 - 2 ... - 11 instead of 1 - 2 ... - 12?
My guess is "we don't do that newfangled 'zero' thing over here."
Hours have been counted from 1 to 12 for a pretty long time (since
Babylonian times, but there were large variations until at least the
middle ages - stuff like "there are 4 watches from dusk till dawn and 12
hours from dawn till dusk"). The way to count them was (and is) the same
as for birthdays and anniversaries: 1 o'clock is at the end of the first
hour after midnight or noon, just like your first birthday is at the end
of the first year of your life. So the hours *are* counted from 1 to 12
and 12 is the end of the period. Not a problem as long as you refer to
fractional hours by relative terms like "a quarter past 3". But at some
time (I'm too lazy to research that, but I guess sometime in the 19th
century for train schedules) somebody invented the hh:mm notation to
denote "mm minutes after hh o'clock". And of course 12:15 *is* 15
minutes after 12 o'clock, and there is no "zero o'clock" in colloquial
English. Mathematically, it's a lot more convenient to write times
in the first hour as 00:mm (just like you write times in the second hour
as 01:mm and more generally times in the n'th hour as (n-1):mm), but you
don't expect mathematical convenience from a people which chooses one
length unit to be 1760 times the next smaller one, do you?
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: Wed, 28 Jan 2015 12:27:38 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Why are these brackets necessary?
Message-Id: <75hica53899m8722o9ojubamf6alsgkbg4@4ax.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>[...] but you
>don't expect mathematical convenience from a people which chooses one
>length unit to be 1760 times the next smaller one, do you?
A little while ago I had to take a test where one question after a long
detour at the end came down to how many feet are 5/12 of one statute
mile.
How on earth would I possibly know how many feet are in one statute
mile? Well, at least I knew that one foot is close to 30cm and one mile
close to 1600m.
So a quick computation 1mile * 1600m/mile * 5/12 * (1/0.3)feet/m got me
a number that was close enough to select the correct multiple choice
answer.
"Die spinnen, die Roemer"
jue
------------------------------
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 4358
***************************************
