[Edu-sig] introducing python

[kirby urner]

When I start introducing Python I use this chart [1]:

Five Dimensions of Python:


   - Level 0: core syntax with keywords & punctuation, indentation (import,
   if...)
   - Level 1: a large set of built-ins (e.g. print)
   - Level 2: special names with the double underlines
   - Level 3: Standard Library (e.g. math)
   - Level 4: 3rd Party Ecosystem (e.g. numpy, pandas, matplotlib)

Here's a Level 2 topic I've been recently working on:

https://nbviewer.org/github/4dsolutions/m4w/blob/main/gadzooks.ipynb

I know, we don't all love those __ribs__ (special names), however that's a
benefit of Free Open Source: you can fork and adapt, take the best ideas,
and leave the rest.

This one is about how implementing __add__ gets you default behavior
for __iadd__ with no extra work, with the option to go on to add your
own __iadd__.

Kirby


[1] example of me doing that:

https://github.com/4dsolutions/clarusway_data_analysis/blob/main/python_warm_up/warmup_python_intro.ipynb

coming from:

https://nbviewer.org/github/4dsolutions/clarusway_data_analysis/blob/main/DAwPy_S1_%28Numpy_Arrays%29/daily_schedule.ipynb

(Exhibit: some Python teaching in the wild)
___
Edu-sig mailing list -- edu-sig@python.org
To unsubscribe send an email to edu-sig-le...@python.org
https://mail.python.org/mailman3/lists/edu-sig.python.org/
Member address: arch...@mail-archive.com

[Edu-sig] Introducing Python... callables = {types, functions}

[kirby urner]

I'm on Safari On-Line sampling:

Introduction to Python by Jessica McKellar
O'Reilly Media, Inc., 2014

a multi-hour video series.

I enjoy and value getting ideas from other Python
instructors.  I'm scheduled to start a new round
myself this very evening.

What's standing out for me is how often Jessica
uses the phrase "just like in math class" or "as
you'd expect from math class".

Exactly, reminding viewers of "math class" is
as bridge to previous relevant experience for
most, though not all.

"Using Python as a calculator" is a standard
on-ramp since Guido's original tutorial.  I do
that too.  I bet most of us do.  We start in a
REPL.

I appreciate that Jessica starts using type( )
immediately, in the first few minutes, at first
to distinguish type(1) from type(1.0) to tease
apart ints and floats.

Instilling a sense of objects being of various
types is going to help students think like
computer scientists and understand the
deep grammar of Python better.

I also tend to introduce dir( ) and help( ) almost
immediately, to give a sense of the built-in
environment and how to inspect it.

Jessica wants to covers int, float, str and bool
then start diving in to control structures right
away, with if, elif, else and comparison operators
(==, >=, < etc.).  We're doing if statements in the
REPL within the first 30 minutes.

I'm also prone to introduce the words "callable"
and "name" early on, and discussing how we
distinguish between callable and not-callable
names.  callable() itself is a built-in function:

>>> type(callable)


Partly why I make this distinction is when using
type( ) and str( ), I'm a bit leery of calling str
"a function" to often.  That's bleeping over an
important distinction is it not?

It's a callable for sure:

>>> str(1)
'1'
>>> callable(str)  # does it "eat"?
True

and yet...

>>> type(str)

>>> type(print)  # another callable to share early


In other words, str( ) is a callable but
not really a builtin function.  Like dict,
list, int, float...  it's the name of a type.

When one calls a type directly by name
(not one of its methods), we're actually
giving birth to a new instance of that
type.  Functions aren't necessarily like
that.  They may return anything, of any
type, including None.

When it comes to laying a foundation,
I find it aids understanding to introduce
"callables" as a super-set of "names that
may be called," inside of which we have
"functions" and "types" as example
members.

On the other hand, this is a fine point,
not to be dwelt on but spiraled back to,
especially when keyword "class" is
introduced.

I think Jessica's approach, of glossing over
this distinction in a first pass, is totally viable
and realize the many delicate trade-offs as
"too much too soon" may result in a sense
of overwhelm.

Finally, I like to emphasize the word "name"
over "variable" as I find it important to shake
off any mental imagery of a variable as
"like a box", which imagery teachers of other
languages tend to find useful.

Using the word "name" helps to break the hold
of "container" which is helpful for understanding
how assignment works.

Like Steve Holden, another Python teacher I've
seen in action a few times, I like to setup a
"namespace and object space" distinction, with
names pointing to objects. Object space is also
"the heap":

https://flic.kr/p/DQb8t6

I think it's time to do some new drawings. :-D

Kirby
___
Edu-sig mailing list
Edu-sig@python.org
https://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python at our community college

[Richard Enbody]

David & Massimo,

Our local community college will begin offering Python courses this 
Fall.  As is common with community colleges there is a lot of 'training' 
for particular tools and languages to meet immediate needs of local 
employers.  As a representative of the big, research university in town 
on the community college's advisory board I was pleased to see interest 
both at the college and with employers.  I can put you in contact with 
them, if you are interested (contact me directly at [EMAIL PROTECTED]).


In our department we began using Python in our CS1 course (first 
programming course for majors) last Fall with the CS2 course still 
taught in C++.  I've surveyed and collected data on whether there is a 
difference in the CS2 experience -- this spring was the first CS2 
offering with students who began with Python. The course just finished 
so I expect to take a while to sort through the data.  I can share it 
with anyone who is interested.  It offers interesting possibilities 
since some students had Python first while others had something else 
(C++ and Java mostly). At this point, the instructor of the CS2 course 
is confident that at the very least the Python students are no worse.


-rich
[EMAIL PROTECTED]

Massimo Di Pierro wrote:

Hi David,
I teach at DePaul university where we now use Python in multiple 
classes. The way we got it in was not by proposing Python in 
substitution to Java or C++. I tried it and that failed for the same 
reasons you mention. I got it in by starting to use Python in 
algorithms classes instead of pseudo code (and I did not permission to 
do it). Python also works great in web development courses (we have a 
course on web frameworks and we use web2py) and networking courses.


Personally I believe that typical intro programming courses are 
obsolete because the target population has changed. When our students 
come in, although they cannot program, they already understand the 
concept of network, data transfer, input/output, files. I think it is 
easier to teach programming by teaching how to manipulate these high 
level structures and then work your way down to loops and conditionals 
that to do it the opposite way, the way we used to do it.


Massimo

On May 5, 2008, at 7:24 PM, David MacQuigg wrote:

I talked with the CIS department chairman and one of the faculty 
about the possibility of teaching Python at our community college, 
and they weren't interested.  (Oh No, not another language ... )  
Also, the lack of declarations was a show-stopper.


I encountered this same objection from one of the faculty at U of A, 
where I just gave a lecture.  It doesn't seem to help when I say: In 
four years of using Python, I can remember only one time when I had a 
subtle error from mistyping a variable name that took an hour to 
track down.  I'll gladly trade that hour for the dozens I've saved 
not having to read and write all these declarations.


I've added this to my QnA page at 
http://ece.arizona.edu/~edatools/ece175/Lecture/QnA.txt 



'''
Q2: Without variables declarations, isn't there a problem with mistyped
variable names leading to subtle errors?

A2: It can happen, but the subtle errors are rather rare.  Usually 
you will

get an immediate and clear message like:

   Traceback (most recent call last):
- - -
   NameError: name 'z' is not defined

where 'z' is the name you intended to type.  The subtle error can 
occur if z

is already defined, and you intended to re-define it.

If you worry about errors like this, you can scan your program with a
utility like pychecker, and it will detect any variables that are defined
but never used.
'''

Still, I wonder if there isn't a better way to handle this objection 
to Python.  I'm thinking of a configuration option in IDLE, something 
that will either:


1) Run a subset of pychecker tests every time you hit the Run button, or
2) Insist on declarations in a comment at the start of every function 
(just the names, not data types).  Any name that isn't already 
declared gets immediately painted red.


I would use #1 if it was no time penalty.  #2 seems like "training 
wheels" to me, but I would expect some folks who are religious about 
declarations might at least find it re-assuring.


-- Dave


___
Edu-sig mailing list
Edu-sig@python.org 
http://mail.python.org/mailman/listinfo/edu-sig




___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
  

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python at our community college

[Massimo Di Pierro]

Hi David,
I teach at DePaul university where we now use Python in multiple  
classes. The way we got it in was not by proposing Python in  
substitution to Java or C++. I tried it and that failed for the same  
reasons you mention. I got it in by starting to use Python in  
algorithms classes instead of pseudo code (and I did not permission  
to do it). Python also works great in web development courses (we  
have a course on web frameworks and we use web2py) and networking  
courses.


Personally I believe that typical intro programming courses are  
obsolete because the target population has changed. When our students  
come in, although they cannot program, they already understand the  
concept of network, data transfer, input/output, files. I think it is  
easier to teach programming by teaching how to manipulate these high  
level structures and then work your way down to loops and  
conditionals that to do it the opposite way, the way we used to do it.


Massimo

On May 5, 2008, at 7:24 PM, David MacQuigg wrote:

I talked with the CIS department chairman and one of the faculty  
about the possibility of teaching Python at our community college,  
and they weren't interested.  (Oh No, not another language ... )   
Also, the lack of declarations was a show-stopper.


I encountered this same objection from one of the faculty at U of  
A, where I just gave a lecture.  It doesn't seem to help when I  
say: In four years of using Python, I can remember only one time  
when I had a subtle error from mistyping a variable name that took  
an hour to track down.  I'll gladly trade that hour for the dozens  
I've saved not having to read and write all these declarations.


I've added this to my QnA page at http://ece.arizona.edu/~edatools/ 
ece175/Lecture/QnA.txt


'''
Q2: Without variables declarations, isn't there a problem with  
mistyped

variable names leading to subtle errors?

A2: It can happen, but the subtle errors are rather rare.  Usually  
you will

get an immediate and clear message like:

   Traceback (most recent call last):
- - -
   NameError: name 'z' is not defined

where 'z' is the name you intended to type.  The subtle error can  
occur if z

is already defined, and you intended to re-define it.

If you worry about errors like this, you can scan your program with a
utility like pychecker, and it will detect any variables that are  
defined

but never used.
'''

Still, I wonder if there isn't a better way to handle this  
objection to Python.  I'm thinking of a configuration option in  
IDLE, something that will either:


1) Run a subset of pychecker tests every time you hit the Run  
button, or
2) Insist on declarations in a comment at the start of every  
function (just the names, not data types).  Any name that isn't  
already declared gets immediately painted red.


I would use #1 if it was no time penalty.  #2 seems like "training  
wheels" to me, but I would expect some folks who are religious  
about declarations might at least find it re-assuring.


-- Dave


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python at our community college

[kirby urner]

Thanks Dave --

A wonderful question that points to the great cultural divide
between compile-time versus runtime error trappers.

The compile timers flirt with the notion that somehow the
compiling step might actually constitute a *mathematical proof*
that the program is correct (if only the language were tightly
specified enough, Haskell maybe?).

The run-timers think that by unit testing at the atomic level,
never letting errors pass silently etc.,, they can patch any
few remaining bugs, plus the code itself is just eminently
more readable...

Bruce Eckel is one of your best and most eloquent writers on
this topic, pointing out the superstitions around compiling,
as if all kinds of subtle errors couldn't sneak through, including
at the level of algorithm.

But he's refreshingly non-dogmatic, because after all,
our VHLLs (very high level languages) are implemented in
these faster lower level ones.  It's not either/or but different
tools for different jobs.  Sometimes the difference between
100x slower than C, and not getting it done at all (or in
time) is worth the sacrifice.

Speed is the real payoff for type declarations, not immunity
from error, as it's really *a lot* easier to write buggy yet
executable C than Python, given your average newbie.

Anyway, I'd make the argument on economic grounds:
Python has a good track record, bright future, and lots of
would-be students are eager to learn it, and look to
community colleges as logical doors upon which to knock.

Taking a side in the compile-time versus run-time debate
needn't be a a high priority on anyone's list as we already
know:  it takes both approaches.

But then a lot of faculty are just threatened by another
language they don't know, so turning this into some
philosophical fist fight works as a delaying maneuver.

You may just have to live with the fact that your particular
school feels no real competition, whereas in other towns,
it's easier to jump on the bandwagon and give students
the option.  Ruby too while we're at it?

Kirby


On Mon, May 5, 2008 at 5:24 PM, David MacQuigg <[EMAIL PROTECTED]> wrote:

<< SNIP >>

>  Still, I wonder if there isn't a better way to handle this objection to 
> Python.  I'm thinking of a configuration option in IDLE, something that will 
> either:
>
>  1) Run a subset of pychecker tests every time you hit the Run button, or
>  2) Insist on declarations in a comment at the start of every function (just 
> the names, not data types).  Any name that isn't already declared gets 
> immediately painted red.
>
>  I would use #1 if it was no time penalty.  #2 seems like "training wheels" 
> to me, but I would expect some folks who are religious about declarations 
> might at least find it re-assuring.
>
>  -- Dave
>
>
>  ___
>  Edu-sig mailing list
>  Edu-sig@python.org
>  http://mail.python.org/mailman/listinfo/edu-sig
>
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

[Edu-sig] Introducing Python at our community college

[David MacQuigg]

I talked with the CIS department chairman and one of the faculty about the 
possibility of teaching Python at our community college, and they weren't 
interested.  (Oh No, not another language ... )  Also, the lack of declarations 
was a show-stopper.  

I encountered this same objection from one of the faculty at U of A, where I 
just gave a lecture.  It doesn't seem to help when I say: In four years of 
using Python, I can remember only one time when I had a subtle error from 
mistyping a variable name that took an hour to track down.  I'll gladly trade 
that hour for the dozens I've saved not having to read and write all these 
declarations.

I've added this to my QnA page at 
http://ece.arizona.edu/~edatools/ece175/Lecture/QnA.txt

'''
Q2: Without variables declarations, isn't there a problem with mistyped
variable names leading to subtle errors?

A2: It can happen, but the subtle errors are rather rare.  Usually you will
get an immediate and clear message like:

   Traceback (most recent call last):
- - -
   NameError: name 'z' is not defined

where 'z' is the name you intended to type.  The subtle error can occur if z
is already defined, and you intended to re-define it.

If you worry about errors like this, you can scan your program with a
utility like pychecker, and it will detect any variables that are defined
but never used.
'''

Still, I wonder if there isn't a better way to handle this objection to Python. 
 I'm thinking of a configuration option in IDLE, something that will either:

1) Run a subset of pychecker tests every time you hit the Run button, or
2) Insist on declarations in a comment at the start of every function (just the 
names, not data types).  Any name that isn't already declared gets immediately 
painted red.

I would use #1 if it was no time penalty.  #2 seems like "training wheels" to 
me, but I would expect some folks who are religious about declarations might at 
least find it re-assuring.

-- Dave


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[David MacQuigg]

At 01:41 AM 3/20/2008 +0100, Stef Mientki wrote:

>I started about a year ago with the Enthought edition 
>http://code.enthought.com/enthon/

This leads to a series of deprecated links, some several months old, and no 
clear guidance as to what a student should install.  This website is a mess!!

>under windows-XP, 4 machines some SP1, some SP2,
>used embedded in Delphi, as a direct replacement for embedded Matlab,
>everything worked like a charm.
>In fact everything worked so well,
>that about 3 months ago,
>I decided to make a pure Python (open source) LabView equivalent with it 
>(should be released in a couple of weeks).
>In the meanwhile I also tried to update Scipy,
>but Enthought switched to the eggs-philosophy,
>which seems to be a big disaster to me ( so I rolled everything back to 
>the orginal Entought suite).

I've been hearing good things about eggs, so I'm a little surprised at this.  
Having a manager for Python packages seems like a good idea, but I would rather 
use the standard egg installer from 
http://peak.telecommunity.com/DevCenter/EasyInstall, not an "enstaller" hacked 
for installing one vendor's products.  That could lead to conflicts later, as I 
add eggs from different sources.

>I think if you send this message to the Scipy list,
>you get an answer of Robert Kern himself within half an hour (if he is 
>awake ;-)

What I'm looking for is not help with the current mess, but confidence that 
students won't have to go through the same thing.  I've now run out of time, so 
I'll have to try again in a few months.

-- Dave



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[Stef Mientki]

hi David,

David MacQuigg wrote:
> Our mandelbrot demo is working nicely, thanks to all the help I've gotten 
> from folks on this list.  We are using only the weave package, not the full 
> SciPy install.  It would be nice to show some additional examples from SciPy, 
> however, especially tools that students will find useful in later classes.
>
> The problem is I'm not sure SciPy is ready for prime time in the 
> undergraduate curriculum.  It will look bad if this package is not as good as 
> Matlab, which is what the students at U of A are using in many of their other 
> courses.  I would like to get some opinions on this issue from others who may 
> have been here before.
>
> Here are my experiences so far in getting started with SciPy, trying to run 
> it as I expect our students would, on their own machines rather than the 
> department's Solaris machines.
>
> 1) I'm using a Windows XP machine, similar to what most of the students are 
> using, so anything we want them to install on their own computers must work 
> under Windows, or at least under Cygwin.  Most students don't have Cygwin 
> installed, but we can consider that as part of the package if we decide to go 
> that route.  Cygwin adds benefits beyond SciPy, of course, but disk space may 
> be an issue.
>
>   
I started about a year ago with the Enthought edition 
http://code.enthought.com/enthon/
under windows-XP, 4 machines some SP1, some SP2,
used embedded in Delphi, as a direct replacement for embedded Matlab,
everything worked like a charm.
In fact everything worked so well,
that about 3 months ago,
I decided to make a pure Python (open source) LabView equivalent with it 
(should be released in a couple of weeks).
In the meanwhile I also tried to update Scipy,
but Enthought switched to the eggs-philosophy,
which seems to be a big disaster to me ( so I rolled everything back to 
the orginal Entought suite).

I think if you send this message to the Scipy list,
you get an answer of Robert Kern himself within half an hour (if he is 
awake ;-)

cheers,
Stef Mientki

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[David MacQuigg]

Our mandelbrot demo is working nicely, thanks to all the help I've gotten from 
folks on this list.  We are using only the weave package, not the full SciPy 
install.  It would be nice to show some additional examples from SciPy, 
however, especially tools that students will find useful in later classes.

The problem is I'm not sure SciPy is ready for prime time in the undergraduate 
curriculum.  It will look bad if this package is not as good as Matlab, which 
is what the students at U of A are using in many of their other courses.  I 
would like to get some opinions on this issue from others who may have been 
here before.

Here are my experiences so far in getting started with SciPy, trying to run it 
as I expect our students would, on their own machines rather than the 
department's Solaris machines.

1) I'm using a Windows XP machine, similar to what most of the students are 
using, so anything we want them to install on their own computers must work 
under Windows, or at least under Cygwin.  Most students don't have Cygwin 
installed, but we can consider that as part of the package if we decide to go 
that route.  Cygwin adds benefits beyond SciPy, of course, but disk space may 
be an issue.

2) I tried a direct install under Windows using the installers
  from http://www.scipy.org/Download
  NumPy 1.0.4 for Python 2.5 - numpy-1.0.4.win32-py2.5.msi
  SciPy 0.6.0 for Python 2.5 - scipy-0.6.0.win32-py2.5.exe

The installs ran without error, but when I tried running the test scripts from 
each of these packages under Python 2.5, all I got was the useless "tell 
Microsoft" window.  
>>> import numpy, scipy 
>>> numpy.test() 
python.exe has encountered a problem .. please tell Microsoft ... 
>>> scipy.test() 
python.exe has encountered a problem .. please tell Microsoft ... 
I guess the problem is that I have not installed Microsoft's C-compiler, but 
neither the installers nor the test scripts tell me that.  There does not seem 
to be any un-install utility, so I will just delete numpy/ and scipy/ from 
C://Python25/Lib/site-packages/ and hope that no problems remain from registry 
entries, egg-info files, and other gradoo left by the installers!

3) I then tried installing under Cygwin, following the incomplete instructions 
at http://scipy.org/Installing_SciPy/Windows

  from http://www.scipy.org/Download
  NumPy 1.0.4 - numpy-1.0.4.tar.gz
  SciPy 0.6.0 - scipy-0.6.0.tar.gz

3a) The numpy install and test ran without error.  
$ pwd 
/packages/Python-2.5/numpy-1.0.4 
$ python setup.py install 
 
$ python -c 'import numpy; numpy.test()' 
 
Ran 692 tests in 1.593s 
OK 
3b) The scipy install hit some snags, however, ending in a corruption of Cygwin 
that could only be fixed with a full reboot.

$ python setup.py install
--> NOT AVAILABLE:  mkl, fftw3, rfftw, drfftw, ptf77blas, f77blas, ...

Restarted cygwin bash shell:
  13283 [main] ? (5388) C:\cygwin\bin\bash.exe: *** fatal error - system shared
memory version mismatch detected - 0x75BE009C/0x8A88009C.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.

4) I then installed just the weave package from scipy, and except for a few 
warnings during the test run, it seems to be OK.

5) I did a google search on [scipy install] and found others having similar 
problems over the years.  One fellow had success with the installer at 
http://www.enthought.com/products/epdacademic.php.  I downloaded that one and 
ran it, a process which took several hours and created a Python25 directory 
with 719MB and 38814 files!!!  sys.path is now crammed with 116 really messy 
paths.  Luckily, I kept all this separate from my normal Python install.

6) I tried testing the new install.  Numpy passed all tests, and SciPy got a 
little further, but ended with a crash.  The error messages, as usual, mean 
nothing.
 vq.py:477: UserWarning: One of the clusters is empty.  Re-run kmean with a 
different initialization.
Running tests:
...
crash - "python.exe has encountered a problem and needs to close ..."

7) I tried running the SciPy tutorial at http://www.scipy.org/SciPy_Tutorial in 
hopes that whatever failed was in some obscure function I won't need.  No such 
luck.  2 out of 4 of the tutorials crashed Python.
Basic Matrix Operations - OK
Sparse Matrices - OK
Numerical Integration - function quad crashes Python
Integrating ODEs - function odeint crashes Python

I see that Enthought has a nicely organized webpage, including a 
http://www.scipy.org/Developer_Zone where they are asking for help with 
packaging.  The two environments most used by our students (PC and Macintosh) 
have nobody volunteering t

Re: [Edu-sig] Introducing Python to Engineering Students

[David MacQuigg]

I got scipy.weave working in my Mandelbrot demo in Python2.5 under Cygwin, and 
the speed improvement is comparable to my hand-coded  extension module.

1a) Python speed = 678 points/sec
1b) C speed  = 115200 points/sec 169X
2a) Python speed = 721 points/sec
2b) C  speed = 126400 points/sec 175X

See 
http://ece.arizona.edu/~edatools/ece175/projects/mandelbrots/mandel_weave.py 
for the complete program, including both the Python and C-coded versions of the 
getpts function.  It should run now in any Python setup with the required 
packages (numpy and weave).

As Rob pointed out, this eliminates all the  interface functions, the 
need to build a shared library for every little test, and the clutter in my 
site-packages directory from all these tests.  Now, I can just tell the 
students "write your own C code, and put it in the stub function in this Python 
module."

The stub function runs 10X faster than the C speed above, so we can be 
confident the Python overhead is negligible.
 

At 09:30 PM 3/13/2008 -0700, Rob Malouf wrote:

>Ugh!  I'm afraid I don't use windows, so I can't offer any advice.  I  
>do know that compiling scipy wasn't that difficult under linux or mac  
>os x, so it shouldn't be too bad under cygwin either.

Weave and Numpy compiled without any snags, and that is all I need for now.

>  There are few  
>extra libraries you need, but you can probably find binaries for them  
>out there somewhere.  In fact, I'm surprised there isn't a cygwin  
>binary for scipy... if you get it working maybe you should post it  
>somewhere!

Or at least some instructions that are more clear on building such a binary.

Many thanks for all the help.

-- Dave


At 07:24 PM 3/11/2008 -0700, Rob Malouf wrote:

>On Mar 11, 2008, at 5:11 PM, David MacQuigg wrote:
>>It would make a nice improvement in this Mandelbrot demo if you  
>>could show me a way to significantly improve the speed of the Python  
>>I already have, perhaps avoiding the need for C.
>
>Actually, I don't see a clean way to vectorize that inner loop, so  
>maybe numpy isn't a good fit here.  Which means weave is.
>
>First, running the program as-is, I get:
>
>1a) Python speed = 776 points/sec
>1b) C speed  = 103200 points/sec
>2a) Python speed = 833 points/sec
>2b) C  speed = 108600 points/sec
>
>With this added to the beginning of the program to load and invoke  
>psyco:
>
>import psyco
>psyco.full()
>
>I get:
>
>1a) Python speed = 2700 points/sec
>1b) C speed  = 101600 points/sec
>2a) Python speed = 2800 points/sec
>2b) C  speed = 110100 points/sec
>
>Or, instead, replacing your getpts with the weave-d version:
>
>from numpy import zeros
>from scipy import weave
>...
>vals = zeros(100,int)
>
>code = r"""
>double cx = cx0 - dx;
>for (int p=0; p<100; p++) {
>double zx = 0.0;
>double zy = 0.0;
>int i;
>cx += dx;
>for (i=0; i<999; i++) {
>double zx2 = zx*zx;
>double zy2 = zy*zy;
>if ((zx2 + zy2) > 4.0) break;
>zy = 2*zx*zy + cy0;
>zx = zx2 - zy2 + cx;
>}
>vals[p] = i;
>}
>"""
>weave.inline(code,['cx0','cy0','dx','vals'])
>
>I get:
>
>1a) Python speed = 102200 points/sec
>1b) C speed  = 103300 points/sec
>2a) Python speed = 108400 points/sec
>2b) C  speed = 110700 points/sec
>
>Not bad! There's probably a more pythonic way to write that, but  
>this'll do.  And after all, this is a realistic situation: you've got  
>the inner loop of a program written in C, but you'd rather write all  
>the supporting code around it in something like Python.  And note that  
>weave automatically compiles and links (if necessary) and then loads  
>the C part when you run mandel.py.  You (or your students) don't need  
>to remember where the python headers are or how to build a shared  
>library on whatever platform they're using.
>
>---
>Rob Malouf <[EMAIL PROTECTED]>
>Department of Linguistics and Asian/Middle Eastern Languages
>San Diego State University



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[David MacQuigg]

At 01:16 PM 3/13/2008 -0700, Warren wrote:

>David,
> 
>There is a known problem with Pygame and IDLE.  (Something about IDLE not 
>running the program in a separate process.)  If you just run the program form 
>a command window, or use a different editor (like SPE) you wouldn't see that 
>problem about closing the window.

Well, it's probably not the TKinter "dueling event loops" problem. (PyGame 
doesn't use TKinter for its own event loop.)  But I do see an FAQ at 
http://www.pygame.org/wiki/search.php?query=IDLE and the proposed solution is 
to make sure there is always a call to pygame.quit().  The example in the FAQ 
doesn't work, but I see what they are trying to do.  Here is how I would write 
the final loop:  
while True: 
event = pygame.event.wait() 
if event.type == pygame.QUIT: 
break 
if event.type == pygame.MOUSEBUTTONDOWN: 
print "Enter new data"

pygame.quit() 
Now there is no problem running from IDLE.

>Changing the program so it updates as the calculation is ongoing is certainly 
>possible.

I'll play around with this some more.  I'm very pleased with the documentation 
on PyGame.  Without knowing anything about the program, I was able to find the 
functions and event types used in the snippet above.

Many thanks for your help.

-- Dave


>- Original Message 
>From: David MacQuigg <[EMAIL PROTECTED]>
>To: Warren Sande <[EMAIL PROTECTED]>
>Sent: Thursday, March 13, 2008 2:51:00 PM
>Subject: Re: [Edu-sig] Introducing Python to Engineering Students
>
>At 08:19 PM 3/12/2008 -0700, Warren Sande wrote:
>
>>By the way, here is a non-OO version of a the fractals program that uses 
>>Pygame to display the output.
>
>Very nice!  I installed PyGame under Python25/Lib/site-packages, using the 
>Windows installer from 
><http://www.pygame.org/install.html>http://www.pygame.org/install.html, and 
>ran the script below from my favorite IDE (IDLE).  I wish Unix installs would 
>go so smoothly.
>
>The only problem I noticed is that the CPU runs 100% and doesn't stop if you 
>forget to click the X on the PyGame window.  When I do click the X, the event 
>loop stops, but he window remains.  If I click the X again, I get Microsoft's 
>"program is not responding" dialog, and its "please tell Microsoft" follow-on. 
> There must be a better way to close this window.
>
>Also, it would be nice if we could show the window as it is being painted, and 
>allow students to interrupt a long computation and try different coordinates.
>
>-- Dave
>
>
>>#-
>># Simple fractal program using Pygame to display results
>># (Based on Kirby Urner's OO version)
>>import pygame, sys
>>palette = [(0,0,0)]
>> 
>>def mkpalette():
>>global palette
>>for i in range(0,255):
>>palette.append((i*5%200 + 20, i*7%200 + 20, i*11%200 + 20))
>>return palette
>>
>>def compute_fractal(n, uleft_x, uleft_y, lright_x, lright_y):
>>global pixels
>>xwidth = lright_x - uleft_x
>>ywidth = uleft_y  - lright_y 
>>pixels = []
>>for x in range (500):
>>pixel_row = []
>>for y in range (500):
>>percentx = x/500.0
>>percenty = y/500.0
>>xp = uleft_x + percentx * xwidth
>>yp = uleft_y - percenty * ywidth
>>z = complex(xp,yp)
>>o = complex(0,0)
>>dotcolor = 0
>>for trials in range(n):
>>if abs(o) <= 2.0:
>>o = o**2 + z
>>else:
>>dotcolor = trials
>>break
>>pixel_row.append(palette[dotcolor])
>>pixels.append(pixel_row)
>>
>>mkpalette()
>>pixels = []
>>print "computing fractal..."
>>compute_fractal(64, -2, 1.25, 0.5, -1.25)
>>print "done."
>>screen = pygame.display.set_mode((500,500))
>>f_surf = pygame.Surface((500, 500))
>>for x in range(500):
>>    for y in range(500):
>>f_surf.set_at((x, y), pixels[x][y])
>>screen.blit(f_surf, [0,0,500,500])
>>pygame.display.flip()
>>while True:
>>for event in pygame.event.get():
>>if event.type == pygame.QUIT:
>>sys.exit()
>>#-
>
>
>
>>- Original Message 
>>From: Warren Sande <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
>>To: <mailto:edu-sig@python.org>edu-sig@python.org
>>Sent: Tuesday, March 11, 2008 12:20:02 AM
>>Subject: Re

Re: [Edu-sig] Introducing Python to Engineering Students

[Warren Sande]

By the way, here is a non-OO version of a the fractals program that uses Pygame 
to display the output.

Warren Sande

#-
# Simple fractal program using Pygame to display results
# (Based on Kirby Urner's OO version)
import pygame, sys
palette = [(0,0,0)]

def mkpalette():
global palette
for i in range(0,255):
palette.append((i*5%200 + 20, i*7%200 + 20, i*11%200 + 20))
return palette

def compute_fractal(n, uleft_x, uleft_y, lright_x, lright_y):
global pixels
xwidth = lright_x - uleft_x
ywidth = uleft_y  - lright_y 
pixels = []
for x in range (500):
pixel_row = []
for y in range (500):
percentx = x/500.0
percenty = y/500.0
xp = uleft_x + percentx * xwidth
yp = uleft_y - percenty * ywidth
z = complex(xp,yp)
o = complex(0,0)
dotcolor = 0
for trials in range(n):
if abs(o) <= 2.0:
o = o**2 + z
else:
dotcolor = trials
break
pixel_row.append(palette[dotcolor])
pixels.append(pixel_row)
 
mkpalette()
pixels = []
print "computing fractal..."
compute_fractal(64, -2, 1.25, 0.5, -1.25)
print "done."
screen = pygame.display.set_mode((500,500))
f_surf = pygame.Surface((500, 500))
for x in range(500):
for y in range(500):
f_surf.set_at((x, y), pixels[x][y])
screen.blit(f_surf, [0,0,500,500])
pygame.display.flip()
while True:
for event in pygame.event.get():
if event.type == pygame.QUIT:
sys.exit()
#-

- Original Message 
From: Warren Sande <[EMAIL PROTECTED]>
To: edu-sig@python.org
Sent: Tuesday, March 11, 2008 12:20:02 AM
Subject: Re: [Edu-sig] Introducing Python to Engineering Students


David,

For output graphics, you might want to have a look at Pygame.  It is a wrapper 
for the SDL library.  It has functionality for creating graphics windows, 
drawing, sprites, etc.  But what might be of interest for you is the simple 
set_at(x,y) method, to set the color of individual pixels in a window.

I have found the Pygame documentation to be pretty good.

Here is a simple example of plotting a sinewave using set_at()

#-
import pygame, sys, math
screen = pygame.display.set_mode([640,480])
for x in range(0, 640):
y = int(math.sin(x/640.0 * 4 * math.pi) * 200 + 240)
screen.set_at([x, y],[255,0,0])
pygame.display.flip()
while True:
for event in pygame.event.get():
if event.type == pygame.QUIT:
sys.exit()
#--

Warren Sande



- Original Message 
From: David MacQuigg <[EMAIL PROTECTED]>
To: edu-sig@python.org
Sent: Monday, March 10, 2008 10:28:21 PM
Subject: [Edu-sig] Introducing Python to Engineering Students

I've been asked to give an intro to Python for a freshman class with 150 
students at University of Arizona.  The class is taught in the Electrical and 
Computer Engineering Department, and is titled Computer Programming for 
Engineering Applications. The language is C (Hanly & Koffman, Problem Solving 
and Program Design in C).

I think a nice way to do this will be an application where we can show the 
advantages of both languages - the computation of Mandelbrot images 
http://en.wikipedia.org/wiki/Mandelbrot_set.  Python will provide the 
high-level "glue" which brings everything together in a nice programming 
environment, and C will provide the raw power for the loop that actually 
computes the pixels.  My initial tests show this loop running about 100 times 
faster in C than in Python.  

The challenge is to do this without overwhelming the students.  The plan is to 
make everything as simple as possible, just follow the instructions, except the 
loop itself, which the students will write in C, based on what I have written 
in Python.  See 
http://ece.arizona.edu/~edatools/ece175/projects/mandelbrots/mbrotHW.html.

Suggestions are welcome.  Has anyone done something like this before?  Can you 
improve on my code (I'm not a Python expert), or even suggest something 
entirely different?

There is one major piece I would like to add to what I have so far - output 
graphics.  This demo would really be cool if the students could see these 
glorious images appear on their screen instead of an array of numbers.  I 
looked at the Python Imaging Library 
http://www.pythonware.com/products/pil/index.htm, and I don't see any examples 
that I can work from in converting an array of numbers into an image, just a 
lot of dense reference material that assumes I already know these image data 
formats.  Maybe there is a simpler way.  Help from someone with experience in 
Python graphics would be most appreciated.

-- Dave 



___
Edu-sig mailing list
Edu-sig@python

Re: [Edu-sig] Introducing Python to Engineering Students

[David MacQuigg]

At 07:24 PM 3/11/2008 -0700, Rob Malouf wrote:

>On Mar 11, 2008, at 5:11 PM, David MacQuigg wrote:
>>It would make a nice improvement in this Mandelbrot demo if you  
>>could show me a way to significantly improve the speed of the Python  
>>I already have, perhaps avoiding the need for C.
>...
>Or, instead, replacing your getpts with the weave-d version:
>
>from numpy import zeros
>from scipy import weave
>...
>vals = zeros(100,int)
>
>code = r"""
>double cx = cx0 - dx;
>for (int p=0; p<100; p++) {
>double zx = 0.0;
>double zy = 0.0;
>int i;
>cx += dx;
>for (i=0; i<999; i++) {
>double zx2 = zx*zx;
>double zy2 = zy*zy;
>if ((zx2 + zy2) > 4.0) break;
>zy = 2*zx*zy + cy0;
>zx = zx2 - zy2 + cx;
>}
>vals[p] = i;
>}
>"""
>weave.inline(code,['cx0','cy0','dx','vals'])
>
>I get:
>
>1a) Python speed = 102200 points/sec
>1b) C speed  = 103300 points/sec
>2a) Python speed = 108400 points/sec
>2b) C  speed = 110700 points/sec

Excellent!!!  This is exactly what we need.  Our students will have no problem 
writing the C code string, and the Python wrappings are simple enough they can 
just follow this example verbatim.

>There's probably a more pythonic way to write that, but  
>this'll do.  And after all, this is a realistic situation: you've got  
>the inner loop of a program written in C, but you'd rather write all  
>the supporting code around it in something like Python.  And note that  
>weave automatically compiles and links (if necessary) and then loads  
>the C part when you run mandel.py.  You (or your students) don't need  
>to remember where the python headers are or how to build a shared  
>library on whatever platform they're using.

That was my next problem.  Our students use mostly Windows, some on MacOS, and 
a few on Linux.  If all we need beyond the latest Python is numpy and scipy, 
that is great!!

I'll have to experiment with this later.  Many thanks.

-- Dave 



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[kirby urner]

On Wed, Mar 12, 2008 at 5:50 AM, John Posner <[EMAIL PROTECTED]> wrote:

>  IMHO, object-oriented programming is like most technologies -- it was
>  developed as a solution to perceived problems. Newbies, who haven't
>  perceived the problems, will have trouble appreciating the solution.
>
>  -John

Fortunately, in elementary mathematics, we have "types of object"
(e.g. rational numbers) very amenable to object oriented treatment.

There's no shortage of "objects" we might model (vectors,
integers modulo N... polynomials).

Python itself is also more understandable if you have a generic
appreciation for "dot notation", which also gets us to a classes
'n objects discussion, i.e. what does dir('hello') really show us?

The perceived problem, to which OO was (still is) a solution, is
that procedural programming, even when structured, is too
difficult, too awkward.  Computer code should more closely
mirror the the knowledge domain.

And what knowledge domain has no objects?

Hard to find, given we already think in terms of "things" and
their relationships, their behaviors.

I'm already doing Dog and Monkey classes on the first day,
with 8th graders sometimes (adults other times).  They get it.

My belief is CS courses postpone classes 'n objects for
a whole year because that's how an earlier generation of
coder learned 'em i.e. late in the game.

So these days they're considered "advanced" (and *there
are* advanced aspects no question -- not saying everything
OO is equally newbie accessible).

I don't think it'll stay that way in every curriculum, especially
those that tackle Python.

Kirby
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[John Posner]

> >  I'll modify my function to look more like yours, going for more 
> > clarity with only a small sacrifice in efficiency.  I can't use the 
> > nice OOP style, however, because these students have studied only 
> > functions.  OOP is an "advanced topic" covered in a later 
> course for 
> > computer engineers, and not at all for electrical and other 
> > engineering majors. :(
> 
> Yes, I understand your frustrations.
> 
> I try to pitch to other faculty that "ontogeny *need not* 
> recapitulate phylogeny" with the example of cell phones:
> you *don't* need to have used a land line first.
> 
> Start early with objects.
> 

IMHO, object-oriented programming is like most technologies -- it was
developed as a solution to perceived problems. Newbies, who haven't
perceived the problems, will have trouble appreciating the solution.

-John

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[kirby urner]

On Tue, Mar 11, 2008 at 2:57 PM, David MacQuigg
<[EMAIL PROTECTED]> wrote:

>  Very nice!!  I like the clear concise explanation of fractals.  I'll add 
> this link to whatever I put together.
>
>  I like the way you construct the color palette, simple but effective.  I'll 
> have to play around with some more high-resolution images to see if I still 
> get such nice colors.  I see you have a link on creating palettes, but it is 
> dead.

Thank you sir.

Link updated.

>  I'll modify my function to look more like yours, going for more clarity with 
> only a small sacrifice in efficiency.  I can't use the nice OOP style, 
> however, because these students have studied only functions.  OOP is an 
> "advanced topic" covered in a later course for computer engineers, and not at 
> all for electrical and other engineering majors. :(

Yes, I understand your frustrations.

I try to pitch to other faculty that "ontogeny *need not*
recapitulate phylogeny" with the example of cell phones:
you *don't* need to have used a land line first.

Start early with objects.

Some recent curriculum writing for a futuristic pre-college
(still on the drawing board), explaining OO to math faculty:

http://www.4dsolutions.net/presentations/tecc_oop.pdf
http://www.4dsolutions.net/presentations/tecc_op_overloading.pdf

Kirby
from Portland Python Users Group (PPUG)
CubeSpace, PDX
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[Rob Malouf]

On Mar 11, 2008, at 2:57 PM, David MacQuigg wrote:
>  I guess what I should conclude is that when performance is  
> important, don't bother trying to optimize Python.  Go straight to  
> C, and get 10 or 100X improvement.

That hasn't always been my experience.  I found that using psyco and  
numpy (along with careful profiling and optimization), I can often get  
essentially the same performance from pure Python that I can get from  
mixed Python/C solutions, and with much less trouble.

---
Rob Malouf <[EMAIL PROTECTED]>
Department of Linguistics and Asian/Middle Eastern Languages
San Diego State University


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[Rob Malouf]

On Mar 11, 2008, at 5:11 PM, David MacQuigg wrote:
> It would make a nice improvement in this Mandelbrot demo if you  
> could show me a way to significantly improve the speed of the Python  
> I already have, perhaps avoiding the need for C.

Actually, I don't see a clean way to vectorize that inner loop, so  
maybe numpy isn't a good fit here.  Which means weave is.

First, running the program as-is, I get:

 1a) Python speed = 776 points/sec
 1b) C speed  = 103200 points/sec
 2a) Python speed = 833 points/sec
 2b) C  speed = 108600 points/sec

With this added to the beginning of the program to load and invoke  
psyco:

import psyco
psyco.full()

I get:

 1a) Python speed = 2700 points/sec
 1b) C speed  = 101600 points/sec
 2a) Python speed = 2800 points/sec
 2b) C  speed = 110100 points/sec

Or, instead, replacing your getpts with the weave-d version:

from numpy import zeros
from scipy import weave
...
 vals = zeros(100,int)

 code = r"""
 double cx = cx0 - dx;
 for (int p=0; p<100; p++) {
 double zx = 0.0;
 double zy = 0.0;
 int i;
 cx += dx;
 for (i=0; i<999; i++) {
 double zx2 = zx*zx;
 double zy2 = zy*zy;
 if ((zx2 + zy2) > 4.0) break;
 zy = 2*zx*zy + cy0;
 zx = zx2 - zy2 + cx;
 }
 vals[p] = i;
 }
 """
 weave.inline(code,['cx0','cy0','dx','vals'])

I get:

 1a) Python speed = 102200 points/sec
 1b) C speed  = 103300 points/sec
 2a) Python speed = 108400 points/sec
 2b) C  speed = 110700 points/sec

Not bad! There's probably a more pythonic way to write that, but  
this'll do.  And after all, this is a realistic situation: you've got  
the inner loop of a program written in C, but you'd rather write all  
the supporting code around it in something like Python.  And note that  
weave automatically compiles and links (if necessary) and then loads  
the C part when you run mandel.py.  You (or your students) don't need  
to remember where the python headers are or how to build a shared  
library on whatever platform they're using.

---
Rob Malouf <[EMAIL PROTECTED]>
Department of Linguistics and Asian/Middle Eastern Languages
San Diego State University



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[Brian Blais]

On Mar 11, 2008, at Mar 11:8:11 PM, David MacQuigg wrote:


At 03:12 PM 3/11/2008 -0700, Rob Malouf wrote:


On Mar 11, 2008, at 2:57 PM, David MacQuigg wrote:

I guess what I should conclude is that when performance is
important, don't bother trying to optimize Python.  Go straight to
C, and get 10 or 100X improvement.


That hasn't always been my experience.  I found that using psyco and
numpy (along with careful profiling and optimization), I can often  
get

essentially the same performance from pure Python that I can get from
mixed Python/C solutions, and with much less trouble.


I agree that the Python/C interface is more trouble than it should  
be, especially for freshman engineering students and technical  
professionals who don't have time for messy programming details.   
What I would like to see is something like a simple "directive" I  
could put in my Python code to say "The following function is in  
C", and have Python set up the linkage for me.


One of the things that drew me to Python for Numerical work was Pyrex  
(and now the Cython project).  Here is your code in Pyrex (sans-doc  
string)


def getpts(double cx0,double cy0,double dx):
vals = []
cdef int p,i
cdef double cx,zx,zy,zx2,zy2
for p from 0<=p<100: # 100 points
cx = cx0 + p * dx#  moving rightx . . . . . .
zx = zy = 0.0
for i from 0<=i<1000: # 100 points
zx2 = zx*zx
zy2 = zy*zy
if (zx2 + zy2) > 4.0 : break  # escape
zy = 2*zx*zy + cy0
zx = zx2 - zy2 + cx

vals.append(i)

return vals

This code gets compiled to C, and returns this unit test:

Expected:
1a) Python speed = 787 points/sec
1b) C speed  = 125500 points/sec
2a) Python speed = 823 points/sec
2b) C  speed = 134300 points/sec
Got:
1a) Python speed = 1214 points/sec
1b) C speed  = 125700 points/sec
2a) Python speed = 1287 points/sec
2b) C  speed = 134500 points/sec


not too shabby!  And for only putting the types of the variable into  
the existing python code, and a slight modification of the for-loop  
syntax, the conversion of a slow python function into a fast  
extension module is trivial.  One of the best things here is that for  
debugging, you can put in arbitrary python code.  You take the  
performance hit, but you don't care during debugging, and you take it  
out again for production.




bb


--
Brian Blais
[EMAIL PROTECTED]
http://web.bryant.edu/~bblais



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[Rob Malouf]

On Mar 11, 2008, at 5:11 PM, David MacQuigg wrote:
>  What I would like to see is something like a simple "directive" I  
> could put in my Python code to say "The following function is in C",  
> and have Python set up the linkage for me.

Actually, there is!  It's part of scipy and it's *very* slick:

http://www.scipy.org/Weave

It works great, though as I said, for my problems it's not always  
faster than python+psyco+numpy (which I have to say I find  
disappointing, considering how cool weave is).

> It would make a nice improvement in this Mandelbrot demo if you  
> could show me a way to significantly improve the speed of the Python  
> I already have, perhaps avoiding the need for C.

I'll take a look at it.

---
Rob Malouf <[EMAIL PROTECTED]>
Department of Linguistics and Asian/Middle Eastern Languages
San Diego State University



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[David MacQuigg]

At 03:12 PM 3/11/2008 -0700, Rob Malouf wrote:

>On Mar 11, 2008, at 2:57 PM, David MacQuigg wrote:
>> I guess what I should conclude is that when performance is  
>>important, don't bother trying to optimize Python.  Go straight to  
>>C, and get 10 or 100X improvement.
>
>That hasn't always been my experience.  I found that using psyco and  
>numpy (along with careful profiling and optimization), I can often get  
>essentially the same performance from pure Python that I can get from  
>mixed Python/C solutions, and with much less trouble.

I agree that the Python/C interface is more trouble than it should be, 
especially for freshman engineering students and technical professionals who 
don't have time for messy programming details.  What I would like to see is 
something like a simple "directive" I could put in my Python code to say "The 
following function is in C", and have Python set up the linkage for me.

It would make a nice improvement in this Mandelbrot demo if you could show me a 
way to significantly improve the speed of the Python I already have, perhaps 
avoiding the need for C.  I've posted the complete Python module at
http://ece.arizona.edu/~edatools/ece175/projects/mandelbrots/mandel.py
Just run the command 
$ python mandel.py
and you should see the output from two examples in the doctests:
1a) Python speed = 787 points/sec
1b) C speed  = 125500 points/sec
2a) Python speed = 823 points/sec
2b) C  speed = 134300 points/sec

The C source, mandelbrotC.c, is also in that same directory.  The tests above 
were done on an old Windows machine running Cygwin.

-- Dave  



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[David MacQuigg]

Many thanks for the quick and very helpful responses!!

At 08:00 PM 3/10/2008 -0700, kirby urner wrote:

>Just in case you want to look at an "all Python" solution down to the
>pixel level (using PIL):
>
>http://4dsolutions.net/ocn/fractals.html

Very nice!!  I like the clear concise explanation of fractals.  I'll add this 
link to whatever I put together.

I like the way you construct the color palette, simple but effective.  I'll 
have to play around with some more high-resolution images to see if I still get 
such nice colors.  I see you have a link on creating palettes, but it is dead.

This module would make a very nice example for the PIL handbook.  They should 
at least link to your page.

>I don't claim it's fast, just conceptually illustrative.

It seems to run about as fast as my Python function, even though I've made some 
efforts to optimize the performance of my Python code (100 points per function 
call, separating real & imaginary parts, etc.).  I guess what I should conclude 
is that when performance is important, don't bother trying to optimize Python.  
Go straight to C, and get 10 or 100X improvement.

I'll modify my function to look more like yours, going for more clarity with 
only a small sacrifice in efficiency.  I can't use the nice OOP style, however, 
because these students have studied only functions.  OOP is an "advanced topic" 
covered in a later course for computer engineers, and not at all for electrical 
and other engineering majors. :(


At 09:17 PM 3/10/2008 -0700, Warren Sande wrote:

>For output graphics, you might want to have a look at 
>Pygame.

I like the ability to create the image in real time directly on the screen, 
instead of to a file.  This should make the demo a little more interactive, and 
visually emphasize the speed difference between Python and C.


At 09:14 PM 3/11/2008 +1100, Steven Bird wrote:

>We're considering this book for adoption in a second year programming
>course for Engineers:
>
>Numerical Methods in Engineering with Python by Jaan Kiusalaas
>http://www.amazon.com/Numerical-Methods-Engineering-Python-Kiusalaas/dp/0521852870

Looks interesting, but not enough on Python for what I would like, and perhaps 
too much overlap with what the students learn using Matlab in other courses.  
For a second-year programming course, I would chose Martelli's "Python in a 
Nutshell", then supplement it with lots of examples, especially rewrites of 
examples students have seen already in C and Java.  The improvements in clarity 
are dramatic.

For a first-year course, I would chose Zelle's "Python Programming".  By the 
way, I'm not on the faculty, just an engineer with an interest in teaching.

-- Dave
http://ece.arizona.edu/~edatools






___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[Steven Bird]

We're considering this book for adoption in a second year programming
course for Engineers:

Numerical Methods in Engineering with Python by Jaan Kiusalaas
http://www.amazon.com/Numerical-Methods-Engineering-Python-Kiusalaas/dp/0521852870

Steven Bird
http://www.csse.unimelb.edu.au/~sb/

On 3/11/08, Warren Sande <[EMAIL PROTECTED]> wrote:
>
> David,
>
> For output graphics, you might want to have a look at Pygame.  It is a
> wrapper for the SDL library.  It has functionality for creating graphics
> windows, drawing, sprites, etc.  But what might be of interest for you is
> the simple set_at(x,y) method, to set the color of individual pixels in a
> window.
>
> I have found the Pygame documentation to be pretty good.
>
> Here is a simple example of plotting a sinewave using set_at()
>
> #-
> import pygame, sys, math
> screen = pygame.display.set_mode([640,480])
> for x in range(0, 640):
> y = int(math.sin(x/640.0 * 4 * math.pi) * 200 + 240)
> screen.set_at([x, y],[255,0,0])
> pygame.display.flip()
> while True:
> for event in pygame.event.get():
> if event.type == pygame.QUIT:
> sys.exit()
> #--
>
> Warren Sande
>
>
> - Original Message 
> From: David MacQuigg <[EMAIL PROTECTED]>
> To: edu-sig@python.org
> Sent: Monday, March 10, 2008 10:28:21 PM
> Subject: [Edu-sig] Introducing Python to Engineering Students
>
> I've been asked to give an intro to Python for a freshman class with 150
> students at University of Arizona.  The class is taught in the Electrical
> and Computer Engineering Department, and is titled Computer Programming for
> Engineering Applications. The language is C (Hanly & Koffman, Problem
> Solving and Program Design in C).
>
> I think a nice way to do this will be an application where we can show the
> advantages of both languages - the computation of Mandelbrot images
> http://en.wikipedia.org/wiki/Mandelbrot_set.  Python will
> provide the high-level "glue" which brings everything together in a nice
> programming environment, and C will provide the raw power for the loop that
> actually computes the pixels.  My initial tests show this loop running about
> 100 times faster in C than in Python.
>
> The challenge is to do this without overwhelming the students.  The plan is
> to make everything as simple as possible, just follow the instructions,
> except the loop itself, which the students will write in C, based on what I
> have written in Python.  See
> http://ece.arizona.edu/~edatools/ece175/projects/mandelbrots/mbrotHW.html.
>
> Suggestions are welcome.  Has anyone done something like this before?  Can
> you improve on my code (I'm not a Python expert), or even suggest something
> entirely different?
>
> There is one major piece I would like to add to what I have so far - output
> graphics.  This demo would really be cool if the students could see these
> glorious images appear on their screen instead of an array of numbers.  I
> looked at the Python Imaging Library
> http://www.pythonware.com/products/pil/index.htm, and I
> don't see any examples that I can work from in converting an array of
> numbers into an image, just a lot of dense reference material that assumes I
> already know these image data formats.  Maybe there is a simpler way.  Help
> from someone with experience in Python graphics would be most appreciated.
>
> -- Dave
>
>
>
> ___
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
>
> ___
>  Edu-sig mailing list
>  Edu-sig@python.org
>  http://mail.python.org/mailman/listinfo/edu-sig
>
>
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[Warren Sande]

David,

For output graphics, you might want to have a look at Pygame. 
It is a wrapper for the SDL library.  It has functionality for creating
graphics windows, drawing, sprites, etc.  But what might be of interest
for you is the simple set_at(x,y) method, to set the color of
individual pixels in a window.

I have found the Pygame documentation to be pretty good.

Here is a simple example of plotting a sinewave using set_at()

#-
import pygame, sys, math
screen = pygame.display.set_mode([640,480])
for x in range(0, 640):
y = int(math.sin(x/640.0 * 4 * math.pi) * 200 + 240)
   
 screen.set_at([x, y],[255,0,0])
pygame.display.flip()
while True:
for event in pygame.event.get():
if event.type == pygame.QUIT:
sys.exit()
#--

Warren Sande


- Original Message 
From: David MacQuigg <[EMAIL PROTECTED]>
To: edu-sig@python.org
Sent: Monday, March 10, 2008 10:28:21 PM
Subject: [Edu-sig] Introducing Python to Engineering Students

I've 
been 
asked 
to 
give 
an 
intro 
to 
Python 
for 
a 
freshman 
class 
with 
150 
students 
at 
University 
of 
Arizona.  
The 
class 
is 
taught 
in 
the 
Electrical 
and 
Computer 
Engineering 
Department, 
and 
is 
titled 
Computer 
Programming 
for 
Engineering 
Applications. 
The 
language 
is 
C 
(Hanly 
& 
Koffman, 
Problem 
Solving 
and 
Program 
Design 
in 
C).

I 
think 
a 
nice 
way 
to 
do 
this 
will 
be 
an 
application 
where 
we 
can 
show 
the 
advantages 
of 
both 
languages 
- 
the 
computation 
of 
Mandelbrot 
images 
http://en.wikipedia.org/wiki/Mandelbrot_set.  
Python 
will 
provide 
the 
high-level 
"glue" 
which 
brings 
everything 
together 
in 
a 
nice 
programming 
environment, 
and 
C 
will 
provide 
the 
raw 
power 
for 
the 
loop 
that 
actually 
computes 
the 
pixels.  
My 
initial 
tests 
show 
this 
loop 
running 
about 
100 
times 
faster 
in 
C 
than 
in 
Python.  

The 
challenge 
is 
to 
do 
this 
without 
overwhelming 
the 
students.  
The 
plan 
is 
to 
make 
everything 
as 
simple 
as 
possible, 
just 
follow 
the 
instructions, 
except 
the 
loop 
itself, 
which 
the 
students 
will 
write 
in 
C, 
based 
on 
what 
I 
have 
written 
in 
Python.  
See 
http://ece.arizona.edu/~edatools/ece175/projects/mandelbrots/mbrotHW.html.

Suggestions 
are 
welcome.  
Has 
anyone 
done 
something 
like 
this 
before?  
Can 
you 
improve 
on 
my 
code 
(I'm 
not 
a 
Python 
expert), 
or 
even 
suggest 
something 
entirely 
different?

There 
is 
one 
major 
piece 
I 
would 
like 
to 
add 
to 
what 
I 
have 
so 
far 
- 
output 
graphics.  
This 
demo 
would 
really 
be 
cool 
if 
the 
students 
could 
see 
these 
glorious 
images 
appear 
on 
their 
screen 
instead 
of 
an 
array 
of 
numbers.  
I 
looked 
at 
the 
Python 
Imaging 
Library 
http://www.pythonware.com/products/pil/index.htm, 
and 
I 
don't 
see 
any 
examples 
that 
I 
can 
work 
from 
in 
converting 
an 
array 
of 
numbers 
into 
an 
image, 
just 
a 
lot 
of 
dense 
reference 
material 
that 
assumes 
I 
already 
know 
these 
image 
data 
formats.  
Maybe 
there 
is 
a 
simpler 
way.  
Help 
from 
someone 
with 
experience 
in 
Python 
graphics 
would 
be 
most 
appreciated.

-- 
Dave 



___
Edu-sig 
mailing 
list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Re: [Edu-sig] Introducing Python to Engineering Students

[kirby urner]

On Mon, Mar 10, 2008 at 7:28 PM, David MacQuigg
<[EMAIL PROTECTED]> wrote:

>  Suggestions are welcome.  Has anyone done something like this before?  Can 
> you improve on my code (I'm not a Python expert), or even suggest something 
> entirely different?

Hi Dave --

Just in case you want to look at an "all Python" solution down to the
pixel level (using PIL):

http://4dsolutions.net/ocn/fractals.html

I don't claim it's fast, just conceptually illustrative.

Kirby
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

[Edu-sig] Introducing Python to Engineering Students

[David MacQuigg]

I've been asked to give an intro to Python for a freshman class with 150 
students at University of Arizona.  The class is taught in the Electrical and 
Computer Engineering Department, and is titled Computer Programming for 
Engineering Applications. The language is C (Hanly & Koffman, Problem Solving 
and Program Design in C).

I think a nice way to do this will be an application where we can show the 
advantages of both languages - the computation of Mandelbrot images 
http://en.wikipedia.org/wiki/Mandelbrot_set.  Python will provide the 
high-level "glue" which brings everything together in a nice programming 
environment, and C will provide the raw power for the loop that actually 
computes the pixels.  My initial tests show this loop running about 100 times 
faster in C than in Python.  

The challenge is to do this without overwhelming the students.  The plan is to 
make everything as simple as possible, just follow the instructions, except the 
loop itself, which the students will write in C, based on what I have written 
in Python.  See 
http://ece.arizona.edu/~edatools/ece175/projects/mandelbrots/mbrotHW.html.

Suggestions are welcome.  Has anyone done something like this before?  Can you 
improve on my code (I'm not a Python expert), or even suggest something 
entirely different?

There is one major piece I would like to add to what I have so far - output 
graphics.  This demo would really be cool if the students could see these 
glorious images appear on their screen instead of an array of numbers.  I 
looked at the Python Imaging Library 
http://www.pythonware.com/products/pil/index.htm, and I don't see any examples 
that I can work from in converting an array of numbers into an image, just a 
lot of dense reference material that assumes I already know these image data 
formats.  Maybe there is a simpler way.  Help from someone with experience in 
Python graphics would be most appreciated.

-- Dave 



___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig