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

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

Basic Python Questions - Oct. 31, 2013

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

Contents

  Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-10-31 04:31 -0500
    Re: Basic Python Questions - Oct. 31, 2013 Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-10-31 11:03 +0100
      Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-10-31 05:38 -0500
        Re: Basic Python Questions - Oct. 31, 2013 Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-10-31 12:30 +0100
        Re: Basic Python Questions - Oct. 31, 2013 Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-10-31 14:17 +0100
          Re: Basic Python Questions - Oct. 31, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-01 01:05 +1100
            Re: Basic Python Questions - Oct. 31, 2013 Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-10-31 15:18 +0100
              Re: Basic Python Questions - Oct. 31, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-01 01:45 +1100
          Re: Basic Python Questions - Oct. 31, 2013 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-31 14:15 +0000
            Re: Basic Python Questions - Oct. 31, 2013 Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-10-31 15:31 +0100
          Re: Basic Python Questions - Oct. 31, 2013 Robert Kern <robert.kern@gmail.com> - 2013-10-31 14:41 +0000
          Re: Basic Python Questions - Oct. 31, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-01 01:49 +1100
          Re: Basic Python Questions - Oct. 31, 2013 Robert Kern <robert.kern@gmail.com> - 2013-10-31 15:11 +0000
        Re: Basic Python Questions - Oct. 31, 2013 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-31 13:48 +0000
          Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 01:17 -0500
            Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-12 04:21 -0600
              Re: Basic Python Questions - Oct. 31, 2013 Chris Angelico <rosuav@gmail.com> - 2013-11-13 10:05 +1100
        Re: Basic Python Questions - Oct. 31, 2013 rusi <rustompmody@gmail.com> - 2013-10-31 08:48 -0700
          Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 00:45 -0500
            Re: Basic Python Questions - Oct. 31, 2013 rusi <rustompmody@gmail.com> - 2013-11-02 23:54 -0700
    Re: Basic Python Questions - Oct. 31, 2013 Roy Smith <roy@panix.com> - 2013-10-31 09:20 -0400
    Re: Basic Python Questions - Oct. 31, 2013 Skip Montanaro <skip@pobox.com> - 2013-10-31 11:14 -0500
    Re: Basic Python Questions - Oct. 31, 2013 William Ray Wing <wrw@mac.com> - 2013-11-01 11:42 -0400
      Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 01:28 -0500
    Re: Basic Python Questions - Oct. 31, 2013 Ethan Furman <ethan@stoneleaf.us> - 2013-11-01 11:08 -0700
    Re: Basic Python Questions - Oct. 31, 2013 William Ray Wing <wrw@mac.com> - 2013-11-01 15:17 -0400
    Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 01:02 -0500
      Re: Basic Python Questions - Oct. 31, 2013 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-03 07:43 +0000
        Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-03 03:47 -0600
          Re: Basic Python Questions - Oct. 31, 2013 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-03 10:05 +0000
        Re: Basic Python Questions - Oct. 31, 2013 rusi <rustompmody@gmail.com> - 2013-11-03 10:28 -0800
          Re: Basic Python Questions - Oct. 31, 2013 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-03 18:58 +0000
            Re: Basic Python Questions - Oct. 31, 2013 rusi <rustompmody@gmail.com> - 2013-11-03 20:07 -0800
      Re: Basic Python Questions - Oct. 31, 2013 Jim Gibson <JimSGibson@gmail.com> - 2013-11-03 10:18 -0800
        Re: Basic Python Questions - Oct. 31, 2013 Grant Edwards <invalid@invalid.invalid> - 2013-11-03 23:16 +0000
        Re: Basic Python Questions - Oct. 31, 2013 "E.D.G." <edgrsprj@ix.netcom.com> - 2013-11-04 23:22 -0600
          Re: Basic Python Questions - Oct. 31, 2013 88888 Dihedral <dihedral88888@gmail.com> - 2013-11-07 06:05 -0800
    Re: Basic Python Questions - Oct. 31, 2013 sigtool@kcl.ac.uk - 2013-11-10 06:40 -0800

Page 1 of 2  [1] 2  Next page →

#58157 — Basic Python Questions - Oct. 31, 2013

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.

[toc] | [next] | [standalone]

#58159

On Thu, Oct 31, 2013 at 10:31 AM, E.D.G. <edgrsprj@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

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

#58162

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.

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

#58166

On Thu, Oct 31, 2013 at 11:38 AM, E.D.G. <edgrsprj@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/

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

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

#58171

"E.D.G." <edgrsprj@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.

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

#58174

On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
<alain@dpt-info.u-strasbg.fr> wrote:
> "E.D.G." <edgrsprj@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

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

#58176

Chris Angelico <rosuav@gmail.com> writes:

> On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
> <alain@dpt-info.u-strasbg.fr> wrote:
>> "E.D.G." <edgrsprj@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.

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.

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

#58178

On Fri, Nov 1, 2013 at 1:18 AM, Alain Ketterlin
<alain@dpt-info.u-strasbg.fr> wrote:
> 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.

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

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

#58175

On 31/10/2013 13:17, Alain Ketterlin wrote:
> "E.D.G." <edgrsprj@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.

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

Mark Lawrence

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

#58179

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

> On 31/10/2013 13:17, Alain Ketterlin wrote:
>> "E.D.G." <edgrsprj@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.

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

#58177

On 2013-10-31 14:05, Chris Angelico wrote:
> On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
> <alain@dpt-info.u-strasbg.fr> wrote:
>> "E.D.G." <edgrsprj@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

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

#58180

On Fri, Nov 1, 2013 at 1:41 AM, Robert Kern <robert.kern@gmail.com> wrote:
> On 2013-10-31 14:05, Chris Angelico wrote:
>>
>> On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
>> <alain@dpt-info.u-strasbg.fr> wrote:
>>>
>>> "E.D.G." <edgrsprj@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

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

#58183

On 2013-10-31 14:49, Chris Angelico wrote:
> On Fri, Nov 1, 2013 at 1:41 AM, Robert Kern <robert.kern@gmail.com> wrote:
>> On 2013-10-31 14:05, Chris Angelico wrote:
>>>
>>> On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
>>> <alain@dpt-info.u-strasbg.fr> wrote:
>>>>
>>>> "E.D.G." <edgrsprj@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.

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

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

#58172

On 31/10/2013 10:38, 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.
>
>        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.
>

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

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

#58372

"Mark Lawrence" <breamoreboy@yahoo.co.uk> wrote in message 
news:mailman.1873.1383227352.18130.python-list@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.

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

#59178

"E.D.G." <edgrsprj@ix.netcom.com> wrote in message 
news:yo-dnWFmi7_7d-jPnZ2dnUVZ_hqdnZ2d@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.

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

#59252

On Tue, Nov 12, 2013 at 9:21 PM, E.D.G. <edgrsprj@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

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

#58186

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

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

#58366

"rusi" <rustompmody@gmail.com> wrote in message 
news:1e63687b-4269-42d9-8700-e3a8dcc5773f@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.

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

#58375

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.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web