[32812] in Perl-Users-Digest
Perl-Users Digest, Issue: 4077 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Nov 16 00:09:39 2013
Date: Fri, 15 Nov 2013 21:09:03 -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 Fri, 15 Nov 2013 Volume: 11 Number: 4077
Today's topics:
Re: 'depth n' combinations of a sequence of numbers <hslee911@yahoo.com>
Re: ImageMagick to rotate an image <jwcarlton@gmail.com>
Re: Program Translation - Nov. 14, 2013 <usenet@page2.eu>
Re: Program Translation - Nov. 14, 2013 <edgrsprj@ix.netcom.com>
Re: Several Perl Questions - Nov. 5, 2013 <ben.usenet@bsb.me.uk>
Re: Several Perl Questions - Nov. 5, 2013 <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 14 Nov 2013 17:06:21 -0800 (PST)
From: James <hslee911@yahoo.com>
Subject: Re: 'depth n' combinations of a sequence of numbers
Message-Id: <f55f24cd-bcbf-4b8b-a780-586b7d2e0660@googlegroups.com>
Using "glob" as suggested by DeRykus, for list [$p..$q] and depth $d,
use Data::Dump qw(dump);
($p, $q, $d) = @ARGV;
$x = join ",", $p..$q;
dump run($x,$d);
sub run {
my ($T, $d) = @_;
if ($d == 1) {
glob "{@{[$T]}}";
} else {
$T = join ",", run($T, --$d);
glob "{@{[$x]}}_{@{[$T]}}";
}
}
James
------------------------------
Date: Thu, 14 Nov 2013 20:51:07 -0800 (PST)
From: Jason C <jwcarlton@gmail.com>
Subject: Re: ImageMagick to rotate an image
Message-Id: <3e3249f3-3507-4e0f-94f3-3c7549580e2d@googlegroups.com>
On Thursday, November 14, 2013 2:24:44 AM UTC-5, Peter J. Holzer wrote:
> Rotation or Orientation, yes. Apparently both are in use.
>
>
>
> Here is what I use:
>
>
>
> use Image::ExifTool qw(ImageInfo);
>
> ...
>
> my $info = ImageInfo($filename);
>
> my $rot = $info->{'Rotation'} || $info->{'Orientation'};
>
> my ($angle) = $rot =~ m/Rotate (\d+) CW/;
>
> return $angle;
>
>
>
> hp
Thanks, guys (both Peter and Ben). I think this will help a lot.
------------------------------
Date: Fri, 15 Nov 2013 11:46:30 +0000
From: Clive Page <usenet@page2.eu>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <bemfspF99cuU1@mid.individual.net>
On 14/11/2013 17:36, Gordon Sande wrote:
> Indeed! Under NAGWare Fortran it runs to completion with C=all but pulls an
> undefined reference when C=undefined is added.
>
> Lots of obsolete features and other warnings but no compiler error
> messages.
>
> The obvious lessons are that 1. Fortran has very good historical continuity
> and 2. the good debugging Fortran compilers do a good job.
>
>
I would also check it out with FTNCHEK as well - it usually finds lots
of potential or actual problems with code of this vintage.
--
Clive Page
------------------------------
Date: Fri, 15 Nov 2013 07:51:57 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Program Translation - Nov. 14, 2013
Message-Id: <jcKdnQiu1ZxguxvPnZ2dnUVZ_qmdnZ2d@earthlink.com>
"E.D.G." <edgrsprj@ix.netcom.com> wrote in message
news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@earthlink.com...
The responses regarding that Etgtab program were encouraging. I was
not sure if anyone would even recognize the code as the program was written
quite a while ago.
The main reason for wanting to translate it into modern language code
is so that it can be easily modified and also merged with another computer
program. The main language it would probably be translated into is True
BASIC. This is because the person doing the work is a retired professional
computer programmer who does work like that as a hobby. But he will only
work with True BASIC. In fact he already translated most of the Etgtab
program. The effort got stopped when he could not understand some of the
FORTRAN code. Unlike working personnel, retired people can start and stop
efforts like that as they please.
From discussions with people in several Newsgroups the conclusions I
arrived at in the past few weeks are the following:
Perl would not work because it does calculations too slowly.
Standard Python would also not work for the same reason. However, there are
Python routines available that would make it possible to accelerate the
calculations.
FORTRAN, True BASIC, XBasic, and another language called Julia likely
do calculations fast enough. Julia looks like it is specifically designed
for that type of work.
http://julialang.org/
I am checking with that programmer to see if he wants to continue
with the effort.
The program itself has some importance for earthquake related
research. A number of years ago I checked with the U.S. Government's "Ask A
Geologist" staff to see if they knew about any freeware programs that
researchers could use to generate those types of data. And I was told that
they did not know of any. Apparently they did not even know that Etgtab
exists. I had to do some Internet searches to find it.
The Solid Earth Tide data it generates are probably fairly good. The
plan is to check its ocean tide data against data from the following Web
site to see how well they match.
http://tbone.biol.sc.edu/tide/
We could not find any good freeware programs for generating the types
of sun and moon location data needed for this research and so we wrote one
ourselves. It has been available for a number of years as a freeware
program written in True BASIC.
------------------------------
Date: Thu, 14 Nov 2013 19:43:16 +0000
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <0.b5967f300a26e198151c.20131114194316GMT.87d2m2vkff.fsf@bsb.me.uk>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> "E.D.G." <edgrsprj@ix.netcom.com> writes:
>
> [...]
>
>>>>> The program that I mentioned that my colleague could not
>>>>> translate was apparently written using FORTRAN 77 with the LAHEY-F77
>>>>> compiler. And this appears to be the present Web site for download
>>>>> versions of the program.
>>>>>
>>>>> http://www.bfo.geophys.uni-stuttgart.de/etgtab.html
>
> [...]
>
>>>> I really don't see any reason why the program can't be used as-is.
>>>
>>> In the sense that the high priest prepares the fruits and vegetables and
>>> chicken and lambs and first born children for the sacrifice while
>>> wearing the white, ornamental robes, then kills everything alive, making
>>> sure to mix and spread the blood exactly as the ancient ritual
>>> prescribes and then takes a deep breath and waits ... until a thunderous
>>> voice booms "The answer is 42!" from the skies, surely.
>>
>> That's too obscure for me (I get the reference, just not the point).
>
> Considering that there's certainly no living being who understands this
> code (and I very much doubt that there ever was), all one can do with this
> program is humbly feed it with some input and gratefully accept whatever
> output it produces, with the result being defined as correct because
> "The computer said so!", despite nobody understands how it arrived there
> and why this result and not some other one was produced.
I get the point. However the question is surely whether there might be
someone who understands this code in the future? It might then be
possible understand the output. I don't think this is an unreasonable
hope.
It's 2318 lines long, but more than half are comment lines, and a
further 120 or so are house-keeping lines like FORMAT and CONTINUE (used
here like } in C, not as a jump). There are only 50 GOTOs and all seem
to forward jumps. At less than 1000 lines of code it doesn't seem
impossible to me that someone could understand it. I've worked with
much less structured Fortran in the past.
Not easy, sure, and it may turn out to be a doomed project, but my first
job was unravelling exactly this sort of program (well, worse, to be
frank) and when I looked at it I thought, "not too bad". I was,
however, glad that this was no longer my job!
--
Ben.
------------------------------
Date: Thu, 14 Nov 2013 20:46:20 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <87ob5mzp7n.fsf@sable.mobileactivedefense.com>
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> "E.D.G." <edgrsprj@ix.netcom.com> writes:
>>
>> [...]
>>
>>>>>> The program that I mentioned that my colleague could not
>>>>>> translate was apparently written using FORTRAN 77 with the LAHEY-F77
>>>>>> compiler. And this appears to be the present Web site for download
>>>>>> versions of the program.
>>>>>>
>>>>>> http://www.bfo.geophys.uni-stuttgart.de/etgtab.html
>>
>> [...]
>>
>>>>> I really don't see any reason why the program can't be used as-is.
>>>>
>>>> In the sense that the high priest prepares the fruits and vegetables and
>>>> chicken and lambs and first born children for the sacrifice while
>>>> wearing the white, ornamental robes, then kills everything alive, making
>>>> sure to mix and spread the blood exactly as the ancient ritual
>>>> prescribes and then takes a deep breath and waits ... until a thunderous
>>>> voice booms "The answer is 42!" from the skies, surely.
>>>
>>> That's too obscure for me (I get the reference, just not the point).
>>
>> Considering that there's certainly no living being who understands this
>> code (and I very much doubt that there ever was), all one can do with this
>> program is humbly feed it with some input and gratefully accept whatever
>> output it produces, with the result being defined as correct because
>> "The computer said so!", despite nobody understands how it arrived there
>> and why this result and not some other one was produced.
>
> I get the point. However the question is surely whether there might be
> someone who understands this code in the future? It might then be
> possible understand the output. I don't think this is an unreasonable
> hope.
>
> It's 2318 lines long, but more than half are comment lines, and a
> further 120 or so are house-keeping lines like FORMAT and CONTINUE (used
> here like } in C, not as a jump).
There are two of them, the older one being a little larger. And the code
looks like this:
DGX(1)=(DHLAT(1)-(6.D0*DLLAT(1)*DC2T)/(3.D0*DCT2-1.D0))*DCAZ**2
1 +(DHLAT(1)-(6.D0*DLLAT(1)*DCT2)/(3.D0*DCT2-1.D0))*DSAZ**2
DGY(1)=0.D0
DGX(2)=(DHLAT(2)-4.D0*DLLAT(2))*DCAZ**2+(DHLAT(2)-DLLAT(2)/DST2
1 +2.D0*DLLAT(2)*DCOTT*DCOTT2)*DSAZ**2
DGY(2)=2.D0*DLLAT(2)*(2.D0*DCOTT2-DCOTT)*DCSTS/DST
DGX(3)=(DHLAT(3)+2.D0*DLLAT(3)*(DCOTT*DCOTT-1.D0))*DCAZ**2
1 +(DHLAT(3)-4.D0*DLLAT(3)/DST2+2.D0*DLLAT(3)*DCOTT*DCOTT)*DSAZ**2
DGY(3)=4.D0*DLLAT(3)*DCOTT*DCSTS/DST
DGX(4)=(DHLAT(4)+DLLAT(4)*(33.D0-45.D0*DCT2)/(5.D0*DCT2-3.D0))*
1 DCAZ**2+(DHLAT(4)-DLLAT(4)*(1.D0+10.D0*DCT2/(5.D0*DCT2-3.D0)))*
2 DSAZ**2
DGY(4)=0.D0
DGX(5)=(DHLAT(5)-DLLAT(5)*(1.D0+10.D0*(1.D0-4.D0*DCT2)/
1 (1.D0-5.D0*DCT2)))*DCAZ**2+(DHLAT(5)+DLLAT(5)*
2 (DCOTT*DCOTT-1.D0/DST2-10.D0*DCT2/(5.D0*DCT2-1.D0)))*DSAZ**2
DGY(5)=-20.D0*DLLAT(5)*DCT*DCSTS/(5.D0*DCT2-1.D0)
DGX(6)=(DHLAT(6)+DLLAT(6)*(2.D0*DCOTT*DCOTT-7.D0))*DCAZ**2
1 +(DHLAT(6)+DLLAT(6)*(2.D0*DCOTT*DCOTT-1.D0-4.D0/DST2))*DSAZ**2
DGY(6)=-4.D0*DLLAT(6)*(DCOTT-1.D0/DCOTT)*DCSTS/DST
DGX(7)=(DHLAT(7)+DLLAT(7)*(6.D0*DCOTT*DCOTT-3.D0))*DCAZ**2
> There are only 50 GOTOs and all seem
> to forward jumps. At less than 1000 lines of code it doesn't seem
> impossible to me that someone could understand it.
It is surely not impossible that someone checks this code
character-by-character, considering the context of all characters
checked so far and still to be checked, to determine what this actually
does and to verify that what it does happens to be correct, however, the
effort necessary to rewrite this shirt cuff doodling gone out of hand from
scratch is almost certainly going to be a lot lower.
------------------------------
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 4077
***************************************
