Basic Python Questions - Oct. 31, 2013

[E.D.G.]

Posted by E.D.G. on October 31, 2013

The following are several relatively basic questions regarding Python's
capabilities. I am not presently using it myself. At the moment a number
of people including myself are comparing it with other programs such as
XBasic for possible use.

1. How fast can Python do math calculations compared with other languages
such as Fortran and fast versions of Basic. I would have to believe that it
is much faster than Perl for doing math calculations.

2. Can Python be used to create CGI programs? These are the ones that run
on Internet server computers and process data submitted through Web site
data entry screens etc. I know that Perl CGI programs will do that.

3. If Python can be used for CGI programming, can it draw charts such as
.png files that will then display on Web pages at a Web site?

4. How well does Python work for interactive programming. For example, if
a Python program is running on a PC and is drawing a chart, can that chart
be modified by simply pressing a key while the Python program is running. I
have Perl and Gnuplot program combinations that can do that. Their
interactive speed is not that great. But it is adequate for my own uses.

5. Can a running Python program send information to the Windows operating
system as if it were typed in from the keyboard? Perl can do that and I
would imagine that Python probably has that same capability.

[Chris “Kwpolska” Warrick]

On Thu, Oct 31, 2013 at 10:31 AM, E.D.G. <edgr...@ix.netcom.com> wrote:
> Posted by E.D.G. on October 31, 2013
>
> The following are several relatively basic questions regarding
> Python's capabilities. I am not presently using it myself. At the moment a
> number of people including myself are comparing it with other programs such
> as XBasic for possible use.
>
> 1. How fast can Python do math calculations compared with other languages
> such as Fortran and fast versions of Basic. I would have to believe that it
> is much faster than Perl for doing math calculations.

Depends on what do you want to calculate. Also, note that Python is
liked by the scientific community to use for calculations. This might
be a hint.

> 2. Can Python be used to create CGI programs? These are the ones that run
> on Internet server computers and process data submitted through Web site
> data entry screens etc. I know that Perl CGI programs will do that.

Yes. Although most people in the Python community dislike the
old-style “CGI” and use “web apps” instead. They are also connected
with a different philosophy, for example we do not store .py files in
/cgi-bin/, we never expose our .py files and put it somewhere else on
the system and let the web server act as a proxy to a WSGI server
(gunicorn/uwsgi).

> 3. If Python can be used for CGI programming, can it draw charts such as
> .png files that will then display on Web pages at a Web site?

Yes, but you need to install additional libraries for that.

> 4. How well does Python work for interactive programming. For example, if
> a Python program is running on a PC and is drawing a chart, can that chart
> be modified by simply pressing a key while the Python program is running. I
> have Perl and Gnuplot program combinations that can do that. Their
> interactive speed is not that great. But it is adequate for my own uses.

Doable, but I cannot give you any information on the speed.

> 5. Can a running Python program send information to the Windows operating
> system as if it were typed in from the keyboard? Perl can do that and I
> would imagine that Python probably has that same capability.

Definitely possible, but might take you a bit of work and knowledge of
Windows internals (go ask Google).

--
Chris “Kwpolska” Warrick <http://kwpolska.tk>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense

[E.D.G.]

Posted by E.D.G. October 31, 2013

Hi Chris,

Thanks for the responses. Several of my questions were answered.

The calculation speed question just involves relatively simple math
such as multiplications and divisions and trig calculations such as sin and
tan etc. Presently I am using Perl to do those types of calculations. And I
am starting to run into problems with how long it takes Perl to do thousands
and even millions of calculations like that even though they are relatively
simple.

The version of Perl that I am presently using has the usual Print
statements for printing to the Perl program window. It sends Windows
programs or files information in the following manner:

Win32::GuiTest::SendKeys("The text within these two parentheses marks will
print as text in an active Notepad window.");

It would be my guess that Python has some type of statement like
that.

[Chris “Kwpolska” Warrick]

On Thu, Oct 31, 2013 at 11:38 AM, E.D.G. <edgr...@ix.netcom.com> wrote:
> Posted by E.D.G. October 31, 2013

no need to write that.

>
> Hi Chris,
>
> Thanks for the responses. Several of my questions were answered.
>
> The calculation speed question just involves relatively simple math
> such as multiplications and divisions and trig calculations such as sin and
> tan etc. Presently I am using Perl to do those types of calculations. And I
> am starting to run into problems with how long it takes Perl to do thousands
> and even millions of calculations like that even though they are relatively
> simple.

I suggest that you try Python out yourself, on your data. I can’t

> The version of Perl that I am presently using has the usual Print
> statements for printing to the Perl program window. It sends Windows
> programs or files information in the following manner:
>
> Win32::GuiTest::SendKeys("The text within these two parentheses marks will
> print as text in an active Notepad window.");
>
> It would be my guess that Python has some type of statement like that.
>

Looks like you want something like [0] (requires pywin32 from [1]).

[0]: http://win32com.goermezer.de/content/view/136/254/
[1]: http://sourceforge.net/projects/pywin32/files/pywin32/Build%20218/

[Roy Smith]

In article <UdGdnaDGa6n9vu_P...@earthlink.com>,

"E.D.G." <edgr...@ix.netcom.com> wrote:

> 1. How fast can Python do math calculations compared with other languages
> such as Fortran and fast versions of Basic. I would have to believe that it
> is much faster than Perl for doing math calculations.

Getting a handle on Python's execution speed is not easy. The problem
is that the core library is mostly written in C, so operations that
happen inside the core library are fast. Operations that happen in
user-written Python code are slow. How fast your overall program will
run is largely determined by how much you're executing user code and how
much you're executing library calls.

People have done lots of comparisons of language execution speed over
the years. If you google for "python speed comparison", you'll find
plenty of more detailed answers than you'll get here.

> 2. Can Python be used to create CGI programs? These are the ones that run
> on Internet server computers and process data submitted through Web site
> data entry screens etc. I know that Perl CGI programs will do that.

Yes, they can. However, CGI is largely an obsolete interface, partly
because it's so inefficient. If you're worried about execution speed,
CGI is not what you should be looking at.

> 3. If Python can be used for CGI programming, can it draw charts such as
> .png files that will then display on Web pages at a Web site?

Yes. There are a number of modules out there for doing this. Again,
google is your friend. Search for "python charting module", or
variations on that.

[Alain Ketterlin]

"E.D.G." <edgr...@ix.netcom.com> writes:

> The calculation speed question just involves relatively simple
> math such as multiplications and divisions and trig calculations such
> as sin and tan etc.

These are not "simple" computations.

Any compiled language (Fortran, C, C++, typically) will probably go much
faster than any interpreted/bytecode-based language (like python or
perl, anything that does not use a jit).

I have never seen any serious use of python for numerical computations
without use of numpy/scipy, which is basically a python wrapper around
compiled libraries. You probably should consider such a combination.

> Presently I am using Perl to do those types of calculations. And I am
> starting to run into problems with how long it takes Perl to do
> thousands and even millions of calculations like that even though they
> are relatively simple.

No surprise.

> [...] It sends Windows programs or files information in the following
> manner:
>
> Win32::GuiTest::SendKeys("...");
>

I have no idea on what this could be useful for, but it took me a few
seconds to type "python sendkeys" and get some interesting results.

-- Alain.

[Mark Lawrence]

https://pypi.python.org/pypi/pywinauto/0.3.9 or
http://stackoverflow.com/questions/1823762/sendkeys-for-python-3-1-on-windows
of any use?

--
Python is the second best programming language in the world.
But the best has yet to be invented. Christian Tismer

Mark Lawrence

[Chris Angelico]

On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
<al...@dpt-info.u-strasbg.fr> wrote:
> "E.D.G." <edgr...@ix.netcom.com> writes:
>
>> The calculation speed question just involves relatively simple
>> math such as multiplications and divisions and trig calculations such
>> as sin and tan etc.
>
> These are not "simple" computations.
>
> Any compiled language (Fortran, C, C++, typically) will probably go much
> faster than any interpreted/bytecode-based language (like python or
> perl, anything that does not use a jit).

Well, they may not be simple to do, but chances are you can push the
work down to the CPU/FPU on most modern hardware - that is, if you're
working with IEEE floating point, which I'm pretty sure CPython always
does; not sure about other Pythons. No need to actually calculate trig
functions unless you need arbitrary precision (and even then, I'd bet
the GMP libraries have that all sewn up for you). So the language
doesn't make a lot of difference.

ChrisA

[Mark Lawrence]

On 31/10/2013 13:17, Alain Ketterlin wrote:
> "E.D.G." <edgr...@ix.netcom.com> writes:
>
>> The calculation speed question just involves relatively simple
>> math such as multiplications and divisions and trig calculations such
>> as sin and tan etc.
>
> These are not "simple" computations.
>
> Any compiled language (Fortran, C, C++, typically) will probably go much
> faster than any interpreted/bytecode-based language (like python or
> perl, anything that does not use a jit).
>

From http://docs.python.org/3/library/math.html "CPython implementation
detail: The math module consists mostly of thin wrappers around the
platform C math library functions."

There's only one way I know of to find if it's actually fast enough and
that's test it.

[Alain Ketterlin]

Well, sure, yes, I agree with you and hope they are left to the FP
engine (still, fp ops are often multi-cycle, but that's a minor point).

But what I meant was: a (bytecode) interpreted program will always be
slower than a compiled program, probably by an order of magnitude when
doing number crunching.

-- Alain.

[Robert Kern]

On 2013-10-31 14:05, Chris Angelico wrote:
> On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
> <al...@dpt-info.u-strasbg.fr> wrote:

>> "E.D.G." <edgr...@ix.netcom.com> writes:
>>
>>> The calculation speed question just involves relatively simple
>>> math such as multiplications and divisions and trig calculations such
>>> as sin and tan etc.
>>
>> These are not "simple" computations.
>>
>> Any compiled language (Fortran, C, C++, typically) will probably go much
>> faster than any interpreted/bytecode-based language (like python or
>> perl, anything that does not use a jit).
>

> Well, they may not be simple to do, but chances are you can push the
> work down to the CPU/FPU on most modern hardware - that is, if you're
> working with IEEE floating point, which I'm pretty sure CPython always
> does; not sure about other Pythons. No need to actually calculate trig
> functions unless you need arbitrary precision (and even then, I'd bet
> the GMP libraries have that all sewn up for you). So the language
> doesn't make a lot of difference.

Sure it does. Python boxes floats into a PyObject structure. Both Python and C
will ultimately implement the arithmetic of "a + b" with an FADD instruction,
but Python will do a bunch of pointer dereferencing, hash lookups, and function
calls before it gets down to that. All of that overhead typically outweighs the
floating point computations down at the bottom, even for the more expensive trig
functions.

This is where numpy comes in. If you can arrange your computation on arrays,
then only the arrays need to be unboxed once, then the rest of the arithmetic
happens in C.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Chris Angelico]

Yeah, but it depends on what your number crunching actually involves.

If you're implementing crypto in Python, then yes, there's a lot of
actual Python number crunching, and it's going to be slow. But
calculating the cosine of 1.23456 is going to take very close to the
same amount of time in each - the work isn't being done in Python.

But yes, Python code does tend to be a lot slower than equivalent C.
The goal of Python is not to lick (or even challenge) C for raw speed,
but to be "fast enough", and to be easy to write and clear to read. It
does a fairly good job at that.

ChrisA

[Alain Ketterlin]

Mark Lawrence <bream...@yahoo.co.uk> writes:

> On 31/10/2013 13:17, Alain Ketterlin wrote:
>> "E.D.G." <edgr...@ix.netcom.com> writes:
>>
>>> The calculation speed question just involves relatively simple
>>> math such as multiplications and divisions and trig calculations such
>>> as sin and tan etc.
>>
>> These are not "simple" computations.
>>
>> Any compiled language (Fortran, C, C++, typically) will probably go much
>> faster than any interpreted/bytecode-based language (like python or
>> perl, anything that does not use a jit).
>>
>
> From http://docs.python.org/3/library/math.html "CPython
> implementation detail: The math module consists mostly of thin
> wrappers around the platform C math library functions."

Of course, at the end, you need to do the computation.

I was not clear enough. I meant: the time taken by the bytecode
interpreter is probably larger than the time taken to compute the
result (and not only for +).

> There's only one way I know of to find if it's actually fast enough
> and that's test it.

Whether they are "fast enough" or not is another question and depends on
the application. It seems that the OP feels they are not fast enough (in
perl, but I see no reason why it would be better in python).

-- Alain.

[Chris Angelico]

On Fri, Nov 1, 2013 at 1:41 AM, Robert Kern <rober...@gmail.com> wrote:
> On 2013-10-31 14:05, Chris Angelico wrote:
>>

>> On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
>> <al...@dpt-info.u-strasbg.fr> wrote:
>>>
>>> "E.D.G." <edgr...@ix.netcom.com> writes:
>>>
>>>> The calculation speed question just involves relatively simple
>>>> math such as multiplications and divisions and trig calculations such
>>>> as sin and tan etc.
>>>
>>>
>>> These are not "simple" computations.
>>>
>>> Any compiled language (Fortran, C, C++, typically) will probably go much
>>> faster than any interpreted/bytecode-based language (like python or
>>> perl, anything that does not use a jit).
>>
>>

>> Well, they may not be simple to do, but chances are you can push the
>> work down to the CPU/FPU on most modern hardware - that is, if you're
>> working with IEEE floating point, which I'm pretty sure CPython always
>> does; not sure about other Pythons. No need to actually calculate trig
>> functions unless you need arbitrary precision (and even then, I'd bet
>> the GMP libraries have that all sewn up for you). So the language
>> doesn't make a lot of difference.
>
>
> Sure it does. Python boxes floats into a PyObject structure. Both Python and
> C will ultimately implement the arithmetic of "a + b" with an FADD
> instruction, but Python will do a bunch of pointer dereferencing, hash
> lookups, and function calls before it gets down to that. All of that
> overhead typically outweighs the floating point computations down at the
> bottom, even for the more expensive trig functions.

Of course that's true, but that difference is just as much whether
you're working with addition or trig functions. That overhead is the
same. So if, as I said in the other post, you're doing some heavy
crypto work or something, then yes, all that boxing and unboxing is
expensive. Most programs aren't doing that, so the advantage is far
less (by proportion).

Plus, high level languages like Python make it a *LOT* easier to work
with arbitrary-precision integers than C does. In Python, you just
work with the default integer type and it's infinite-precision. In C,
you have to switch to explicitly using GMP (or equivalent). I'd much
rather pay the overhead and have the convenience of int being able to
store any integer.

ChrisA

[Robert Kern]

On 2013-10-31 14:49, Chris Angelico wrote:
> On Fri, Nov 1, 2013 at 1:41 AM, Robert Kern <rober...@gmail.com> wrote:
>> On 2013-10-31 14:05, Chris Angelico wrote:
>>>
>>> On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
>>> <al...@dpt-info.u-strasbg.fr> wrote:
>>>>

>>>> "E.D.G." <edgr...@ix.netcom.com> writes:
>>>>
>>>>> The calculation speed question just involves relatively simple
>>>>> math such as multiplications and divisions and trig calculations such
>>>>> as sin and tan etc.
>>>>
>>>>
>>>> These are not "simple" computations.
>>>>
>>>> Any compiled language (Fortran, C, C++, typically) will probably go much
>>>> faster than any interpreted/bytecode-based language (like python or
>>>> perl, anything that does not use a jit).
>>>
>>>

>>> Well, they may not be simple to do, but chances are you can push the
>>> work down to the CPU/FPU on most modern hardware - that is, if you're
>>> working with IEEE floating point, which I'm pretty sure CPython always
>>> does; not sure about other Pythons. No need to actually calculate trig
>>> functions unless you need arbitrary precision (and even then, I'd bet
>>> the GMP libraries have that all sewn up for you). So the language
>>> doesn't make a lot of difference.
>>
>>
>> Sure it does. Python boxes floats into a PyObject structure. Both Python and
>> C will ultimately implement the arithmetic of "a + b" with an FADD
>> instruction, but Python will do a bunch of pointer dereferencing, hash
>> lookups, and function calls before it gets down to that. All of that
>> overhead typically outweighs the floating point computations down at the
>> bottom, even for the more expensive trig functions.
>
> Of course that's true, but that difference is just as much whether
> you're working with addition or trig functions. That overhead is the
> same. So if, as I said in the other post, you're doing some heavy
> crypto work or something, then yes, all that boxing and unboxing is
> expensive.

Yes, Alain was wrong to suggest that these are not "simple calculations" and
thus will benefit from a lower-level language. In fact, the relationship is
reversed. These are *such* simple operations that they do benefit from the
immediate surrounding code being done in C. The amount of time spent on overhead
doesn't change based on the operation itself but the immediate surrounding code,
the inner loops. That's where the language (implementation) matters.

> Most programs aren't doing that, so the advantage is far
> less (by proportion).

But we're not talking about most programs. We are talking about the OP's
programs, which apparently *do* involve lots of iterated floating point
calculations.

[rusi]

On Thursday, October 31, 2013 4:08:48 PM UTC+5:30, E.D.G. wrote:
> Posted by E.D.G. October 31, 2013

> Hi Chris,

> Thanks for the responses. Several of my questions were answered.

> The calculation speed question just involves relatively
> simple math such as multiplications and divisions and trig
> calculations such as sin and tan etc. Presently I am using Perl to
> do those types of calculations. And I am starting to run into
> problems with how long it takes Perl to do thousands and even
> millions of calculations like that even though they are relatively
> simple.

If raw machine performance is your main concern, python will likely
not will prizes*

Not sure what will… you may look at Julia: http://julialang.org/

Some extracts from there:
--------------------
Julia is a dynamic language in the tradition of Lisp, Perl, Python and
Ruby. It aims to advance expressiveness and convenience for scientific
and technical computing beyond that of environments like Matlab and
NumPy, while simultaneously closing the performance gap with compiled
languages like C, C++, Fortran and Java.

Most high-performance dynamic language implementations have taken an
existing interpreted language and worked to accelerate its
execution. In creating Julia, we have reconsidered the basic language
design, taking into account the capabilities of modern JIT compilers
and the specific needs of technical computing. Our design includes:

- Multiple dispatch as the core language paradigm.
- Exposing a sophisticated type system including parametric dependent types.
- Dynamic type inference to generate fast code from programs with no
declarations.
- Aggressive specialization of generated code for types encountered at run-time.

Julia feels light and natural for data exploration and algorithm
prototyping, but has performance that lets you deploy your prototypes.


----
* Considering my recent posts "treat python as a given", Im not being consistent. Must be getting senile :D

[Skip Montanaro]

> 1. How fast can Python do math calculations compared with other languages
> such as Fortran and fast versions of Basic. I would have to believe that it
> is much faster than Perl for doing math calculations.

As others have indicated, a lot depends on the form of your
calculations. There is a cost to crossing the Python/C boundary, and
you may or may not care about the other stuff Python can do
on-the-fly, like promote ints to Python longs, check for zero
division, etc. If you have floating point code that is array-like,
then organizing it to use numpy can be a big win, as you will cross
that expensive boundary much less often per underlying operation. (I'm
thinking here of more complex operations like trigonometric functions,
not simple adds and subtracts, which are handled by the Python virtual
machine.)

I will relate one anecdote from my job here which highlights the cost
of the boundary. I work at a trading firm. I work solely within a
Python world, but my stuff is built on top of a lot of C++ code
developed by others at the firm. Several years ago, it was decided
that we needed a price library because some exchanges (the London
Stock Exchange, for example) sets the minimum price change based on
the current trading price range. Consider a stock like AAPL, which
closed yesterday at 489.56. It trades in pennies on NASDAQ, no matter
its price. If it was on the LSE, it might trade in half pennies if it
was trading in a $100 range, or in dimes if it was trading near $1000
range. (I'm making this stuff up, just to give you an idea what I'm
referring to.)

So, a price library was written in C++. You could ask for the next
higher or lower valid price. It was all very peppy, because of course,
it relied heavily on C++ inline functions for all these simple
operations. It was wrapped with Boost::Python and tossed over the
fence for us Python peons to use. Guess what? It was unbearably slow,
because not only did we were crossing the Python/C boundary to do
little more (most of the time) than a single add or subtract.

The solution was to write a pure Python version of the parts that mattered most.

Moral of the story: consider how your code is structured and whether
it makes sense to reorganize it when implementing in Python.

Skip

[William Ray Wing]

On Oct 31, 2013, at 5:31 AM, "E.D.G." <edgr...@ix.netcom.com> wrote:

> Posted by E.D.G. on October 31, 2013
>
> The following are several relatively basic questions regarding Python's capabilities. I am not presently using it myself. At the moment a number of people including myself are comparing it with other programs such as XBasic for possible use.
>
> 1. How fast can Python do math calculations compared with other languages such as Fortran and fast versions of Basic. I would have to believe that it is much faster than Perl for doing math calculations.
>

[byte]

> 4. How well does Python work for interactive programming. For example, if a Python program is running on a PC and is drawing a chart, can that chart be modified by simply pressing a key while the Python program is running. I have Perl and Gnuplot program combinations that can do that. Their interactive speed is not that great. But it is adequate for my own uses.
>

I thought about responding to this yesterday, decided others could do so better than I, but then decided to point out a bit of demo code that was one of the first really startling pieces of Python that I stumbled into.

If you look here: http://wiki.wxpython.org/MatplotlibFourierDemo

You will find a fairly short, well documented demo code that interactively computes a Fast Fourier transform from the frequency domain to the time domain. As you move the two sliders below the graphs, the input aptitude and location of the frequency peaks are changed and the resulting wavelet is plotted, all in real time.

Computing a Fourier transform is numerically pretty intensive, doing so in real time with no perceptible delay (at least on a reasonably modern system) should convince any skeptic of Python's ability to do BOTH number crunching AND interactive display.

Granted, this performance is based on pulling in libraries. It imports numpy, mathplotlib, and wx to handle the fast array calculations, the plotting, and the GUI respectively, but those are exactly the sorts of "batteries included" libraries that give Python so much power and flexibility.

-Bill

[Ethan Furman]

On 11/01/2013 08:42 AM, William Ray Wing wrote:
>
> Granted, this performance is based on pulling in libraries. It imports numpy, mathplotlib, and wx to handle the fast array calculations, the plotting, and the GUI respectively, but those are exactly the sorts of "batteries included" libraries that give Python so much power and flexibility.

Not to take away from your points about Python, combined with the appropriate libraries, being fast enough, but the
"batteries included" refers to what comes in the stdlib -- those three libraries are not in the stdlib, so they're more
along the lines of "power generators easily acquired". :)

--
~Ethan~

[William Ray Wing]

> --
> https://mail.python.org/mailman/listinfo/python-list

Strictly speaking, you are absolutely correct. But, those three libraries are SO widely available (for so many platforms), I took the liberty of being inclusive.

Thanks,
Bill

[E.D.G.]

"rusi" <rusto...@gmail.com> wrote in message
news:1e63687b-4269-42d9...@googlegroups.com...

>>Not sure what will� you may look at Julia: http://julialang.org/

That program language speed comparison table looks quite interesting.
And I asked some of the other people that I work with to take a look at the
Web page. One or two of them might want to consider using it instead of
XBasic assuming the calculation speeds and chart generation capabilities are
at least roughly equal. If either of them decides to move in that direction
I will probably try using it myself.

[E.D.G.]

"E.D.G." <edgr...@ix.netcom.com> wrote in message
news:UdGdnaDGa6n9vu_P...@earthlink.com...

Thanks for all of the comments. I have been away from my Internet
connection for several days and could not respond to them when they were
first posted here.

The comments have all been considered. And I am discussing them with
other researchers that I work with. Since Perl has a calculation speed limit
that is probably not easy to get around, before too long another language
will be selected for initially doing certain things such as performing
calculations and plotting charts. And the existing Perl code might then be
gradually translated into that new language.

Gnuplot is presently being used to draw charts. And it works. But it
has its own limitations such as with its interaction speed when it is used
for working with Perl program generated data files.

My main, complex programs won't be run at Web sites. They will
instead continue to be available as downloadable exe programs. The CGI (or
whatever) programming work would involve relatively simple programs. But
they would need to be able to generate charts that would be displayed on Web
pages. That sounds like it is probably fairly easy to do using Python. A
Perl - Gnuplot combination is also supposed to be able to do that. But so
far I have not seen any good explanations for how to actually get Gnuplot to
run as a callable CGI program. So other programs such as Python are being
considered.

[E.D.G.]

"Mark Lawrence" <bream...@yahoo.co.uk> wrote in message
news:mailman.1873.1383227...@python.org...

> https://pypi.python.org/pypi/pywinauto/0.3.9 or
> http://stackoverflow.com/questions/1823762/sendkeys-for-python-3-1-on-windows

Python "SendKey" looks like it probably works about the same as the Perl
version. It prints or sends control information to the active window.

[E.D.G.]

"William Ray Wing" <w...@mac.com> wrote in message
news:mailman.1934.1383320...@python.org...

>>If you look here: http://wiki.wxpython.org/MatplotlibFourierDemo

A suggestion that I would like to add is that when people make "Demo"
programs like that available they might want to create exe versions that
people can download and try without installing the original programming
language. However, there might have been an exe version at that Web site
and I just didn't see it.

I myself use expendable backup computers (Windows XP) for testing new
exe programs so that problems are not created for my primary computer. If
something goes wrong on one of the backup systems it is simply told to go
back to an earlier restore point.

[rusi]

On Sunday, November 3, 2013 11:15:48 AM UTC+5:30, E.D.G. wrote:
> "rusi" wrote:

> >>Not sure what will… you may look at Julia: http://julialang.org/

> That program language speed comparison table looks quite interesting.
> And I asked some of the other people that I work with to take a look at the
> Web page. One or two of them might want to consider using it instead of
> XBasic assuming the calculation speeds and chart generation capabilities are
> at least roughly equal. If either of them decides to move in that direction
> I will probably try using it myself.

And please post back your findings when you have some concrete data

For the record I have exactly zero experience with Julia.

[Steven D'Aprano]

On Sun, 03 Nov 2013 01:02:24 -0500, E.D.G. wrote:

[...]

> Since Perl has a calculation speed
> limit that is probably not easy to get around, before too long another
> language will be selected for initially doing certain things such as
> performing calculations and plotting charts. And the existing Perl code
> might then be gradually translated into that new language.

The nice things about Python are that it makes a great glue language for
putting together components written in low-level languages like C and
Fortran, and that there is a rich ecosystem of products for speeding it
up in various ways. So when you hit the speed limits of pure Python, you
have lots of options. In no particular order:


* try using another Python compiler: PyPy is probably the most
mature of the stand-alone optimizing compilers, and you can
expect to double the speed of "typical" Python code, but
there are others;

* use numpy and scipy for vectorized mathematical routines;

* re-write critical code as C or Fortran libraries;

* use Pyrex (possibly unmaintained now) or Cython to write
C extensions in a Python-like language;

* use Psyco or Numba (JIT specialising compilers for Python);

* use Theano (optimizing computer algebra system compiler);

* use ctypes to call C functions directly;

* use other products like Boost, Weave, and more.


See, for example:

http://jakevdp.github.io/blog/2013/06/15/numba-vs-cython-take-2/

http://technicaldiscovery.blogspot.com.au/2011/06/speeding-up-python-numpy-cython-and.html



--
Steven

[E.D.G.]

"Steven D'Aprano" <steve+comp....@pearwood.info> wrote in message
news:5275fe91$0$29972$c3e8da3$5496...@news.astraweb.com...

> http://jakevdp.github.io/blog/2013/06/15/numba-vs-cython-take-2/
>
> http://technicaldiscovery.blogspot.com.au/2011/06/speeding-up-python-numpy-cython-and.html

It appears that Python can do what is needed. And if the people that
I work with want to move in that direction I will probably post a note here
stating, "This is exactly what we need to do. What would be the best Python
download and compiler to do that?"

It should be a simple matter to determine which compiler and libraries
etc. should be used.

[Mark Lawrence]

I've literally just stumbled across this, I've no idea whether it's of
any use to you https://speakerdeck.com/ianozsvald/high-performance-python

[Jim Gibson]

In article <OKCdnXfaQqxze-jP...@earthlink.com>, E.D.G.

<edgr...@ix.netcom.com> wrote:

> My main, complex programs won't be run at Web sites. They will
> instead continue to be available as downloadable exe programs. The CGI (or
> whatever) programming work would involve relatively simple programs. But
> they would need to be able to generate charts that would be displayed on Web
> pages. That sounds like it is probably fairly easy to do using Python. A
> Perl - Gnuplot combination is also supposed to be able to do that. But so
> far I have not seen any good explanations for how to actually get Gnuplot to
> run as a callable CGI program. So other programs such as Python are being
> considered.

One way to generate plot within a CGI program is this:

1. Write a file with gnuplot commands (e.g., 'gnuplot.cmd') that set
the output device to a graphics file of some format (e.g., PNG),
generate a plot, and quit gnuplot.

2. Run gnuplot and point it to the file of commands (e.g., 'gnuplot
gunplot.cmd') . How this is done depends upon the CGI program language
(see below).

3. Generate HTML that uses the generated graphics file as an embedded
image (using the <img> tag).

I have done this in the past, but not recently. This should work for
Python (os.system("gnuplot gnuplot.cmd") or Perl (system("gnuplot
gnuplot.cmd") with suitable commands to execute external programs.

--
Jim Gibson

[rusi]

Yes python is really state-of-art in this respect:
Every language will have some area where it sucks.
Allowing for a hatch where one could jump out is helpful.
Python allows more such hatches than probably any other language (that I know)

https://mail.python.org/pipermail/python-list/2012-August/628090.html
is a (non exhaustive) list I had made some time.

On the other hand if you know you are going to be escaping out often,
you may want to consider whether the 'escapee' should be your base
rather than python.

Which means take something like the pairwise function and code it up in python and julia -- its hardly 10 lines of code. And see what comparative performance you get.

[Mark Lawrence]

On 03/11/2013 18:28, rusi wrote:
>
> Which means take something like the pairwise function and code it up in python and julia -- its hardly 10 lines of code. And see what comparative performance you get.
>

Solely on the grounds that you've mentioned julia how about this
http://blog.leahhanson.us/julia-calling-python-calling-julia.html

[Grant Edwards]

On 2013-11-03, Jim Gibson <JimSG...@gmail.com> wrote:
> In article <OKCdnXfaQqxze-jP...@earthlink.com>, E.D.G.
><edgr...@ix.netcom.com> wrote:
>
>> My main, complex programs won't be run at Web sites. They will
>> instead continue to be available as downloadable exe programs. The CGI (or
>> whatever) programming work would involve relatively simple programs. But
>> they would need to be able to generate charts that would be displayed on Web
>> pages. That sounds like it is probably fairly easy to do using Python. A
>> Perl - Gnuplot combination is also supposed to be able to do that. But so
>> far I have not seen any good explanations for how to actually get Gnuplot to
>> run as a callable CGI program. So other programs such as Python are being
>> considered.
>
> One way to generate plot within a CGI program is this:
>
> 1. Write a file with gnuplot commands (e.g., 'gnuplot.cmd') that set
> the output device to a graphics file of some format (e.g., PNG),
> generate a plot, and quit gnuplot.

Or you can use the pygnuplot module which handles much of that for y0ou.

http://pygnuplot.sourceforge.net/

--
Grant

[rusi]

On Monday, November 4, 2013 12:28:24 AM UTC+5:30, Mark Lawrence wrote:
> On 03/11/2013 18:28, rusi wrote:
> > Which means take something like the pairwise function and code it
> > up in python and julia -- its hardly 10 lines of code. And see
> > what comparative performance you get.

> Solely on the grounds that you've mentioned julia how about this
> http://blog.leahhanson.us/julia-calling-python-calling-julia.html

Good stuff -- thanks

[E.D.G.]

"Jim Gibson" <JimSG...@gmail.com> wrote in message
news:031120131018099327%JimSG...@gmail.com...

> One way to generate plot within a CGI program is this:

To start off with, I am not a CGI expert. Also, I have several
degrees in the physical sciences and many years of doing computer
programming. But the programming work is done just to get various science
projects to work.

The question that I could not get an answer for was, “How can you get
Gnuplot to run on an Internet server computer?”

And I would eventually have to ask that same question for Python.

My Internet Server looks like it has Perl, Perl5, and PHP available.
And I have created a number of CGI Perl programs that run on the Web site.
But as I said, I would not know how to get Gnuplot or Python to run at the
site.

Any recommendations for how to do that? Or should I just do a search
for the necessary documentation?

[88888 Dihedral]

Please try modpy.

[sig...@kcl.ac.uk]

On Q4, you could try Waterloo Graphics <http://waterloo.sourceforge.net>. Its LGPLv3 and, although Java-based, runs in Python via Py4J. It has built-in mouse interactivity/GUI editors etc that will all be active when used from Python.

It is Java Swing-based, so e.g. data points can be drawn as standard clickable Swing components (see http://waterloo.sourceforge.net/R/scatter.html for an example using R [N.B. not interactive on the web site which just shows a bit-map]).

For Python examples see http://waterloo.sourceforge.net/python/grid.html

On Thursday, October 31, 2013 9:31:11 AM UTC, E.D.G. wrote:
> Posted by E.D.G. on October 31, 2013
>
>
>
> The following are several relatively basic questions regarding Python's
>
> capabilities. I am not presently using it myself. At the moment a number
>
> of people including myself are comparing it with other programs such as
>
> XBasic for possible use.
>
>
>
> 1. How fast can Python do math calculations compared with other languages
>
> such as Fortran and fast versions of Basic. I would have to believe that it
>
> is much faster than Perl for doing math calculations.
>
>
>

> 2. Can Python be used to create CGI programs? These are the ones that run
>
> on Internet server computers and process data submitted through Web site
>
> data entry screens etc. I know that Perl CGI programs will do that.
>
>
>
> 3. If Python can be used for CGI programming, can it draw charts such as
>
> .png files that will then display on Web pages at a Web site?

>
>
>
> 4. How well does Python work for interactive programming. For example, if
>
> a Python program is running on a PC and is drawing a chart, can that chart
>
> be modified by simply pressing a key while the Python program is running. I
>
> have Perl and Gnuplot program combinations that can do that. Their
>
> interactive speed is not that great. But it is adequate for my own uses.
>
>
>

> 5. Can a running Python program send information to the Windows operating
>
> system as if it were typed in from the keyboard? Perl can do that and I
>
> would imagine that Python probably has that same capability.

[E.D.G.]

"E.D.G." <edgr...@ix.netcom.com> wrote in message

news:yo-dnWFmi7_7d-jP...@earthlink.com...

Posted by E.D.G. on November 12, 2013

The following is part of a note that I just posted to the Perl
Newsgroup. But it is actually intended for all computer programmers who are
circulating free download software.

One of the people that I work with and I are using an important
computer program that is quite unique. It was created a long time ago by a
highly regarded scientist who passed away a while back. And he made three
copies of the program available for people as free downloads. The first is
an exe version of the program that will run on any Windows machine. The
second is the code for the program written using what is now an ancient
version of Fortran. And the third is for the same program using an ancient
version of Basic.

The professional programmer and I attempted to produce versions of
the program using a modern language. I managed the project and the
programmer did the actual work. And unfortunately, in spite of his many
years of experience he could not understand the Fortran and Basic versions
to the point where he could translate them. I recommended that he post some
notes to the Fortran Newsgroup and ask if anyone visiting that Newsgroup had
an instruction manual for that ancient version of Fortran that would explain
what the program code meant. But for some reason he chose not to do that.
And it would have taken me a considerable amount of time to attempt the
translation myself.

So, the end result is that when the program needs to generate data,
the exe version is used "as is." Or it is called from a Perl program and
given the input information it needs so that it can generate data.

The point is, when people want to make some computer program
available for use by others around the world they might want to circulate a
version of their program that has such a simple format that anyone can
understand it. And for actual use they can generate parallel versions that
have more efficient code that people who are working with that language can
understand.

[Chris Angelico]

On Tue, Nov 12, 2013 at 9:21 PM, E.D.G. <edgr...@ix.netcom.com> wrote:
> The point is, when people want to make some computer program available
> for use by others around the world they might want to circulate a version of
> their program that has such a simple format that anyone can understand it.
> And for actual use they can generate parallel versions that have more
> efficient code that people who are working with that language can
> understand.

Sounds to me like something out of cryptography. You have a "reference
implementation" that's slow, readable, and straight-forward, and then
you have "optimized implementations" that are actually fast enough to
use - but if any time you want to know if you're producing the right
output, you just compare against the reference implementation.

ChrisA