Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #59435 > unrolled thread

Program Translation - Nov. 14, 2013

Back to article view | Back to comp.lang.python

Contents

  Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-14 08:18 -0600
    Re: Program Translation - Nov. 14, 2013 mecej4 <mecej4_nospam@operamail.com> - 2013-11-14 11:07 -0600
      Re: Program Translation - Nov. 14, 2013 Gordon Sande <Gordon.Sande@gmail.com> - 2013-11-14 13:36 -0400
        Re: Program Translation - Nov. 14, 2013 Clive Page <usenet@page2.eu> - 2013-11-15 11:46 +0000
      Re: Program Translation - Nov. 14, 2013 Jürgen Exner <jurgenex@hotmail.com> - 2013-11-17 09:02 -0800
    Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-15 07:51 -0600
      Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 04:25 -0600
        Re: Program Translation - Nov. 14, 2013 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-11-17 12:45 +0000
          Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 08:37 -0600
            Re: Program Translation - Nov. 14, 2013 Henry Law <news@lawshouse.org> - 2013-11-17 14:42 +0000
              Re: Program Translation - Nov. 14, 2013 Roy Smith <roy@panix.com> - 2013-11-17 10:20 -0500
                Re: Program Translation - Nov. 14, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-18 02:28 +1100
                Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 10:25 -0600
                  Re: Program Translation - Nov. 14, 2013 Tim Prince <tprince@computer.org> - 2013-11-17 08:30 -0800
                    Re: Program Translation - Nov. 14, 2013 Roy Smith <roy@panix.com> - 2013-11-17 11:43 -0500
                      Re: Program Translation - Nov. 14, 2013 nospam@see.signature (Richard Maine) - 2013-11-17 09:05 -0800
                        Re: Program Translation - Nov. 14, 2013 Joel Goldstick <joel.goldstick@gmail.com> - 2013-11-17 12:29 -0500
                          Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-18 11:30 -0600
                Re: Program Translation - Nov. 14, 2013 Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-17 18:59 +0000
            Re: Program Translation - Nov. 14, 2013 "James Van Buskirk" <not_valid@comcast.net> - 2013-11-17 09:05 -0700
          Re: Program Translation - Nov. 14, 2013 Charlton Wilbur <cwilbur@chromatico.net> - 2013-11-17 23:22 -0500
        Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 10:17 -0600
          Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-17 12:07 -0600
        Re: Program Translation - Nov. 14, 2013 Terry Reedy <tjreedy@udel.edu> - 2013-11-17 22:28 -0500
          Re: Program Translation - Nov. 14, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-18 11:15 -0600
            Re: Program Translation - Nov. 14, 2013 Joel Goldstick <joel.goldstick@gmail.com> - 2013-11-18 12:35 -0500
        Several Topics - Nov. 19, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-19 05:26 -0600
          Re: Several Topics - Nov. 19, 2013 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-19 20:51 +0000
            Re: Several Topics - Nov. 19, 2013 Yaşar Arabacı <yasar11732@gmail.com> - 2013-11-19 23:31 +0200
            Re: Several Topics - Nov. 19, 2013 Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-19 21:35 +0000
              Re: Several Topics - Nov. 19, 2013 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-19 22:43 +0000
                Re: Several Topics - Nov. 19, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-20 10:01 +1100
                Re: Several Topics - Nov. 19, 2013 gamo <gamo@telecable.es> - 2013-11-20 21:48 +0100
    Re: Program Translation - Nov. 14, 2013 "Terence" <tbwright@bigpond.net.au> - 2013-11-16 20:31 +1100
      Re: Program Translation - Nov. 14, 2013 William Ray Wing <wrw@mac.com> - 2013-11-16 09:00 -0500

Page 2 of 2 — ← Prev page 1 [2]

#59835

>>>>> "BB" == Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

    BB> There is a slight air in unreality to all this, 

This is a far more polite way of putting it than I would.  It's an
earthquake predictor based on pseudoscience and technobabble.

    BB> Finally, why are you timing Perl arithmetic?  A translation into
    BB> Perl does not seem to be an option.

EDG has been trying ineffectually to get this suite of programs to work,
integrating them with gnuplot and a Perl web application, for as long as
I can remember.  I suspect years ago someone told him that Perl was the
One True Language for web applications and the evidence of the
intervening decade has not been enough to convince him otherwise.

Followups set to comp.lang.perl.misc; c.l.python and c.l.fortran have
enough crazy overlap from c.l.p.m without adding me to the mix.

Charlton


-- 
Charlton Wilbur
cwilbur@chromatico.net

[toc] | [prev] | [next] | [standalone]

#59755

>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@earthlink.com...

       All of the necessary information regarding this effort has now been 
obtained.  So, further discussions of this particular project will probably 
take place in only the Fortran Newsgroup.  If and when the project is 
completed I will probably post another general note about it.

       The retired computer programmer that I am working with has agreed to 
work on it.  If we can generate a modern Fortran translation of the original 
program code then that will be made available to people and probably tested 
by Fortran users.  And researchers around the world can then work with that 
code if they wish.  But, if my programming colleague is going to do any work 
on modifying the newer program code then that will need to be done using 
True BASIC as that is the only language he will work with.  So, for our own 
work, its that language or nothing.

       The project is in my opinion worthwhile as the Etgtab program seems 
to be so unique.  No other freeware program can generate those data as far 
as I am aware.  And it has been my own experience that True BASIC code is 
very easy to translate into virtually any other language.

[toc] | [prev] | [next] | [standalone]

#59781

>>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@earthlink.com...

       Some additional research indicates that there is an international 
scientific organization that should be interested in this particular program 
translation effort.  And tomorrow I plan to contact them and see what they 
have to say about it.  It is possible they might decide to do the work 
themselves.

[toc] | [prev] | [next] | [standalone]

#59830

On 11/17/2013 5:25 AM, E.D.G. wrote:
[snip several paragraphs that have nothing to do with Python]

A couple of sentences of follow-up would have been sufficient.

'We decided to go with Fortran and True-Basic and not Python."

> PERL SPEED COMPARISON
>
>        Some of the early discussions leading to this point involved
> calculation speed comparisons for Perl and Python.  The table on the
> following Web page contains some interesting speed comparisons between
> various programming languages.  They are all compared to the speed it
> takes a "C" language program to run the tests.
>
> http://julialang.org/

[snip discussion of perl that is off-topic for python-list]



-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#59893

"Terry Reedy" <tjreedy@udel.edu> wrote in message 
news:mailman.2820.1384745298.18130.python-list@python.org...

> A couple of sentences of follow-up would have been sufficient.

       The experience that I have had over the years with Newsgroup posting 
is that it is generally better to try to be polite and answer as many 
questions as possible even when that results in more information being 
posted than might be necessary.  Hopefully a discussion will then end 
quietly on a pleasant note.

       That approach seems to usually produce good results.  Quite often 
people who are happy with the tone of the public Newsgroup discussion will 
send along some valuable information by E-mail.  And that has been happening 
with this present discussion that will now continue in only the Fortran 
Newsgroup.

[toc] | [prev] | [next] | [standalone]

#59895

On Mon, Nov 18, 2013 at 12:15 PM, E.D.G. <edgrsprj@ix.netcom.com> wrote:
> "Terry Reedy" <tjreedy@udel.edu> wrote in message
> news:mailman.2820.1384745298.18130.python-list@python.org...
>
>
>> A couple of sentences of follow-up would have been sufficient.
>
>
>       The experience that I have had over the years with Newsgroup posting
> is that it is generally better to try to be polite and answer as many
> questions as possible even when that results in more information being
> posted than might be necessary.  Hopefully a discussion will then end
> quietly on a pleasant note.
>
>       That approach seems to usually produce good results.  Quite often
> people who are happy with the tone of the public Newsgroup discussion will
> send along some valuable information by E-mail.  And that has been happening
> with this present discussion that will now continue in only the Fortran
> Newsgroup.
>
> --
> https://mail.python.org/mailman/listinfo/python-list

This is just plain senseless.  Is the op a Bot?

-- 
Joel Goldstick
http://joelgoldstick.com

[toc] | [prev] | [next] | [standalone]

#59981 — Several Topics - Nov. 19, 2013

>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@earthlink.com...
Posted by E.D.G. on November 19, 2013

1.  PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN

2.  COMPUTER PROGRAMMING PROJECTS


PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN

       This program translation project has become one of the most 
surprisingly successful programming projects I have worked on to date.  A 
considerable amount of valuable information has been sent to me by E-mail in 
addition to all of the information posted to the Newsgroups.

       The original posts actually discussed calculation speed matters 
involving Perl and Python.  And responses indicated that there were ways to 
develop routines that could dramatically accelerate Python calculations. 
But it did not sound like there were any for Perl.

However, a kind soul sent me the following references:

http://pdl.perl.org/
http://www.youtube.com/watch?v=IE-vnnRWiOg
http://www.youtube.com/watch?v=rf1yfZ2yUFo

       From what I can see, PDL represents a group of modules that can be 
linked with Perl to do faster calculations and to generate charts.  I gather 
that it converts calculations directly to the C language so that they run 
faster.  And now I am wondering how those calculations would compare with 
Python and Fortran and the other programs listed on the following Web page:

http://julialang.org/

       As soon as possible I am planning to give the PDL modules a try 
myself and see if they help with my present Perl calculation speed 
limitations.

       Does anyone have any comments they can add regarding PDL (for posting 
in the Perl Newsgroup)?

       Would those PDL modules be available on Internet Servers that let 
users develop and run Perl CGI programs?  Or would they need to be specially 
installed?


COMPUTER PROGRAMMING PROJECTS

       As most people visiting these Newsgroups probably know, computers run 
our world.  And therefore, computer programmers at least indirectly run our 
world.  As an experienced scientist who does some programming work I myself 
am fully aware of that.  But relatively few other scientists are.  And 
almost no government officials appear to be.  And they are the ones who have 
all of the money.

       As an experienced scientist I regularly send free technical advice to 
governments and nongovernmental organizations (NGOs) around the world 
regarding humanitarian projects.  Some of my past efforts have been highly 
successful.  And because I am so aware of the importance of computer 
programming to the success of most efforts I can be especially effective 
when discussing proposed projects.  I know enough about computer 
programming, electronics, and machine shop usage that I can provide the 
government officials with exact instructions for how they should proceed 
with developing some project.

       For example, sometimes the best way to get something done is with a 
specially designed electronic circuit.  At other times it is more efficient 
to use a microprocessor to do the data processing.

       There are several highly important computer programming intensive 
projects that I have been attempting to get our governments to develop for 
some time.  They are in my opinion needed by people around the world.  I 
have several Web sites that were created so that information could be easily 
circulated regarding those projects.  And as time permits I plan to start 
discussing them in various computer language Newsgroups.

       An effort is also in progress to get some modifications made to the 
U.S. Government Petitions Web Site so that it works a little better and is 
of more use to people.

https://petitions.whitehouse.gov/

      It has been my personal experience that our government officials who 
decide which projects should get funding and how many computer programmers 
etc. need to be hired for this or that effort usually know so little about 
the work that computer programmers and even scientists do that they often 
don't have any idea regarding how to solve various problems and also often 
don't even know that certain problems exist.

These are personal opinions.

[toc] | [prev] | [next] | [standalone]

#60031 — Re: Several Topics - Nov. 19, 2013

In comp.lang.fortran E.D.G. <edgrsprj@ix.netcom.com> wrote:
>>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@earthlink.com...
> Posted by E.D.G. on November 19, 2013
 
> 1.  PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN
 
(snip)

>       This program translation project has become one of the most 
> surprisingly successful programming projects I have worked on to date.  A 
> considerable amount of valuable information has been sent to me by E-mail in 
> addition to all of the information posted to the Newsgroups.
 
>       The original posts actually discussed calculation speed matters 
> involving Perl and Python.  And responses indicated that there were ways to 
> develop routines that could dramatically accelerate Python calculations. 
> But it did not sound like there were any for Perl.

In general, language processors can be divided into two categories
called compilers and interpreters.  Compilers generate instructions for
the target processors. Interpreters generate (usually) an intermediate
representation which is then interpreted by a program to perform the
desired operations. That latter tends to be much slower, but more
portable.

There are a few langauges that allow dynamic generation of code, which
often makes compilation impossible, and those languages tend to be
called 'interpreted langauges'. 

Some years ago when working with perl programs that ran too slow, we
found a perl to C translator. Surprisingly, the result ran just as slow!
It turns out that the perl to C translator generates a C program
containing the intermediate code and the interpreter, and so runs just
the same speed.

More recently, there are JIT systems which generate the intermediate
code, but then at the appropriate time (Just In Time) compile that to
machine code and execute it. This is common for Java, and more recently
for languages like Matlab.

-- glen

[toc] | [prev] | [next] | [standalone]

#60032 — Re: Several Topics - Nov. 19, 2013

2013/11/19 glen herrmannsfeldt <gah@ugcs.caltech.edu>:
> More recently, there are JIT systems which generate the intermediate
> code, but then at the appropriate time (Just In Time) compile that to
> machine code and execute it. This is common for Java, and more recently
> for languages like Matlab.

Is there a particular reason why you didn't mention PyPy?

-- 
http://ysar.net/

[toc] | [prev] | [next] | [standalone]

#60033 — Re: Several Topics - Nov. 19, 2013

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> In comp.lang.fortran E.D.G. <edgrsprj@ix.netcom.com> wrote:
>>>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
>>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@earthlink.com...
>> Posted by E.D.G. on November 19, 2013
>  
>> 1.  PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN
>  
> (snip)
>
>>       This program translation project has become one of the most 
>> surprisingly successful programming projects I have worked on to date.  A 
>> considerable amount of valuable information has been sent to me by E-mail in 
>> addition to all of the information posted to the Newsgroups.
>  
>>       The original posts actually discussed calculation speed matters 
>> involving Perl and Python.  And responses indicated that there were ways to 
>> develop routines that could dramatically accelerate Python calculations. 
>> But it did not sound like there were any for Perl.
>
> In general, language processors can be divided into two categories
> called compilers and interpreters.  Compilers generate instructions for
> the target processors. Interpreters generate (usually) an intermediate
> representation which is then interpreted by a program to perform the
> desired operations. That latter tends to be much slower, but more
> portable.
>
> There are a few langauges that allow dynamic generation of code, which
> often makes compilation impossible, and those languages tend to be
> called 'interpreted langauges'.

These two paragraphs use the same terms in conflicting ways and the
assertions in the second paragraph are wrong: Lisp is presumably the
oldest language which allows 'dynamic code creation' and implementations
exist which not only have a compiler but actually don't have an
interpreter, cf

http://www.sbcl.org/manual/index.html#Compiler_002donly-Implementation

The main difference between a compiler and an interpreter is that the
compiler performs lexical and semantical analysis of 'the source code'
once and then transforms it into some kind of different 'directly
executable representation' while an interpreter would analyze some part
of the source code, execute it, analyze the next, execute that, and so
forth, possibly performing lexical and semantical analysis steps many
times for the same bit of 'source code'.

Some compilers produce 'machine code' which can be executed directly by
'a CPU', others generate 'machine code' for some kind of virtual machine
which is itself implemented as a program. The distinction isn't really
clear-cut because some CPUs are designed to run 'machine code'
originally targetted at a virtual machine, eg, what used to be ARM
Jazelle for executing JVM byte code directly on an ARM CPU, some virtual
machines are supposed to execute 'machine code' which used to run
'directly on a CPU' in former times, eg, used for backwards
compatibility on Bull Novascale computers.

Prior to execution, Perl source code is compiled to 'machine code' for a
(stack-based) virtual machine. Both the compiler and the VM are provided
by the perl program. There were some attempts to create a standalone
Perl compiler in the past but these never gained much traction.

[toc] | [prev] | [next] | [standalone]

#60037 — Re: Several Topics - Nov. 19, 2013

In comp.lang.fortran Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> In comp.lang.fortran E.D.G. <edgrsprj@ix.netcom.com> wrote:
>>>>> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
>>>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@earthlink.com...
>>> Posted by E.D.G. on November 19, 2013
  
>>> 1.  PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN
  
 (snip)

>>>       This program translation project has become one of the most 
>>> surprisingly successful programming projects I have worked on to date.  A 
>>> considerable amount of valuable information has been sent to me by E-mail in 
>>> addition to all of the information posted to the Newsgroups.

(snip, I wrote)

>> In general, language processors can be divided into two categories
>> called compilers and interpreters.  Compilers generate instructions for
>> the target processors. Interpreters generate (usually) an intermediate
>> representation which is then interpreted by a program to perform the
>> desired operations. That latter tends to be much slower, but more
>> portable.

>> There are a few langauges that allow dynamic generation of code, which
>> often makes compilation impossible, and those languages tend to be
>> called 'interpreted langauges'.
 
> These two paragraphs use the same terms in conflicting ways and the
> assertions in the second paragraph are wrong: Lisp is presumably the
> oldest language which allows 'dynamic code creation' and implementations
> exist which not only have a compiler but actually don't have an
> interpreter, cf
 
> http://www.sbcl.org/manual/index.html#Compiler_002donly-Implementation
 
> The main difference between a compiler and an interpreter is that the
> compiler performs lexical and semantical analysis of 'the source code'
> once and then transforms it into some kind of different 'directly
> executable representation' while an interpreter would analyze some part
> of the source code, execute it, analyze the next, execute that, and so
> forth, possibly performing lexical and semantical analysis steps many
> times for the same bit of 'source code'.

OK, but many intepreters at least do a syntax check on the whole file,
and many also convert the statements to a more convenient internal
representation.

For an example of something that can't be compiled, consider TeX which
allows the category code of characters to be changed dynamically.

I once wrote self-modifying code for Mathematica, where the running code
(on what Mathematica calls the back end) asked the front end (which does
editing of input data) to change the code. 
 
> Some compilers produce 'machine code' which can be executed directly by
> 'a CPU', others generate 'machine code' for some kind of virtual machine
> which is itself implemented as a program. The distinction isn't really
> clear-cut because some CPUs are designed to run 'machine code'
> originally targetted at a virtual machine, eg, what used to be ARM
> Jazelle for executing JVM byte code directly on an ARM CPU, some virtual
> machines are supposed to execute 'machine code' which used to run
> 'directly on a CPU' in former times, eg, used for backwards
> compatibility on Bull Novascale computers.

Yes. There are also systems that do simple processing on each statement,
with no interstatement memory. Converting numerical constants to
internal form, encoding keywords to a single byte, and such. 

It is interesting to see the program listing look different than the way
it was entered, such as constants coming out as 1e6 when you entered
it as 1000000.  The HP2000 BASIC system is the one I still remember.

The popular microcomputer BASIC systems, mostly from Microsoft, allowed
things like:

IF I=1 THEN FOR J=1 TO 10
PRINT J
IF I=1 THEN NEXT J

If you left out the IF on the last line, it would fail when it reached
the NEXT J statement if the FOR hadn't been executed. Compare to C:

if(i==1) for(j=1;j<=10;j++) {
   printf("%d\n",j);
}

A compiler would match up the FOR and NEXT at compile time. Many 
interpreters do it at run time, depending on the current state.

I also used to use a BASIC system that allowed you to stop a program
(or the program stopped itself), change statements (fix bugs) and
continue on from where it stopped. Not all can do that, but pretty
much compilers never do.
 
> Prior to execution, Perl source code is compiled to 'machine code' for a
> (stack-based) virtual machine. Both the compiler and the VM are provided
> by the perl program. There were some attempts to create a standalone
> Perl compiler in the past but these never gained much traction.

And, importantly, the code runs fairly slow. Some years ago, I was
working with simple PERL programs that could process data at 1 megabyte
per minute. Rewriting in C, I got one megabyte per second. It is not too
unusual to run 10 times slower, but 60 was rediculous.

-- glen

[toc] | [prev] | [next] | [standalone]

#60041 — Re: Several Topics - Nov. 19, 2013

On Wed, Nov 20, 2013 at 9:43 AM, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
> I also used to use a BASIC system that allowed you to stop a program
> (or the program stopped itself), change statements (fix bugs) and
> continue on from where it stopped. Not all can do that, but pretty
> much compilers never do.

Ditto, both in GW-BASIC and Q-BASIC, but in each case there were some
fairly strict rules about what could be edited. Changing anything to
do with control flow quickly got you a "Can't continue" error. And of
course, assembly language with DEBUG.EXE lets you do basically
anything... rewrite memory (code or data, there's no difference),
change the instruction pointer (so execution resumes somewhere else),
change other registers, etc, etc.

Most languages don't give you quite that much flexibility, because
it's really REALLY easy to mess things up and confuse yourself
completely. Python kinda will, though; all you have to do is fiddle
with sys.modules so it won't be cached, or rename the file to
something unique before reimporting it. You can then patch in
functions from the new module and start using them. Pike makes this
sort of thing much more convenient; it's not hard to write code that
smoothly slides to a new version of itself, without losing any sort of
state. But the granularity never gets down below the function, meaning
the Python and Pike compilers/interpreters are free to fiddle around
inside a function (note, for instance, how Python locals basically
just become indices into an array; it'd be a bit awkward to tweak a
running Python function and add a 'global' declaration).

ChrisA
(See? I'm posting on topic!)

[toc] | [prev] | [next] | [standalone]

#60136 — Re: Several Topics - Nov. 19, 2013

El 19/11/13 23:43, glen herrmannsfeldt escribió:
>
> And, importantly, the code runs fairly slow. Some years ago, I was
> working with simple PERL programs that could process data at 1 megabyte
> per minute. Rewriting in C, I got one megabyte per second. It is not too
> unusual to run 10 times slower, but 60 was rediculous.
>
> -- glen
>

Can you provide more information on the topic? Perl version, method to
read/write, etc.

Thanks

[toc] | [prev] | [next] | [standalone]

#59595

I downloaded the packed file mentioned, extracted the files and had a look
at the Fortran sources given:
ETGTAB.FOR and ETGTAB.F

The ETGTAB.FOR file had double spacing, which Iremoved automatically, then
compared the two sources automatically (passing and copying equals and
offering choice between lexically different lines).

The two files were now very nearly identical, but the .FOR file had some
CALLs to GEOEXT(IUIT6,DEXTIM) which were commented out in the other; also
calls to LAHEY timing functions not used in the .F version (and a minor
change in two format statements which effectively just changed the shift in
the output report).

I don't see why not either source (given access to the external GEOEXT, etc,
fuctions) shouldn't be left for compilation (and later running) by any F77
or later compiler. The code is still valid.

[toc] | [prev] | [next] | [standalone]

#59606

On Nov 16, 2013, at 4:31 AM, Terence <tbwright@bigpond.net.au> wrote:

> I downloaded the packed file mentioned, extracted the files and had a look
> at the Fortran sources given:
> ETGTAB.FOR and ETGTAB.F
> 
> The ETGTAB.FOR file had double spacing, which Iremoved automatically, then
> compared the two sources automatically (passing and copying equals and
> offering choice between lexically different lines).
> 
> The two files were now very nearly identical, but the .FOR file had some
> CALLs to GEOEXT(IUIT6,DEXTIM) which were commented out in the other; also
> calls to LAHEY timing functions not used in the .F version (and a minor
> change in two format statements which effectively just changed the shift in
> the output report).
> 
> I don't see why not either source (given access to the external GEOEXT, etc,
> fuctions) shouldn't be left for compilation (and later running) by any F77
> or later compiler. The code is still valid.
> 

Then, use F2PY to put a python wrapper around the code, and it could easily be incorporated into the python workflow that the OP was originally asking for.

-Bill

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web