[33085] in Perl-Users-Digest
Perl-Users Digest, Issue: 4361 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 2 05:17:22 2015
Date: Mon, 2 Feb 2015 02:17:07 -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 Mon, 2 Feb 2015 Volume: 11 Number: 4361
Today's topics:
Am I adding an unnecessary step? <jblack@nospam.com>
Re: Am I adding an unnecessary step? <hjp-usenet3@hjp.at>
Re: Am I adding an unnecessary step? <gravitalsun@hotmail.foo>
Re: Am I adding an unnecessary step? <gravitalsun@hotmail.foo>
Re: Am I adding an unnecessary step? <jurgenex@hotmail.com>
Re: Am I adding an unnecessary step? <jblack@nospam.com>
Re: Am I adding an unnecessary step? <jblack@nospam.com>
Re: Am I adding an unnecessary step? <jblack@nospam.com>
Re: Am I adding an unnecessary step? <rweikusat@mobileactivedefense.com>
Re: Am I adding an unnecessary step? <mvdwege@gmail.com>
Re: Global, Local, Static (was: Twelve Drummers Drummin (Tim McDaniel)
Re: Global, Local, Static <jblack@nospam.com>
Re: Global, Local, Static <rweikusat@mobileactivedefense.com>
Re: Global, Local, Static <rweikusat@mobileactivedefense.com>
Re: relative speed of regex vs split for splitting on w <ddomgn@gmail.com>
Re: relative speed of regex vs split for splitting on w <rweikusat@mobileactivedefense.com>
Re: Why are these brackets necessary? (Tim McDaniel)
Re: Why are these brackets necessary? <lionslair@consolidated.net>
Re: Why are these brackets necessary? <news@lawshouse.org>
Re: Why are these brackets necessary? (Tim McDaniel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 31 Jan 2015 16:26:58 -0600
From: John Black <jblack@nospam.com>
Subject: Am I adding an unnecessary step?
Message-Id: <MPG.2f37129a818e296a989812@news.eternal-september.org>
Not a big deal, big in the spirit of education, its bugging me a little so I thought I'd ask.
I have a bunch of arrays that define RGB color defininitions:
#Define Color RGB Values
@red = qw (255 000 000);
@blue = qw (000 000 255);
@green = qw (000 255 000);
@yellow = qw (255 255 000);
@white = qw (255 255 255);
@purple = qw (255 000 255);
@cyan = qw (000 255 255);
@gray = qw (175 175 175);
@orange = qw (255 140 000);
I have a plot routine that plots pixels given an x and y coordinate and a reference to one of
the color arrays. You call it as follows:
plot ($x, $y, $ref_to_color_array);
I have a string supplied by the user for what color they want a particular graph to be. That
string will match one of the color array names like $color = 'yellow';
I want to call the plot routine but I need a reference to the @yellow array given a string
equal to 'yellow'. My solution is simple enough. I create a hash mapping the string names
to array references:
%colors = (
red => \@red ,
blue => \@blue ,
green => \@green ,
yellow => \@yellow ,
white => \@white ,
pink => \@pink ,
cyan => \@cyan ,
gray => \@gray ,
orange => \@orange ,
);
allowing me to call plot as follows: plot($x, $y, $colors{$color});
But I can't help but feel that I should be able to eliminate that hash somehow since the name
of the array is the same as the string that points to it? Possible? Thanks.
John Black
------------------------------
Date: Sat, 31 Jan 2015 23:53:10 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <slrnmcqn6m.dr7.hjp-usenet3@hrunkner.hjp.at>
On 2015-01-31 22:26, John Black <jblack@nospam.com> wrote:
> I have a bunch of arrays that define RGB color defininitions:
>
> #Define Color RGB Values
> @red = qw (255 000 000);
> @blue = qw (000 000 255);
[...]
> I have a string supplied by the user for what color they want a
> particular graph to be. That string will match one of the color array
> names like $color = 'yellow';
>
> I want to call the plot routine but I need a reference to the @yellow
> array given a string equal to 'yellow'. My solution is simple enough.
> I create a hash mapping the string names to array references:
>
> %colors = (
> red => \@red ,
> blue => \@blue ,
[...]
> );
>
> allowing me to call plot as follows: plot($x, $y, $colors{$color});
>
> But I can't help but feel that I should be able to eliminate that hash
> somehow since the name of the array is the same as the string that
> points to it? Possible? Thanks.
Possible, yes, but bad style. You should do it the other way around and
get rid of the individual arrays:
%colors = (
red => [255, 0, 0],
blue => [ 0, 0, 255],
[...]
);
Rule of thumb: Every time you want to refer to a variable by name, you
should consider using a hash instead.
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, 01 Feb 2015 01:32:34 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <majonf$1ie9$1@news.ntua.gr>
On 1/2/2015 12:26 πμ, John Black wrote:
> @red = qw (255 000 000);
> @blue = qw (000 000 255);
> @green = qw (000 255 000);
use strict; use warnings;
our @red = qw (255 000 000);
our @blue = qw (000 000 255);
our @green = qw (000 255 000);
Foo( 'blue' );
sub Foo {
my @as_array = @{ $main::{$_[0]}};
my $as_ref = \@{ $main::{$_[0]}};
print "@as_array\n";
print "@{$as_ref}\n";
}
------------------------------
Date: Sun, 01 Feb 2015 01:43:30 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <majpbu$1k3v$1@news.ntua.gr>
# or if you do any OO then
our @red = qw (255 000 000);
# blah blah
my @as_array = eval '@{$'. __PACKAGE__ .'::{"red"}}';
my $as_ref = eval '\@{$'. __PACKAGE__ .'::{"red"}}';
print "@as_array\n";
print "@{$as_ref}\n";
# probably you could do easier using the module PadWalker
------------------------------
Date: Sat, 31 Jan 2015 15:53:43 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <4eqqcadfpkol9a6rpifq4o2infbf3h7vak@4ax.com>
John Black <jblack@nospam.com> wrote:
>Not a big deal, big in the spirit of education, its bugging me a little so I thought I'd ask.
>
>I have a bunch of arrays that define RGB color defininitions:
>
>#Define Color RGB Values
> @red = qw (255 000 000);
> @blue = qw (000 000 255);
> @green = qw (000 255 000);
[...]
Why not use a hash of arrays?
%colours = (
red => [255, 0, 0],
blue => [ 0, 0, 255],
green => [0, 255, 000],
[...]
);
>I want to call the plot routine but I need a reference to the @yellow array given a string
>equal to 'yellow'. My solution is simple enough. I create a hash mapping the string names
>to array references:
>
>allowing me to call plot as follows: plot($x, $y, $colors{$color});
Exactly that!
jue
------------------------------
Date: Sat, 31 Jan 2015 21:54:36 -0600
From: John Black <jblack@nospam.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <MPG.2f375f79a26b2c88989813@news.eternal-september.org>
In article <slrnmcqn6m.dr7.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
> %colors = (
> red => [255, 0, 0],
> blue => [ 0, 0, 255],
> [...]
> );
>
> Rule of thumb: Every time you want to refer to a variable by name, you
> should consider using a hash instead.
>
Duh. Yes, I like this. The [255, 0, 0] syntax automatically creates a reference to a list
so I don't even need the named arrays! Thanks.
John Black
------------------------------
Date: Sat, 31 Jan 2015 21:55:17 -0600
From: John Black <jblack@nospam.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <MPG.2f375f9df5e3b6cd989814@news.eternal-september.org>
In article <4eqqcadfpkol9a6rpifq4o2infbf3h7vak@4ax.com>, jurgenex@hotmail.com says...
> Why not use a hash of arrays?
> %colours = (
> red => [255, 0, 0],
> blue => [ 0, 0, 255],
> green => [0, 255, 000],
> [...]
> );
>
>
Yep, thanks!
John Black
------------------------------
Date: Sat, 31 Jan 2015 21:58:37 -0600
From: John Black <jblack@nospam.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <MPG.2f37606ba56c12a4989815@news.eternal-september.org>
In article <majpbu$1k3v$1@news.ntua.gr>, gravitalsun@hotmail.foo says...
>
> # or if you do any OO then
>
>
> our @red = qw (255 000 000);
>
> # blah blah
>
> my @as_array = eval '@{$'. __PACKAGE__ .'::{"red"}}';
> my $as_ref = eval '\@{$'. __PACKAGE__ .'::{"red"}}';
>
> print "@as_array\n";
> print "@{$as_ref}\n";
>
> # probably you could do easier using the module PadWalker
George, thanks for your solutions. I think the hash of list references is a cleaner
solution.
John Black
------------------------------
Date: Sun, 01 Feb 2015 20:58:29 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <87lhkhfix6.fsf@doppelsaurus.mobileactivedefense.com>
John Black <jblack@nospam.com> writes:
> In article <majpbu$1k3v$1@news.ntua.gr>, gravitalsun@hotmail.foo says...
>>
>> # or if you do any OO then
>>
>>
>> our @red = qw (255 000 000);
>>
>> # blah blah
>>
>> my @as_array = eval '@{$'. __PACKAGE__ .'::{"red"}}';
>> my $as_ref = eval '\@{$'. __PACKAGE__ .'::{"red"}}';
>>
>> print "@as_array\n";
>> print "@{$as_ref}\n";
>>
>> # probably you could do easier using the module PadWalker
>
> George, thanks for your solutions.
Simply using symbolic references, possibly after telling the compiler
that you want that, is a better idea than hacking around something
strict prohibits by default in this way:
----------------
use strict;
our @red = qw(255 0 0);
our @blue = qw(0 0 255);
sub print_rgb
{
no strict 'refs';
print(join(',', @{$_[0]}), "\n");
}
print_rgb('red');
print_rgb('blue');
------------------------------
Date: Mon, 02 Feb 2015 08:15:17 +0100
From: Mart van de Wege <mvdwege@gmail.com>
Subject: Re: Am I adding an unnecessary step?
Message-Id: <86bnlcu6m2.fsf@gaheris.avalon.lan>
John Black <jblack@nospam.com> writes:
> In article <slrnmcqn6m.dr7.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
>> %colors = (
>> red => [255, 0, 0],
>> blue => [ 0, 0, 255],
>> [...]
>> );
>>
>> Rule of thumb: Every time you want to refer to a variable by name, you
>> should consider using a hash instead.
>>
>
> Duh. Yes, I like this. The [255, 0, 0] syntax automatically creates
> a reference to a list
It's important to get this concept right: [ 255, 0, 0 ] does not create
a reference to a list; the square brackets take a list and return a
reference to an array.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Sun, 1 Feb 2015 20:57:20 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Global, Local, Static (was: Twelve Drummers Drumming)
Message-Id: <mam3vg$qnk$1@reader1.panix.com>
In article <Y8-dnRyg7ZTPwVrJnZ2dnUVZ57ydnZ2d@giganews.com>,
Robbie Hatley <see.my.sig@for.my.address> wrote:
>QUESTION: Are there any Perl-specific downsides to making
>variables global ($main::variable) that I should know about?
Package variables (I think that's the formal/pedantic name for "global
variables" in Perl) have their names in a symbol table and are
accessable by it and by typeglobs. See "man perlmod". Nowadays, this
is hardly done, but it's still a theoretical vulnerability. I don't
much understand this example though I cooked it up, but here it is:
$ cat local/test/136.pl
#! /usr/bin/perl
use warnings;
# NOT use strict;
$avar = 27;
print "<$avar>\n";
my $varname = 'avar';
print "symtab <", $main::{$varname}, ">\n";
$main::{$varname} = \73;
print "<$avar>\n";
exit 0;
$ perl local/test/136.pl
<27>
symtab <*main::avar>
<73>
BTW, it's not "packagename::" per se that makes a package variable. If
you don't have "use strict", then (1) you're a poopyhead and (2) any
use of an undeclared variable refers to a package variable. Maybe you
can understand "man perlmod" better than I can.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sat, 31 Jan 2015 16:08:24 -0600
From: John Black <jblack@nospam.com>
Subject: Re: Global, Local, Static
Message-Id: <MPG.2f370e539b9a833a989811@news.eternal-september.org>
In article <slrnmcp96s.jto.hjp-usenet3@hrunkner.hjp.at>, hjp-usenet3@hjp.at says...
>
> On 2015-01-30 22:44, John Black <jblack@nospam.com> wrote:
> > In article <87h9v9a60e.fsf@doppelsaurus.mobileactivedefense.com>,
> > rweikusat@mobileactivedefense.com says...
> >> > local => temporary value; revert when leave scope
> >>
> >> The important thing about local is that it creates a lexcially scoped
> >> binding for a dynamic symbol, eg,
>
> Hmm. I understand what you mean, but that's a rather confusing way of
> describing it.
>
>
> >> ---------
> >> our $master;
> >>
> >> sub servant
> >> {
> >> print("My master is $master\n");
> >> }
> >>
> >> sub mr_melon
> >> {
> >> local $master = "Mr Melon";
> >> servant();
> >> }
> >>
> >> sub general_duckhead
> >> {
> >> local $master = "General Duckhead";
> >> servant();
> >> }
> >>
> >> mr_melon();
> >> general_duckhead();
> >> ---------
> >
> > I don't really get how this is different from the case where $master
> > is global. If I remove the 'our $master' and remove the words
> > 'local', I get the exact same results.
>
> Change the last two lines to:
>
> $master = "nobody";
> servant();
> mr_melon();
> servant();
> general_duckhead();
> servant();
>
> and you will see the difference.
>
> >
> >> This can also be used to create a (localized) name for an anonymous
> >> object (by assigning the reference to that to the corresponding glob):
> >>
> >> ---------
> >> our @list;
> >>
> >> sub print_list
> >> {
> >> local *list = $_[0];
> >> print("$_\n") for @list;
> >> }
> >>
> >> print_list([1,2,3,4]);
> >> print_list([qw(a b c d)]);
> >
> > Again, I can easily pass a list to a subroutine and print it without
> > need for 'our' or 'local'. I'm missing what they are buying me...
>
> ?our? gives you global variables. Or rather it gives you a way to
> *declare* a global variable, since global variables are the default in
> Perl.
>
> ?local? gives you dynamically scoped local variables. Before ?my? was
> introduced, this was the only kind of local variables Perl had. So
> historically, the question wasn't ?why would we need ?local? when we
> already have ?my?? but the other way around - and the answer was of
> course that you can *see* the the scope of a lexically scoped variable on
> the screen, while you have to track calls to subroutines to determine
> the dynamic scope. So normally you use lexical scoping with ?my?.
>
> Still, ?local? is occasionally useful, for two reasons:
>
> * Perl has a ton of built-in global variables, which you might want to
> temporarily override. For example perldoc perlvar recommends to
> override $/ like this:
>
> my $content = '';
> open my $fh, "<", "foo" or die $!;
> {
> local $/;
> $content = <$fh>;
> }
> close $fh;
>
> At the closing brace, $/ reverts to the value it had before, so you
> don't have to worry about some other code which might use $/.
>
> * ?local? works on any lvalue, not just variables. So for example if I
> want to temporarily prevent DBI from throwing exceptions, I can do
> something like this:
>
> # $dbh->{AutoRaise} might be true or false here.
>
> {
> $local $dbh->{AutoRaise} = 0;
>
> # do something which might otherwise raise an exception and just
> # check the return value
> }
>
> # AutoRaise has the previous value again.
>
>
> hp
This makes a lot of sense. Thanks.
John Black
------------------------------
Date: Sun, 01 Feb 2015 20:50:32 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Global, Local, Static
Message-Id: <87vbjlfjaf.fsf@doppelsaurus.mobileactivedefense.com>
John Black <jblack@nospam.com> writes:
> rweikusat@mobileactivedefense.com says...
>> > local => temporary value; revert when leave scope
>>
>> The important thing about local is that it creates a lexcially scoped
>> binding for a dynamic symbol, eg,
>>
>> ---------
>> our $master;
>>
>> sub servant
>> {
>> print("My master is $master\n");
>> }
>>
>> sub mr_melon
>> {
>> local $master = "Mr Melon";
>> servant();
>> }
>>
>> sub general_duckhead
>> {
>> local $master = "General Duckhead";
>> servant();
>> }
>>
>> mr_melon();
>> general_duckhead();
>> ---------
>
> I don't really get how this is different from the case where $master
> is global. If I remove the 'our $master' and remove the words
> 'local', I get the exact same results.
The local documentation states that
A local modifies the listed variables to be local to the enclosing
block, file, or eval.
This isn't particularly clear, either. An explanation will need to make
a recourse to the history of LISP (Perl 5 is remarkably similar that):
In the beginning, LISP only supported so-called dynamic scoping: Every
'variable' had a name in the symbol table and all code could access it
by using this name. A construct called 'let' could be used to 'bind' new
value to a symbol for the evaluation of a certain expression (or set of
expressions), eg, assuming the following function definitions,
(defun e+1 () (1+ e))
(defun inc-5 ()
(let
((e 5))
(declare (special e))
(e+1)))
(the declare is necessary beause the 'default scoping mode' changed
meanwhile)
inc-5 evaluated e+1 with the value of e bound to 5 (hence, the result is
6). Based on inc-5, a function inc-6 can now be defined as
(defun inc-6 ()
(let
((e (inc-5)))
(declare (special e))
(e+1)))
and the result is actually 7, regardless of what other value may be
associated with the symbol e. This can directly be expressed in Perl,
as
sub inc_e { $e + 1 }
sub inc_5 { local $e = 5; inc_e; }
sub inc_6 { local $e = inc_5; inc_e; }
With the invention of Scheme, a different scoping model was introduced,
namely, so-called 'lexical scoping': A binding establised in a certain
expression is only accessible with the expression itself. That's what is
used when the declares are removed from the LISP code and the result of
evaluating e+1 then depends on whatever values was assigned/ bound to e
outside of the inc-5 and inc-6 functions. The Perl-equivalent is a
variable created via my whose name is not resolved to something by doing
a symbol table lookup but only exists in whatever the scope the my
happened.
The point of this was to show that local is not "some obsolete,
inferior way to do what is better done via my" but a genuinely different
feature: It binds a value to a name in the symbol table which is valid
until the end of the surrounding block and visible to all code executed
until then, either directly or indirectly.
Fairly elaborate nonsense program
---------------
our ($prep, $loc);
country_of_Assuan(in, [southern_desert, in, oasis, in, forest, in],
[capital, in,
[bridge_accross_the_river, at],
[river, accross, innn, at]],
[nothern_mountains, in,
[pass, at],
[pass, in, snowstorm, in]],
[border_plains, in, lake, at]);
country_of_Bezinat();
sub wanderer
{
print("I'm $prep the $loc\n");
}
sub refrep
{
my (@parts, $x);
for (@_) {
push(@parts, $_), next unless ref($_);
push(@parts, refrep(@$_));
}
return @parts > 1 ? '['.join(',', @parts).']' : $parts[0];
}
sub go
{
if (ref($_[0])) {
go(@$_) for @_;
return;
}
eval($_->[0].'('.$_->[1].','.refrep(@$_[2 .. $#$_]).')');
}
sub AUTOLOAD
{
my $l;
$l = $AUTOLOAD;
$l =~ s/^.*:://;
$l =~ tr/_/ /;
$l .= ' '."$prep the $loc" if $loc;
local $loc = $l;
local $prep = shift;
wanderer();
go($_) for @_;
}
--------------
>> This can also be used to create a (localized) name for an anonymous
>> object (by assigning the reference to that to the corresponding glob):
>>
>> ---------
>> our @list;
>>
>> sub print_list
>> {
>> local *list = $_[0];
>> print("$_\n") for @list;
>> }
>>
>> print_list([1,2,3,4]);
>> print_list([qw(a b c d)]);
>
> Again, I can easily pass a list to a subroutine and print it without
> need for 'our' or 'local'. I'm missing what they are buying me...
The 'our' exists here because it is IMHO good practice to declare
variables and for this case, the
local *list = $_[0]
means that the anonymous array $_[0] refers to can be accessed as @list
within this subroutine, just as if it wasn't an anymous array. I didn't
find this particularly useful so far but it may server to make the code
simpler as explicit dereferencing isn't needed anymore.
------------------------------
Date: Sun, 01 Feb 2015 23:27:50 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Global, Local, Static
Message-Id: <87vbjl5i15.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> eval($_->[0].'('.$_->[1].','.refrep(@$_[2 .. $#$_]).')');
This wandered here from AUTOLOAD and should of course be
eval($_[0].'('.$_[1].','.refrep(@_[2 .. $#_]).')');
in this context ...
------------------------------
Date: Sun, 1 Feb 2015 08:43:34 -0800 (PST)
From: Dmitry Davletbaev <ddomgn@gmail.com>
Subject: Re: relative speed of regex vs split for splitting on whitespace
Message-Id: <6666706e-06ac-4bc8-9024-7db780c9ee19@googlegroups.com>
On Friday, January 30, 2015 at 8:40:02 PM UTC+5, Rainer Weikusat wrote:
> A past posting by George Mpouras claimed that using the regex engine to
> split a line into fields would be much faster than using split (IIRC).
> Since I wanted to know if this is actually true, I wrote the following
> test program:
>=20
> -------------
> use Benchmark;
>=20
> use constant MAX_TOKENS =3D> 5;
> use constant MAX_TOKEN =3D> 10;
> use constant MAX_WS =3D> 1;
>=20
> use constant N_LINES =3D> 10;
>=20
> sub make_token
> {
> return 'A' x (rand(MAX_TOKEN) + 1);
> }
>=20
> sub make_sep
> {
> return ' ' x (rand(MAX_WS) + 1);
> }
>=20
> sub make_line
> {
> my $l;
>=20
> $l =3D make_token();
> $l .=3D make_sep().make_token() for 1 .. rand(MAX_TOKENS);
>=20
> return $l;
> }
>=20
> my @lines =3D map { make_line(); } 1 .. N_LINES;
>=20
> #print(map {$_, "\n" } @lines);
>=20
> timethese(-3,
> {
> split =3D> sub {
> my @a;
> @a =3D split for @lines;
> },
>=20
> regex =3D> sub {
> my @a;
> @a =3D /\S+/g for @lines;
> }});
> -------------
>=20
> At least for me, the result of running it was that split was always
> faster no matter what combination of line parameters I tried.
Hi Rainer!
Usually it's difficult to tell whether operation is handled faster with reg=
ular expressions or with split() (or another function). It highly depends o=
n regex implementation, the operation you're trying to perform, etc. Don't =
think about which solution is faster, just use what you are most familiar w=
ith. Then, if you have performance issues, dig into it and find the best so=
lution.
--
Dmitry Davletbaev
Software Developer
dmitry.davletbaev@maginfo.com
http://www.maginfo.com/
------------------------------
Date: Sun, 01 Feb 2015 21:06:13 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: relative speed of regex vs split for splitting on whitespace
Message-Id: <87h9v5fika.fsf@doppelsaurus.mobileactivedefense.com>
Dmitry Davletbaev <ddomgn@gmail.com> writes:
> On Friday, January 30, 2015 at 8:40:02 PM UTC+5, Rainer Weikusat wrote:
>> A past posting by George Mpouras claimed that using the regex engine to
>> split a line into fields would be much faster than using split (IIRC).
>> Since I wanted to know if this is actually true, I wrote the following
>> test program:
[code omitted]
> Hi Rainer!
>
> Usually it's difficult to tell whether operation is handled faster
> with regular expressions or with split() (or another function). It
> highly depends on regex implementation, the operation you're trying to
> perform, etc.
I hope you don't seriously believe that "the execution speed of Perl
builtins depends on their implementation" can be regarded as 'news' ...
------------------------------
Date: Sun, 1 Feb 2015 22:37:56 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Why are these brackets necessary?
Message-Id: <mam9s4$opg$1@reader1.panix.com>
In article <D_CdnZWihcyKqlXJnZ2dnUVZ572dnZ2d@giganews.com>,
Robbie Hatley <see.my.sig@for.my.address> wrote:
>because any time over "11:59:59" on the 24HR scale is PM.
>(12:00:00AM is midnight, 12:00:00PM is noon.)
A pedantic snot, like I am sometimes, will point out that some people,
especially in the past and/or knowing the Latin meanings of "ante
meridies" and "post meridies" (before midday and after midday), would
define "noon" as neither A.M. nor P.M. (The Chicago Manual of Style
notes that "M.", "meridies", 'midday', could be used, but few do. I
suspect most people would be bewildered or might think that an
abbreviation for "midnight"!)
http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight
has some discussion.
I think, though, that it is vastly more useful to do as you do and
call noon "12:00:00.000... P.M.", because then it's simple to deal
with "12:xx:xx P.M." all being a contiguous block of time just like
every other hour. So midnight would have to be 12 AM. I think that's
now the common convention.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 01 Feb 2015 21:48:32 -0600
From: Martin Eastburn <lionslair@consolidated.net>
Subject: Re: Why are these brackets necessary?
Message-Id: <msCzw.724820$W25.131896@fx02.iad>
On 2/1/2015 4:37 PM, Tim McDaniel wrote:
> In article <D_CdnZWihcyKqlXJnZ2dnUVZ572dnZ2d@giganews.com>,
> Robbie Hatley <see.my.sig@for.my.address> wrote:
>> because any time over "11:59:59" on the 24HR scale is PM.
>> (12:00:00AM is midnight, 12:00:00PM is noon.)
>
> A pedantic snot, like I am sometimes, will point out that some people,
> especially in the past and/or knowing the Latin meanings of "ante
> meridies" and "post meridies" (before midday and after midday), would
> define "noon" as neither A.M. nor P.M. (The Chicago Manual of Style
> notes that "M.", "meridies", 'midday', could be used, but few do. I
> suspect most people would be bewildered or might think that an
> abbreviation for "midnight"!)
> http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight
> has some discussion.
>
> I think, though, that it is vastly more useful to do as you do and
> call noon "12:00:00.000... P.M.", because then it's simple to deal
> with "12:xx:xx P.M." all being a contiguous block of time just like
> every other hour. So midnight would have to be 12 AM. I think that's
> now the common convention.
>
I always heard Meridian for M. But then Mom and Dad are old time
Chicago 'ites'.
Looks like we can call the clock a Base 11. 0 (not yet an hour)
1,2,3... 11 and it changes the Meridian (English) or 'meridies' (latin)
you have the 'noon' hour and begin 1,2,3...11 Meridian Midnight hour...
Martin :-)
------------------------------
Date: Mon, 02 Feb 2015 08:46:01 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Why are these brackets necessary?
Message-Id: <GbudnSYs2Z_NpFLJnZ2dnUVZ8t-dnZ2d@giganews.com>
On 02/02/15 03:48, Martin Eastburn wrote:
> Meridian Midnight hour
Doesn't scan!
--
Henry Law Manchester, England
------------------------------
Date: Mon, 2 Feb 2015 09:06:25 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Why are these brackets necessary?
Message-Id: <manemh$ev0$1@reader1.panix.com>
In article <slrnmcigap.efb.hjp-usenet3@hrunkner.hjp.at>,
Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
>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.
It's good to remember that that's current Western custom, but not
necessarily true around the world. In old Japanese tradition, and
according to http://en.wikipedia.org/wiki/East_Asian_age_reckoning in
East Asia generally, a child when born was in his first year, and a
year was added with the new year around 4 Februaryish. So TOKUGAWA
Ieyasu, born 31 January 1543, a few days after he was born turned 2,
or to be accurate, entered his second year.
(According to that article, everyone but Korea has pretty much gone to
the Western system.)
--
Tim McDaniel, tmcd@panix.com
------------------------------
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 4361
***************************************
