Re: [Numpy-discussion] question about standalone small software and teaching
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
Re: [Numpy-discussion] question about standalone small software and teaching
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] Big list of Numpy & Scipy users
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] basic python questions
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
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
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] basic python questions
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
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
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
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] question about standalone small software and teaching
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] question about standalone small software and teaching
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
[Numpy-discussion] Big list of Numpy & Scipy users
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
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
Re: [Numpy-discussion] question about standalone small software and teaching
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] nd_image.affine_transform edge effects
> 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] nd_image.affine_transform edge effects
> 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] question about standalone small software and teaching
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] question about standalone small software and teaching
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
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
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
[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
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
--- 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
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
[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
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
[Numpy-discussion] [ANN] PyTables 2.0b2 relased
===
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] About NumPy description
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] Silent install of .exe
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] NumPy 1.0.2 released
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
Re: [Numpy-discussion] About NumPy description
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] question about standalone small software and teaching
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
