[32939] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4215 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 18 21:09:21 2014

Date: Sun, 18 May 2014 18:09:07 -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, 18 May 2014     Volume: 11 Number: 4215

Today's topics:
    Re: A question about grep <rweikusat@mobileactivedefense.com>
    Re: A question about grep <m@rtij.nl.invlalid>
    Re: A question about grep <rweikusat@mobileactivedefense.com>
    Re: A question about grep (Tim McDaniel)
        Correct design for parallel opening of sockets to remot <news@lawshouse.org>
    Re: Correct design for parallel opening of sockets to r <ben.usenet@bsb.me.uk>
    Re: Help with an operator precedence (?) puzzle <xhoster@gmail.com>
    Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
    Re: Help with an operator precedence (?) puzzle <derykus@gmail.com>
    Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
        perl and math <nospam@nspam.invalid>
    Re: perl and math <cartercc@gmail.com>
    Re: perl and math <nospam@nspam.invalid>
    Re: perl and math <nospam@nspam.invalid>
    Re: perl and math <gamo@telecable.es>
    Re: perl and math <hSoPrAsMt@raSdPnAeMrs.de>
    Re: perl and math <cartercc@gmail.com>
    Re: perl and math <nospam@nspam.invalid>
    Re: perl and math <nospam@nspam.invalid>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sun, 18 May 2014 19:21:06 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: A question about grep
Message-Id: <87bnuv0wz1.fsf@sable.mobileactivedefense.com>

"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-05-16 10:57, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>> 'Not' some string is not well documented, but seems to return an
>>> empty string if the string is not empty and 1 if the string is empty.
>>
>> ! is documented as 'returns the logical negation of its right operand'
>>   and perlsyn(1) states that
>>
>>      Truth and Falsehood
>>        The number 0, the strings '0' and '', the empty list "()", and
>>        "undef" are all false in a boolean context. All other values are
>>        true.  Negation of a true value by "!" or "not" returns a special
>>        false value.  When evaluated as a string it is treated as '', but
>>        as a number, it is treated as 0.
>>
>> How's that "not well documented"?
>
> It doesn't document what negation of a false value returns. (although I
> doubt that this is what Martijn meant, since it isn't specific to
> strings.)

The claim was "'Not' some string' is not well documented". The
documentation states that 'not' performs logical negation, quotes all
examples of string counting as 'false values' and states that any other
string counts as a 'true value'. That's not qualtiatively different from
the way other 'kinds' of values (eg, numbers) are treated in this
respect. Hence, it doesn't make sense to single out strings in this
respect and I, too, doubt that the original statement was supposed to be
a general "Perl is not well documented" (or event just "the ! operator
is not well documented") lament ...




------------------------------

Date: Sun, 18 May 2014 20:55:37 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: A question about grep
Message-Id: <9acn4b-cu1.ln1@news.rtij.nl>

On Fri, 16 May 2014 11:57:11 +0100, Rainer Weikusat wrote:

> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>> On Thu, 15 May 2014 23:27:36 -0700, Martin Lee wrote:
> 
> [...]
> 
> 
>>> PS:
>>> Could you tell me the mean of "! $HTTP::SimpleLinkChecker::ERROR;" in
>>> the last code? :)
>>
>> That variable is documented as a string, '!' is not. 'Not' some string
>> is not well documented, but seems to return an empty string if the
>> string is not empty and 1 if the string is empty.
> 
> ! is documented as 'returns the logical negation of its right operand'
>   and perlsyn(1) states that
> 
>      Truth and Falsehood
>        The number 0, the strings '0' and '', the empty list "()", and
>        "undef" are all false in a boolean context. All other values are
>        true.  Negation of a true value by "!" or "not" returns a special
>        false value.  When evaluated as a string it is treated as '', but
>        as a number, it is treated as 0.
> 
> How's that "not well documented"?

It did not occur to me to look in perlsyn. How is negation 'syntax'??

M4


------------------------------

Date: Sun, 18 May 2014 20:30:12 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: A question about grep
Message-Id: <8738g628cb.fsf@sable.mobileactivedefense.com>

Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Fri, 16 May 2014 11:57:11 +0100, Rainer Weikusat wrote:
>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>> On Thu, 15 May 2014 23:27:36 -0700, Martin Lee wrote:
>> 
>> [...]
>> 
>>>> PS:
>>>> Could you tell me the mean of "! $HTTP::SimpleLinkChecker::ERROR;" in
>>>> the last code? :)
>>>
>>> That variable is documented as a string, '!' is not. 'Not' some string
>>> is not well documented, but seems to return an empty string if the
>>> string is not empty and 1 if the string is empty.
>> 
>> ! is documented as 'returns the logical negation of its right operand'
>>   and perlsyn(1) states that
>> 
>>      Truth and Falsehood
>>        The number 0, the strings '0' and '', the empty list "()", and
>>        "undef" are all false in a boolean context. All other values are
>>        true.  Negation of a true value by "!" or "not" returns a special
>>        false value.  When evaluated as a string it is treated as '', but
>>        as a number, it is treated as 0.
>> 
>> How's that "not well documented"?
>
> It did not occur to me to look in perlsyn. How is negation 'syntax'??

IMO, this paragraph is misplaced and rather belongs to perlop (and it
should also, should document the result when negating a false value,
which happens to be a 'special truth value' whose numerical value is 1
and whose string value is '1'). But 'returns the logical negation of its
right operand' isn't terribly expressive on its own for other types,
either, eg, why shouldn't "the logical negation of 1" be "-1"?


------------------------------

Date: Sun, 18 May 2014 22:45:05 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: A question about grep
Message-Id: <llbd5h$stl$1@reader1.panix.com>

perlsyn:
Truth and Falsehood
  The number 0, the strings '0' and '', the empty list "()", and
  "undef" are all false in a boolean context. All other values are
  true.  Negation of a true value by "!" or "not" returns a special
  false value.  When evaluated as a string it is treated as '', but
  as a number, it is treated as 0.

In article <8738g628cb.fsf@sable.mobileactivedefense.com>,
Rainer Weikusat  <rweikusat@mobileactivedefense.com> wrote:
>should also, should document the result when negating a false value,
>which happens to be a 'special truth value' whose numerical value is
>1 and whose string value is '1').

I'm afraid I'm not following you.  The negation of a true value does
indeed have a slight difference from both normal '' and 0:

$ perl -e 'use warnings; use strict; my $x = ""; print($x + 5, "\n"); print ("($x)\n");'
Argument "" isn't numeric in addition (+) at -e line 1.
5
()

$ perl -e 'use warnings; use strict; my $x = !1; print($x + 5, "\n"); print ("($x)\n");'
5
()

But 1 or '1' has no such specialness: you can perform arithmetic with
either without a warning, for example, and each converts to the other
in the appropriate circumstances.  In what way is the value of !0 a
special value?

-- 
Tim McDaniel, tmcd@panix.com


------------------------------

Date: Sun, 18 May 2014 23:25:05 +0100
From: Henry Law <news@lawshouse.org>
Subject: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <HbudnUVo6rjQruTOnZ2dnUVZ8kqdnZ2d@giganews.com>

I have a Perl program design problem that I'm sure has been overcome 
before; it's just that with my level of ability with the language I 
can't see how to solve it.

My program will check the communications with (at least ten) hosts 
elsewhere on the network.  I can try to open a socket (using 
IO::Socket::INET) to each host in turn, using a port which I know is 
open (they're my hosts), and wait to see if it times out.  But each 
timeout will take at least one second, so all twelve machines will take 
at least twelve seconds: that's too long for the user to wait.

So I need to fork copies of the program, one for each host, and let them 
time out in parallel; my design problem is that I can't work out how to 
do that.  Here's my latest unsuccessful attempt, based on the example 
under heading "Safe Pipe Opens" in perlipc:

#! /usr/bin/perl
use strict;
use warnings;

my $hosts = [
	     { name=>'beta' }, { name=>'saturn', port=>80 }
	     ];  # Sample host data, in hashes since I need
                  # to add other data here later

for my $host ( @$hosts ) {
   my $child_pid;
   my $retries = 0;
   do {
     $child_pid = open( $host->{fh}, "-|" );
     unless ( defined $child_pid ) {
       die "Giving up on $host->{name}" if ++$retries>4;
       sleep 1;
     }
   } until defined $child_pid;

   if ( $child_pid ) {             # Parent
     my $fh = $host->{fh};
     while ( my $data = <$fh> ) {  # <$host->{fh}> is syntax error
       print "[Parent] Read '$data'\n";
     }
     close $host->{fh} ||
       warn "Child process for $host->{name} has exited: $?\n";
   }
   else {                          # Child
     my $delay = int(rand(10));
     warn "[child] Simulating $delay seconds delay in contacting host 
$host->{name}.\n";
     sleep $delay;
     print STDOUT "data for $host->{name}";  # Simulating the data returned
     warn "Child for $host->{name} finishing\n";
     exit;
   }
}

But the parent process still waits for each host in turn:

 ./checkhosts
[child] Simulating 3 seconds delay in contacting host beta.
Child for beta finishing
[Parent] Read 'data for beta'
[child] Simulating 1 seconds delay in contacting host saturn.
Child for saturn finishing
[Parent] Read 'data for saturn'

My head is spinning.  I wake up thinking about fork statements and 
zombie processes ... There's an easy answer to this; can someone help me 
find it?

-- 

Henry Law            Manchester, England


------------------------------

Date: Mon, 19 May 2014 01:55:31 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <0.cccd1a69515c906bc33a.20140519015531BST.874n0m37uk.fsf@bsb.me.uk>

Henry Law <news@lawshouse.org> writes:

> I have a Perl program design problem that I'm sure has been overcome
> before; it's just that with my level of ability with the language I
> can't see how to solve it.
>
> My program will check the communications with (at least ten) hosts
> elsewhere on the network.  I can try to open a socket (using
> IO::Socket::INET) to each host in turn, using a port which I know is
> open (they're my hosts), and wait to see if it times out.  But each
> timeout will take at least one second, so all twelve machines will
> take at least twelve seconds: that's too long for the user to wait.
>
> So I need to fork copies of the program, one for each host, and let
> them time out in parallel; my design problem is that I can't work out
> how to do that.  Here's my latest unsuccessful attempt, based on the
> example under heading "Safe Pipe Opens" in perlipc:
>
> #! /usr/bin/perl
> use strict;
> use warnings;
>
> my $hosts = [
> 	     { name=>'beta' }, { name=>'saturn', port=>80 }
> 	     ];  # Sample host data, in hashes since I need
>                  # to add other data here later
>
> for my $host ( @$hosts ) {
>   my $child_pid;
>   my $retries = 0;
>   do {
>     $child_pid = open( $host->{fh}, "-|" );
>     unless ( defined $child_pid ) {
>       die "Giving up on $host->{name}" if ++$retries>4;
>       sleep 1;
>     }
>   } until defined $child_pid;
>
>   if ( $child_pid ) {             # Parent
>     my $fh = $host->{fh};
>     while ( my $data = <$fh> ) {  # <$host->{fh}> is syntax error
>       print "[Parent] Read '$data'\n";
>     }
>     close $host->{fh} ||
>       warn "Child process for $host->{name} has exited: $?\n";
>   }
>   else {                          # Child
>     my $delay = int(rand(10));
>     warn "[child] Simulating $delay seconds delay in contacting host
> $host->{name}.\n";
>     sleep $delay;
>     print STDOUT "data for $host->{name}";  # Simulating the data returned
>     warn "Child for $host->{name} finishing\n";
>     exit;
>   }
> }
>
> But the parent process still waits for each host in turn:
>
> ./checkhosts
> [child] Simulating 3 seconds delay in contacting host beta.
> Child for beta finishing
> [Parent] Read 'data for beta'
> [child] Simulating 1 seconds delay in contacting host saturn.
> Child for saturn finishing
> [Parent] Read 'data for saturn'
>
> My head is spinning.  I wake up thinking about fork statements and
> zombie processes ... There's an easy answer to this; can someone help
> me find it?

You have one loop.  For every host, you fork and then wait -- blocking on
a read -- for that child to write.  It's inherently sequential. 

I am not exactly sure of the best of the best solution.  As usual it
will depend, but for starters, finish this loop before you try to read
anything.  Then, in a second loop (once all the children are running),
loop though the hosts structure reading from the file handles.

If instead of looping to read each child's output in turn (which will be
sub-optimal since you can't be sure to read the data in the order it
becomes available), you could use select to read data as an when it
becomes available for any of the child descriptors.  See IO::select.

I am sure I could give you some code if it were not so late!

-- 
Ben.


------------------------------

Date: Sat, 17 May 2014 22:19:32 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <ll9g0c$f8c$1@dont-email.me>

On 05/16/14 09:17, Dave Saville wrote:

> Recently been involved in an project where the original authors were 
> cut n paste happy.  The lead programmer of today christened it "the 
> curse of the duplicated code" due to somone in the past finding a bug 
> and fixing N out of M copies. :-(   N usually being *much* smaller 
> than M.

Yeah, that is frustrating.  But I also see the opposite, where they
write trivial a function used N times.  And then changed the function
because they need a different behavior in M places, where M << N.

Xho



------------------------------

Date: Sun, 18 May 2014 13:50:07 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <874n0nfdz4.fsf@sable.mobileactivedefense.com>

Charles DeRykus <derykus@gmail.com> writes:
> On 5/16/2014 5:17 AM, Rainer Weikusat wrote:
>> Charles DeRykus <derykus@gmail.com> writes:
>  ..
>>> The comma op is ok. Not in this example, but, a d'oh moment is
>>> possible with a comma op too:         ....,return or ....
>>
>> Did you ever inherit a relatively large body of code various people of
>> varying competence-levels and copy'n'past-happiness worked on for some
>> time? 'Accidental meanings', that is, code which doesn't make any
>> literal sense and requires 'inside information' about the thoughts of
>> the author while writing it (possibly shadowed by the fact that the bit
>> in question is the 25th mutated copy of something which originally
>> appeared in a totally different context) are a HUGE understanding
>> impediment: Some guy who isn't you and possibly doesn't even know you
>> won't a priori be aware of the fact that the do in
>>
>> do { $frog = 'green' } and return if blort()
>>
>> is a 'clever hack' supposed to silence a compiler warning which occurred
>> because the compiler considered this a boolean expression instead of a
>> 'funky' sequencing construct. This would warrant a comment documenting
>> it and then, things start to get really silly because that will end up
>> as something
>>
>> # this is the wrong way but I like it
>> do { $frog = 'green' } and return if blort()
>
> Through an extremist's prism, most of Perl's TIMTOWDI looks like a
> hack. They'll complain there's no need for "do" blocks or statement
> qualifiers for that matter... yuck! Not how "real coders" operate.

That's - at best - an unrelated general statement, at worst, a not so
subtle way to suggest that people who aren't solipsists are a general
danger (and ought to be burnt at the stake, persumably). What's that
supposed to mean in the given context?

> To me a compiler warning doesn't equate to "wrong way". "Uninitialized
> value" warnings are routinely turned off. It doesn't warrant an
> apology or a comment or the slavish exclusivity of "if" blocks or
> comma op's as the "One True Way".

and is a conditional operator supposed to evaluate its right hand
operand when evaluating its left-hand operand yielded a true value.
'comma' is a sequencing operator supposed to evaluate it's right-hand
operand after evaluating its left-hand operand, regardless of the value
that resulted in.

$frog = 'green' and return if blort();

causes a compiler warning because the compiler assumed, based on the
fact that and was used despite the left-hand operand always evaluates to
true, that someone might erroneously have used an assignment operator
('=') instead of a comparison operator ('=='), IOW, that the complex
'unconditional' expression was meant to be a conditional
expression. Considering that it wasn't, using an operator without this
property, ie

$frog = 'green', return if blort();

seems like a pretty natural choice.
 


------------------------------

Date: Sun, 18 May 2014 11:16:45 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <llatef$3nf$1@speranza.aioe.org>

On 5/18/2014 5:50 AM, Rainer Weikusat wrote:
 .....
>>>
>>> # this is the wrong way but I like it
>>> do { $frog = 'green' } and return if blort()
>>
>> Through an extremist's prism, most of Perl's TIMTOWDI looks like a
>> hack. They'll complain there's no need for "do" blocks or statement
>> qualifiers for that matter... yuck! Not how "real coders" operate.
>
> That's - at best - an unrelated general statement, at worst, a not so
> subtle way to suggest that people who aren't solipsists are a general
> danger (and ought to be burnt at the stake, persumably). What's that
> supposed to mean in the given context?

I reacted (or overreacted) to the comment "wrong way but I like it".
Still use of the word "wrong" suggests a One-True-Way and those who
utter that can be just as solipsistic as anyone else.

>
>> To me a compiler warning doesn't equate to "wrong way". "Uninitialized
>> value" warnings are routinely turned off. It doesn't warrant an
>> apology or a comment or the slavish exclusivity of "if" blocks or
>> comma op's as the "One True Way".
>
 ...
>
> $frog = 'green', return if blort();
>
> seems like a pretty natural choice.

Amen... all's well in the church of TIMTOWDI.

-- 
Charles DeRykus


------------------------------

Date: Sun, 18 May 2014 19:56:33 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <877g5i29we.fsf@sable.mobileactivedefense.com>

Charles DeRykus <derykus@gmail.com> writes:
> On 5/18/2014 5:50 AM, Rainer Weikusat wrote:
> .....
>>>>
>>>> # this is the wrong way but I like it
>>>> do { $frog = 'green' } and return if blort()
>>>
>>> Through an extremist's prism, most of Perl's TIMTOWDI looks like a
>>> hack. They'll complain there's no need for "do" blocks or statement
>>> qualifiers for that matter... yuck! Not how "real coders" operate.
>>
>> That's - at best - an unrelated general statement, at worst, a not so
>> subtle way to suggest that people who aren't solipsists are a general
>> danger (and ought to be burnt at the stake, persumably). What's that
>> supposed to mean in the given context?
>
> I reacted (or overreacted) to the comment "wrong way but I like it".
> Still use of the word "wrong" suggests a One-True-Way and those who
> utter that can be just as solipsistic as anyone else.

Well, I still maintain that hiding the unconditional expression such
that the compiler doesn't find it anymore instead of fixing the problem
is 'wrong'.


------------------------------

Date: Sat, 17 May 2014 19:00:30 -0400
From: "Bill Cunningham" <nospam@nspam.invalid>
Subject: perl and math
Message-Id: <ll8pmd$9ts$1@speranza.aioe.org>

    I am looking at several languages for math work. Algebraic work mainly 
linear equations and expanding and factoring equations. All this can be done 
by hand of course and C has a good library. What can perl do with math?

Bill




------------------------------

Date: Sat, 17 May 2014 17:30:47 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: perl and math
Message-Id: <eaa9f020-fb28-4ea6-b5bd-049f184b14f9@googlegroups.com>

I don't do much math, but do a fair amount of stats and data manipulation. I think Perl is a great tool, and I use Perl every day.

If I wee to start doing a lot of math, I'd take a very serious look at NumPy, SciPy, and mathplotlib in Python. I would also have a very strong bias for R, for the simple reason that I know it and use it.

For something old and new, try FORTRAN and Julia. I've never used these, but others have touted them for math.

Perl's very good, but I don't think that it's the best tool for math.

CC


------------------------------

Date: Sat, 17 May 2014 23:07:05 -0400
From: "Bill Cunningham" <nospam@nspam.invalid>
Subject: Re: perl and math
Message-Id: <ll984q$62g$1@speranza.aioe.org>


"ccc31807" <cartercc@gmail.com> wrote in message 
news:eaa9f020-fb28-4ea6-b5bd-049f184b14f9@googlegroups.com...
>I don't do much math, but do a fair amount of stats and data manipulation. 
>I think Perl is a great tool, and I use Perl every day.
>
> If I wee to start doing a lot of math, I'd take a very serious look at 
> NumPy, SciPy, and mathplotlib in Python. I would also have a very strong 
> bias for R, for the simple reason that I know it and use it.
>
> For something old and new, try FORTRAN and Julia. I've never used these, 
> but others have touted them for math.
>
> Perl's very good, but I don't think that it's the best tool for math.

    I looked at Ada too. It seemed too complicated. I like C ans it seems to 
have an excellent library for math. Especially with some of the newer 
standards out. I looked at python and the syntax seemed a little complicated 
too. But the thing about python and perl is that you can get modules.

Bill




------------------------------

Date: Sat, 17 May 2014 23:08:17 -0400
From: "Bill Cunningham" <nospam@nspam.invalid>
Subject: Re: perl and math
Message-Id: <ll9871$65a$1@speranza.aioe.org>

    [snip]

Also I have never heard of R or Julia. I guess you learn something new 
everyday.

Bill




------------------------------

Date: Sun, 18 May 2014 12:44:20 +0200
From: gamo <gamo@telecable.es>
Subject: Re: perl and math
Message-Id: <lla2uk$umc$1@speranza.aioe.org>

El 18/05/14 01:00, Bill Cunningham escribió:
>      I am looking at several languages for math work. Algebraic work mainly
> linear equations and expanding and factoring equations. All this can be done
> by hand of course and C has a good library. What can perl do with math?
>
> Bill
>
>

Search in CPAN for symbolic math, I guess that's what you means.
For other types of math or stats, perl is perfectly suitable per se.

-- 
http://www.telecable.es/personales/gamo/


------------------------------

Date: Sun, 18 May 2014 14:24:21 +0200
From: "Horst-W. Radners" <hSoPrAsMt@raSdPnAeMrs.de>
Subject: Re: perl and math
Message-Id: <lla8pm$7ei$1@online.de>

Bill Cunningham schrieb am 18.05.2014 01:00:
>     I am looking at several languages for math work. Algebraic work mainly 
> linear equations and expanding and factoring equations. All this can be done 
> by hand of course and C has a good library. What can perl do with math?

Assuming you don't mean "symbolic math", the CPAN lists about 1000
modules doing all sorts of math:

	https://metacpan.org/search?q=Math%3A%3A

Of course, *native* Perl isn't as fast as C, but many of the modules in
the Math:: namespace have compiled XS parts, which gives you comparable
speed.

Especially if you want to work with (large) matrices, have a look at the
PDL module.
It's intro says:

    PDL - the Perl Data Language

    PDL is the Perl Data Language, a perl extension that is designed for
    scientific and bulk numeric data processing and display. It extends
perl's
    syntax and includes fully vectorized, multidimensional array handling,
    plus several paths for device-independent graphics output.

    PDL is fast, comparable and often outperforming IDL and MATLAB in real
    world applications. PDL allows large N-dimensional data sets such as
large
    images, spectra, etc to be stored efficiently and manipulated quickly.


HTH, Horst
-- 
<remove S P A M 2x from my email address to get the real one>


------------------------------

Date: Sun, 18 May 2014 09:40:46 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: perl and math
Message-Id: <27e65f06-a77b-4f08-8564-b182ef672bbd@googlegroups.com>

On Saturday, May 17, 2014 11:08:17 PM UTC-4, Bill Cunningham wrote:
> Also I have never heard of R or Julia. 


R is hot. If you do statistics or data analysis, you owe it to yourself to take a good long look at R.

I know nothing about Julia except that people who seem to know say that it's good.

If you are doing math, what's wrong with Fortran? You can compile it with gcc, and it's been around for a ling, long time.

CC


------------------------------

Date: Sun, 18 May 2014 14:14:54 -0400
From: "Bill Cunningham" <nospam@nspam.invalid>
Subject: Re: perl and math
Message-Id: <llataq$3bf$1@speranza.aioe.org>


"ccc31807" <cartercc@gmail.com> wrote in message 
news:27e65f06-a77b-4f08-8564-b182ef672bbd@googlegroups.com...
> On Saturday, May 17, 2014 11:08:17 PM UTC-4, Bill Cunningham wrote:
>> Also I have never heard of R or Julia.
>
>
> R is hot. If you do statistics or data analysis, you owe it to yourself to 
> take a good long look at R.
>
> I know nothing about Julia except that people who seem to know say that 
> it's good.
>
> If you are doing math, what's wrong with Fortran? You can compile it with 
> gcc, and it's been around for a ling, long time.
>
    I am not saying that there is anything wrong with Fortran. I have talked 
to some who swear by g77 fortran 95 and some the more recent standards. I am 
looking for opinions now before I get into anything. The (to me) simpliest 
syntax seems to be perl. Just by looking a little bit and not really getting 
into anything. But perl has modules too and I want to consider that. I am 
looking into fortran too. Ada is out. Too complicated syntax to learn for 
me.

Bill




------------------------------

Date: Sun, 18 May 2014 14:17:07 -0400
From: "Bill Cunningham" <nospam@nspam.invalid>
Subject: Re: perl and math
Message-Id: <llateu$3oa$1@speranza.aioe.org>


"ccc31807" <cartercc@gmail.com> wrote in message 
news:27e65f06-a77b-4f08-8564-b182ef672bbd@googlegroups.com...
> On Saturday, May 17, 2014 11:08:17 PM UTC-4, Bill Cunningham wrote:
>> Also I have never heard of R or Julia.
>
>
> R is hot. If you do statistics or data analysis, you owe it to yourself to 
> take a good long look at R.

[snip]

I appreciate your help much. Like I say I've never heard of R. I will 
definately check into it.

Bill




------------------------------

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 4215
***************************************


home help back first fref pref prev next nref lref last post