Just asking.
In [35]: type(array(1.0)*2)
Out[35]: <type 'numpy.float64'>
In [36]: type(array(1.0))
Out[36]: <type 'numpy.ndarray'>
Chuck
_______________________________________________ Scipy-dev mailing list Scipy-dev <at> scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Hi there,
I would like to clean-up and improve the kmean algorithm (more
initialization schemes for the algorithm, and better docs). I already
have write access to the scipy svn rep, but as scipy.clusters is not in
the sandbox nor my code, I would like to make sure it is OK,
cheers,
David
David Cournapeau wrote: > Hi there, > > I would like to clean-up and improve the kmean algorithm (more > initialization schemes for the algorithm, and better docs). I already > have write access to the scipy svn rep, but as scipy.clusters is not in > the sandbox nor my code, I would like to make sure it is OK, It is. Thank you! -- -- 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
David Cournapeau wrote: > Hi there, > > I would like to clean-up and improve the kmean algorithm (more > initialization schemes for the algorithm, and better docs). I already > have write access to the scipy svn rep, but as scipy.clusters is not in > the sandbox nor my code, I would like to make sure it is OK, > I'm pretty sure nobody else is working on it at the moment so please do whatever you can. Many thanks, -Travis
To all SciPy / NumPy users: NumPy 1.0.2 was released yesterday (4-02-07). Get it by following the download link at http://numpy.scipy.org This is a bug-fix release with a couple of additional features. Thanks to everybody who helped track down and fix bugs. -Travis
Hi
Running scipy.test() after installing an SVN version of scipy on
windows ('0.5.3.dev2895') causes the interpereter to crash on
the "generic 1d filter" test. This problem seems to be windows
specific and have appeared sometime after '0.5.3.dev2866'.
scipy.test(1,10)
generation of a binary structure 3 ... ok
generation of a binary structure 4 ... ok
generic filter 1 ... ERROR
generic 1d filter 1
Build environment
scipy.__version__ = '0.5.3.dev2895'
numpy.__version__ = '1.0.3.dev3657'
WinXP, Python2.4, MinGW (gcc 3.4.5), ATLAS 3.7.11
TIA
Brett
Hi Brett
I fixed a couple of issues in ndimage regarding spline interpolation,
which required porting some of the code from numarray to numpy. The
memory leak was probably introduced then. I ran the whole test suite
under valgrind, which didn't report any problems under linux (just did
it again to make sure, and it's still fine).
Unfortunately, I am not familiar enough with windows systems to know
what the equivalent of valgrind would be. Is there any way you can
localise the problem further?
Just to be safe, please make sure you are doing a clean build
of scipy > r2889.
Regards
Stéfan
On Wed, Apr 04, 2007 at 08:02:08AM +0200, Brett Olivier wrote:
> Hi
>
> Running scipy.test() after installing an SVN version of scipy on
> windows ('0.5.3.dev2895') causes the interpereter to crash on
> the "generic 1d filter" test. This problem seems to be windows
> specific and have appeared sometime after '0.5.3.dev2866'.
>
> scipy.test(1,10)
> generation of a binary structure 3 ... ok
> generation of a binary structure 4 ... ok
> generic filter 1 ... ERROR
> generic 1d filter 1
>
> Build environment
> scipy.__version__ = '0.5.3.dev2895'
> numpy.__version__ = '1.0.3.dev3657'
> WinXP, Python2.4, MinGW (gcc 3.4.5), ATLAS 3.7.11
>
> TIA
> Brett
Nils Wagner wrote: > Hi all, > > scipy.test(1,10) reports a lot of memory leaks, e.g. > > Getting factors of complex matrixswig/python detected a memory leak of > type 'void *', no destructor found. > Getting factors of real matrixswig/python detected a memory leak of type > 'void *', no destructor found. > Solve with UMFPACK: double precision complexswig/python detected a > memory leak of type 'void *', no destructor found. > swig/python detected a memory leak of type 'void *', no destructor found. > ... ok > Solve: single precision complexUse minimum degree ordering on A'+A. > ... ok > Solve with UMFPACK: double precisionswig/python detected a memory leak > of type 'void *', no destructor found. > swig/python detected a memory leak of type 'void *', no destructor found. > ... ok > > Is this a swig problem ? > > I am using > > Numpy version 1.0.2.dev3562 > Scipy version 0.5.3.dev2774 Hi Nils, it was not a swig problem but mine (passing bad 'own' flag in a typemap)). One can be really blind... Now it seems fixed. (rev. 2896) r.
Robert Kern <robert.kern <at> gmail.com> writes:
[on the question whether the svn-layout {branch,tags,trunk}/subproject
(Robert) or subproject/{branch,tags,trunk} (me) is preferable for scikits]
> By and large, it simply doesn't matter to "get everything related to your
> project". Believe me, you don't want all of branches/ and tags/ in a
> checkout.
I have done so in order to get some overview over a project that I was
unfamiliar with, but I agree that that's hardly an important use case.
Migration convenience seems more relevant, but unless rearranging dir
structure in svn repositories is really hard, that's not a big factor either.
> On the other hand, "getting all of the packages in scikits" does matter.
Sure, but not that often either. Why would many people want to frequently
update the svn versions of all of several unrelated and fairly special purpose
scientific packages? I would assume the typical case is that someone hacks
e.g. mlabwrap and updates that from time to time rather than a dozen other
porjects.
> IMO, the inconvenience of prefixing your branches and tags is secondary to
> the performance problems of svn:external, which slows down all checkouts and
> updates for everyone
Only dirs with svn:externals would be affected, right? Since the only such dir
would be /scikits, which most people won't checkout, I don't think there would
be much of an impact (see above).
> (although I'll have to double-check that claim for svn:external links within
> the same repository).
I think you're right: I added an external 'ext' on mlabwrap to mlabwrap/test,
and it appears to slow down checkout; I've got a very old svn client, but you
can try yourself:
svn co http://scipy.org/svn/scikits/trunk/mlabwrap/
> Also, it appears that Trac doesn't like svn:external to other repositories;
> I'm not sure if that extends to svn:external within the same repository.
>
> http://trac.edgewall.org/wiki/TracFaq#DoesTracsupportsvn:externalsubversionrepositories
For this purpose it seems to work fine:
<https://projects.scipy.org/scipy/scikits/browser/trunk/mlabwrap>
It just displays the svn:externals property, which is all you want here, I
think.
Anyway, the choice between either layout (i.e. subproject internal/external
{tags,branches,trunk}) seems not terribly important. Each approach has
advantages and disadvantages, and apparently both are common; the 'official'
SVN book authors prefer internal, as do I, but write about the toplevel
{tags,branches,trunk} approach:
<http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.reposadmin.projects.chooselayout>
There's nothing particularly incorrect about such a layout, but it may or
may not seem as intuitive for your users. Especially in large,
multi-project situations with many users, those users may tend to be
familiar with only one or two of the projects in the repository. But the
projects-as-branch-siblings tends to de-emphasize project individuality
and focus on the entire set of projects as a single entity. That's a
social issue though. We like our originally suggested arrangement for
purely practical reasons: it's easier to ask about (or modify, or migrate
elsewhere) the entire history of a single project when there's a single
repository path that holds the history entirepast, present, tagged,
branched andfor that project and that project alone.
> > Maybe the structure I proposed would also make importing and exporting of
> > projects slightly easier (because it mirrors the typical layout of an
> > individual svn project). Speaking of which -- is there something I can do with
> > the existing CVS so that it can be easily imported in the scikits svn (in
> > which case we can get rid of what's already checked in), or would importing
> > the CVS involve a hassle in any case, because then I'll just archive it on
> > sourceforge.
>
> I don't know. You'll have to read the cvs2svn documentation.
Sorry, I should have phrased this better. I have already read the cvs2svn docs
and converted the CVS repository (just a single trunk, no branches or tags).
If I put a tar.bz2 of that repository on the web, can someone with admin
rights easily install it in lieu of the existing repository? Is Berkeley db
fine as backend? If it's not easy and quick to do, I'm also happy to loose the
revision history and abandon conversion attempts.
> > The other thing I've been wondering is if such a setup couldn't also be made
> > to accomodate something like Stefan van der Walt's layout proposal, which as
> > far as I can see would allow for the most convenient way possible to grab all
> > scikits and build them:
> >
> > setup.py
> > scikits/
> > __init_xg_.py
> > -> mlabwrap/
> > mlabwrap_setup.py
> > __init__.py
> > awmstools.py
> > ...
> > -> some_other_scikit/
> > some_other_scikit_setup.py
>
> Having two ways to install something is just begging for trouble.
I wasn't advocating two ways; you always call scikits/setup.py and it just
installs different amounts of stuff depending on how many subdirs you've
checked out.
> > Couldn't one have a toplevel setup.py that just runs all
> > scikits/DIRNAME/DIRNAME_setup.py's it can find, passing through the command line
> > options (or something along those lines[1])?
>
> That's unworkable. I've tried.
I suspected that it might turn out to be. Pitty.
> >> If so it should also use numpy.distutils. Just make sure to import
> >> setuptools first.
> >>
> >> import setuptools
> >> from numpy.distutils.core import setup
> >> ...
> >
> > Is there a recipe/template for this somewhere? Googling "scipy setuptools"
> > comes up with
> >
> > <http://projects.scipy.org/ipython/ipython/wiki/SetupTools>
> >
> > as the first hit, which seems to indicate that setuptools is still a bit alpha
> > and the docs can't be trusted if one wants something that actually works.
>
> Fernando's a curmudgeon, and that page is old. Ignore him. 
OK, I'm going the``ez_setup.py`` way.
> Like I said, just import setuptools before you import numpy.distutils. Then use
> numpy.distutils as normal to handle all of the building and stuff. setuptools
> adds some keywords to setup() that you should also provide, namely
>
> namespace_packages=['scikits'],
>
> That's all that's necessary. There's no particular magic to combining setuptools
> and numpy.distutils.
Well, it's not quite obvious how to fully take advantage of setuptools,
though. One of the main reasons for using it is that it's meant to download
and install depenedencies automatically, but that can't work if my setup.py
import something from its sole dependency (numpy) to start with. Surely there
must be some way to write packages that depend on numpy but can be installed
automatically (and download numpy if required)? And why do I need to use
numpy.distutils in the first place? I find
<http://www.scipy.org/Documentation/numpy_distutils> rather unhelpful and I
didn't find any other documentation.
Another thing: should ``scikits/__init__.py`` be really empty? From
<http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages>
it looks a bit to me like it should contain:
__import__('pkg_resources').declare_namespace(__name__)
?
Finally, what is the preferred download url for scikits projects? Should I
continue to host the file-release on SF, or should they go somewhere else?
Same for the webpage.
So I think some kind of template for scikit authors would be useful and I'd
suggest that once I've got setup.py etc. ironed out I put some info for other
prospective scikit authors on a wikipage on scipy.org -- what would be a good
place?
Finally, just to double check, does this directory structure look good to you:
mlabwrap/
setup.py
README.txt
tests/ # N.B. renamed from 'test'
test_mlabwrap.py
...
scikits/
__init__.py # empty
mlabwrap/
__init__.py
_mlabwrap.py
mlabraw.py
-> awmstools.py
-> awmsmeta.py
?
thanks,
'as
Alexander Schmolck wrote:
> Robert Kern <robert.kern <at> gmail.com> writes:
> Anyway, the choice between either layout (i.e. subproject internal/external
> {tags,branches,trunk}) seems not terribly important.
Fine. Please let's drop the issue, then.
>>> Maybe the structure I proposed would also make importing and exporting of
>>> projects slightly easier (because it mirrors the typical layout of an
>>> individual svn project). Speaking of which -- is there something I can do with
>>> the existing CVS so that it can be easily imported in the scikits svn (in
>>> which case we can get rid of what's already checked in), or would importing
>>> the CVS involve a hassle in any case, because then I'll just archive it on
>>> sourceforge.
>> I don't know. You'll have to read the cvs2svn documentation.
>
> Sorry, I should have phrased this better. I have already read the cvs2svn docs
> and converted the CVS repository (just a single trunk, no branches or tags).
> If I put a tar.bz2 of that repository on the web, can someone with admin
> rights easily install it in lieu of the existing repository?
Is there no conversion tool that simply puts revisions into an existing
directory of a repository instead of making a new repository?
> Is Berkeley db
> fine as backend?
No. We use the fsfs.
>>>> If so it should also use numpy.distutils. Just make sure to import
>>>> setuptools first.
>>>>
>>>> import setuptools
>>>> from numpy.distutils.core import setup
>>>> ...
>>> Is there a recipe/template for this somewhere? Googling "scipy setuptools"
>>> comes up with
>>>
>>> <http://projects.scipy.org/ipython/ipython/wiki/SetupTools>
>>>
>>> as the first hit, which seems to indicate that setuptools is still a bit alpha
>>> and the docs can't be trusted if one wants something that actually works.
>> Fernando's a curmudgeon, and that page is old. Ignore him.
>
> OK, I'm going the``ez_setup.py`` way.
No, ez_setup.py is deprecated. That part of the setuptools docs is out of date.
When the Cheeseshop comes back up read this page with up-to-date information
about how to get going with setuptools:
http://cheeseshop.python.org/pypi/setuptools
>> Like I said, just import setuptools before you import numpy.distutils. Then use
>> numpy.distutils as normal to handle all of the building and stuff. setuptools
>> adds some keywords to setup() that you should also provide, namely
>>
>> namespace_packages=['scikits'],
>>
>> That's all that's necessary. There's no particular magic to combining setuptools
>> and numpy.distutils.
>
> Well, it's not quite obvious how to fully take advantage of setuptools,
> though. One of the main reasons for using it is that it's meant to download
> and install depenedencies automatically, but that can't work if my setup.py
> import something from its sole dependency (numpy) to start with. Surely there
> must be some way to write packages that depend on numpy but can be installed
> automatically (and download numpy if required)?
Not really. The dependencies that you can specify are requirements for using the
package after it is installed, not requirements for building the package. The
structure of distutils setup.py files pretty much enforces this. setuptools
doesn't really get to do anything until setup() is called, i.e. after you've
used your dependencies.
You might be able to hack something together with
pkg_resources.WorkingSet.resolve(), though.
http://peak.telecommunity.com/DevCenter/PkgResources#workingset-methods-and-attributes
> And why do I need to use
> numpy.distutils in the first place?
<shrug> You don't strictly have to. numpy.get_include() is probably sufficient
for you, but it has the same problem.
> Another thing: should ``scikits/__init__.py`` be really empty? From
>
> <http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages>
>
> it looks a bit to me like it should contain:
>
> __import__('pkg_resources').declare_namespace(__name__)
>
> ?
Yes, apologies.
> Finally, what is the preferred download url for scikits projects? Should I
> continue to host the file-release on SF, or should they go somewhere else?
I recommend putting them on the Cheeseshop.
> Same for the webpage.
scipy.org wiki if you can.
> So I think some kind of template for scikit authors would be useful and I'd
> suggest that once I've got setup.py etc. ironed out I put some info for other
> prospective scikit authors on a wikipage on scipy.org -- what would be a good
> place?
http://projects.scipy.org/scipy/scikits
> Finally, just to double check, does this directory structure look good to you:
>
> mlabwrap/
> setup.py
> README.txt
> tests/ # N.B. renamed from 'test'
> test_mlabwrap.py
> ...
> scikits/
> __init__.py # empty
> mlabwrap/
> __init__.py
> _mlabwrap.py
> mlabraw.py
> -> awmstools.py
> -> awmsmeta.py
>
> ?
Yes.
--
--
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
RSS Feed89 | |
|---|---|
196 | |
65 | |
44 | |
85 | |
122 | |
95 | |
33 | |
67 | |
82 | |
61 | |
62 | |
128 | |
99 | |
52 | |
123 | |
62 | |
92 | |
85 | |
335 | |
613 | |
207 | |
194 | |
101 | |
202 | |
113 | |
201 | |
178 | |
301 | |
166 | |
328 | |
162 | |
215 | |
183 | |
177 | |
251 | |
523 | |
227 | |
306 | |
417 | |
174 | |
116 | |
158 | |
130 | |
213 | |
160 | |
333 | |
170 | |
145 | |
200 | |
152 | |
42 | |
116 | |
124 | |
126 | |
192 | |
171 | |
180 | |
197 | |
130 | |
66 | |
116 | |
181 | |
51 | |
151 | |
64 | |
45 | |
71 | |
85 | |
45 | |
194 | |
230 | |
159 | |
606 | |
358 | |
477 | |
536 | |
118 | |
51 | |
45 | |
38 | |
51 | |
26 | |
52 | |
55 | |
66 | |
47 | |
254 | |
143 | |
94 | |
21 | |
12 | |
20 | |
28 | |
50 | |
43 | |
9 | |
16 | |
22 | |
42 | |
77 | |
46 | |
22 | |
14 | |
10 | |
48 | |
23 | |
99 | |
39 | |
34 | |
56 | |
64 | |
89 | |
95 | |
76 | |
16 | |
24 | |
31 | |
1 |
