From da@maigret.cog.brown.edu  Tue Jul  2 18:37:58 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Tue, 2 Jul 1996 13:37:58 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] mac numeric version?
Message-ID: <199607021737.NAA18467@maigret>

Has anyone ported the numeric stuff to the mac version since we 
last 'spoke' on this topic?

--david


=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================

From steve@estel.uindy.edu  Tue Jul  2 19:27:03 1996
From: steve@estel.uindy.edu (Steve Spicklemire)
Date: Tue, 2 Jul 96 13:27:03 -0500
Subject: [PYTHON MATRIX-SIG] mac numeric version?
In-Reply-To: <199607021737.NAA18467@maigret> (da@maigret.cog.brown.edu)
Message-ID: <9607021827.AA21589@estel.uindy.edu>

David,

	I can put up a Mac version of python with numeric stuff 
in it if you like. It's 68K only... (that's all I have.. sorry)

-steve

>>>>> "David" == David Ascher <da@maigret.cog.brown.edu> writes:

    David> Has anyone ported the numeric stuff to the mac version
    David> since we last 'spoke' on this topic?

    David> --david


    David> ================= MATRIX-SIG - SIG on Matrix Math for
    David> Python

    David> send messages to: matrix-sig@python.org administrivia to:
    David> matrix-sig-request@python.org =================


=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================

From da@maigret.cog.brown.edu  Sat Jul  6 17:06:59 1996
From: da@maigret.cog.brown.edu (David Ascher)
Date: Sat, 6 Jul 1996 12:06:59 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] numeric #ifdef
Message-ID: <199607061606.MAA03009@maigret>

1. I'd like to know what #define I can use to test for the presence of the
   Numeric extension -- I'm writing C code which can both be used with
   or without the extension, but obviously I need to #ifdef out the
   Array calls if the numeric extension is not defined.

   If such a #define isn't in 0.36, I'd like it to be in 0.36+x.

2. If anyone wants the files needed to make PythonWin numeric-aware, let
   me know.  It's just a replacement py130-3.dll and the usual lib/numeric
   files.  If you want to know the required source changes, I can tell
   you that as well.  I'll put it up on my web site as soon as I get
   the time to write a little HTML.

3. The URNG module is hard to port, because of its reliance on
   drand48(), which AFAIK is not available on Windows95/NT or the Mac.
   Is there a free drand48 somewhere?  
  
Cheers,

--david

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================

From tbyang@icf.llnl.gov  Wed Jul 17 00:10:11 1996
From: tbyang@icf.llnl.gov (Tser-Yuan (Brian) Yang)
Date: Tue, 16 Jul 1996 16:10:11 -0700 (PDT)
Subject: [PYTHON MATRIX-SIG] FYI: OverflowError in PrettyPrinter.py
Message-ID: <Pine.SUN.3.92.960716160903.10954A-100000@icf.llnl.gov>

FYI. A member of our group discovered that the variable max_val in the
function _floatFormat of ArrayPrinter.py needed to be set to a number
less than 2.15e9 on our machines. Otherwise it caused the following
error message:

Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "./PrettyPrinter.py", line 45, in arrayToString
    format, item_length = _floatFormat(data, precision, suppress_small)
  File "./PrettyPrinter.py", line 109, in _floatFormat
    max_str_len = len(str(int(max_val))) + precision + 2
OverflowError: float too large to convert

						Brian Yang


=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================

From mclay@eeel.nist.gov  Tue Jul 23 15:01:42 1996
From: mclay@eeel.nist.gov (Michael McLay)
Date: Tue, 23 Jul 1996 14:01:42 GMT
Subject: [PYTHON MATRIX-SIG] Speed of opengl
Message-ID: <199607231401.OAA14652@fermi.eeel.nist.gov>


Is openglmodule-0.33.c the most current version of the opengl module?
There were a couple other modules available so I wasn't sure.

I modified the glu, glut and opengl modules so the prefixes are no
longer necessary.  They seemed redundent and C'ish.  I also had to
patch up the example fog.py and movelight.py demonstration programs in
order to get them to work.  For movelight.py this involved changing:

  glut.MouseFunc(movelight)
  glut.MotionFunc(motion)
  glut.ReshapeFunc(reshape)
  glut.DisplayFunc(display)

to 

  glut.SetMouseFuncCallback(movelight)
  glut.MouseFunc()
  glut.SetMotionFuncCallback(motion)  
  glut.MotionFunc()
  glut.SetReshapeFuncCallback(reshape)
  glut.ReshapeFunc()
  glut.SetDisplayFuncCallback(display)
  glut.DisplayFunc()
  glut.DisplayFunc(display)


The performance of the python OpenGL module on a Linux system isn't
meeting my design objectives and I was wondering if I'm doing
something wrong or if it's just slow software.  The system uses
Mesa-1.2.8 on a Pentium 90 system with #9GXE 64Pro graphics card.
When I run the the Mesa samples/speed test for the configuration the
results are: 

	antialiasing: off
	depthtest: off
	fog: off
	lighting: off
	shading: flat
	texturing: off
	Points per second: 112360
	Lines per second: 53763.4
	Triangles per second: 15408.3
	Rects per second: 10172.9

This is pretty slow compared to an SGI.  I can live with it in the
application but I'd like the drawing rate to be about 4x this speed.    
I may even break down and buy a Acellerated-X OpenGL server for the
PC, but that would be a last resort.

The performance seems to drop below an acceptable speed when I use it
with Python.  Here's a test that draws 500 random length lines.  

  import Ranf
  rlines = (Ranf.random_sample(3000) -.5)*4
  t = time.time()
  Lines(rlines)
  tr = time.time() - t




1000 random lines takes 0.173418 seconds (5766.412600 lines/second

1000 random lines takes 0.041487 seconds (24103.948646 lines/second

There seems to be a great difference in speed if the line length
becomes very small.   

I did some more testing including a comparison with the Mesa
sample/speed.c test.  


The C version draws 100 lines in a glBegin ... glEnd loop and then
repeat this loop 1000 times.  

    for (i = 0; i < repeatCount; i++) {
	v1[0] = 10;
	v1[1] = 10;
	v1[2] = 10;
	v2[0] = 20;
	v2[1] = 20;
	v2[2] = 10;
	glBegin(GL_LINES);
	    for (j = 0; j < loopCount; j++) {
		glVertex2fv(v1);
		glVertex2fv(v2);
	    }
	glEnd();

The results of this test reports:

	Lines per second: 44052.9


I wrote a Python based test that approximates this number of line
draws.  

  small = N.array([0.,.0,0.,10.0,10.0,10.0])
  for i in range(13):
      small = small.concat(small)

  size = len(small)/6
  t = time.time()
  Lines(small)
  tr = time.time() - t
  print "speed line test takes %f seconds (%f lines/second)" %( tr, size/tr)

It results plotted about 8192 lines inside the Lines() command.  The
report printed 

  in reshape 600 300
  speed line test takes 1.377772 seconds (5945.831500 lines/second)
  1000 random lines takes 0.104659 seconds (9554.843538 lines/second

This test uses the same size window as the test script.  The viewport
is closer to the objects being drawn so the lines appear longer.

The Python based version draw at a rate of ~6000 l/s compared to the C
version was drawing at 44k l/s.  The difference is difficult to
uderstand.  It looks like all the time should be spent inside the
gl_Lines loop, so why isn't performance better.  Did I miss something
in my test? 

Michael

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================

From jjh@goldilocks.lcs.mit.edu  Tue Jul 23 20:48:21 1996
From: jjh@goldilocks.lcs.mit.edu (Jim Hugunin)
Date: Tue, 23 Jul 1996 15:48:21 -0400
Subject: [PYTHON MATRIX-SIG] Speed of opengl
References: <199607231401.OAA14652@fermi.eeel.nist.gov>
Message-ID: <31F52C85.1994@sls.lcs.mit.edu>

Michael McLay wrote:
> 
> Is openglmodule-0.33.c the most current version of the opengl module?
> There were a couple other modules available so I wasn't sure.

That's the most recent publically available version.  David Ascher, Tom
Schwaller and myself need to find the time to clean up and distribute a
final version sometime soon.

> I modified the glu, glut and opengl modules so the prefixes are no
> longer necessary.  They seemed redundent and C'ish.  I also had to
...
More reason to produce a clean version so each person doesn't have to do
this.

> The performance of the python OpenGL module on a Linux system isn't
> meeting my design objectives and I was wondering if I'm doing
> something wrong or if it's just slow software.  The system uses
> Mesa-1.2.8 on a Pentium 90 system with #9GXE 64Pro graphics card.
...
> This is pretty slow compared to an SGI.  I can live with it in the
> application but I'd like the drawing rate to be about 4x this speed.

Well, a P-90 is pretty slow compared to an SGI, and Mesa is not exactly
a speed demon.  

> I may even break down and buy a Acellerated-X OpenGL server for the
> PC, but that would be a last resort.

This is the price you'll have to pay if you want really great
performance (or switch over to NT 4.0 where they have a fairly nice
implementation distributed with the OS).
 
> The performance seems to drop below an acceptable speed when I use it
> with Python.  Here's a test that draws 500 random length lines.

Now this part I should be able to help with.

First, I'd advise using the idiom:

gl.Begin(GL_LINES)
gl.Vertex(array_of_vertices)
gl.End(GL_LINES)

its a much more general approach and Lines will probably be fading out
of future versions of the module.

As far as the speeds that you're noticing, this is completely counter to
my own experiences.  Could you send me the complete source (both python
and C) to your test programs so that I can look at them and run my own
tests?

-Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================

From drh@oasis.unl.edu  Wed Jul 24 03:06:02 1996
From: drh@oasis.unl.edu (Doug Heisterkamp)
Date: Tue, 23 Jul 1996 21:06:02 -0500 (CDT)
Subject: [PYTHON MATRIX-SIG] reverse function
Message-ID: <199607240206.VAA04504@oasis.unl.edu>

Hi,

After upgrading to version 3.6 I noticed that the reverse function
is not working:

>>> a = arange(100).reshape(5,20)
>>> reverse(a)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python/numeric/Numeric.py", line 124, in reverse
    return m[None] #::-1]
ArrayError: index must be either an int or a sequence

If I use the part that is commented out:

>>> a[::-1]
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
>>> 

Using ::-1 seems to work for 1 and 2D arrays.  Is there a reason
not to use it?  What is the exact meaning of :: ?

Thanks,
Doug
drh@oasis.unl.edu


=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================

From fredrik_lundh@ivab.se  Thu Jul 25 10:51:01 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Thu, 25 Jul 1996 11:51:01 +0200
Subject: [PYTHON MATRIX-SIG] [PREANNOUNCEMENT] netCDF reader for the matrix and image extensions
Message-ID: <9607250951.AA02801@arnold.image.ivab.se>



Just a little teaser ;-)


I've pulled together a netCDF reader that doesn't need any C library:

	data = NetCdfDataFile.open("dataset.cdf")

	# list variables
	print "variables:", data.keys()

	# global attributes
	print "global attributes:", data.attr.keys()

	# dump all variables in the file
	for i in data.keys():
	    var = data[i]
	    print i, data.type, data.shape
	    print "- data:", var[:]
	    if var.attr:
		print "- local attributes:", var.attr.keys()

It currently sports a slightly different interface compared to Bill
Noon's, but they can probably be unified.  And of course, to create or
modify netCDF files, you need to use the real library.


- The above module can be used with the Numerical extension to load
data as multidimensional arrays for further processing.

	var = data["foo"]
	foo = Numeric.array(var) # 1-dimensional
	foo.reshape(var.shape) # make n-dimensional


- It can also be used with the next version of PIL 0.2 in order to
load image data from netCDF files (PIL still supports 8-bit data only,
but you can use scale/offset to fit other data into the 0..255 range).

	# foo must be a 2-dimensional variable
	var = data["foo"]
	im = Image.new("L", var.shape)
	im.putdata(var, scale, offset)
	im.save("output.jpg")


I plan to release this with PIL 0.2.  Comments and flames are welcome.

	/F

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================