Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Giorgio Luciano
Thanks for the reply I will sure try to use it and so some small software.
Giorgio
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] About NumPy description

2007-04-04 Thread Francesc Altet
A Dimecres 04 Abril 2007 00:42, Charles R Harris escrigué:
> OT, but...
>
> Francesc, could you say whether tickets 373 and 394, reporting possible
> memory leaks, are still valid?

394 was fixed by Travis long time ago (he simply forgot to close the ticket, 
but now he have done it). Regarding 373, well, while I'm definitely not an 
expert at interpreting valgrind output, I don't really think this would 
represent a serious problem, so I'd close it.

> Travis, is there something to be done about ticket 399 or should it be
> marked an enhancement or some such.

Travis has fixed this tonight :)

> Just trying to clean stuff up ;)

Of course, good idea!

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] NumPy 1.0.2 released

2007-04-04 Thread Sven Schreiber
Charles R Harris wrote:
> 
> 
> On 4/3/07, *Travis Oliphant* <[EMAIL PROTECTED]

> 
> NumPy 1.0.2 was released yesterday (4-02-07).   Get it by following the

> And thanks for getting it out.
> 

>From me too!
-sven

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] Silent install of .exe

2007-04-04 Thread Mark Janikas
Is there a way to silently install the numpy.exe from a Microsoft DOS
prompt?

 

Something like: numpy-1.0.2.win32-py2.4.exe -silent

 

Thanks ahead of time...

 

MJ

 

Mark Janikas

Product Engineer

ESRI, Geoprocessing

380 New York St.

Redlands, CA 92373

909-793-2853 (2563)

[EMAIL PROTECTED]

 

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] About NumPy description

2007-04-04 Thread Francesc Altet
A Dimecres 04 Abril 2007 04:13, Steven H. Rogers escrigué:
> How about:
> """
> NumPy extends Python with a multi-dimensional array type (class) and
> related mathematical functions.  This provides the Python user with
> useful abstractions for managing and computing with multi-dimensional
> bulk data.  This provides a strong foundation for for such domains as
> statistics, image and signal processing, finance, and general systems
> modeling.  Easy integration with ctypes and Fortran allow efficient
> leveraging of high performance C and Fortran code.
> """

Yeah. That's better because it stresses both parts, the data containers and 
the mathematical functionality. However, I think that the word 
multi-dimensional (which is cited twice) may mislead some potential users 
that might be more interested in the heterogeneous type support for use in 
the database field.

At any rate, it's very difficult to expose all the nice things that is 
offering NumPy to the Python users in just a few lines.  Because of this, 
perhaps it is worth to expand these possibilities in the home page of NumPy 
(numpy.scipy.org). BTW, I see this better explained now:

"""
Besides it's obvious scientific uses, NumPy can also be used as an efficient 
multi-dimensional container of generic data. Arbitrary data-types can be 
defined. This allows NumPy to seamlessly and speedily integrate with a 
wide-variety of databases.
"""

Perhaps Travis has modifyied this recently? In that case, I find the above 
paragraph quite informative for the database field.

Lately, I tend to think (as someone has already suggested here) that NumPy is 
embracing many different fields at once and that a split in a couple of 
packages could adapt better to the users need.  IMO, a core with the 
containers and very few functions on top of them (sorting, lookup, 
selection,...), and another layer on top of the core with more mathematical 
(random, linalg, FFT...) functionality would make more sense than the  
current organisation (all in one single package).

Of course, such a split could introduce more difficulties to manage (more 
SVNs, more distribution lists, more releases, more binary packages and so on 
and so forth), but also could lead to a small core that do few things but 
very well done (and hence, easy to integrate in many different projects) and 
the next layer that do many more things but that would be used by a more 
specific user base (more scientific/technical biased). Incidentally, at the 
top of this stack of layers should be scipy, of course.

Finally, I suppose that the NumPy core  that I'm referring to would somehow 
overlap with the PEP for the new buffer interface that Travis is lately 
pushing forward (and that is meant to be integrated with Python 3000), 
although as I see the things, adding basic functionality to this buffer (like 
as I already said, fast sorting, lookup, data selection...) and packaging 
this in a single, compact package could be a really great contribution to the 
Python community in general.

Just some thoughts,

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] [ANN] PyTables 2.0b2 relased

2007-04-04 Thread Francesc Altet
===
 Announcing PyTables 2.0b2
===

PyTables is a library for managing hierarchical datasets and designed to
efficiently cope with extremely large amounts of data with support for
full 64-bit file addressing.  PyTables runs on top of the HDF5 library
and NumPy package for achieving maximum throughput and convenient use.

The PyTables development team is happy to announce the public
availability of the second *beta* version of PyTables 2.0. This will
hopefully be the last beta version of 2.0 series, so we need your
feedback if you want your issues to be solved before 2.0 final would be
out.

You can download a source package of the version 2.0b2 with
generated PDF and HTML docs and binaries for Windows from
http://www.pytables.org/download/preliminary/

For an on-line version of the manual, visit:
http://www.pytables.org/docs/manual-2.0b2
Please have in mind that some sections in the manual can be obsolete
(specially the "Optimization tips" chapter).  Other chapters should be
fairly up-to-date though (although still a bit in state of flux).

In case you want to know more in detail what has changed in this
version, have a look at ``RELEASE_NOTES.txt``.  Find the HTML version
for this document at:
http://www.pytables.org/moin/ReleaseNotes/Release_2.0b2

If you are a user of PyTables 1.x, probably it is worth for you to look
at ``MIGRATING_TO_2.x.txt`` file where you will find directions on how
to migrate your existing PyTables 1.x apps to the 2.0 version.  You can
find an HTML version of this document at
http://www.pytables.org/moin/ReleaseNotes/Migrating_To_2.x

Keep reading for an overview of the most prominent improvements in
PyTables 2.0 series.


New features of PyTables 2.0


- NumPy is finally at the core!  That means that PyTables no longer
  needs numarray in order to operate, although it continues to be
  supported (as well as Numeric).  This also means that you should be
  able to run PyTables in scenarios combining Python 2.5 and 64-bit
  platforms (these are a source of problems with numarray/Numeric
  because they don't support this combination as of this writing).

- Most of the operations in PyTables have experimented noticeable
  speed-ups (sometimes up to 2x, like in regular Python table
  selections).  This is a consequence of both using NumPy internally and
  a considerable effort in terms of refactorization and optimization of
  the new code.

- Combined conditions are finally supported for in-kernel selections.
  So, now it is possible to perform complex selections like::

  result = [ row['var3'] for row in
 table.where('(var2 < 20) | (var1 == "sas")') ]

  or::

  complex_cond = '((%s <= col5) & (col2 <= %s)) ' \
 '| (sqrt(col1 + 3.1*col2 + col3*col4) > 3)'
  result = [ row['var3'] for row in
 table.where(complex_cond % (inf, sup)) ]

  and run them at full C-speed (or perhaps more, due to the cache-tuned
  computing kernel of Numexpr, which has been integrated into PyTables).

- Now, it is possible to get fields of the ``Row`` iterator by
  specifying their position, or even ranges of positions (extended
  slicing is supported).  For example, you can do::

  result = [ row[4] for row in table# fetch field #4
 if row[1] < 20 ]
  result = [ row[:] for row in table# fetch all fields
 if row['var2'] < 20 ]
  result = [ row[1::2] for row in   # fetch odd fields
 table.iterrows(2, 3000, 3) ]

  in addition to the classical::

  result = [row['var3'] for row in table.where('var2 < 20')]

- ``Row`` has received a new method called ``fetch_all_fields()`` in
  order to easily retrieve all the fields of a row in situations like::

  [row.fetch_all_fields() for row in table.where('column1 < 0.3')]

  The difference between ``row[:]`` and ``row.fetch_all_fields()`` is
  that the former will return all the fields as a tuple, while the
  latter will return the fields in a NumPy void type and should be
  faster.  Choose whatever fits better to your needs.

- Now, all data that is read from disk is converted, if necessary, to
  the native byteorder of the hosting machine (before, this only
  happened with ``Table`` objects).  This should help to accelerate
  applications that have to do computations with data generated in
  platforms with a byteorder different than the user machine.

- The modification of values in ``*Array`` objects (through __setitem__)
  now doesn't make a copy of the value in the case that the shape of the
  value passed is the same as the slice to be overwritten. This results
  in considerable memory savings when you are modifying disk objects
  with big array values.

- All the leaf constructors (except Array) have received a new
  ``chunkshape`` argument that lets the user to explicitly select the
  chunksizes for the underlying HDF5 datasets (only for advanced 

Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread vallis . 35530053
Hello Gael (numpy friends),

I'd love to use Traits and TraitsUI. It looks
like a very promising approach. But why is it so difficult to install? If
I download the source from http://code.enthought.com/traits/, and follow the
instructions in enthought.traits-1.1.0/README, and then run the "code snippet
#1" in your tutorial, I get

--- begin error message ---

/Users/vallis/Desktop/enthought.traits-1.1.0/enthought/pyface/util/python_stc.py:14:
DeprecationWarning: The wxPython compatibility package is no longer 
automatically
generated or activly maintained.  Please switch to the wx package as soon
as possible.
  from wxPython.wx import *
Traceback (most recent call last):

  File "prova.py", line 23, in ?
camera.configure_traits()
  File "enthought/traits/has_traits.py",
line 1871, in configure_traits
  File 
"/Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/wx/toolkit.py",
line 134, in view_application
import view_application
  File 
"/Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/wx/view_application.py",
line 29, in ?
from enthought.debug.fbi \
  File "/Users/vallis/Desktop/enthought.traits-1.1.0/enthought/debug/fbi.py",
line 257, in ?
auto_size  = False
  File 
"/Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/editors.py",
line 196, in TableEditor
return toolkit().table_editor( *args, **traits
)
  File 
"/Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/wx/toolkit.py",
line 514, in table_editor
return te.ToolkitEditorFactory( *args, **traits
)
  File 
"/Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/editor_factory.py",
line 55, in __init__
HasPrivateTraits.__init__( self, **traits )
  File
"enthought/traits/trait_handlers.py", line 172, in error
enthought.traits.trait_errors.TraitError:
The 'selection_color' trait of a ToolkitEditorFactory instance must be a 
wx.Colour
instance, an integer which in hex is of the form 0xRRGGBB, where RR is red,
GG is green, and BB is blue, but a value of black was specified.

--- end
error message ---

BTW, I'm using Python 2.4.4 on Macintel, with wxPython-2.8.0.


If I get the latest SVN of the enthought tool suite, go to 
enthought/src/lib/enthought/traits,
and build with

python setup.py build_src build_clib build_ext --inplace


as suggested in the enthought wiki, and then add enthought/src/lib to my
PYTHONPATH, then your snippet fails with

--- begin error message ---


Traceback (most recent call last):
  File "prova.py", line 5, in ?
   
class Camera(HasTraits):
NameError: name 'HasTraits' is not defined

---
end error message ---

Last, I see that matplotlib includes some enthought/traits
code, but not the ui frontends. Why is that? Is the matplotlib traits usable?


As you can see, I'm very confused... if only there was a traits Python
egg...

Thanks!

Michele


--- Discussion of Numerical Python  chapter of my tutorial
> http://gael-varoquaux.info/computers/traits_tutorial/traits_tutorial.html

> . You can also build a complete interactive application, as described in

> the rest of the tutorial, but this is more work.
> 
> If you have more
questions about this approach feal free to ask.
> 
> Ga�l
> 
> ___

> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

> 
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Robert Kern
[EMAIL PROTECTED] wrote:
> Hello Gael (numpy friends),
> 
> I'd love to use Traits and TraitsUI. It looks
> like a very promising approach. But why is it so difficult to install? If
> I download the source from http://code.enthought.com/traits/, and follow the
> instructions in enthought.traits-1.1.0/README, and then run the "code snippet
> #1" in your tutorial, I get

> BTW, I'm using Python 2.4.4 on Macintel, with wxPython-2.8.0.

We require wxPython 2.6 at the moment.

> If I get the latest SVN of the enthought tool suite, go to 
> enthought/src/lib/enthought/traits,
> and build with
> 
> python setup.py build_src build_clib build_ext --inplace
> 
> 
> as suggested in the enthought wiki, and then add enthought/src/lib to my
> PYTHONPATH, then your snippet fails with
> 
> --- begin error message ---
> 
> Traceback (most recent call last):
>   File "prova.py", line 5, in ?
>
> class Camera(HasTraits):
> NameError: name 'HasTraits' is not defined

Hmm, it works for me. Are you sure that your build is being correctly picked up?
Import enthought, then print enthought.__file__.

> Last, I see that matplotlib includes some enthought/traits
> code, but not the ui frontends. Why is that? Is the matplotlib traits usable?

No, in fact I don't believe it was used at all. It was going to be experimented
with, but I don't think that ever progressed anywhere.

> As you can see, I'm very confused... if only there was a traits Python
> egg...

There are, but only binaries for win32 at the moment. Building from source on OS
X should be straightforward, though.

  https://svn.enthought.com/enthought/wiki/IntelMacPython25

Python 2.4 from www.python.org should work similarly.

-- 
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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Gael Varoquaux
On Wed, Apr 04, 2007 at 04:36:19PM -0500, Robert Kern wrote:
> > As you can see, I'm very confused... if only there was a traits Python
> > egg...

> There are, but only binaries for win32 at the moment. Building from
> source on OS X should be straightforward, though.

How about linux eggs ? I had the feeling they had made a lot of progress.

Michele, indeed I would say that the weak point of traitsUI is the
packaging. It is a great module, but it lacks packaging. I personnaly
compile it from svn, but I know this is not an option for everybody.
People are working on this issue, and it is making progress, but
unfortunatly it seems to me that packaging things on OS X is a bit
challenge currently.

Regards,

Gaël

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread vallis . 35530053
--- Discussion of Numerical Python  > BTW, I'm using Python 2.4.4 on Macintel, with wxPython-2.8.0.

> 
> We require wxPython 2.6 at the moment.

Ah, good to know. This could
explain the errors I get when compiling in place.

> > If I get the latest
SVN of the enthought tool suite, go to enthought/src/lib/enthought/traits,

> > and build with
> > 
> > python setup.py build_src build_clib build_ext
--inplace
> > 
> > 
> > as suggested in the enthought wiki, and then add
enthought/src/lib to my
> > PYTHONPATH, then your snippet fails with
> >

> > --- begin error message ---
> > 
> > Traceback (most recent call last):

> >   File "prova.py", line 5, in ?
> >
> > class Camera(HasTraits):

> > NameError: name 'HasTraits' is not defined
> 
> Hmm, it works for me.
Are you sure that your build is being correctly picked up?
> Import enthought,
then print enthought.__file__.

Yes, it is picking up the right one. I assume
I can run the setup.py in enthought/src/lib/enthought/traits to get only traits,
right? I'm not installing scipy, or anything else.

> > As you can see,
I'm very confused... if only there was a traits Python
> > egg...
> 
>
There are, but only binaries for win32 at the moment. Building from source
on OS
> X should be straightforward, though.
> 
>   https://svn.enthought.com/enthought/wiki/IntelMacPython25


Ok, I'll try tomorrow and let you know.

Michele 

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Robert Kern
Gael Varoquaux wrote:
> On Wed, Apr 04, 2007 at 04:36:19PM -0500, Robert Kern wrote:
>>> As you can see, I'm very confused... if only there was a traits Python
>>> egg...
> 
>> There are, but only binaries for win32 at the moment. Building from
>> source on OS X should be straightforward, though.
> 
> How about linux eggs ? I had the feeling they had made a lot of progress.

There's certainly been progress on making the subpackages independently
buildable. I don't think you'll see eggs for Linux, though. Frankly, eggs for
Linux are nearly useless except for specific deployment goals. A Fedora Core 4
egg won't work on a Debian box, etc.

Building enthought from source is not hard. Certainly easier than scipy or
matplotlib.

-- 
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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Robert Kern
[EMAIL PROTECTED] wrote:
> --- Discussion of Numerical Python  [EMAIL PROTECTED]
> wrote:

>>> If I get the latest
> SVN of the enthought tool suite, go to enthought/src/lib/enthought/traits,
> 
>>> and build with
>>>
>>> python setup.py build_src build_clib build_ext
> --inplace
>>>
>>> as suggested in the enthought wiki, and then add
> enthought/src/lib to my
>>> PYTHONPATH, then your snippet fails with
>>>
> 
>>> --- begin error message ---
>>>
>>> Traceback (most recent call last):
> 
>>>   File "prova.py", line 5, in ?
>>>
>>> class Camera(HasTraits):
> 
>>> NameError: name 'HasTraits' is not defined
>> Hmm, it works for me.
> Are you sure that your build is being correctly picked up?
>> Import enthought,
> then print enthought.__file__.
> 
> Yes, it is picking up the right one. I assume
> I can run the setup.py in enthought/src/lib/enthought/traits to get only 
> traits,
> right? I'm not installing scipy, or anything else.

Ah, sorry, I missed the bit where you said you only built inside
enthought/traits/. I'd build the whole suite. It'll take a bit, building the
extension modules for Kiva, but nothing too bad. I don't know why you'd get the
error, though. enthought.traits.api should have HasTraits.

-- 
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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Sebastian Haase
Is enthought now defaulting to numpy ?

-Sebastian


On 4/4/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > --- Discussion of Numerical Python  > [EMAIL PROTECTED]
> > wrote:
>
> >>> If I get the latest
> > SVN of the enthought tool suite, go to enthought/src/lib/enthought/traits,
> >
> >>> and build with
> >>>
> >>> python setup.py build_src build_clib build_ext
> > --inplace
> >>>
> >>> as suggested in the enthought wiki, and then add
> > enthought/src/lib to my
> >>> PYTHONPATH, then your snippet fails with
> >>>
> >
> >>> --- begin error message ---
> >>>
> >>> Traceback (most recent call last):
> >
> >>>   File "prova.py", line 5, in ?
> >>>
> >>> class Camera(HasTraits):
> >
> >>> NameError: name 'HasTraits' is not defined
> >> Hmm, it works for me.
> > Are you sure that your build is being correctly picked up?
> >> Import enthought,
> > then print enthought.__file__.
> >
> > Yes, it is picking up the right one. I assume
> > I can run the setup.py in enthought/src/lib/enthought/traits to get only 
> > traits,
> > right? I'm not installing scipy, or anything else.
>
> Ah, sorry, I missed the bit where you said you only built inside
> enthought/traits/. I'd build the whole suite. It'll take a bit, building the
> extension modules for Kiva, but nothing too bad. I don't know why you'd get 
> the
> error, though. enthought.traits.api should have HasTraits.
>
> --
> Robert Kern
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Sebastian Haase
Hello Gael,

Short question regarding your tutorial -- I'm very intrigued by traits
and would like to use them too 
Why do you define e.g. the Point class like this:
class Point(object):
""" 3D Point objects """
x = 0.
y = 0.
z = 0.

and not like this:
class Point(object):
""" 3D Point objects """
def __init__(self):
   self.x = 0.
   self.y = 0.
   self.z = 0.

I thought in the first case, if one did "a = Point(); a.x = 6"  that
from then on ANY new point ( "b = Point()" ) would be created with b.x
being 6 -- because 'x' is a class attribute   and nor a instance
attribute  !?

This is obviously a beginners question - and I'm hopefully missing something.

Thanks,
Sebastian Haase




On 4/3/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> You can do a script with a GUI front end, as described in the first
> chapter of my tutorial
> http://gael-varoquaux.info/computers/traits_tutorial/traits_tutorial.html
> . You can also build a complete interactive application, as described in
> the rest of the tutorial, but this is more work.
>
> If you have more questions about this approach feal free to ask.
>
> Gaël
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Robert Kern
Sebastian Haase wrote:
> Is enthought now defaulting to numpy ?

Still set NUMERIX=numpy for now.

-- 
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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Robert Kern
Sebastian Haase wrote:
> Hello Gael,
> 
> Short question regarding your tutorial -- I'm very intrigued by traits
> and would like to use them too 
> Why do you define e.g. the Point class like this:
> class Point(object):
> """ 3D Point objects """
> x = 0.
> y = 0.
> z = 0.
> 
> and not like this:
> class Point(object):
> """ 3D Point objects """
> def __init__(self):
>self.x = 0.
>self.y = 0.
>self.z = 0.
> 
> I thought in the first case, if one did "a = Point(); a.x = 6"  that
> from then on ANY new point ( "b = Point()" ) would be created with b.x
> being 6 -- because 'x' is a class attribute   and nor a instance
> attribute  !?

No, setting "a.x = 6" will set it on the instance, not the class.

-- 
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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] nd_image.affine_transform edge effects

2007-04-04 Thread James Turner
 > OK, that was a one-line patch.  Please test to see if there are any
 > subtle conditions on the border that I may have missed. I know of one
 > already, but I'd be glad if you can find any others :)

Thanks, Stefan! That looks much better.

Today I finally had time to figure out the basics of SVN, make a patch and
apply your changes to my numarray version of nd_image (I'll switch to numpy
as soon as STScI does a full numpy-based release...). Your integer clipping
changes wouldn't compile under numarray unmodified, but my data are floating
point anyway, so I just applied and tested the array indexing changes.

It looks like there may still be some edge effects due to the mirroring
properties of the spline algorithm for higher orders, but the gross problem
of extrapolating 1 pixel into the mirrored data has gone away :-). I think
that's good enough for nd_image to be useful for me, but if I can find time
later it would be good to look into improving the behaviour further.

For my real data, mode="constant" now seems to work well, but I also tested
some simple examples (like in this thread) using "reflect" and "wrap". I'm
not 100% sure from the numarray manual what their correct behaviour is
supposed to be, but I noticed some things that seem anomalous. For example:

-

import numarray as N
import numarray.nd_image as ndi

I = N.zeros((2,4),N.Float32)
I[:,:] = N.arange(4.0, 0.0, -1.0)

trmatrix = N.array([[1,0],[0,1]])
troffset1 = (0.0, -0.1)

I_off1 = ndi.affine_transform(I, trmatrix, troffset1, order=1,
   mode='reflect', output_shape=(2,6))

print I
print I_off1

-

produces

[[ 4.  3.  2.  1.]
  [ 4.  3.  2.  1.]]
[[ 3.099   3.099   2.099   1.1002  1.8998
1.8998]
  [ 3.099   3.099   2.099   1.1002  1.8998
1.8998]]

It looks like the last output value is produced by reflecting the
input and then interpolating, but presumably then the first value
should be 3.9, for consistency, not 3.1? Does that make sense?

Cheers,

James.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] nd_image.affine_transform edge effects

2007-04-04 Thread James Turner
 > It looks like the last output value is produced by reflecting the
 > input and then interpolating, but presumably then the first value
 > should be 3.9, for consistency, not 3.1? Does that make sense?

Aargh. I think I see what's happening now. The input is supposed to
be interpolated and then reflected like this:

  [4  3  2  1]  ->  [3.1  3.1  2.1  1.1  1.1]

The problem is that there is still one value too many being
"interpolated" here before the reflection takes place. Do the
sections beginning at lines 168 & 178 need changing in a similar way
to their counterparts at lines 129 & 139? I started looking into
this, but I don't understand the code well enough to be sure I'm
making the right changes...

Thanks,

James.

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Sebastian Haase
On 4/4/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Sebastian Haase wrote:
> > Hello Gael,
> >
> > Short question regarding your tutorial -- I'm very intrigued by traits
> > and would like to use them too 
> > Why do you define e.g. the Point class like this:
> > class Point(object):
> > """ 3D Point objects """
> > x = 0.
> > y = 0.
> > z = 0.
> >
> > and not like this:
> > class Point(object):
> > """ 3D Point objects """
> > def __init__(self):
> >self.x = 0.
> >self.y = 0.
> >self.z = 0.
> >
> > I thought in the first case, if one did "a = Point(); a.x = 6"  that
> > from then on ANY new point ( "b = Point()" ) would be created with b.x
> > being 6 -- because 'x' is a class attribute   and nor a instance
> > attribute  !?
>
> No, setting "a.x = 6" will set it on the instance, not the class.

OK, but what is "wrong" with the first way !?  I mean,  it somehow
seems not like "it's usually done" in Python ?  Normally there is
always a __init__(self) that sets up everything referring to self --
why is this tutorial doing it differently ?

-Sebastian
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Robert Kern
Sebastian Haase wrote:

> OK, but what is "wrong" with the first way !?  I mean,  it somehow
> seems not like "it's usually done" in Python ?  Normally there is
> always a __init__(self) that sets up everything referring to self --
> why is this tutorial doing it differently ?

Because it makes the code more readable for the point it's trying to get across.
The __init__ style code would be irrelevant detail detracting from the main 
point.

-- 
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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] Big list of Numpy & Scipy users

2007-04-04 Thread Bill Baxter
On 4/4/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Bill Baxter wrote:
> > Is there any place on the Wiki that lists all the known software that
> > uses Numpy in some way?
> >
>> > It would be nice to start collecting such a list if there isn't one
> > already.  Screenshots would be nice too.
>
> There is no such list that I know of, but you may start one on the wiki if 
> you like.

Ok, I made a start:  http://www.scipy.org/Scipy_Projects
Anyone who has a project that depends on Numpy or Scipy, please go add
your info there!

I haven't linked it from anywhere, because it looks pretty pathetic
right now with only three or four entries.  But hopefully everyone
will jumps in and add their project to the list.

Part of the idea is that this should be a good place to point
nay-sayers to when they say "meh - numpy... that's a niche project for
a handful of scientists."

So ... hopefully a good portion of the links will be things other than
science projects.  There will hopefully be a lot of things that
"ordinary users" would care about.  :-)

I couldn't figure out how to add an image, but if someone knows how to
do that, please do.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Bill Baxter
Ok, I got another hopefully easy question:

Why this:
class Point(object):
  ...

Instead of the style that's used in the Python tutorial in the
'classes' chapter:
class Point:
...

--bb


On 4/5/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Sebastian Haase wrote:
>
> > OK, but what is "wrong" with the first way !?  I mean,  it somehow
> > seems not like "it's usually done" in Python ?  Normally there is
> > always a __init__(self) that sets up everything referring to self --
> > why is this tutorial doing it differently ?
>
> Because it makes the code more readable for the point it's trying to get 
> across.
> The __init__ style code would be irrelevant detail detracting from the main 
> point.
>
> --
> 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
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Robert Kern
Bill Baxter wrote:
> Ok, I got another hopefully easy question:
> 
> Why this:
> class Point(object):
>   ...
> 
> Instead of the style that's used in the Python tutorial in the
> 'classes' chapter:
> class Point:
> ...

Because the former make new-style classes and the latter make old-style classes.
It's not an issue of personal preference: they are somewhat different object
models and there are things that old-style classes can't do. As HasTraits is
also a new-style class, there's no point in using old-style classes in this
tutorial.

-- 
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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] basic python questions

2007-04-04 Thread Bill Baxter
On 4/5/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Bill Baxter wrote:
> > Ok, I got another hopefully easy question:
> >
> > Why this:
> > class Point(object):
> >   ...
> >
> > Instead of the style that's used in the Python tutorial in the
> > 'classes' chapter:
> > class Point:
> > ...
>
> Because the former make new-style classes and the latter make old-style 
> classes.
> It's not an issue of personal preference: they are somewhat different object
> models and there are things that old-style classes can't do. As HasTraits is
> also a new-style class, there's no point in using old-style classes in this
> tutorial.

What's the difference in the object models?  I'm surprised that the
Python tutorial seems to be completely silent on this issue.
(http://docs.python.org/tut/node11.html)

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] basic python questions

2007-04-04 Thread Robert Kern
Bill Baxter wrote:
> On 4/5/07, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Bill Baxter wrote:
>>> Ok, I got another hopefully easy question:
>>>
>>> Why this:
>>> class Point(object):
>>>   ...
>>>
>>> Instead of the style that's used in the Python tutorial in the
>>> 'classes' chapter:
>>> class Point:
>>> ...
>> Because the former make new-style classes and the latter make old-style 
>> classes.
>> It's not an issue of personal preference: they are somewhat different object
>> models and there are things that old-style classes can't do. As HasTraits is
>> also a new-style class, there's no point in using old-style classes in this
>> tutorial.
> 
> What's the difference in the object models?  I'm surprised that the
> Python tutorial seems to be completely silent on this issue.
> (http://docs.python.org/tut/node11.html)

http://www.python.org/doc/newstyle.html

-- 
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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] basic python questions

2007-04-04 Thread Bill Baxter
On 4/5/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Bill Baxter wrote:
> > On 4/5/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> >> Bill Baxter wrote:
> >>> Ok, I got another hopefully easy question:
> >>>
> >>> Why this:
> >>> class Point(object):
> >>>   ...
> >>>
> >>> Instead of the style that's used in the Python tutorial in the
> >>> 'classes' chapter:
> >>> class Point:
> >>> ...
> >> Because the former make new-style classes and the latter make old-style 
> >> classes.
> >> It's not an issue of personal preference: they are somewhat different 
> >> object
> >> models and there are things that old-style classes can't do. As HasTraits 
> >> is
> >> also a new-style class, there's no point in using old-style classes in this
> >> tutorial.
> >
> > What's the difference in the object models?  I'm surprised that the
> > Python tutorial seems to be completely silent on this issue.
> > (http://docs.python.org/tut/node11.html)
>
> http://www.python.org/doc/newstyle.html
>

Good link.  Thanks!

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] basic python questions

2007-04-04 Thread Eric Firing
Robert Kern wrote:
> Bill Baxter wrote:
>> On 4/5/07, Robert Kern <[EMAIL PROTECTED]> wrote:
>>> Bill Baxter wrote:
 Ok, I got another hopefully easy question:

 Why this:
 class Point(object):
   ...

 Instead of the style that's used in the Python tutorial in the
 'classes' chapter:
 class Point:
 ...
>>> Because the former make new-style classes and the latter make old-style 
>>> classes.
>>> It's not an issue of personal preference: they are somewhat different object
>>> models and there are things that old-style classes can't do. As HasTraits is
>>> also a new-style class, there's no point in using old-style classes in this
>>> tutorial.
>> What's the difference in the object models?  I'm surprised that the
>> Python tutorial seems to be completely silent on this issue.
>> (http://docs.python.org/tut/node11.html)
> 
> http://www.python.org/doc/newstyle.html
> 

Key point: properties work with new-style classes but fail silently and 
mysteriously with classic classes.

Eric

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] basic python questions

2007-04-04 Thread Alan G Isaac
On Wed, 04 Apr 2007, Eric Firing apparently wrote: 
> Key point: properties work with new-style classes but fail 
> silently and mysteriously with classic classes. 

Or making the same point a little more generally,
descriptors only work for new-style classes:
http://users.rcn.com/python/download/Descriptor.htm

I am nevertheless uncertain why you need new-style
classes if you create a iterable class that you
want numpy to be able to convert to an array.

Cheers,
Alan Isaac


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Big list of Numpy & Scipy users

2007-04-04 Thread Sebastian Haase
Hi,
Why do you call it
Scipy_Projects
if it also lists people/project who use (only) numpy.

I wish I could suggest a better name ...
I just checked the swig.org web site;  the call it just
"projects"   ( http://www.swig.org/projects.html )
[ Open source projects using SWIG ]
so maybe just leaving out the "Scipy_" part.

BTW,  do peer review papers count !?  I have two of them, using numpy
(originally numarray, but now it's numpy)

Maybe the projects should be in categories:
- open source
- commercial   (?)
- papers
- ??

-Sebastian




On 4/4/07, Bill Baxter <[EMAIL PROTECTED]> wrote:
> On 4/4/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> > Bill Baxter wrote:
> > > Is there any place on the Wiki that lists all the known software that
> > > uses Numpy in some way?
> > >
> >> > It would be nice to start collecting such a list if there isn't one
> > > already.  Screenshots would be nice too.
> >
> > There is no such list that I know of, but you may start one on the wiki if 
> > you like.
>
> Ok, I made a start:  http://www.scipy.org/Scipy_Projects
> Anyone who has a project that depends on Numpy or Scipy, please go add
> your info there!
>
> I haven't linked it from anywhere, because it looks pretty pathetic
> right now with only three or four entries.  But hopefully everyone
> will jumps in and add their project to the list.
>
> Part of the idea is that this should be a good place to point
> nay-sayers to when they say "meh - numpy... that's a niche project for
> a handful of scientists."
>
> So ... hopefully a good portion of the links will be things other than
> science projects.  There will hopefully be a lot of things that
> "ordinary users" would care about.  :-)
>
> I couldn't figure out how to add an image, but if someone knows how to
> do that, please do.
>
> --bb
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] basic python questions

2007-04-04 Thread Sebastian Haase
On 4/4/07, Bill Baxter <[EMAIL PROTECTED]> wrote:
> On 4/5/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> > Bill Baxter wrote:
> > > Ok, I got another hopefully easy question:
> > >
> > > Why this:
> > > class Point(object):
> > >   ...
> > >
> > > Instead of the style that's used in the Python tutorial in the
> > > 'classes' chapter:
> > > class Point:
> > > ...
> >
> > Because the former make new-style classes and the latter make old-style 
> > classes.
> > It's not an issue of personal preference: they are somewhat different object
> > models and there are things that old-style classes can't do. As HasTraits is
> > also a new-style class, there's no point in using old-style classes in this
> > tutorial.
>
> What's the difference in the object models?  I'm surprised that the
> Python tutorial seems to be completely silent on this issue.
> (http://docs.python.org/tut/node11.html)
>
Not really answering your question -- but I have complained about that
tutorial before, with regards to new language features ... it does not
mention
from __future__ import division
In my mind this should be put at the very front - because it's going
to be a very big thing once Python 3000 comes around.
The Python-list people did not like my arguing because apparently the
tutorial is supposed to "look nice"   [[ don't get me wrong,  I
really recommend the tutorial, I like it, I think it's good ]]
But some (even if) ugly things should be said up front, if they clear
up the way.
Python 3000 will also default to new-style classes -- so that
"(object)" thing would go away again if I'm not mistaken.

-Sebastian

PS:
Maybe this list could officially endorse the
from __future__ import division
I would be very interested in this !
Math becomes clearer, and  things like  arr[5/2]  won't only suddenly
fail in the future,  they should be NOW written as arr[5//2] (if you
need integer division)
Thanks. [[ please start a new thread, and put up a page on the wiki ;-) ]]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Big list of Numpy & Scipy users

2007-04-04 Thread Bill Baxter
On 4/5/07, Sebastian Haase <[EMAIL PROTECTED]> wrote:
> Hi,
> Why do you call it
> Scipy_Projects
> if it also lists people/project who use (only) numpy.
>
> I wish I could suggest a better name ...
> I just checked the swig.org web site;  the call it just
> "projects"   ( http://www.swig.org/projects.html )
> [ Open source projects using SWIG ]
> so maybe just leaving out the "Scipy_" part.
>
> BTW,  do peer review papers count !?  I have two of them, using numpy
> (originally numarray, but now it's numpy)
>
> Maybe the projects should be in categories:
> - open source
> - commercial   (?)
> - papers
> - ??
>
> -Sebastian
>
>
>
>
> On 4/4/07, Bill Baxter <[EMAIL PROTECTED]> wrote:
> > On 4/4/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> > > Bill Baxter wrote:
> > > > Is there any place on the Wiki that lists all the known software that
> > > > uses Numpy in some way?
> > > >
> > >> > It would be nice to start collecting such a list if there isn't one
> > > > already.  Screenshots would be nice too.
> > >
> > > There is no such list that I know of, but you may start one on the wiki 
> > > if you like.
> >
> > Ok, I made a start:  http://www.scipy.org/Scipy_Projects
> > Anyone who has a project that depends on Numpy or Scipy, please go add
> > your info there!
> >
> > I haven't linked it from anywhere, because it looks pretty pathetic
> > right now with only three or four entries.  But hopefully everyone
> > will jumps in and add their project to the list.
> >
> > Part of the idea is that this should be a good place to point
> > nay-sayers to when they say "meh - numpy... that's a niche project for
> > a handful of scientists."
> >
> > So ... hopefully a good portion of the links will be things other than
> > science projects.  There will hopefully be a lot of things that
> > "ordinary users" would care about.  :-)
> >
> > I couldn't figure out how to add an image, but if someone knows how to
> > do that, please do.
> >
> > --bb

Good points.  I don't really have answers.  So just go to town
reorganizing as you feel fit.
But open source / commercial is not a real dichotomy.  And a paper may
be written about a system that is available as open source.  I tried
to think of some such categories, but applications vs libs was about
the best I could come up with.  Probably a tagging system would be the
most appropriate, but that's not so easy to make work on a Wiki.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Gael Varoquaux
On Wed, Apr 04, 2007 at 05:07:38PM -0500, Robert Kern wrote:
> Ah, sorry, I missed the bit where you said you only built inside
> enthought/traits/. I'd build the whole suite. It'll take a bit,
> building the extension modules for Kiva, but nothing too bad. I don't
> know why you'd get the error, though. enthought.traits.api should have
> HasTraits.

Actually if you have problem compiling you can try leaving out kiva, it
is not terribly useful for what you are currently doing. To do this
comment the "config.add_subpackage('kiva') in "setup.py". I have found
out that kiva is the package that is the hardest to compile.

The way I compile the ETS is to use the old "./build_inplace.sh numpy"
method. IWOMB (it works on my box).

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] question about standalone small software and teaching

2007-04-04 Thread Gael Varoquaux
On Wed, Apr 04, 2007 at 04:46:59PM -0700, Sebastian Haase wrote:
> Why do you define e.g. the Point class like this:
> class Point(object):
> """ 3D Point objects """
> x = 0.
> y = 0.
> z = 0.

> and not like this:
> class Point(object):
> """ 3D Point objects """
> def __init__(self):
>self.x = 0.
>self.y = 0.
>self.z = 0.

> I thought in the first case, if one did "a = Point(); a.x = 6"  that
> from then on ANY new point ( "b = Point()" ) would be created with b.x
> being 6 -- because 'x' is a class attribute   and nor a instance
> attribute  !?

> This is obviously a beginners question - and I'm hopefully missing something.

Actually this raises quite subtle problems. 

The first syntax defines class attributes, and the second instance
attributes. Now in the given example there is no diference, because "x"
is a float, wich is immutable, so x get replaced each time it is
modified. I tend to use class attributes because I find that the class
definition is more readable, and they also survive to a forgotten
"super().__init__" in the init. Another reason is that traits are always
class attributes, so as I use traits a lot I tend to have the habit of
class attributes.

Now the subtle problems are illustrated by this code snippet:


class Foo(object):
a = [1, ]

f = Foo()
f.a.append(1)

g = Foo()

print g.a


This will print out "[1, 1]". The reason is that the class attribute "a"
is a mutable that has been modified in place by the "append" operation.

I have seen beginners get tangled in these problems and I have recently
started avoided using class attributes when not necessary, so as to
avoid having to explain what are mutables, and class attributes... to
beginners, who often do not find all this easy to understand.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion