From cimrman3 at ntc.zcu.cz  Tue Sep  2 08:14:14 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Tue, 02 Sep 2008 14:14:14 +0200
Subject: [SciPy-dev] ANN: SfePy-00.50.00
Message-ID: <48BD2E16.4080307@ntc.zcu.cz>

I am pleased announce the release of SfePy 00.50.00.

SfePy is a finite element analysis software in Python, based primarily
on Numpy and SciPy.

Mailing lists, issue tracking, mercurial repository: http://sfepy.org
Home page: http://sfepy.kme.zcu.cz

People who contributed to this release: Ondrej Certik, Ryan Krauss, 
Vladimir Lukes.

Major improvements:
- finite strain elasticity: neo-Hookean, Mooney-Rivlin materials in the 
total Lagrangian (TL) formulation
- solving problems in complex numbers
- generalized equations to allow linear combination of terms
- run-time type of state term arguments
- refactoring to follow Python coding style guidelines
- new terms

For more information on this release, see
http://sfepy.googlecode.com/svn/web/releases/005000_RELEASE_NOTES.txt

Best regards,
Robert Cimrman


From david at ar.media.kyoto-u.ac.jp  Tue Sep  2 22:59:02 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 03 Sep 2008 11:59:02 +0900
Subject: [SciPy-dev] Is it ok to start a signal/speech toolbox in scikits ?
Message-ID: <48BDFD76.4030500@ar.media.kyoto-u.ac.jp>

Hi,

    I know there is no formal process, but just wanted to check whether
anyone would be against starting a speech/signal toolbox in scikits. The
idea is to provide things which where in my sandbox before, but are
relatively general (lpc, music and other high resolution methods
available in matlab signal toolbox), as well as more speech oriented
stuff (mfcc, etc...). The code would be as much BSD as possible, so that
some of it may be included in scipy later if deemed useful.

cheers,

David


From millman at berkeley.edu  Wed Sep  3 01:04:42 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Tue, 2 Sep 2008 22:04:42 -0700
Subject: [SciPy-dev] Is it ok to start a signal/speech toolbox in
	scikits ?
In-Reply-To: <48BDFD76.4030500@ar.media.kyoto-u.ac.jp>
References: <48BDFD76.4030500@ar.media.kyoto-u.ac.jp>
Message-ID: <c7009a550809022204q73459137va167b691532efcbf@mail.gmail.com>

On Tue, Sep 2, 2008 at 7:59 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
>    I know there is no formal process, but just wanted to check whether
> anyone would be against starting a speech/signal toolbox in scikits. The
> idea is to provide things which where in my sandbox before, but are
> relatively general (lpc, music and other high resolution methods
> available in matlab signal toolbox), as well as more speech oriented
> stuff (mfcc, etc...). The code would be as much BSD as possible, so that
> some of it may be included in scipy later if deemed useful.

That sounds great.  Once you get started, we can take a closer look
and give you some feedback.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From millman at berkeley.edu  Wed Sep  3 02:16:09 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Tue, 2 Sep 2008 23:16:09 -0700
Subject: [SciPy-dev] 1.2.0rc1 tagged!
Message-ID: <c7009a550809022316vcd77770ideb5e1789fb6d3a0@mail.gmail.com>

Hello,

The 1.2.0rc1 is now available:
http://svn.scipy.org/svn/numpy/tags/1.2.0rc1

The source tarball is here:
https://cirl.berkeley.edu/numpy/numpy-1.2.0rc1.tar.gz

Here is the universal Mac binary:
https://cirl.berkeley.edu/numpy/numpy-1.2.0rc1-py2.5-macosx10.5.dmg

Here are the Window's binaries:
http://www.ar.media.kyoto-u.ac.jp/members/david/archives/numpy/numpy-1.2.0rc1-win32-superpack-python2.4.exe
http://www.ar.media.kyoto-u.ac.jp/members/david/archives/numpy/numpy-1.2.0rc1-win32-superpack-python2.5.exe

Here are the release notes:
http://scipy.org/scipy/numpy/milestone/1.2.0

Please test this release ASAP and let us know if there are any
problems.  If there are no show stoppers, this will likely become the
1.2.0 release.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From alan.mcintyre at gmail.com  Wed Sep  3 12:22:44 2008
From: alan.mcintyre at gmail.com (Alan McIntyre)
Date: Wed, 3 Sep 2008 09:22:44 -0700
Subject: [SciPy-dev] scipy.cluster.distance.yule print statement
Message-ID: <1d36917a0809030922i1357c442ufbf919106eb3801e@mail.gmail.com>

There's a print statement in scipy/cluster/distance.py:yule that
creates an enormous amount of output when the SciPy test suite is run.
 Can that be commented out or removed?


From oliphant at enthought.com  Wed Sep  3 12:26:24 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Wed, 03 Sep 2008 11:26:24 -0500
Subject: [SciPy-dev] Is it ok to start a signal/speech toolbox in
 scikits ?
In-Reply-To: <48BDFD76.4030500@ar.media.kyoto-u.ac.jp>
References: <48BDFD76.4030500@ar.media.kyoto-u.ac.jp>
Message-ID: <48BEBAB0.9050100@enthought.com>

David Cournapeau wrote:
> Hi,
>
>     I know there is no formal process, but just wanted to check whether
> anyone would be against starting a speech/signal toolbox in scikits. The
> idea is to provide things which where in my sandbox before, but are
> relatively general (lpc, music and other high resolution methods
> available in matlab signal toolbox), as well as more speech oriented
> stuff (mfcc, etc...). The code would be as much BSD as possible, so that
> some of it may be included in scipy later if deemed useful.
>
>   
Sounds great.

-Travis



From robert.kern at gmail.com  Wed Sep  3 15:31:26 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 3 Sep 2008 14:31:26 -0500
Subject: [SciPy-dev] scipy.cluster.distance.yule print statement
In-Reply-To: <1d36917a0809030922i1357c442ufbf919106eb3801e@mail.gmail.com>
References: <1d36917a0809030922i1357c442ufbf919106eb3801e@mail.gmail.com>
Message-ID: <3d375d730809031231o1d345ef7vce0259edf07ed1c2@mail.gmail.com>

On Wed, Sep 3, 2008 at 11:22, Alan McIntyre <alan.mcintyre at gmail.com> wrote:
> There's a print statement in scipy/cluster/distance.py:yule that
> creates an enormous amount of output when the SciPy test suite is run.
>  Can that be commented out or removed?

Done.

-- 
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


From uschmitt at mineway.de  Thu Sep  4 08:54:19 2008
From: uschmitt at mineway.de (Uwe Schmitt)
Date: Thu, 04 Sep 2008 14:54:19 +0200
Subject: [SciPy-dev] numpy.distuils question
Message-ID: <48BFDA7B.2090307@mineway.de>

Hi,

Thanks to the document team I managed to write a setup.py file which
builds an extension module with f2py.
My problem is to install further Python files.

My directory looks like this:

    setup.py
    module.pyf
    module.f
    my_new_package/
        __init__.py
        modulewrapper.py


the modulewrapper loads module.pyd.

setup.py looks like this:

    def configuration(parent_package='',top_path=None):
        from numpy.distutils.misc_util import Configuration
        config = Configuration('my_new_package',parent_package,top_path)

        config.add_extension('module',
                             sources = ['module.pyf', 'module.f']
                 )

        return config

    if __name__ == "__main__":
        from numpy.distutils.core import setup
        setup(**configuration(top_path='').todict())



How do I have to change/extend setup.py ?

Greetings, Uwe

-- 
Dr. rer. nat. Uwe Schmitt
F&E Mathematik
 
mineway GmbH
Science Park 2
D-66123 Saarbr?cken
 
Telefon: +49 (0)681 8390 5334
Telefax: +49 (0)681 830 4376
 
uschmitt at mineway.de
www.mineway.de
 
Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer
Amtsgericht Saarbr?cken HRB 12339


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080904/0ce10be4/attachment.html>

From doutriaux1 at llnl.gov  Fri Sep  5 13:02:27 2008
From: doutriaux1 at llnl.gov (Charles Doutriaux)
Date: Fri, 05 Sep 2008 10:02:27 -0700
Subject: [SciPy-dev] numpy.distuils question
In-Reply-To: <48BFDA7B.2090307@mineway.de>
References: <48BFDA7B.2090307@mineway.de>
Message-ID: <48C16623.3040903@llnl.gov>

Uwe,

I'm attaching an example of setup.py i have that does what you want.

I have the strucutre:
setup.py
  Lib/
    __init__.py
    ...python files ....
  Src/
     ..fortran or C files ...

Hope this helps.
C.

Note that I also have a .pyf file just to make the i/o to f2py a bit 
cleaner but it is not necessary

C.

Uwe Schmitt wrote:
> Hi,
>
> Thanks to the document team I managed to write a setup.py file which
> builds an extension module with f2py.
> My problem is to install further Python files.
>
> My directory looks like this:
>
>     setup.py
>     module.pyf
>     module.f
>     my_new_package/
>         __init__.py
>         modulewrapper.py
>
>
> the modulewrapper loads module.pyd.
>
> setup.py looks like this:
>
>     def configuration(parent_package='',top_path=None):
>         from numpy.distutils.misc_util import Configuration
>         config = Configuration('my_new_package',parent_package,top_path)
>
>         config.add_extension('module',
>                              sources = ['module.pyf', 'module.f']
>                  )
>
>         return config
>
>     if __name__ == "__main__":
>         from numpy.distutils.core import setup
>         setup(**configuration(top_path='').todict())
>
>
>
> How do I have to change/extend setup.py ?
>
> Greetings, Uwe
> -- 
> Dr. rer. nat. Uwe Schmitt
> F&E Mathematik
>  
> mineway GmbH
> Science Park 2
> D-66123 Saarbr?cken
>  
> Telefon: +49 (0)681 8390 5334
> Telefax: +49 (0)681 830 4376
>  
> uschmitt at mineway.de
> www.mineway.de
>  
> Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer
> Amtsgericht Saarbr?cken HRB 12339
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http:// projects.scipy.org/mailman/listinfo/scipy-dev
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: text/x-python
Size: 926 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080905/64ef3a2f/attachment.py>

From uschmitt at mineway.de  Fri Sep  5 13:08:07 2008
From: uschmitt at mineway.de (Uwe Schmitt)
Date: Fri, 5 Sep 2008 19:08:07 +0200
Subject: [SciPy-dev] numpy.distuils question
In-Reply-To: <48C16623.3040903@llnl.gov>
References: <48BFDA7B.2090307@mineway.de> <48C16623.3040903@llnl.gov>
Message-ID: <173DB550-D816-4975-B289-D1FD5A099A63@mineway.de>

Thanks, I will try it.

Greetings, Uwe


Am 05.09.2008 um 19:02 schrieb Charles Doutriaux:

> Uwe,
>
> I'm attaching an example of setup.py i have that does what you want.
>
> I have the strucutre:
> setup.py
> Lib/
>   __init__.py
>   ...python files ....
> Src/
>    ..fortran or C files ...
>
> Hope this helps.
> C.
>
> Note that I also have a .pyf file just to make the i/o to f2py a bit  
> cleaner but it is not necessary
>
> C.
>
> Uwe Schmitt wrote:
>> Hi,
>>
>> Thanks to the document team I managed to write a setup.py file which
>> builds an extension module with f2py.
>> My problem is to install further Python files.
>>
>> My directory looks like this:
>>
>>    setup.py
>>    module.pyf
>>    module.f
>>    my_new_package/
>>        __init__.py
>>        modulewrapper.py
>>
>>
>> the modulewrapper loads module.pyd.
>>
>> setup.py looks like this:
>>
>>    def configuration(parent_package='',top_path=None):
>>        from numpy.distutils.misc_util import Configuration
>>        config =  
>> Configuration('my_new_package',parent_package,top_path)
>>
>>        config.add_extension('module',
>>                             sources = ['module.pyf', 'module.f']
>>                 )
>>
>>        return config
>>
>>    if __name__ == "__main__":
>>        from numpy.distutils.core import setup
>>        setup(**configuration(top_path='').todict())
>>
>>
>>
>> How do I have to change/extend setup.py ?
>>
>> Greetings, Uwe
>> -- 
>> Dr. rer. nat. Uwe Schmitt
>> F&E Mathematik
>> mineway GmbH
>> Science Park 2
>> D-66123 Saarbr?cken
>> Telefon: +49 (0)681 8390 5334
>> Telefax: +49 (0)681 830 4376
>> uschmitt at mineway.de
>> www.mineway.de
>> Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer
>> Amtsgericht Saarbr?cken HRB 12339
>>
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http:// projects.scipy.org/mailman/listinfo/scipy-dev
>>
> import sys,os
> target_prefix = sys.prefix
> for i in range(len(sys.argv)):
>    a = sys.argv[i]
>    if a=='--prefix':
>        target_prefix=sys.argv[i+1]
>    sp = a.split("--prefix=")
>    if len(sp)==2:
>        target_prefix=sp[1]
> sys.path.insert(0,os.path.join(target_prefix,'lib','python%i.%i' %  
> sys.version_info[:2],'site-packages'))
> from numpy.distutils.core import Extension
> import sys
>
> sources = """
> Src/msuweight.f
> """.split()
>
> extra_link_args=[]
> if sys.platform=='darwin':
>    extra_link_args = ['-bundle','-bundle_loader '+sys.prefix+'/bin/ 
> python']
> ext1 = Extension(name = 'eqmsu',
>                 extra_link_args=extra_link_args,
>                 sources = ['Src/eqmsu.pyf',]+sources)
>
> if __name__ == "__main__":
>    from numpy.distutils.core import setup
>    setup(name = 'MSU',
>          ext_modules = [ext1,],
>          packages = ['MSU'],
>          package_dir = {'MSU': 'Lib',
>                     },
>          )
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev



From uschmitt at mineway.de  Mon Sep  8 07:00:02 2008
From: uschmitt at mineway.de (Uwe Schmitt)
Date: Mon, 08 Sep 2008 13:00:02 +0200
Subject: [SciPy-dev] [mailinglist] Re:  numpy.distuils question
In-Reply-To: <48C16623.3040903@llnl.gov>
References: <48BFDA7B.2090307@mineway.de> <48C16623.3040903@llnl.gov>
Message-ID: <48C505B2.4070501@mineway.de>

Charles Doutriaux schrieb:
> Uwe,
>
> I'm attaching an example of setup.py i have that does what you want.
>
> I have the strucutre:
> setup.py
>  Lib/
>    __init__.py
>    ...python files ....
>  Src/
>     ..fortran or C files ...
>
> Hope this helps.
> C.
Hi and Thanks,

your script works, but there are still some problems for me:

1) How do you get your extension module loaded during
   development ?
   If I use the script, the extension xxx.pyd is built
   in the same directory as setup.py
   But the script which loads the extension is one
   level below.

2) If I use the install command of setup.py my
   extension is copied to .../site-packagen/xxx.pyd,
   the rest of the package will be below
   .../site-package/my_package/

I would be happy if  "setup.py build_ext --inplace" would  put the 
extension module
to Lib/
and if "setup.py install" would put the extension module into the 
package folder
below .../site-packages/

Greetings, Uwe

 

-- 
Dr. rer. nat. Uwe Schmitt
F&E Mathematik
 
mineway GmbH
Science Park 2
D-66123 Saarbr?cken
 
Telefon: +49 (0)681 8390 5334
Telefax: +49 (0)681 830 4376
 
uschmitt at mineway.de
www.mineway.de
 
Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer
Amtsgericht Saarbr?cken HRB 12339




From millman at berkeley.edu  Mon Sep  8 19:25:00 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Mon, 8 Sep 2008 16:25:00 -0700
Subject: [SciPy-dev] mixed-EOL problems w/
Message-ID: <c7009a550809081625y3d85135aj5bd986f2e8353cba@mail.gmail.com>

I have been trying to get Launchpad to do continuous imports of the
SciPy subversion repository into Bazaar:
https://code.launchpad.net/~vcs-imports/scipy/trunk
This works fine for NumPy:
https://code.launchpad.net/~vcs-imports/numpy/trunk

However, this doesn't work for SciPy due to a mixed-EOL issue:
https://bugs.launchpad.net/launchpad-cscvs/+bug/256050

Colin Watson has recently volunteered to look into fixing this issue
and was asking if anyone had a preference about how this should be
solved.  Please let me know if you see any reason for one solution
over another.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From wnbell at gmail.com  Fri Sep 12 16:05:04 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Fri, 12 Sep 2008 16:05:04 -0400
Subject: [SciPy-dev] building binary installers
Message-ID: <d05265cb0809121305s5e7502b8wc53c32e9c11152fb@mail.gmail.com>

Once the next stable versions of NumPy and SciPy are released, I'd
like to provide binary installers for PyAMG[1] for several platforms
(32 and 64-bit Linux and Windows mainly).  Currently, I just compile
all three from source on my Ubuntu system, but I wouldn't expect
others, especially those on a Windows system, to do so.

FWIW, PyAMG uses extension modules which make limited use of LAPACK.
The build system (setup.py) was directly adapted from the one in
SciPy.

Is there a pain-free method to produce installers for these platforms?
 Are there any machines available for testing and creating binaries on
the various platforms?

Any guidance or advice is most appreciated.

[1] http://code.google.com/p/pyamg/

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From stefan at sun.ac.za  Sat Sep 13 01:38:08 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 13 Sep 2008 07:38:08 +0200
Subject: [SciPy-dev] building binary installers
In-Reply-To: <d05265cb0809121305s5e7502b8wc53c32e9c11152fb@mail.gmail.com>
References: <d05265cb0809121305s5e7502b8wc53c32e9c11152fb@mail.gmail.com>
Message-ID: <9457e7c80809122238k69942979se6919992c991dcbe@mail.gmail.com>

Hi Nathan

I am impressed by the organisation of your Google Code page; very
professional!  Could you point me to an introductory paper on AMG and
where it can be applied (maybe put it on the wiki -- along with
references to your own papers, so that people who use your package can
cite you)?

I don't have much advice for building on the different platforms -- I
assume David will have more to say.  For SciPy, we create a virtual
machine under VMPlayer which runs Windows XP or XP64, and then do all
the compiling and building there.  That way, you can build on your
private box, and if someone else needs to take over the
responsibility, you just give them the VM image.

Good luck!
St?fan

2008/9/12 Nathan Bell <wnbell at gmail.com>:
> Once the next stable versions of NumPy and SciPy are released, I'd
> like to provide binary installers for PyAMG[1] for several platforms
> (32 and 64-bit Linux and Windows mainly).  Currently, I just compile
> all three from source on my Ubuntu system, but I wouldn't expect
> others, especially those on a Windows system, to do so.
>
> FWIW, PyAMG uses extension modules which make limited use of LAPACK.
> The build system (setup.py) was directly adapted from the one in
> SciPy.
>
> Is there a pain-free method to produce installers for these platforms?
>  Are there any machines available for testing and creating binaries on
> the various platforms?
>
> Any guidance or advice is most appreciated.
>
> [1] http://code.google.com/p/pyamg/


From david at ar.media.kyoto-u.ac.jp  Sat Sep 13 02:05:40 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 13 Sep 2008 15:05:40 +0900
Subject: [SciPy-dev] building binary installers
In-Reply-To: <9457e7c80809122238k69942979se6919992c991dcbe@mail.gmail.com>
References: <d05265cb0809121305s5e7502b8wc53c32e9c11152fb@mail.gmail.com>
	<9457e7c80809122238k69942979se6919992c991dcbe@mail.gmail.com>
Message-ID: <48CB5834.8020101@ar.media.kyoto-u.ac.jp>

St?fan van der Walt wrote:
> That way, you can build on your
> private box, and if someone else needs to take over the
> responsibility, you just give them the VM image.

Well, you have to be careful here: you are not supposed to just give a
VM with windows inside like this without violating the license.

>>
>>
>> Is there a pain-free method to produce installers for these platforms?
>>  Are there any machines available for testing and creating binaries on
>> the various platforms?

On windows, you can use the build_msi/build_wininst command of
distutils, but this will only produce a binary for your package: users
will need to install both numpy and scipy first. On Windows, you have
the problem of blas/lapack: if you don't need much, I would strongly
encourage you to use netlib blas/lapack only, and to not bother with
atlas. There is also the problem of not mixing g77/gfortran, like on
Linux. For windows 64, you can't use mingw, including the fortran
compiler...

On Mac OS X, the build_mpkg does the same as build_wininst on windows,
with the same restrictions. You don't have to bother about
blas/lapack/co, because Mac OS X includes an optimized one in the
system, making the dependency problem much easier to deal with than on
windows. You need a mac to build those, but I guess you already knew that :)

cheers,

David


From dfarning at sugarlabs.org  Sat Sep 13 23:20:12 2008
From: dfarning at sugarlabs.org (David Farning)
Date: Sat, 13 Sep 2008 22:20:12 -0500
Subject: [SciPy-dev] Learning about api documentation.
Message-ID: <1221362412.18444.20.camel@dfarning.desktop.org>

I just want to introduce myself.  I am working on generating API
documentation for Sugar the user interface for the One Laptop Per Child
project.

I was introduced to pydocweb by Janet Swisher at a doc sprint a few
weeks ago.

With some help from pauli, I have a somewhat functioning site at
http://sugarlabs1.xen.prgmr.com/pydocweb/wiki/Front%20Page/ .

It is unlikely that I will do much editing at scipy or numpy;( I would
appreciate the ability to edit so that I can view the source and learn
about the ReStructured Text you are using to document scipy.

username dfarning

thanks
david



From stefan at sun.ac.za  Sun Sep 14 04:27:07 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 14 Sep 2008 10:27:07 +0200
Subject: [SciPy-dev] Learning about api documentation.
In-Reply-To: <1221362412.18444.20.camel@dfarning.desktop.org>
References: <1221362412.18444.20.camel@dfarning.desktop.org>
Message-ID: <9457e7c80809140127x2204c4d7gcc6305a071e2edb7@mail.gmail.com>

Hey David

2008/9/14 David Farning <dfarning at sugarlabs.org>:
> With some help from pauli, I have a somewhat functioning site at
> http://sugarlabs1.xen.prgmr.com/pydocweb/wiki/Front%20Page/ .

Fantastic!  I am glad to see the tool being used.

> It is unlikely that I will do much editing at scipy or numpy;( I would
> appreciate the ability to edit so that I can view the source and learn
> about the ReStructured Text you are using to document scipy.
>
> username dfarning

Done.

Cheers
St?fan


From wnbell at gmail.com  Sun Sep 14 15:20:14 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sun, 14 Sep 2008 15:20:14 -0400
Subject: [SciPy-dev] building binary installers
In-Reply-To: <9457e7c80809122238k69942979se6919992c991dcbe@mail.gmail.com>
References: <d05265cb0809121305s5e7502b8wc53c32e9c11152fb@mail.gmail.com>
	<9457e7c80809122238k69942979se6919992c991dcbe@mail.gmail.com>
Message-ID: <d05265cb0809141220r23260f09uf67921187a17e706@mail.gmail.com>

On Sat, Sep 13, 2008 at 1:38 AM, St?fan van der Walt <stefan at sun.ac.za> wrote:
>
> I am impressed by the organisation of your Google Code page; very
> professional!  Could you point me to an introductory paper on AMG and
> where it can be applied (maybe put it on the wiki -- along with
> references to your own papers, so that people who use your package can
> cite you)?
>

We're preparing a paper that introduces AMG to non-specialists and
describes what PyAMG can do.

There's a discussion of AMG towards the end of the "Multigrid Tutorial" slides:
https://computation.llnl.gov/casc/people/henson/mgtut/welcome.html

> I don't have much advice for building on the different platforms -- I
> assume David will have more to say.  For SciPy, we create a virtual
> machine under VMPlayer which runs Windows XP or XP64, and then do all
> the compiling and building there.  That way, you can build on your
> private box, and if someone else needs to take over the
> responsibility, you just give them the VM image.

I'll give that a try.  From the Windows installation documentation[1]
it seems that Cygwin is the way to go.  Is that still true?

[1] http://www.scipy.org/Installing_SciPy/Windows


-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From wnbell at gmail.com  Sun Sep 14 15:24:31 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sun, 14 Sep 2008 15:24:31 -0400
Subject: [SciPy-dev] building binary installers
In-Reply-To: <48CB5834.8020101@ar.media.kyoto-u.ac.jp>
References: <d05265cb0809121305s5e7502b8wc53c32e9c11152fb@mail.gmail.com>
	<9457e7c80809122238k69942979se6919992c991dcbe@mail.gmail.com>
	<48CB5834.8020101@ar.media.kyoto-u.ac.jp>
Message-ID: <d05265cb0809141224i5ef0fb84mce2bf95dc8cb40a6@mail.gmail.com>

On Sat, Sep 13, 2008 at 2:05 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
>
> On windows, you can use the build_msi/build_wininst command of
> distutils, but this will only produce a binary for your package: users
> will need to install both numpy and scipy first. On Windows, you have
> the problem of blas/lapack: if you don't need much, I would strongly
> encourage you to use netlib blas/lapack only, and to not bother with
> atlas. There is also the problem of not mixing g77/gfortran, like on
> Linux. For windows 64, you can't use mingw, including the fortran
> compiler...
>

An unoptimized blas/lapack is sufficient for our usage.  Should I then
place the netlib blas and lapack in my source tree somewhere?  If so,
is there an example of how to make the build scripts compile and link
the library?

I would like to make compiling PyAMG as simple as possible.  We only
use BLAS/LAPACK on small matrices (e.g. 3x3 to 6x6), so speed is
unimportant.

Thanks for your help.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From david at ar.media.kyoto-u.ac.jp  Sun Sep 14 23:36:00 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 15 Sep 2008 12:36:00 +0900
Subject: [SciPy-dev] building binary installers
In-Reply-To: <d05265cb0809141220r23260f09uf67921187a17e706@mail.gmail.com>
References: <d05265cb0809121305s5e7502b8wc53c32e9c11152fb@mail.gmail.com>	<9457e7c80809122238k69942979se6919992c991dcbe@mail.gmail.com>
	<d05265cb0809141220r23260f09uf67921187a17e706@mail.gmail.com>
Message-ID: <48CDD820.5040202@ar.media.kyoto-u.ac.jp>

Nathan Bell wrote:
>
> I'll give that a try.  From the Windows installation documentation[1]
> it seems that Cygwin is the way to go.  Is that still true?

Not really. Cygwin is mandatory to build ATLAS, but numpy/scipy do not
need cygwin, only mingw (which is a port of gcc to windows, using the
win32 API and the MS C runtime; on the contrary, cygwin is the full GNU
runtime, with glibc and co, and is not 'windows native').

David


From david at ar.media.kyoto-u.ac.jp  Sun Sep 14 23:48:50 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 15 Sep 2008 12:48:50 +0900
Subject: [SciPy-dev] building binary installers
In-Reply-To: <d05265cb0809141224i5ef0fb84mce2bf95dc8cb40a6@mail.gmail.com>
References: <d05265cb0809121305s5e7502b8wc53c32e9c11152fb@mail.gmail.com>	<9457e7c80809122238k69942979se6919992c991dcbe@mail.gmail.com>	<48CB5834.8020101@ar.media.kyoto-u.ac.jp>
	<d05265cb0809141224i5ef0fb84mce2bf95dc8cb40a6@mail.gmail.com>
Message-ID: <48CDDB22.1000608@ar.media.kyoto-u.ac.jp>

Nathan Bell wrote:
>
> An unoptimized blas/lapack is sufficient for our usage.  Should I then
> place the netlib blas and lapack in my source tree somewhere?  If so,
> is there an example of how to make the build scripts compile and link
> the library?

To build blas and lapack with mingw, you could use the tools I use for
numpy/scipy, in svn:

http://svn.scipy.org/svn/numpy/vendor (Note that this is in the root of
svn, not in a branch or something).

The build scripts are really hackish for now, but the idea is that each
configuration (sse, sse2, no sse) is driven by a configuration file
given to the build script.

python tools/build.py tools/nosse.cfg

Should build blas and lapack correctly. I know I just said that you
don't need cygwin, but those scripts work only on cygwin I think, sorry
for the confusion.

Then, you put those libraries somewhere (I usually reproduce the Unix
convention: C:\local\lib, C:\local\include, etc... Avoiding space in
path is a good idea generally), and you set the site.cfg file inside
numpy/PyAMG/etc... sources as following:

[DEFAULT]
library_dir=C:\local\lib

cheers,

David


From ilanschnell at gmail.com  Tue Sep 16 14:51:09 2008
From: ilanschnell at gmail.com (Ilan Schnell)
Date: Tue, 16 Sep 2008 13:51:09 -0500
Subject: [SciPy-dev] Bug in blas test
Message-ID: <2fbe16300809161151y20a12ae9w332d8930962f481f@mail.gmail.com>

Hello,
I just found a bug in tests for blas.
Line 74 and 75 of scipy/lib/blas/tests/test_blas.py (current trunk):
    f = getattr(fblas,p+'dotc')
    assert_almost_equal(f([3j,-4,3-4j],[2,3j,1]),3-14j)

The result of the dot product of these two vectors is 3-10j,
as can be easily veryfied:
>>> def f(a, b):
...     return sum(x*y for x, y in zip(a, b))
...
>>> f([3j,-4,3-4j],[2,3j,1])
(3-10j)

Is it OK if I fix this in the current trunk?

- Ilan


From uschmitt at mineway.de  Tue Sep 16 15:36:16 2008
From: uschmitt at mineway.de (Uwe Schmitt)
Date: Tue, 16 Sep 2008 21:36:16 +0200
Subject: [SciPy-dev] Bug in blas test
In-Reply-To: <2fbe16300809161151y20a12ae9w332d8930962f481f@mail.gmail.com>
References: <2fbe16300809161151y20a12ae9w332d8930962f481f@mail.gmail.com>
Message-ID: <ABCEBC23-2CB8-47BE-ACCF-9EC6A19DF06E@mineway.de>


Am 16.09.2008 um 20:51 schrieb Ilan Schnell:

> Hello,
> I just found a bug in tests for blas.
> Line 74 and 75 of scipy/lib/blas/tests/test_blas.py (current trunk):
>    f = getattr(fblas,p+'dotc')
>    assert_almost_equal(f([3j,-4,3-4j],[2,3j,1]),3-14j)
>
> The result of the dot product of these two vectors is 3-10j,
> as can be easily veryfied:
>>>> def f(a, b):
> ...     return sum(x*y for x, y in zip(a, b))

You implemented  the *real* dot product, not the complex one !
I made this mistake sometime ago too.

According to http://orion.math.iastate.edu/docs/cmlib/blas/cdotc
the test is ok.

The right implementation would be

    def f(a,b):
        return sum(complex(x).conjugate()*y for x,y in zip(a,b))

Greetings, Uwe

>
> ...
>>>> f([3j,-4,3-4j],[2,3j,1])
> (3-10j)
>
> Is it OK if I fix this in the current trunk?
>
> - Ilan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev



From ilanschnell at gmail.com  Tue Sep 16 17:23:06 2008
From: ilanschnell at gmail.com (Ilan Schnell)
Date: Tue, 16 Sep 2008 16:23:06 -0500
Subject: [SciPy-dev] Bug in blas test
In-Reply-To: <ABCEBC23-2CB8-47BE-ACCF-9EC6A19DF06E@mineway.de>
References: <2fbe16300809161151y20a12ae9w332d8930962f481f@mail.gmail.com>
	<ABCEBC23-2CB8-47BE-ACCF-9EC6A19DF06E@mineway.de>
Message-ID: <2fbe16300809161423l7a1e7a6ag82df3710e57b67e6@mail.gmail.com>

Thank you very much Uwe, I forgot completely.
And the reason for having the comlpex dot product is
that things need to be normalized, so that for example the
vector with the element [1j] dot [1j] results to 1 (and not -1).
- Ilan

On Tue, Sep 16, 2008 at 2:36 PM, Uwe Schmitt <uschmitt at mineway.de> wrote:
>
> Am 16.09.2008 um 20:51 schrieb Ilan Schnell:
>
>> Hello,
>> I just found a bug in tests for blas.
>> Line 74 and 75 of scipy/lib/blas/tests/test_blas.py (current trunk):
>>    f = getattr(fblas,p+'dotc')
>>    assert_almost_equal(f([3j,-4,3-4j],[2,3j,1]),3-14j)
>>
>> The result of the dot product of these two vectors is 3-10j,
>> as can be easily veryfied:
>>>>> def f(a, b):
>> ...     return sum(x*y for x, y in zip(a, b))
>
> You implemented  the *real* dot product, not the complex one !
> I made this mistake sometime ago too.
>
> According to http://orion.math.iastate.edu/docs/cmlib/blas/cdotc
> the test is ok.
>
> The right implementation would be
>
>    def f(a,b):
>        return sum(complex(x).conjugate()*y for x,y in zip(a,b))
>
> Greetings, Uwe
>
>>
>> ...
>>>>> f([3j,-4,3-4j],[2,3j,1])
>> (3-10j)
>>
>> Is it OK if I fix this in the current trunk?
>>
>> - Ilan
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


From mfajer at gmail.com  Wed Sep 17 02:52:49 2008
From: mfajer at gmail.com (Mikolai Fajer)
Date: Tue, 16 Sep 2008 23:52:49 -0700
Subject: [SciPy-dev] mpi4py hacked
Message-ID: <3ff66ae00809162352s6290a9eer2e289e872e78efde@mail.gmail.com>

I am unsure where to post this, but the mpi4py section of the scipy
wiki appears to have been hacked into.  Who is maintaining this
package so that I can contact them directly?  Thanks!

-- 

 -Mikolai Fajer-


From robert.kern at gmail.com  Wed Sep 17 02:57:55 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 17 Sep 2008 01:57:55 -0500
Subject: [SciPy-dev] mpi4py hacked
In-Reply-To: <3ff66ae00809162352s6290a9eer2e289e872e78efde@mail.gmail.com>
References: <3ff66ae00809162352s6290a9eer2e289e872e78efde@mail.gmail.com>
Message-ID: <3d375d730809162357g37aa1v5725b0e05758517f@mail.gmail.com>

On Wed, Sep 17, 2008 at 01:52, Mikolai Fajer <mfajer at gmail.com> wrote:
> I am unsure where to post this, but the mpi4py section of the scipy
> wiki appears to have been hacked into.  Who is maintaining this
> package so that I can contact them directly?  Thanks!

Brian Granger (CC'ed) would be one such person.

-- 
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


From fperez.net at gmail.com  Wed Sep 17 17:37:29 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 17 Sep 2008 14:37:29 -0700
Subject: [SciPy-dev] mpi4py hacked
In-Reply-To: <3d375d730809162357g37aa1v5725b0e05758517f@mail.gmail.com>
References: <3ff66ae00809162352s6290a9eer2e289e872e78efde@mail.gmail.com>
	<3d375d730809162357g37aa1v5725b0e05758517f@mail.gmail.com>
Message-ID: <db6b5ecc0809171437s396e4458ha2d563e3faa39461@mail.gmail.com>

On Tue, Sep 16, 2008 at 11:57 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Wed, Sep 17, 2008 at 01:52, Mikolai Fajer <mfajer at gmail.com> wrote:
>> I am unsure where to post this, but the mpi4py section of the scipy
>> wiki appears to have been hacked into.  Who is maintaining this
>> package so that I can contact them directly?  Thanks!
>
> Brian Granger (CC'ed) would be one such person.

I've resent this with CC to Lisandro Dalcin, who'd be the other
appropriate contact.

Cheers,

f


From ellisonbg.net at gmail.com  Wed Sep 17 18:39:55 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 17 Sep 2008 15:39:55 -0700
Subject: [SciPy-dev] mpi4py hacked
In-Reply-To: <db6b5ecc0809171437s396e4458ha2d563e3faa39461@mail.gmail.com>
References: <3ff66ae00809162352s6290a9eer2e289e872e78efde@mail.gmail.com>
	<3d375d730809162357g37aa1v5725b0e05758517f@mail.gmail.com>
	<db6b5ecc0809171437s396e4458ha2d563e3faa39461@mail.gmail.com>
Message-ID: <6ce0ac130809171539v6d2ca003qfb67de2c9176fbc8@mail.gmail.com>

I fixed this today.  There shouldn't be any more problems, but please
let me know if any show up.  I talked to Lisandro and our plan is to
move the mpi4py website to google code (the svn repo is already
there).

Cheers,

Brian

On Wed, Sep 17, 2008 at 2:37 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Sep 16, 2008 at 11:57 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> On Wed, Sep 17, 2008 at 01:52, Mikolai Fajer <mfajer at gmail.com> wrote:
>>> I am unsure where to post this, but the mpi4py section of the scipy
>>> wiki appears to have been hacked into.  Who is maintaining this
>>> package so that I can contact them directly?  Thanks!
>>
>> Brian Granger (CC'ed) would be one such person.
>
> I've resent this with CC to Lisandro Dalcin, who'd be the other
> appropriate contact.
>
> Cheers,
>
> f
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


From cournape at gmail.com  Thu Sep 18 02:43:13 2008
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 18 Sep 2008 15:43:13 +0900
Subject: [SciPy-dev] Why does scipy set numpy to ignore all FPU exceptions ?
Message-ID: <5b8d13220809172343v16a72c6cn8dc6b15f1a4fd5a4@mail.gmail.com>

Hi,

It took me a while to find this; I wanted to check some underflow in
some code by using seterr(under = "raise"), but I found that it did
not work in my project while working in ipython. I found out that
scipy is the culprit:

_num.seterr(all='ignore')

Why was this set ? I may be missing something (Travis must had a
reason to set it; the log mentions some tests issues), but this does
not seem right to me, since this means that if you import scipy after
having used seterr, you lose your settings.

cheers,


From dave.hirschfeld at gmail.com  Fri Sep 19 13:35:54 2008
From: dave.hirschfeld at gmail.com (Dave)
Date: Fri, 19 Sep 2008 17:35:54 +0000 (UTC)
Subject: [SciPy-dev] Error in scikits.timeseries module
Message-ID: <loom.20080919T173026-820@post.gmane.org>

Whilst starting to experiment with the timeseries module I came across the 
following error. Any idea what is wrong / what I'm doing wrong?

Thanks,
Dave


Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.

import numpy as np
import scikits.timeseries as ts
data = np.random.uniform(-100,100,600)
today = ts.now('B')
series = ts.time_series(data, dtype=np.float_, freq='B', start_date=today-
600)
series
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\dev\Python25\Lib\site-packages\scikits\timeseries\tseries.py", line 
715, in __repr__
    return desc_short % {'data': str(self._series),
  File "C:\dev\Python25\Lib\site-packages\scikits\timeseries\tseries.py", line 
485, in _get_series
    return self.view(MaskedArray)
  File "C:\dev\Python25\Lib\site-packages\scikits\timeseries\tseries.py", line 
471, in view
    output = MaskedArray.view(self, dtype=dtype, type=type)
ValueError: Cannot specify output type twice.
np.__version__
'1.2.0rc1'
ts.__version__
'0.67.0.dev'






From pgmdevlist at gmail.com  Fri Sep 19 14:20:33 2008
From: pgmdevlist at gmail.com (Pierre GM)
Date: Fri, 19 Sep 2008 14:20:33 -0400
Subject: [SciPy-dev] Error in scikits.timeseries module
In-Reply-To: <loom.20080919T173026-820@post.gmane.org>
References: <loom.20080919T173026-820@post.gmane.org>
Message-ID: <200809191420.34846.pgmdevlist@gmail.com>

On Friday 19 September 2008 13:35:54 Dave wrote:
> Whilst starting to experiment with the timeseries module I came across the
> following error. Any idea what is wrong / what I'm doing wrong?

That's a known problem, sorry about that. You'll need numpy 1.2.1 (I know, 
1.2.0 is not even released yet...), or the latest SVN.
Alternatively, just replace line 471 of tseries.py with
>>>?output = MaskedArray.view(self, dtype)

I'll commit a workaround today or tomorrow.
Thanks for your patience.
P.


From nwagner at iam.uni-stuttgart.de  Sun Sep 21 03:59:25 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 21 Sep 2008 09:59:25 +0200
Subject: [SciPy-dev] problems with openopt
Message-ID: <web-111614589@uni-stuttgart.de>

Hi Dmitrey,

I have installed the most recent openopt from svn.

Now, several examples failed with a KeyError.

python -i svn/openopt/scikits/openopt/examples/lsp_1.py
OpenOpt checks user-supplied gradient df (shape: (3, 2) )
according to:
     prob.diffInt = [  1.00000000e-07]
     |1 - info_user/info_numerical| <= prob.maxViolation = 
0.01
derivatives are equal
========================
Traceback (most recent call last):
   File "svn/openopt/scikits/openopt/examples/lsp_1.py", 
line 45, in <module>
     r = p.solve('scipy_leastsq', plot=1, iprint = -1)
   File 
"build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/BaseProblem.py", 
line 186, in solve
   File 
"build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/runProbSolver.py", 
line 43, in runProbSolver
KeyError: 'scipy_leastsq'
  
Nils


From dmitrey.kroshko at scipy.org  Sun Sep 21 04:27:35 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 21 Sep 2008 11:27:35 +0300
Subject: [SciPy-dev] problems with openopt
In-Reply-To: <web-111614589@uni-stuttgart.de>
References: <web-111614589@uni-stuttgart.de>
Message-ID: <48D60577.80004@scipy.org>

Hi Nils,
unfortunately I can't reproduce the bug.
Does anyone else encounter the one?

As for the bug, it means openopt can't find 
.../openopt/solvers/scipy_optim/scipy_leastsq_oo.py file. It could be 
raised if you use openopt from egg file. However, you say you have 
installed from svn, and with ordinary python setup.py install it 
shouldn't be happened.

D.

Nils Wagner wrote:
> Hi Dmitrey,
>
> I have installed the most recent openopt from svn.
>
> Now, several examples failed with a KeyError.
>
> python -i svn/openopt/scikits/openopt/examples/lsp_1.py
> OpenOpt checks user-supplied gradient df (shape: (3, 2) )
> according to:
>      prob.diffInt = [  1.00000000e-07]
>      |1 - info_user/info_numerical| <= prob.maxViolation = 
> 0.01
> derivatives are equal
> ========================
> Traceback (most recent call last):
>    File "svn/openopt/scikits/openopt/examples/lsp_1.py", 
> line 45, in <module>
>      r = p.solve('scipy_leastsq', plot=1, iprint = -1)
>    File 
> "build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/BaseProblem.py", 
> line 186, in solve
>    File 
> "build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/runProbSolver.py", 
> line 43, in runProbSolver
> KeyError: 'scipy_leastsq'
>   
> Nils
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From cohen at slac.stanford.edu  Sun Sep 21 13:35:10 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Sun, 21 Sep 2008 10:35:10 -0700
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D60577.80004@scipy.org>
References: <web-111614589@uni-stuttgart.de> <48D60577.80004@scipy.org>
Message-ID: <48D685CE.5070305@slac.stanford.edu>

hi there,
how do I switch off installation of numpy 1.1.1 on my linux box? I have 
numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt 
when I  launch python setup.py install
thanks,
Johann

dmitrey wrote:
> Hi Nils,
> unfortunately I can't reproduce the bug.
> Does anyone else encounter the one?
>
> As for the bug, it means openopt can't find 
> .../openopt/solvers/scipy_optim/scipy_leastsq_oo.py file. It could be 
> raised if you use openopt from egg file. However, you say you have 
> installed from svn, and with ordinary python setup.py install it 
> shouldn't be happened.
>
> D.
>
> Nils Wagner wrote:
>   
>> Hi Dmitrey,
>>
>> I have installed the most recent openopt from svn.
>>
>> Now, several examples failed with a KeyError.
>>
>> python -i svn/openopt/scikits/openopt/examples/lsp_1.py
>> OpenOpt checks user-supplied gradient df (shape: (3, 2) )
>> according to:
>>      prob.diffInt = [  1.00000000e-07]
>>      |1 - info_user/info_numerical| <= prob.maxViolation = 
>> 0.01
>> derivatives are equal
>> ========================
>> Traceback (most recent call last):
>>    File "svn/openopt/scikits/openopt/examples/lsp_1.py", 
>> line 45, in <module>
>>      r = p.solve('scipy_leastsq', plot=1, iprint = -1)
>>    File 
>> "build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/BaseProblem.py", 
>> line 186, in solve
>>    File 
>> "build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/runProbSolver.py", 
>> line 43, in runProbSolver
>> KeyError: 'scipy_leastsq'
>>   
>> Nils
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>   
>>     
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   


From dmitrey.kroshko at scipy.org  Sun Sep 21 14:29:09 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 21 Sep 2008 21:29:09 +0300
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D685CE.5070305@slac.stanford.edu>
References: <web-111614589@uni-stuttgart.de> <48D60577.80004@scipy.org>
	<48D685CE.5070305@slac.stanford.edu>
Message-ID: <48D69275.6050005@scipy.org>

Johann Cohen-Tanugi wrote:
> hi there,
> how do I switch off installation of numpy 1.1.1 on my linux box? I have 
> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt 
> when I  launch python setup.py install
> thanks,
> Johann
>   
I didn't put any numpy version requirements into setup.py file. If the 
problem still somehow exist it's better to search an answer in 
setuptools mail list.

Also, to avoid the bug, you could just copy openopt/scikits/* files to 
.../site-packages/scikits directory (latter should be created)

Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO 
install works ok:
---------------------
...
byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to 
__init__.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/PKG-INFO -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/SOURCES.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/dependency_links.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/namespace_packages.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/requires.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/top_level.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/zip-safe -> 
build/bdist.linux-x86_64/egg/EGG-INFO
creating dist
creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding 
'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing scikits.openopt-0.19.dev-py2.5.egg
Copying scikits.openopt-0.19.dev-py2.5.egg to 
/usr/lib/python2.5/site-packages
Removing scikits.openopt 0.19.dev from easy-install.pth file
Adding scikits.openopt 0.19.dev to easy-install.pth file

Installed 
/usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
Processing dependencies for scikits.openopt==0.19.dev
Searching for numpy==1.3.0.dev5858
Best match: numpy 1.3.0.dev5858
Adding numpy 1.3.0.dev5858 to easy-install.pth file

Using /usr/lib/python2.5/site-packages
Finished processing dependencies for scikits.openopt==0.19.dev

-------------------------------
Regards, D.


From dmitrey.kroshko at scipy.org  Sun Sep 21 15:02:17 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 21 Sep 2008 22:02:17 +0300
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits fail [was:
	installing openopt]
In-Reply-To: <48D69275.6050005@scipy.org>
References: <web-111614589@uni-stuttgart.de>
	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>
	<48D69275.6050005@scipy.org>
Message-ID: <48D69A39.3080006@scipy.org>

Hi all,
after updating numpy I have troubles with openopt
ImportError: No module named openopt

and seems like it is related to timeseries as well: I have similar bug:

~/scikits/timeseries/scikits/timeseries/tests# python test_dates.py
Traceback (most recent call last):
  File "test_dates.py", line 21, in <module>
    import scikits.timeseries as ts
ImportError: No module named timeseries


> Johann Cohen-Tanugi wrote:
>   
>> hi there,
>> how do I switch off installation of numpy 1.1.1 on my linux box? I have 
>> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt 
>> when I  launch python setup.py install
>> thanks,
>> Johann
>>   
>>     
> I didn't put any numpy version requirements into setup.py file. If the 
> problem still somehow exist it's better to search an answer in 
> setuptools mail list.
>
> Also, to avoid the bug, you could just copy openopt/scikits/* files to 
> .../site-packages/scikits directory (latter should be created)
>
> Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO 
> install works ok:
> ---------------------
> ...
> byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to 
> __init__.pyc
> creating build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/PKG-INFO -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/SOURCES.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/dependency_links.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/namespace_packages.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/requires.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/top_level.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/zip-safe -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> creating dist
> creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding 
> 'build/bdist.linux-x86_64/egg' to it
> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
> Processing scikits.openopt-0.19.dev-py2.5.egg
> Copying scikits.openopt-0.19.dev-py2.5.egg to 
> /usr/lib/python2.5/site-packages
> Removing scikits.openopt 0.19.dev from easy-install.pth file
> Adding scikits.openopt 0.19.dev to easy-install.pth file
>
> Installed 
> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
> Processing dependencies for scikits.openopt==0.19.dev
> Searching for numpy==1.3.0.dev5858
> Best match: numpy 1.3.0.dev5858
> Adding numpy 1.3.0.dev5858 to easy-install.pth file
>
> Using /usr/lib/python2.5/site-packages
> Finished processing dependencies for scikits.openopt==0.19.dev
>
> -------------------------------
> Regards, D.
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From robert.kern at gmail.com  Sun Sep 21 17:06:11 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 21 Sep 2008 16:06:11 -0500
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits fail
	[was: installing openopt]
In-Reply-To: <48D69A39.3080006@scipy.org>
References: <web-111614589@uni-stuttgart.de> <48D60577.80004@scipy.org>
	<48D685CE.5070305@slac.stanford.edu> <48D69275.6050005@scipy.org>
	<48D69A39.3080006@scipy.org>
Message-ID: <3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>

On Sun, Sep 21, 2008 at 14:02, dmitrey <dmitrey.kroshko at scipy.org> wrote:
> Hi all,
> after updating numpy I have troubles with openopt
> ImportError: No module named openopt
>
> and seems like it is related to timeseries as well: I have similar bug:
>
> ~/scikits/timeseries/scikits/timeseries/tests# python test_dates.py
> Traceback (most recent call last):
>  File "test_dates.py", line 21, in <module>
>    import scikits.timeseries as ts
> ImportError: No module named timeseries

In fact, I have fixed a bug related to the combination of setuptools
and numpy.distutils when using "python setup.py install". Please
remove all scikits and reinstall them. If you are still having
problems, please tell me exactly what commands you are using to
install.

-- 
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


From dmitrey.kroshko at scipy.org  Mon Sep 22 07:01:18 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Mon, 22 Sep 2008 14:01:18 +0300
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>
References: <web-111614589@uni-stuttgart.de>
	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>
	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>
	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>
Message-ID: <48D77AFE.9080603@scipy.org>

Robert Kern wrote:
> On Sun, Sep 21, 2008 at 14:02, dmitrey <dmitrey.kroshko at scipy.org> wrote:
>   
>> Hi all,
>> after updating numpy I have troubles with openopt
>> ImportError: No module named openopt
>>
>> and seems like it is related to timeseries as well: I have similar bug:
>>
>> ~/scikits/timeseries/scikits/timeseries/tests# python test_dates.py
>> Traceback (most recent call last):
>>  File "test_dates.py", line 21, in <module>
>>    import scikits.timeseries as ts
>> ImportError: No module named timeseries
>>     
>
> In fact, I have fixed a bug related to the combination of setuptools
> and numpy.distutils when using "python setup.py install". Please
> remove all scikits and reinstall them.
> If you are still having
> problems, please tell me exactly what commands you are using to
> install.
>   
Yes I have, openopt works incorrectly, you could check it by yourself

 >>> from scikits.openopt import NLP
 >>> NLP(lambda x:x**2,4).solve('ralg')

OO Error:incorrect solver is called, maybe the solver "ralg" is not 
installed. Maybe setting p.debug=1 could specify the matter more precisely
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File 
"build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/BaseProblem.py", 
line 186, in solve
  File 
"build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/runProbSolver.py", 
line 48, in runProbSolver
  File 
"build/bdist.linux-x86_64/egg/scikits/openopt/Kernel/oologfcn.py", line 
16, in ooerr
scikits.openopt.Kernel.oologfcn.OpenOptException: incorrect solver is 
called, maybe the solver "ralg" is not installed. Maybe setting 
p.debug=1 could specify the matter more precisely

I guess now "python setup.py install" forms Python egg (previously there 
was a simple copying of Python files to installation directory), and 
openopt can't find path to a solver. Dictionary with the paths to 
*_oo.py files  is formed via os.walk() during start of openopt session, 
and os.walk can't handle situation with eggs.

D.



From dmitrey.kroshko at scipy.org  Mon Sep 22 07:10:11 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Mon, 22 Sep 2008 14:10:11 +0300
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>
References: <web-111614589@uni-stuttgart.de>
	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>
	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>
	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>
Message-ID: <48D77D13.9070600@scipy.org>

Robert Kern wrote:
> On Sun, Sep 21, 2008 at 14:02, dmitrey <dmitrey.kroshko at scipy.org> wrote:
>   
>> Hi all,
>> after updating numpy I have troubles with openopt
>> ImportError: No module named openopt
>>
>> and seems like it is related to timeseries as well: I have similar bug:
>>
>> ~/scikits/timeseries/scikits/timeseries/tests# python test_dates.py
>> Traceback (most recent call last):
>>  File "test_dates.py", line 21, in <module>
>>    import scikits.timeseries as ts
>> ImportError: No module named timeseries
>>     
>
> In fact, I have fixed a bug related to the combination of setuptools
> and numpy.distutils when using "python setup.py install". Please
> remove all scikits and reinstall them. If you are still having
> problems, please tell me exactly what commands you are using to
> install.
>   
I have another one bug that should be mentioned:
if I modify any source file and then run "python setup.py install" once 
again I have error:

........
(lots of "byte-compiling")
........
byte-compiling 
build/bdist.linux-x86_64/egg/scikits/openopt/tests/nlsp1.py to nlsp1.pyc
byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to 
__init__.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/PKG-INFO -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/SOURCES.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/dependency_links.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/namespace_packages.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/requires.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/top_level.txt -> 
build/bdist.linux-x86_64/egg/EGG-INFO
copying scikits.openopt.egg-info/zip-safe -> 
build/bdist.linux-x86_64/egg/EGG-INFO
creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding 
'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing scikits.openopt-0.19.dev-py2.5.egg
Removing /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
Copying scikits.openopt-0.19.dev-py2.5.egg to 
/usr/lib/python2.5/site-packages
scikits.openopt 0.19.dev is already the active version in easy-install.pth

Installed 
/usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
Processing dependencies for scikits.openopt==0.19.dev
Traceback (most recent call last):
  File "setup.py", line 96, in <module>
    'Topic :: Scientific/Engineering']
  File "/usr/lib/python2.5/site-packages/numpy/distutils/core.py", line 
184, in setup
    return old_setup(**new_attr)
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File 
"/usr/lib/python2.5/site-packages/numpy/distutils/command/install.py", 
line 51, in run
    r = self.setuptools_run()
  File 
"/usr/lib/python2.5/site-packages/numpy/distutils/command/install.py", 
line 45, in setuptools_run
    self.do_egg_install()
  File "/usr/lib/python2.5/site-packages/setuptools/command/install.py", 
line 104, in do_egg_install
    cmd.run()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 211, in run
    self.easy_install(spec, not self.no_deps)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 427, in easy_install
    return self.install_item(None, spec, tmpdir, deps, True)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 478, in install_item
    self.process_distribution(spec, dist, deps)
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", 
line 519, in process_distribution
    [requirement], self.local_index, self.easy_install
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 529, in 
resolve
    requirements.extend(dist.requires(req.extras)[::-1])
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 2107, 
in requires
    dm = self._dep_map
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 2099, 
in _dep_map
    for extra,reqs in split_sections(self._get_metadata(name)):
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 2518, 
in split_sections
    for line in yield_lines(s):
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1813, 
in yield_lines
    for ss in strs:
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 2121, 
in _get_metadata
    for line in self.get_metadata_lines(name):
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1140, 
in get_metadata_lines
    return yield_lines(self.get_metadata(name))
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1137, 
in get_metadata
    return self._get(self._fn(self.egg_info,name))
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1195, 
in _get
    return self.loader.get_data(path)
zipimport.ZipImportError: bad local file header in 
/usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg

So currently each time I have modified openopt source code I have to use
"rm /usr/lib/python2.5/site-packages/*openopt*"

D.


From david at ar.media.kyoto-u.ac.jp  Mon Sep 22 08:12:55 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 22 Sep 2008 21:12:55 +0900
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <48D77AFE.9080603@scipy.org>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>
	<48D77AFE.9080603@scipy.org>
Message-ID: <48D78BC7.5080408@ar.media.kyoto-u.ac.jp>

dmitrey wrote:
> Robert Kern wrote:
>> On Sun, Sep 21, 2008 at 14:02, dmitrey <dmitrey.kroshko at scipy.org> wrote:
>>   
>>> Hi all,
>>> after updating numpy I have troubles with openopt
>>> ImportError: No module named openopt
>>>
>>> and seems like it is related to timeseries as well: I have similar bug:
>>>
>>> ~/scikits/timeseries/scikits/timeseries/tests# python test_dates.py
>>> Traceback (most recent call last):
>>>  File "test_dates.py", line 21, in <module>
>>>    import scikits.timeseries as ts
>>> ImportError: No module named timeseries
>>>     
>> In fact, I have fixed a bug related to the combination of setuptools
>> and numpy.distutils when using "python setup.py install". Please
>> remove all scikits and reinstall them.
>> If you are still having
>> problems, please tell me exactly what commands you are using to
>> install.
>>   
> Yes I have, openopt works incorrectly, you could check it by yourself
>
>  >>> from scikits.openopt import NLP
>  >>> NLP(lambda x:x**2,4).solve('ralg')

FWIW, this works for me (with last revision of both scikits and numpy),

>
> I guess now "python setup.py install" forms Python egg (previously there 
> was a simple copying of Python files to installation directory)

Yes, this is true unfortunately.

> , and 
> openopt can't find path to a solver. Dictionary with the paths to 
> *_oo.py files  is formed via os.walk() during start of openopt session, 
> and os.walk can't handle situation with eggs.

You need to change this, I guess, but for the time being, you can tell
setuptools install to avoid using eggs (I personally always install
scikits this way, since I want to avoid eggs on my system, and this
works well):

python setup.py install --prefix=foo --single-version-externally-managed
--record=/dev/null

I have an alias which shall remain nameless in public to 'python
setup.py install --single-version-externally-managed --record=/dev/null'

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Mon Sep 22 08:14:31 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 22 Sep 2008 21:14:31 +0900
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <48D78BC7.5080408@ar.media.kyoto-u.ac.jp>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>	<48D77AFE.9080603@scipy.org>
	<48D78BC7.5080408@ar.media.kyoto-u.ac.jp>
Message-ID: <48D78C27.2010503@ar.media.kyoto-u.ac.jp>

David Cournapeau wrote:
>
> FWIW, this works for me (with last revision of both scikits and numpy),
>   

Sorry: this should read this works for me if you use the instructions
below, which you can use before making the changes to your package.

>> , and 
>> openopt can't find path to a solver. Dictionary with the paths to 
>> *_oo.py files  is formed via os.walk() during start of openopt session, 
>> and os.walk can't handle situation with eggs.
>>     
>
> You need to change this, I guess, but for the time being, you can tell
> setuptools install to avoid using eggs (I personally always install
> scikits this way, since I want to avoid eggs on my system, and this
> works well):
>
> python setup.py install --prefix=foo --single-version-externally-managed
> --record=/dev/null
>
> I have an alias which shall remain nameless in public to 'python
> setup.py install --single-version-externally-managed --record=/dev/null'
>   



From dmitrey.kroshko at scipy.org  Mon Sep 22 08:45:48 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Mon, 22 Sep 2008 15:45:48 +0300
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <48D78BC7.5080408@ar.media.kyoto-u.ac.jp>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>	<48D77AFE.9080603@scipy.org>
	<48D78BC7.5080408@ar.media.kyoto-u.ac.jp>
Message-ID: <48D7937C.3000002@scipy.org>

David Cournapeau wrote:
> dmitrey wrote:
>   
>> I guess now "python setup.py install" forms Python egg (previously there 
>> was a simple copying of Python files to installation directory)
>>     
>
> Yes, this is true unfortunately.
>   
>> , and 
>> openopt can't find path to a solver. Dictionary with the paths to 
>> *_oo.py files  is formed via os.walk() during start of openopt session, 
>> and os.walk can't handle situation with eggs.
>>     
>
> You need to change this, I guess, but for the time being, you can tell
> setuptools install to avoid using eggs (I personally always install
> scikits this way, since I want to avoid eggs on my system, and this
> works well):
>
> python setup.py install --prefix=foo --single-version-externally-managed
> --record=/dev/null
>   
1. This is valid for Linux only, while OO users expect to have other 
OSes as well.
2. Users usually just type "python setup.py install" and don't read any 
install instructions. It would be nice to put the options into setup.py 
file (or mb setup.cgf).

Do you have any idea how to do the trick?
Regards, D.



From david at ar.media.kyoto-u.ac.jp  Mon Sep 22 08:41:55 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 22 Sep 2008 21:41:55 +0900
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <48D7937C.3000002@scipy.org>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>	<48D77AFE.9080603@scipy.org>	<48D78BC7.5080408@ar.media.kyoto-u.ac.jp>
	<48D7937C.3000002@scipy.org>
Message-ID: <48D79293.9080602@ar.media.kyoto-u.ac.jp>

dmitrey wrote:
>
> 1. This is valid for Linux only, while OO users expect to have other 
> OSes as well.

No, it works on every OS I have ever used numpy on (and this includes
all the majors ones since my work on numscons); of course, the /dev/null
is OS dependant, but you can use any file for this (why setuptools
requires the --record in this situtation is beyond me BTW). I never use
eggs on any OS, so I can be 100 % affirmative it does work on every
platform it matters

> 2. Users usually just type "python setup.py install" and don't read any 
> install instructions. It would be nice to put the options into setup.py 
> file (or mb setup.cgf).

Yes, you will have to fix this, this was just meant as a quick fixaround
until you fix your package. You can't put those options somewhere, the
user still have to get the choice for eggs if wanted.

>
> Do you have any idea how to do the trick?

I think you should avoid dealing with the filesystem after installation
if at all possible. This is really fragile, and difficult to get right
on every platform/condition. If you can't, you should use the ressources
API, which is part of python itself; I don't think there is any other way:

http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources

But I don't know enough about openopt to be 100 % affirmative.

cheers,

David


From dmitrey.kroshko at scipy.org  Mon Sep 22 08:58:27 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Mon, 22 Sep 2008 15:58:27 +0300
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <48D78BC7.5080408@ar.media.kyoto-u.ac.jp>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>	<48D77AFE.9080603@scipy.org>
	<48D78BC7.5080408@ar.media.kyoto-u.ac.jp>
Message-ID: <48D79673.6000104@scipy.org>

David Cournapeau wrote:
> You need to change this, I guess, but for the time being, you can tell
> setuptools install to avoid using eggs (I personally always install
> scikits this way, since I want to avoid eggs on my system, and this
> works well):
>
> python setup.py install --prefix=foo --single-version-externally-managed
> --record=/dev/null
>
> I have an alias which shall remain nameless in public to 'python
> setup.py install --single-version-externally-managed --record=/dev/null'
>   
I wonder why scikits installation now is performed into eggs?
Initially there were no problems with pure Python code. Also, AFAIK eggs 
are zipped, at least according to the message I obtain that contains 
zipimport.ZipImportError. I guess unzipping 2 MB of openopt's code each 
session leads to some time leak, also, it will be harder to trace 
programs (via debugger or something like that).

I hope the situation with scikits eggs will be turned back to plain code.

D.



From matthieu.brucher at gmail.com  Mon Sep 22 09:03:14 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Mon, 22 Sep 2008 15:03:14 +0200
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits fail
	[was: installing openopt]
In-Reply-To: <48D79293.9080602@ar.media.kyoto-u.ac.jp>
References: <web-111614589@uni-stuttgart.de> <48D60577.80004@scipy.org>
	<48D685CE.5070305@slac.stanford.edu> <48D69275.6050005@scipy.org>
	<48D69A39.3080006@scipy.org>
	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>
	<48D77AFE.9080603@scipy.org> <48D78BC7.5080408@ar.media.kyoto-u.ac.jp>
	<48D7937C.3000002@scipy.org> <48D79293.9080602@ar.media.kyoto-u.ac.jp>
Message-ID: <e76aa17f0809220603q15ceec19m42ef01fe873dd9b3@mail.gmail.com>

>> Do you have any idea how to do the trick?
>
> I think you should avoid dealing with the filesystem after installation
> if at all possible. This is really fragile, and difficult to get right
> on every platform/condition. If you can't, you should use the ressources
> API, which is part of python itself; I don't think there is any other way:
>
> http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources
>
> But I don't know enough about openopt to be 100 % affirmative.

Isn't it possible to just use the zip_safe switch ? For the moment,
openopt declares that it can run from a zip file, but it cannot. I may
be missing something though...

Matthieu
-- 
French PhD student
Information System Engineer
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher


From david at ar.media.kyoto-u.ac.jp  Mon Sep 22 08:51:24 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 22 Sep 2008 21:51:24 +0900
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <e76aa17f0809220603q15ceec19m42ef01fe873dd9b3@mail.gmail.com>
References: <web-111614589@uni-stuttgart.de>
	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>
	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>	<48D77AFE.9080603@scipy.org>
	<48D78BC7.5080408@ar.media.kyoto-u.ac.jp>	<48D7937C.3000002@scipy.org>
	<48D79293.9080602@ar.media.kyoto-u.ac.jp>
	<e76aa17f0809220603q15ceec19m42ef01fe873dd9b3@mail.gmail.com>
Message-ID: <48D794CC.4090203@ar.media.kyoto-u.ac.jp>

Matthieu Brucher wrote:
>
> Isn't it possible to just use the zip_safe switch ? For the moment,
> openopt declares that it can run from a zip file, but it cannot. I may
> be missing something though...
>   

Ah, yes, I forgot about this, this may work. I only know enough about
setuptools to avoid using its features as much as possible, I guess.

cheers,

David


From dmitrey.kroshko at scipy.org  Mon Sep 22 10:28:25 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Mon, 22 Sep 2008 17:28:25 +0300
Subject: [SciPy-dev] [MAJOR BUG] latest numpy leads to scikits
 fail	[was: installing openopt]
In-Reply-To: <48D794CC.4090203@ar.media.kyoto-u.ac.jp>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D69A39.3080006@scipy.org>	<3d375d730809211406hccc22a8sa7b0062c58879ca6@mail.gmail.com>	<48D77AFE.9080603@scipy.org>	<48D78BC7.5080408@ar.media.kyoto-u.ac.jp>	<48D7937C.3000002@scipy.org>	<48D79293.9080602@ar.media.kyoto-u.ac.jp>	<e76aa17f0809220603q15ceec19m42ef01fe873dd9b3@mail.gmail.com>
	<48D794CC.4090203@ar.media.kyoto-u.ac.jp>
Message-ID: <48D7AB89.4030800@scipy.org>

David Cournapeau wrote:
> Matthieu Brucher wrote:
>   
>> Isn't it possible to just use the zip_safe switch ? For the moment,
>> openopt declares that it can run from a zip file, but it cannot. I may
>> be missing something though...
>>   
>>     
>
> Ah, yes, I forgot about this, this may work. I only know enough about
> setuptools to avoid using its features as much as possible, I guess.
>
> cheers,
>
> David
So I have committed some changes for *_oo.py files paths (now they are 
not generated while oo session start but when setup.py file is used) and 
changed zip_safe to False. If I have True, I have to type "python 
setup.py install" for twice (after any code changes). 1st time it yields 
"zipimport.ZipImportError: bad local file header in 
/usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg", 
after 2nd time all is ok.

D.


From cohen at slac.stanford.edu  Mon Sep 22 15:37:26 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Mon, 22 Sep 2008 21:37:26 +0200
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D69275.6050005@scipy.org>
References: <web-111614589@uni-stuttgart.de>
	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>
	<48D69275.6050005@scipy.org>
Message-ID: <48D7F3F6.4020207@slac.stanford.edu>

ok, no idea.... I get that
Installed 
/usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
Processing dependencies for scikits.openopt==0.19.dev
Searching for numpy
Reading http://pypi.python.org/simple/numpy/
Reading http://numeric.scipy.org
Reading 
http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103
Reading http://numpy.scipy.org
Best match: numpy 1.1.1
Downloading 
http://downloads.sourceforge.net/numpy/numpy-1.1.1.tar.gz?modtime=1217627080&big_mirror=0

and still numpy is in my path and perfectly imported when I start python....
If someone has a hint out there...
Johann

dmitrey wrote:
> Johann Cohen-Tanugi wrote:
>   
>> hi there,
>> how do I switch off installation of numpy 1.1.1 on my linux box? I have 
>> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt 
>> when I  launch python setup.py install
>> thanks,
>> Johann
>>   
>>     
> I didn't put any numpy version requirements into setup.py file. If the 
> problem still somehow exist it's better to search an answer in 
> setuptools mail list.
>
> Also, to avoid the bug, you could just copy openopt/scikits/* files to 
> .../site-packages/scikits directory (latter should be created)
>
> Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO 
> install works ok:
> ---------------------
> ...
> byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to 
> __init__.pyc
> creating build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/PKG-INFO -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/SOURCES.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/dependency_links.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/namespace_packages.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/requires.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/top_level.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying scikits.openopt.egg-info/zip-safe -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> creating dist
> creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding 
> 'build/bdist.linux-x86_64/egg' to it
> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
> Processing scikits.openopt-0.19.dev-py2.5.egg
> Copying scikits.openopt-0.19.dev-py2.5.egg to 
> /usr/lib/python2.5/site-packages
> Removing scikits.openopt 0.19.dev from easy-install.pth file
> Adding scikits.openopt 0.19.dev to easy-install.pth file
>
> Installed 
> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
> Processing dependencies for scikits.openopt==0.19.dev
> Searching for numpy==1.3.0.dev5858
> Best match: numpy 1.3.0.dev5858
> Adding numpy 1.3.0.dev5858 to easy-install.pth file
>
> Using /usr/lib/python2.5/site-packages
> Finished processing dependencies for scikits.openopt==0.19.dev
>
> -------------------------------
> Regards, D.
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   


From matthieu.brucher at gmail.com  Mon Sep 22 15:54:05 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Mon, 22 Sep 2008 21:54:05 +0200
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D7F3F6.4020207@slac.stanford.edu>
References: <web-111614589@uni-stuttgart.de> <48D60577.80004@scipy.org>
	<48D685CE.5070305@slac.stanford.edu> <48D69275.6050005@scipy.org>
	<48D7F3F6.4020207@slac.stanford.edu>
Message-ID: <e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>

Hi,

How did you install numpy ? Is there a numpy.something.pth in your
site-package folder ?

Matthieu

2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
> ok, no idea.... I get that
> Installed
> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
> Processing dependencies for scikits.openopt==0.19.dev
> Searching for numpy
> Reading http://pypi.python.org/simple/numpy/
> Reading http://numeric.scipy.org
> Reading
> http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103
> Reading http://numpy.scipy.org
> Best match: numpy 1.1.1
> Downloading
> http://downloads.sourceforge.net/numpy/numpy-1.1.1.tar.gz?modtime=1217627080&big_mirror=0
>
> and still numpy is in my path and perfectly imported when I start python....
> If someone has a hint out there...
> Johann
>
> dmitrey wrote:
>> Johann Cohen-Tanugi wrote:
>>
>>> hi there,
>>> how do I switch off installation of numpy 1.1.1 on my linux box? I have
>>> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt
>>> when I  launch python setup.py install
>>> thanks,
>>> Johann
>>>
>>>
>> I didn't put any numpy version requirements into setup.py file. If the
>> problem still somehow exist it's better to search an answer in
>> setuptools mail list.
>>
>> Also, to avoid the bug, you could just copy openopt/scikits/* files to
>> .../site-packages/scikits directory (latter should be created)
>>
>> Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO
>> install works ok:
>> ---------------------
>> ...
>> byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to
>> __init__.pyc
>> creating build/bdist.linux-x86_64/egg/EGG-INFO
>> copying scikits.openopt.egg-info/PKG-INFO ->
>> build/bdist.linux-x86_64/egg/EGG-INFO
>> copying scikits.openopt.egg-info/SOURCES.txt ->
>> build/bdist.linux-x86_64/egg/EGG-INFO
>> copying scikits.openopt.egg-info/dependency_links.txt ->
>> build/bdist.linux-x86_64/egg/EGG-INFO
>> copying scikits.openopt.egg-info/namespace_packages.txt ->
>> build/bdist.linux-x86_64/egg/EGG-INFO
>> copying scikits.openopt.egg-info/requires.txt ->
>> build/bdist.linux-x86_64/egg/EGG-INFO
>> copying scikits.openopt.egg-info/top_level.txt ->
>> build/bdist.linux-x86_64/egg/EGG-INFO
>> copying scikits.openopt.egg-info/zip-safe ->
>> build/bdist.linux-x86_64/egg/EGG-INFO
>> creating dist
>> creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding
>> 'build/bdist.linux-x86_64/egg' to it
>> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
>> Processing scikits.openopt-0.19.dev-py2.5.egg
>> Copying scikits.openopt-0.19.dev-py2.5.egg to
>> /usr/lib/python2.5/site-packages
>> Removing scikits.openopt 0.19.dev from easy-install.pth file
>> Adding scikits.openopt 0.19.dev to easy-install.pth file
>>
>> Installed
>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>> Processing dependencies for scikits.openopt==0.19.dev
>> Searching for numpy==1.3.0.dev5858
>> Best match: numpy 1.3.0.dev5858
>> Adding numpy 1.3.0.dev5858 to easy-install.pth file
>>
>> Using /usr/lib/python2.5/site-packages
>> Finished processing dependencies for scikits.openopt==0.19.dev
>>
>> -------------------------------
>> Regards, D.
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
French PhD student
Information System Engineer
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher


From cohen at slac.stanford.edu  Mon Sep 22 16:01:23 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Mon, 22 Sep 2008 22:01:23 +0200
Subject: [SciPy-dev] installing openopt
In-Reply-To: <e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>
References: <web-111614589@uni-stuttgart.de>
	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>
	<48D69275.6050005@scipy.org>	<48D7F3F6.4020207@slac.stanford.edu>
	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>
Message-ID: <48D7F993.9030007@slac.stanford.edu>

I compiled it from svn sources, using python setup.py .... No there is 
no pth file in there...
Johann

Matthieu Brucher wrote:
> Hi,
>
> How did you install numpy ? Is there a numpy.something.pth in your
> site-package folder ?
>
> Matthieu
>
> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>   
>> ok, no idea.... I get that
>> Installed
>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>> Processing dependencies for scikits.openopt==0.19.dev
>> Searching for numpy
>> Reading http://pypi.python.org/simple/numpy/
>> Reading http://numeric.scipy.org
>> Reading
>> http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103
>> Reading http://numpy.scipy.org
>> Best match: numpy 1.1.1
>> Downloading
>> http://downloads.sourceforge.net/numpy/numpy-1.1.1.tar.gz?modtime=1217627080&big_mirror=0
>>
>> and still numpy is in my path and perfectly imported when I start python....
>> If someone has a hint out there...
>> Johann
>>
>> dmitrey wrote:
>>     
>>> Johann Cohen-Tanugi wrote:
>>>
>>>       
>>>> hi there,
>>>> how do I switch off installation of numpy 1.1.1 on my linux box? I have
>>>> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt
>>>> when I  launch python setup.py install
>>>> thanks,
>>>> Johann
>>>>
>>>>
>>>>         
>>> I didn't put any numpy version requirements into setup.py file. If the
>>> problem still somehow exist it's better to search an answer in
>>> setuptools mail list.
>>>
>>> Also, to avoid the bug, you could just copy openopt/scikits/* files to
>>> .../site-packages/scikits directory (latter should be created)
>>>
>>> Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO
>>> install works ok:
>>> ---------------------
>>> ...
>>> byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to
>>> __init__.pyc
>>> creating build/bdist.linux-x86_64/egg/EGG-INFO
>>> copying scikits.openopt.egg-info/PKG-INFO ->
>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>> copying scikits.openopt.egg-info/SOURCES.txt ->
>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>> copying scikits.openopt.egg-info/dependency_links.txt ->
>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>> copying scikits.openopt.egg-info/namespace_packages.txt ->
>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>> copying scikits.openopt.egg-info/requires.txt ->
>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>> copying scikits.openopt.egg-info/top_level.txt ->
>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>> copying scikits.openopt.egg-info/zip-safe ->
>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>> creating dist
>>> creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding
>>> 'build/bdist.linux-x86_64/egg' to it
>>> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
>>> Processing scikits.openopt-0.19.dev-py2.5.egg
>>> Copying scikits.openopt-0.19.dev-py2.5.egg to
>>> /usr/lib/python2.5/site-packages
>>> Removing scikits.openopt 0.19.dev from easy-install.pth file
>>> Adding scikits.openopt 0.19.dev to easy-install.pth file
>>>
>>> Installed
>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>> Processing dependencies for scikits.openopt==0.19.dev
>>> Searching for numpy==1.3.0.dev5858
>>> Best match: numpy 1.3.0.dev5858
>>> Adding numpy 1.3.0.dev5858 to easy-install.pth file
>>>
>>> Using /usr/lib/python2.5/site-packages
>>> Finished processing dependencies for scikits.openopt==0.19.dev
>>>
>>> -------------------------------
>>> Regards, D.
>>> _______________________________________________
>>> Scipy-dev mailing list
>>> Scipy-dev at scipy.org
>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>       
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>
>>     
>
>
>
>   


From travis at enthought.com  Mon Sep 22 16:18:17 2008
From: travis at enthought.com (Travis Vaught)
Date: Mon, 22 Sep 2008 15:18:17 -0500
Subject: [SciPy-dev] ANN: Enthought Python Distribution 4.0.300 Beta 2
	available
Message-ID: <75D8561B-D264-4F32-AE0B-75CF0C074600@enthought.com>

Greetings,

We've recently posted the second beta release of the Enthought Python  
Distribution (EPD) for our upcoming general release of version 4.0.300  
with Python 2.5.  You may download the beta from here:

http://www.enthought.com/products/epdbeta.php

Please feel free to test it out and provide feedback on the EPD Trac  
instance: https://svn.enthought.com/epd

You can check out the release notes here: http://www.enthought.com/products/epdbetareleasenotes.php


About EPD
---------
The Enthought Python Distribution (EPD) is a "kitchen-sink-included"  
distribution of the Python? Programming Language, including over 60  
additional tools and libraries. The EPD bundle includes NumPy, SciPy,  
IPython, 2D and 3D visualization, database adapters, and a lot of  
other tools right out of the box.

http://www.enthought.com/products/epd.php

It is currently available as a single-click installer for Windows XP  
(x86), Mac OS X (a universal binary for Intel 10.4 and above) and  
RedHat EL3 (x86 and amd64).

EPD is free for academic use.  An annual Subscription and installation  
support are available for individual commercial use (http://www.enthought.com/products/epddownload.php 
).  An Enterprise Subscription with support for particular deployment  
environments is also available for commercial purchase (http://www.enthought.com/products/enterprise.php 
). The Beta versions of EPD are available for indefinite free trial.

Thanks,

Travis

From matthieu.brucher at gmail.com  Mon Sep 22 16:26:19 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Mon, 22 Sep 2008 22:26:19 +0200
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D7F993.9030007@slac.stanford.edu>
References: <web-111614589@uni-stuttgart.de> <48D60577.80004@scipy.org>
	<48D685CE.5070305@slac.stanford.edu> <48D69275.6050005@scipy.org>
	<48D7F3F6.4020207@slac.stanford.edu>
	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>
	<48D7F993.9030007@slac.stanford.edu>
Message-ID: <e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>

Sorry, it's not a pth file, it's the egg-info file or folder for the
development version. Is it in your site-packages folder ?

Matthieu

2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
> I compiled it from svn sources, using python setup.py .... No there is
> no pth file in there...
> Johann
>
> Matthieu Brucher wrote:
>> Hi,
>>
>> How did you install numpy ? Is there a numpy.something.pth in your
>> site-package folder ?
>>
>> Matthieu
>>
>> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>>
>>> ok, no idea.... I get that
>>> Installed
>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>> Processing dependencies for scikits.openopt==0.19.dev
>>> Searching for numpy
>>> Reading http://pypi.python.org/simple/numpy/
>>> Reading http://numeric.scipy.org
>>> Reading
>>> http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103
>>> Reading http://numpy.scipy.org
>>> Best match: numpy 1.1.1
>>> Downloading
>>> http://downloads.sourceforge.net/numpy/numpy-1.1.1.tar.gz?modtime=1217627080&big_mirror=0
>>>
>>> and still numpy is in my path and perfectly imported when I start python....
>>> If someone has a hint out there...
>>> Johann
>>>
>>> dmitrey wrote:
>>>
>>>> Johann Cohen-Tanugi wrote:
>>>>
>>>>
>>>>> hi there,
>>>>> how do I switch off installation of numpy 1.1.1 on my linux box? I have
>>>>> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt
>>>>> when I  launch python setup.py install
>>>>> thanks,
>>>>> Johann
>>>>>
>>>>>
>>>>>
>>>> I didn't put any numpy version requirements into setup.py file. If the
>>>> problem still somehow exist it's better to search an answer in
>>>> setuptools mail list.
>>>>
>>>> Also, to avoid the bug, you could just copy openopt/scikits/* files to
>>>> .../site-packages/scikits directory (latter should be created)
>>>>
>>>> Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO
>>>> install works ok:
>>>> ---------------------
>>>> ...
>>>> byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to
>>>> __init__.pyc
>>>> creating build/bdist.linux-x86_64/egg/EGG-INFO
>>>> copying scikits.openopt.egg-info/PKG-INFO ->
>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>> copying scikits.openopt.egg-info/SOURCES.txt ->
>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>> copying scikits.openopt.egg-info/dependency_links.txt ->
>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>> copying scikits.openopt.egg-info/namespace_packages.txt ->
>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>> copying scikits.openopt.egg-info/requires.txt ->
>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>> copying scikits.openopt.egg-info/top_level.txt ->
>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>> copying scikits.openopt.egg-info/zip-safe ->
>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>> creating dist
>>>> creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding
>>>> 'build/bdist.linux-x86_64/egg' to it
>>>> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
>>>> Processing scikits.openopt-0.19.dev-py2.5.egg
>>>> Copying scikits.openopt-0.19.dev-py2.5.egg to
>>>> /usr/lib/python2.5/site-packages
>>>> Removing scikits.openopt 0.19.dev from easy-install.pth file
>>>> Adding scikits.openopt 0.19.dev to easy-install.pth file
>>>>
>>>> Installed
>>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>>> Processing dependencies for scikits.openopt==0.19.dev
>>>> Searching for numpy==1.3.0.dev5858
>>>> Best match: numpy 1.3.0.dev5858
>>>> Adding numpy 1.3.0.dev5858 to easy-install.pth file
>>>>
>>>> Using /usr/lib/python2.5/site-packages
>>>> Finished processing dependencies for scikits.openopt==0.19.dev
>>>>
>>>> -------------------------------
>>>> Regards, D.
>>>> _______________________________________________
>>>> Scipy-dev mailing list
>>>> Scipy-dev at scipy.org
>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>>>
>>> _______________________________________________
>>> Scipy-dev mailing list
>>> Scipy-dev at scipy.org
>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>
>>
>>
>>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
French PhD student
Information System Engineer
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher


From cohen at slac.stanford.edu  Mon Sep 22 16:30:07 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Mon, 22 Sep 2008 22:30:07 +0200
Subject: [SciPy-dev] installing openopt
In-Reply-To: <e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>
References: <web-111614589@uni-stuttgart.de>
	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>
	<48D69275.6050005@scipy.org>	<48D7F3F6.4020207@slac.stanford.edu>	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>	<48D7F993.9030007@slac.stanford.edu>
	<e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>
Message-ID: <48D8004F.6080502@slac.stanford.edu>

no problem. No, my numpy build did not create a numpy  egg-info 
directory in site-package. I do not think tht it ever did....
Johann

Matthieu Brucher wrote:
> Sorry, it's not a pth file, it's the egg-info file or folder for the
> development version. Is it in your site-packages folder ?
>
> Matthieu
>
> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>   
>> I compiled it from svn sources, using python setup.py .... No there is
>> no pth file in there...
>> Johann
>>
>> Matthieu Brucher wrote:
>>     
>>> Hi,
>>>
>>> How did you install numpy ? Is there a numpy.something.pth in your
>>> site-package folder ?
>>>
>>> Matthieu
>>>
>>> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>>>
>>>       
>>>> ok, no idea.... I get that
>>>> Installed
>>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>>> Processing dependencies for scikits.openopt==0.19.dev
>>>> Searching for numpy
>>>> Reading http://pypi.python.org/simple/numpy/
>>>> Reading http://numeric.scipy.org
>>>> Reading
>>>> http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103
>>>> Reading http://numpy.scipy.org
>>>> Best match: numpy 1.1.1
>>>> Downloading
>>>> http://downloads.sourceforge.net/numpy/numpy-1.1.1.tar.gz?modtime=1217627080&big_mirror=0
>>>>
>>>> and still numpy is in my path and perfectly imported when I start python....
>>>> If someone has a hint out there...
>>>> Johann
>>>>
>>>> dmitrey wrote:
>>>>
>>>>         
>>>>> Johann Cohen-Tanugi wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> hi there,
>>>>>> how do I switch off installation of numpy 1.1.1 on my linux box? I have
>>>>>> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt
>>>>>> when I  launch python setup.py install
>>>>>> thanks,
>>>>>> Johann
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> I didn't put any numpy version requirements into setup.py file. If the
>>>>> problem still somehow exist it's better to search an answer in
>>>>> setuptools mail list.
>>>>>
>>>>> Also, to avoid the bug, you could just copy openopt/scikits/* files to
>>>>> .../site-packages/scikits directory (latter should be created)
>>>>>
>>>>> Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO
>>>>> install works ok:
>>>>> ---------------------
>>>>> ...
>>>>> byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to
>>>>> __init__.pyc
>>>>> creating build/bdist.linux-x86_64/egg/EGG-INFO
>>>>> copying scikits.openopt.egg-info/PKG-INFO ->
>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>> copying scikits.openopt.egg-info/SOURCES.txt ->
>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>> copying scikits.openopt.egg-info/dependency_links.txt ->
>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>> copying scikits.openopt.egg-info/namespace_packages.txt ->
>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>> copying scikits.openopt.egg-info/requires.txt ->
>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>> copying scikits.openopt.egg-info/top_level.txt ->
>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>> copying scikits.openopt.egg-info/zip-safe ->
>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>> creating dist
>>>>> creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding
>>>>> 'build/bdist.linux-x86_64/egg' to it
>>>>> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
>>>>> Processing scikits.openopt-0.19.dev-py2.5.egg
>>>>> Copying scikits.openopt-0.19.dev-py2.5.egg to
>>>>> /usr/lib/python2.5/site-packages
>>>>> Removing scikits.openopt 0.19.dev from easy-install.pth file
>>>>> Adding scikits.openopt 0.19.dev to easy-install.pth file
>>>>>
>>>>> Installed
>>>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>>>> Processing dependencies for scikits.openopt==0.19.dev
>>>>> Searching for numpy==1.3.0.dev5858
>>>>> Best match: numpy 1.3.0.dev5858
>>>>> Adding numpy 1.3.0.dev5858 to easy-install.pth file
>>>>>
>>>>> Using /usr/lib/python2.5/site-packages
>>>>> Finished processing dependencies for scikits.openopt==0.19.dev
>>>>>
>>>>> -------------------------------
>>>>> Regards, D.
>>>>> _______________________________________________
>>>>> Scipy-dev mailing list
>>>>> Scipy-dev at scipy.org
>>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> Scipy-dev mailing list
>>>> Scipy-dev at scipy.org
>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>
>>     
>
>
>
>   


From matthieu.brucher at gmail.com  Mon Sep 22 16:37:52 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Mon, 22 Sep 2008 22:37:52 +0200
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D8004F.6080502@slac.stanford.edu>
References: <web-111614589@uni-stuttgart.de> <48D60577.80004@scipy.org>
	<48D685CE.5070305@slac.stanford.edu> <48D69275.6050005@scipy.org>
	<48D7F3F6.4020207@slac.stanford.edu>
	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>
	<48D7F993.9030007@slac.stanford.edu>
	<e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>
	<48D8004F.6080502@slac.stanford.edu>
Message-ID: <e76aa17f0809221337y9cfdc6ah7b91fdd6e7f914f4@mail.gmail.com>

It should have. It's what setuptools is using to know what is already
installed. The fact that it is not present on your system forces
setuptools to install a new version.

Matthieu

2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
> no problem. No, my numpy build did not create a numpy  egg-info
> directory in site-package. I do not think tht it ever did....
> Johann
>
> Matthieu Brucher wrote:
>> Sorry, it's not a pth file, it's the egg-info file or folder for the
>> development version. Is it in your site-packages folder ?
>>
>> Matthieu
>>
>> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>>
>>> I compiled it from svn sources, using python setup.py .... No there is
>>> no pth file in there...
>>> Johann
>>>
>>> Matthieu Brucher wrote:
>>>
>>>> Hi,
>>>>
>>>> How did you install numpy ? Is there a numpy.something.pth in your
>>>> site-package folder ?
>>>>
>>>> Matthieu
>>>>
>>>> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>>>>
>>>>
>>>>> ok, no idea.... I get that
>>>>> Installed
>>>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>>>> Processing dependencies for scikits.openopt==0.19.dev
>>>>> Searching for numpy
>>>>> Reading http://pypi.python.org/simple/numpy/
>>>>> Reading http://numeric.scipy.org
>>>>> Reading
>>>>> http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103
>>>>> Reading http://numpy.scipy.org
>>>>> Best match: numpy 1.1.1
>>>>> Downloading
>>>>> http://downloads.sourceforge.net/numpy/numpy-1.1.1.tar.gz?modtime=1217627080&big_mirror=0
>>>>>
>>>>> and still numpy is in my path and perfectly imported when I start python....
>>>>> If someone has a hint out there...
>>>>> Johann
>>>>>
>>>>> dmitrey wrote:
>>>>>
>>>>>
>>>>>> Johann Cohen-Tanugi wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> hi there,
>>>>>>> how do I switch off installation of numpy 1.1.1 on my linux box? I have
>>>>>>> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt
>>>>>>> when I  launch python setup.py install
>>>>>>> thanks,
>>>>>>> Johann
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I didn't put any numpy version requirements into setup.py file. If the
>>>>>> problem still somehow exist it's better to search an answer in
>>>>>> setuptools mail list.
>>>>>>
>>>>>> Also, to avoid the bug, you could just copy openopt/scikits/* files to
>>>>>> .../site-packages/scikits directory (latter should be created)
>>>>>>
>>>>>> Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO
>>>>>> install works ok:
>>>>>> ---------------------
>>>>>> ...
>>>>>> byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to
>>>>>> __init__.pyc
>>>>>> creating build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>> copying scikits.openopt.egg-info/PKG-INFO ->
>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>> copying scikits.openopt.egg-info/SOURCES.txt ->
>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>> copying scikits.openopt.egg-info/dependency_links.txt ->
>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>> copying scikits.openopt.egg-info/namespace_packages.txt ->
>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>> copying scikits.openopt.egg-info/requires.txt ->
>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>> copying scikits.openopt.egg-info/top_level.txt ->
>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>> copying scikits.openopt.egg-info/zip-safe ->
>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>> creating dist
>>>>>> creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding
>>>>>> 'build/bdist.linux-x86_64/egg' to it
>>>>>> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
>>>>>> Processing scikits.openopt-0.19.dev-py2.5.egg
>>>>>> Copying scikits.openopt-0.19.dev-py2.5.egg to
>>>>>> /usr/lib/python2.5/site-packages
>>>>>> Removing scikits.openopt 0.19.dev from easy-install.pth file
>>>>>> Adding scikits.openopt 0.19.dev to easy-install.pth file
>>>>>>
>>>>>> Installed
>>>>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>>>>> Processing dependencies for scikits.openopt==0.19.dev
>>>>>> Searching for numpy==1.3.0.dev5858
>>>>>> Best match: numpy 1.3.0.dev5858
>>>>>> Adding numpy 1.3.0.dev5858 to easy-install.pth file
>>>>>>
>>>>>> Using /usr/lib/python2.5/site-packages
>>>>>> Finished processing dependencies for scikits.openopt==0.19.dev
>>>>>>
>>>>>> -------------------------------
>>>>>> Regards, D.
>>>>>> _______________________________________________
>>>>>> Scipy-dev mailing list
>>>>>> Scipy-dev at scipy.org
>>>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Scipy-dev mailing list
>>>>> Scipy-dev at scipy.org
>>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Scipy-dev mailing list
>>> Scipy-dev at scipy.org
>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>
>>
>>
>>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
French PhD student
Information System Engineer
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher


From cohen at slac.stanford.edu  Tue Sep 23 02:15:43 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 23 Sep 2008 08:15:43 +0200
Subject: [SciPy-dev] installing openopt
In-Reply-To: <e76aa17f0809221337y9cfdc6ah7b91fdd6e7f914f4@mail.gmail.com>
References: <web-111614589@uni-stuttgart.de>
	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>
	<48D69275.6050005@scipy.org>	<48D7F3F6.4020207@slac.stanford.edu>	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>	<48D7F993.9030007@slac.stanford.edu>	<e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>	<48D8004F.6080502@slac.stanford.edu>
	<e76aa17f0809221337y9cfdc6ah7b91fdd6e7f914f4@mail.gmail.com>
Message-ID: <48D8898F.5060303@slac.stanford.edu>

is there anything special I should do to force building it when 
installing numpy? I can remove the whole directory and start numpy 
install from scratch..... but usually that is what I do anyway.
best,
J

Matthieu Brucher wrote:
> It should have. It's what setuptools is using to know what is already
> installed. The fact that it is not present on your system forces
> setuptools to install a new version.
>
> Matthieu
>
> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>   
>> no problem. No, my numpy build did not create a numpy  egg-info
>> directory in site-package. I do not think tht it ever did....
>> Johann
>>
>> Matthieu Brucher wrote:
>>     
>>> Sorry, it's not a pth file, it's the egg-info file or folder for the
>>> development version. Is it in your site-packages folder ?
>>>
>>> Matthieu
>>>
>>> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>>>
>>>       
>>>> I compiled it from svn sources, using python setup.py .... No there is
>>>> no pth file in there...
>>>> Johann
>>>>
>>>> Matthieu Brucher wrote:
>>>>
>>>>         
>>>>> Hi,
>>>>>
>>>>> How did you install numpy ? Is there a numpy.something.pth in your
>>>>> site-package folder ?
>>>>>
>>>>> Matthieu
>>>>>
>>>>> 2008/9/22 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>>>>>
>>>>>
>>>>>           
>>>>>> ok, no idea.... I get that
>>>>>> Installed
>>>>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>>>>> Processing dependencies for scikits.openopt==0.19.dev
>>>>>> Searching for numpy
>>>>>> Reading http://pypi.python.org/simple/numpy/
>>>>>> Reading http://numeric.scipy.org
>>>>>> Reading
>>>>>> http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103
>>>>>> Reading http://numpy.scipy.org
>>>>>> Best match: numpy 1.1.1
>>>>>> Downloading
>>>>>> http://downloads.sourceforge.net/numpy/numpy-1.1.1.tar.gz?modtime=1217627080&big_mirror=0
>>>>>>
>>>>>> and still numpy is in my path and perfectly imported when I start python....
>>>>>> If someone has a hint out there...
>>>>>> Johann
>>>>>>
>>>>>> dmitrey wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Johann Cohen-Tanugi wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> hi there,
>>>>>>>> how do I switch off installation of numpy 1.1.1 on my linux box? I have
>>>>>>>> numpy '1.3.0.dev5834' but it does not seem to be recognized by openopt
>>>>>>>> when I  launch python setup.py install
>>>>>>>> thanks,
>>>>>>>> Johann
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> I didn't put any numpy version requirements into setup.py file. If the
>>>>>>> problem still somehow exist it's better to search an answer in
>>>>>>> setuptools mail list.
>>>>>>>
>>>>>>> Also, to avoid the bug, you could just copy openopt/scikits/* files to
>>>>>>> .../site-packages/scikits directory (latter should be created)
>>>>>>>
>>>>>>> Some minuties ago I have update numpy to latest 1.3.0.dev5858, and OO
>>>>>>> install works ok:
>>>>>>> ---------------------
>>>>>>> ...
>>>>>>> byte-compiling build/bdist.linux-x86_64/egg/scikits/__init__.py to
>>>>>>> __init__.pyc
>>>>>>> creating build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>>> copying scikits.openopt.egg-info/PKG-INFO ->
>>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>>> copying scikits.openopt.egg-info/SOURCES.txt ->
>>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>>> copying scikits.openopt.egg-info/dependency_links.txt ->
>>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>>> copying scikits.openopt.egg-info/namespace_packages.txt ->
>>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>>> copying scikits.openopt.egg-info/requires.txt ->
>>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>>> copying scikits.openopt.egg-info/top_level.txt ->
>>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>>> copying scikits.openopt.egg-info/zip-safe ->
>>>>>>> build/bdist.linux-x86_64/egg/EGG-INFO
>>>>>>> creating dist
>>>>>>> creating 'dist/scikits.openopt-0.19.dev-py2.5.egg' and adding
>>>>>>> 'build/bdist.linux-x86_64/egg' to it
>>>>>>> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
>>>>>>> Processing scikits.openopt-0.19.dev-py2.5.egg
>>>>>>> Copying scikits.openopt-0.19.dev-py2.5.egg to
>>>>>>> /usr/lib/python2.5/site-packages
>>>>>>> Removing scikits.openopt 0.19.dev from easy-install.pth file
>>>>>>> Adding scikits.openopt 0.19.dev to easy-install.pth file
>>>>>>>
>>>>>>> Installed
>>>>>>> /usr/lib/python2.5/site-packages/scikits.openopt-0.19.dev-py2.5.egg
>>>>>>> Processing dependencies for scikits.openopt==0.19.dev
>>>>>>> Searching for numpy==1.3.0.dev5858
>>>>>>> Best match: numpy 1.3.0.dev5858
>>>>>>> Adding numpy 1.3.0.dev5858 to easy-install.pth file
>>>>>>>
>>>>>>> Using /usr/lib/python2.5/site-packages
>>>>>>> Finished processing dependencies for scikits.openopt==0.19.dev
>>>>>>>
>>>>>>> -------------------------------
>>>>>>> Regards, D.
>>>>>>> _______________________________________________
>>>>>>> Scipy-dev mailing list
>>>>>>> Scipy-dev at scipy.org
>>>>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> _______________________________________________
>>>>>> Scipy-dev mailing list
>>>>>> Scipy-dev at scipy.org
>>>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> Scipy-dev mailing list
>>>> Scipy-dev at scipy.org
>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>
>>     
>
>
>
>   


From david at ar.media.kyoto-u.ac.jp  Tue Sep 23 02:09:05 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 23 Sep 2008 15:09:05 +0900
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D8898F.5060303@slac.stanford.edu>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D7F3F6.4020207@slac.stanford.edu>	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>	<48D7F993.9030007@slac.stanford.edu>	<e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>	<48D8004F.6080502@slac.stanford.edu>	<e76aa17f0809221337y9cfdc6ah7b91fdd6e7f914f4@mail.gmail.com>
	<48D8898F.5060303@slac.stanford.edu>
Message-ID: <48D88801.3090904@ar.media.kyoto-u.ac.jp>

Johann Cohen-Tanugi wrote:
> is there anything special I should do to force building it when 
> installing numpy? I can remove the whole directory and start numpy 
> install from scratch..... but usually that is what I do anyway.
> best,
>   

If you don't care about setuptools easyness, use the command I mentioned
before:

python setup.py install --single-version-externally-managed
--record=/dev/null

For openopt only.
 This should work.

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Tue Sep 23 05:17:13 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 23 Sep 2008 18:17:13 +0900
Subject: [SciPy-dev] Are Creative Commons  licenses acceptable for scipy ?
Message-ID: <48D8B419.8080404@ar.media.kyoto-u.ac.jp>

Hi,

    I would like to include some small audio samples in my talkbox
scikits, and I found a set of samples from the OLPC project available
under the CC Attribution 3.0 unported license. Is this an acceptable
license for scipy (if some code is to be included in scipy at some point) ?

http://wiki.laptop.org/go/Sound_samples
http://creativecommons.org/licenses/by/3.0/

cheers,

David


From cohen at slac.stanford.edu  Tue Sep 23 06:13:47 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Tue, 23 Sep 2008 12:13:47 +0200
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D88801.3090904@ar.media.kyoto-u.ac.jp>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D7F3F6.4020207@slac.stanford.edu>	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>	<48D7F993.9030007@slac.stanford.edu>	<e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>	<48D8004F.6080502@slac.stanford.edu>	<e76aa17f0809221337y9cfdc6ah7b91fdd6e7f914f4@mail.gmail.com>	<48D8898F.5060303@slac.stanford.edu>
	<48D88801.3090904@ar.media.kyoto-u.ac.jp>
Message-ID: <48D8C15B.3010805@slac.stanford.edu>

yes that worked.... thanks!
I would still love to understand whether I am doing smthg wrong when 
building numpy.
Johann

David Cournapeau wrote:
> Johann Cohen-Tanugi wrote:
>   
>> is there anything special I should do to force building it when 
>> installing numpy? I can remove the whole directory and start numpy 
>> install from scratch..... but usually that is what I do anyway.
>> best,
>>   
>>     
>
> If you don't care about setuptools easyness, use the command I mentioned
> before:
>
> python setup.py install --single-version-externally-managed
> --record=/dev/null
>
> For openopt only.
>  This should work.
>
> cheers,
>
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   


From oliphant at enthought.com  Tue Sep 23 09:14:22 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Tue, 23 Sep 2008 08:14:22 -0500
Subject: [SciPy-dev] Are Creative Commons licenses acceptable for scipy ?
In-Reply-To: <48D8B419.8080404@ar.media.kyoto-u.ac.jp>
References: <48D8B419.8080404@ar.media.kyoto-u.ac.jp>
Message-ID: <48D8EBAE.2000200@enthought.com>

David Cournapeau wrote:
> Hi,
>
>     I would like to include some small audio samples in my talkbox
> scikits, and I found a set of samples from the OLPC project available
> under the CC Attribution 3.0 unported license. Is this an acceptable
> license for scipy (if some code is to be included in scipy at some point) ?
>
> http://wiki.laptop.org/go/Sound_samples
> http://creativecommons.org/licenses/by/3.0/
>   

Others may weigh in here of course.  But, from my perspective that 
license seems fine.  There is some under-specification of the license in 
that we must make attribution as required by the author. 

If the attribution requirement is particularly obnoxious (i.e. your 
"program" must have a "plugin" that shows my name), then that will be 
difficult.   If, however, all that is needed is a README in the 
directory that shows where it came from, then no problem at all.

-Travis



From robert.kern at gmail.com  Tue Sep 23 13:18:29 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 23 Sep 2008 12:18:29 -0500
Subject: [SciPy-dev] Are Creative Commons licenses acceptable for scipy ?
In-Reply-To: <48D8B419.8080404@ar.media.kyoto-u.ac.jp>
References: <48D8B419.8080404@ar.media.kyoto-u.ac.jp>
Message-ID: <3d375d730809231018o1c0deadfu2fcda936dc6ff3f3@mail.gmail.com>

On Tue, Sep 23, 2008 at 04:17, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Hi,
>
>    I would like to include some small audio samples in my talkbox
> scikits, and I found a set of samples from the OLPC project available
> under the CC Attribution 3.0 unported license. Is this an acceptable
> license for scipy (if some code is to be included in scipy at some point) ?

Inside the package itself, or just in the examples?

-- 
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


From dmitrey.kroshko at scipy.org  Tue Sep 23 16:30:30 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Tue, 23 Sep 2008 23:30:30 +0300
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D8C15B.3010805@slac.stanford.edu>
References: <web-111614589@uni-stuttgart.de>	<48D60577.80004@scipy.org>	<48D685CE.5070305@slac.stanford.edu>	<48D69275.6050005@scipy.org>	<48D7F3F6.4020207@slac.stanford.edu>	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>	<48D7F993.9030007@slac.stanford.edu>	<e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>	<48D8004F.6080502@slac.stanford.edu>	<e76aa17f0809221337y9cfdc6ah7b91fdd6e7f914f4@mail.gmail.com>	<48D8898F.5060303@slac.stanford.edu>	<48D88801.3090904@ar.media.kyoto-u.ac.jp>
	<48D8C15B.3010805@slac.stanford.edu>
Message-ID: <48D951E6.8000106@scipy.org>

I have noticed one more openopt installation issue with latest numpy:

modifying any single line in openopt's sources and then running "python 
setup.py install" now recompiles all openopt's files. Even if there were 
no changes at all, anyway all OO files are recompiled. Taking into 
account that I run this dozens times per day it's very annoying, and my 
increases danger for my HDD. Of course I could use OO without "python 
setup.py install" but this is inconvenient because of some reasons (I 
had already tried)

I hope the issue will be fixed by numpy.distutils developers.

Regards, D.


From robert.kern at gmail.com  Tue Sep 23 16:57:50 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 23 Sep 2008 15:57:50 -0500
Subject: [SciPy-dev] installing openopt
In-Reply-To: <48D951E6.8000106@scipy.org>
References: <web-111614589@uni-stuttgart.de>
	<e76aa17f0809221254x2432d336hcd762dd069f7f40b@mail.gmail.com>
	<48D7F993.9030007@slac.stanford.edu>
	<e76aa17f0809221326p7a6649bar6e94f737b596afc0@mail.gmail.com>
	<48D8004F.6080502@slac.stanford.edu>
	<e76aa17f0809221337y9cfdc6ah7b91fdd6e7f914f4@mail.gmail.com>
	<48D8898F.5060303@slac.stanford.edu>
	<48D88801.3090904@ar.media.kyoto-u.ac.jp>
	<48D8C15B.3010805@slac.stanford.edu> <48D951E6.8000106@scipy.org>
Message-ID: <3d375d730809231357t5e03b8a3uacf5cfce68b2f593@mail.gmail.com>

On Tue, Sep 23, 2008 at 15:30, dmitrey <dmitrey.kroshko at scipy.org> wrote:
> I have noticed one more openopt installation issue with latest numpy:
>
> modifying any single line in openopt's sources and then running "python
> setup.py install" now recompiles all openopt's files. Even if there were
> no changes at all, anyway all OO files are recompiled. Taking into
> account that I run this dozens times per day it's very annoying, and my
> increases danger for my HDD. Of course I could use OO without "python
> setup.py install" but this is inconvenient because of some reasons (I
> had already tried)

For development, I recommend "python setup.py develop". That way, you
don't have to rebuild or install anything. Or you can use the

python setup.py install --single-version-externally-managed --record=/dev/null

and then you shouldn't see unnecessary recompiles.

-- 
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


From david at ar.media.kyoto-u.ac.jp  Wed Sep 24 01:40:39 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 24 Sep 2008 14:40:39 +0900
Subject: [SciPy-dev] Are Creative Commons licenses acceptable for scipy ?
In-Reply-To: <3d375d730809231018o1c0deadfu2fcda936dc6ff3f3@mail.gmail.com>
References: <48D8B419.8080404@ar.media.kyoto-u.ac.jp>
	<3d375d730809231018o1c0deadfu2fcda936dc6ff3f3@mail.gmail.com>
Message-ID: <48D9D2D7.706@ar.media.kyoto-u.ac.jp>

Robert Kern wrote:
>
> Inside the package itself, or just in the examples?

I was planning on including them in the package, so that people could
easily reproduce the examples without getting the files themselves (I
would first downsample the samples, so none of them would take more than
say 50 kb, so license aside, I don't think it would be much trouble).

cheers,

David



From robert.kern at gmail.com  Wed Sep 24 02:19:44 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 24 Sep 2008 01:19:44 -0500
Subject: [SciPy-dev] Are Creative Commons licenses acceptable for scipy ?
In-Reply-To: <48D9D2D7.706@ar.media.kyoto-u.ac.jp>
References: <48D8B419.8080404@ar.media.kyoto-u.ac.jp>
	<3d375d730809231018o1c0deadfu2fcda936dc6ff3f3@mail.gmail.com>
	<48D9D2D7.706@ar.media.kyoto-u.ac.jp>
Message-ID: <3d375d730809232319h1607161en2781972022cc7815@mail.gmail.com>

On Wed, Sep 24, 2008 at 00:40, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Robert Kern wrote:
>>
>> Inside the package itself, or just in the examples?
>
> I was planning on including them in the package, so that people could
> easily reproduce the examples without getting the files themselves (I
> would first downsample the samples, so none of them would take more than
> say 50 kb, so license aside, I don't think it would be much trouble).

I mean, inside the scipy.signal Python package or in the
examples/signal/ directory in the source tarball (which is not what I
am not referring to when I say "package")?

I don't care for the former, but I'm content with the latter.

-- 
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


From david at ar.media.kyoto-u.ac.jp  Wed Sep 24 02:17:26 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 24 Sep 2008 15:17:26 +0900
Subject: [SciPy-dev] Are Creative Commons licenses acceptable for scipy ?
In-Reply-To: <3d375d730809232319h1607161en2781972022cc7815@mail.gmail.com>
References: <48D8B419.8080404@ar.media.kyoto-u.ac.jp>	<3d375d730809231018o1c0deadfu2fcda936dc6ff3f3@mail.gmail.com>	<48D9D2D7.706@ar.media.kyoto-u.ac.jp>
	<3d375d730809232319h1607161en2781972022cc7815@mail.gmail.com>
Message-ID: <48D9DB76.70909@ar.media.kyoto-u.ac.jp>

Robert Kern wrote:
> I mean, inside the scipy.signal Python package or in the
> examples/signal/ directory in the source tarball (which is not what I
> am not referring to when I say "package")?
>
> I don't care for the former, but I'm content with the latter.
>   

Ah, sorry for the confusion, I meant the latter (in the source tarball).
The former would make more sense in the hypothetical dataset package, I
guess, and is not what I had in mind.

David



From pebarrett at gmail.com  Wed Sep 24 16:34:56 2008
From: pebarrett at gmail.com (Paul Barrett)
Date: Wed, 24 Sep 2008 16:34:56 -0400
Subject: [SciPy-dev] Default data type of mtrand distributions
Message-ID: <40e64fa20809241334yd3f5a77raa89cc78cde3bad6@mail.gmail.com>

I'm using numpy to simulate - and then analyze - large scale (8k x 8k)
astronomical images. The counts per pixel are not expected to be much
greater that 100k for the brightest stars, so an int32 data type is
completely adequate for my needs.  In some cases, an int16 data type
will do, when the brightest object has <65k counts.  In fact, most
pixels are of the background sky with typical counts of <20.  When I
add Poisson noise to the simulated image, the output array has a data
type of int64 on my 64 bit workstation.  This results in an array size
of 512 MB, when a 256 MB array (i.e. int32 data type) will do.

So the question is: Is it possible to add a dtype keyword to the
distribution functions that will specify the output data type as
opposed to the current situation of defaulting to the largest possible
data type?  How difficult is it to make such changes?

 -- Paul


From robert.kern at gmail.com  Wed Sep 24 17:06:22 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 24 Sep 2008 16:06:22 -0500
Subject: [SciPy-dev] Default data type of mtrand distributions
In-Reply-To: <40e64fa20809241334yd3f5a77raa89cc78cde3bad6@mail.gmail.com>
References: <40e64fa20809241334yd3f5a77raa89cc78cde3bad6@mail.gmail.com>
Message-ID: <3d375d730809241406t14c543fcx9284a4930e823e81@mail.gmail.com>

On Wed, Sep 24, 2008 at 15:34, Paul Barrett <pebarrett at gmail.com> wrote:
> I'm using numpy to simulate - and then analyze - large scale (8k x 8k)
> astronomical images. The counts per pixel are not expected to be much
> greater that 100k for the brightest stars, so an int32 data type is
> completely adequate for my needs.  In some cases, an int16 data type
> will do, when the brightest object has <65k counts.  In fact, most
> pixels are of the background sky with typical counts of <20.  When I
> add Poisson noise to the simulated image, the output array has a data
> type of int64 on my 64 bit workstation.  This results in an array size
> of 512 MB, when a 256 MB array (i.e. int32 data type) will do.
>
> So the question is: Is it possible to add a dtype keyword to the
> distribution functions that will specify the output data type as
> opposed to the current situation of defaulting to the largest possible
> data type?  How difficult is it to make such changes?

Probably more annoying than difficult but sufficiently annoying that
I'm not going to do it any time soon. Present me with a complete
patch, though ...

-- 
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


From pebarrett at gmail.com  Wed Sep 24 21:02:49 2008
From: pebarrett at gmail.com (Paul Barrett)
Date: Wed, 24 Sep 2008 21:02:49 -0400
Subject: [SciPy-dev] Default data type of mtrand distributions
In-Reply-To: <3d375d730809241406t14c543fcx9284a4930e823e81@mail.gmail.com>
References: <40e64fa20809241334yd3f5a77raa89cc78cde3bad6@mail.gmail.com>
	<3d375d730809241406t14c543fcx9284a4930e823e81@mail.gmail.com>
Message-ID: <40e64fa20809241802j4f6a49a3k795b6603d158ace2@mail.gmail.com>

Robert,

I'm prepared to submit a patch, if I can find the time.  What is the
easiest way to go about this?  It would appear that some of this code
is generated.  If yes, then what should I look out for.  Any tips
would help speed this patch along.

 -- Paul

On Wed, Sep 24, 2008 at 5:06 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Wed, Sep 24, 2008 at 15:34, Paul Barrett <pebarrett at gmail.com> wrote:
>> I'm using numpy to simulate - and then analyze - large scale (8k x 8k)
>> astronomical images. The counts per pixel are not expected to be much
>> greater that 100k for the brightest stars, so an int32 data type is
>> completely adequate for my needs.  In some cases, an int16 data type
>> will do, when the brightest object has <65k counts.  In fact, most
>> pixels are of the background sky with typical counts of <20.  When I
>> add Poisson noise to the simulated image, the output array has a data
>> type of int64 on my 64 bit workstation.  This results in an array size
>> of 512 MB, when a 256 MB array (i.e. int32 data type) will do.
>>
>> So the question is: Is it possible to add a dtype keyword to the
>> distribution functions that will specify the output data type as
>> opposed to the current situation of defaulting to the largest possible
>> data type?  How difficult is it to make such changes?
>
> Probably more annoying than difficult but sufficiently annoying that
> I'm not going to do it any time soon. Present me with a complete
> patch, though ...
>
> --
> 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
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


From nwagner at iam.uni-stuttgart.de  Thu Sep 25 03:23:27 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 25 Sep 2008 09:23:27 +0200
Subject: [SciPy-dev] talkbox
Message-ID: <web-111829324@uni-stuttgart.de>

Hi David,

I found some typos (missing commas) in test_basic.py


python -i 
svn/talkbox/scikits/talkbox/spectral/tests/test_basic.py
   File 
"svn/talkbox/scikits/talkbox/spectral/tests/test_basic.py", 
line 14
     0.13803913 1.51075717, 0.23526771, 0.66520833, 
0.28393413, 0.09545270,
                         ^
SyntaxError: invalid syntax
>>>

Nils



From david at ar.media.kyoto-u.ac.jp  Thu Sep 25 08:53:32 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 25 Sep 2008 21:53:32 +0900
Subject: [SciPy-dev] talkbox
In-Reply-To: <web-111829324@uni-stuttgart.de>
References: <web-111829324@uni-stuttgart.de>
Message-ID: <48DB89CC.9020505@ar.media.kyoto-u.ac.jp>

Nils Wagner wrote:
> Hi David,
>
> I found some typos (missing commas) in test_basic.py
>   

Ah, yes. This file has not real test yet, actually, it should not be run
:) I fixed the typo nonetheless,

thanks,

David



From nwagner at iam.uni-stuttgart.de  Thu Sep 25 09:53:43 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 25 Sep 2008 15:53:43 +0200
Subject: [SciPy-dev] talkbox
In-Reply-To: <48DB89CC.9020505@ar.media.kyoto-u.ac.jp>
References: <web-111829324@uni-stuttgart.de>
	<48DB89CC.9020505@ar.media.kyoto-u.ac.jp>
Message-ID: <web-111858060@uni-stuttgart.de>

On Thu, 25 Sep 2008 21:53:32 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Nils Wagner wrote:
>> Hi David,
>>
>> I found some typos (missing commas) in test_basic.py
>>   
> 
> Ah, yes. This file has not real test yet, actually, it 
>should not be run
> :) I fixed the typo nonetheless,
> 
> thanks,
> 
> David
>
David,

the next problem is
  
python -i 
svn/talkbox/scikits/talkbox/spectral/tests/test_basic.py
Traceback (most recent call last):
   File 
"svn/talkbox/scikits/talkbox/spectral/tests/test_basic.py", 
line 5, in <module>
     from scikits.talkbox.spectrum.basic import specgram
ImportError: No module named spectrum.basic
  
Nils



From nwagner at iam.uni-stuttgart.de  Thu Sep 25 12:43:10 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 25 Sep 2008 18:43:10 +0200
Subject: [SciPy-dev] scipy 0.7
Message-ID: <web-111866459@uni-stuttgart.de>

Hi all,

Is there a chance that the patch "dae-1.patch" concerning 
DAE's

http://projects.scipy.org/scipy/scipy/ticket/730

will be applied to the trunk before the next release 0.7 ?

Nils


From kkwweett at hotmail.fr  Thu Sep 25 12:42:22 2008
From: kkwweett at hotmail.fr (Paul Langevin)
Date: Thu, 25 Sep 2008 18:42:22 +0200
Subject: [SciPy-dev] [delaunay] boundary specification
Message-ID: <BAY119-W42AD27E70D1E6B71DC6A95BA440@phx.gbl>


Hi,

Going on my investigation, I'm still wondering if it  will be possible to specify the desired boundary for the triangulated meshes  in order to design holes.

Thank you in advance.

P.S. Here's the advice Jeff Whitaker, from Matplotlib-users list, gave me about my post on this list :



Re: [Matplotlib-users] [delaunay] boundary specification?
De :     Jeff Whitaker (jswhit at fastmail.fm)
Envoy? :     jeu. 25/09/08 15:30
? :     Paul Langevin (kkwweett at hotmail.fr)
Cc :     matplotlib-users at lists.sourceforge.net

Paul Langevin wrote:
> Hi,
>
> I'm wondering if it is 
 
Paul: No, it's not.
> (or when will it be if not) possible to specify the desired boundary 
> for the triangulated meshes  in order to design holes which seems 
> impossible at the moment (the boundary seems to always  be the convex 
> hull of the set of points when using delaunay.Triangulation(x,y) ).
>
> Thanks.
 
The delaunay package is an external package (from scipy) that is 
included in matplotlib for convenience.  It's not maintained by the 
matplotlib developers.  I'd ask on the scipy list.
 
 
-Jeff
 
-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328
 



_________________________________________________________________
T?l?phonez gratuitement ? tous vos proches avec Windows Live Messenger? !? T?l?chargez-le maintenant !?
http://www.windowslive.fr/messenger/1.asp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080925/42df9ec4/attachment.html>

From robert.kern at gmail.com  Thu Sep 25 13:24:59 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 25 Sep 2008 12:24:59 -0500
Subject: [SciPy-dev] [delaunay] boundary specification
In-Reply-To: <BAY119-W42AD27E70D1E6B71DC6A95BA440@phx.gbl>
References: <BAY119-W42AD27E70D1E6B71DC6A95BA440@phx.gbl>
Message-ID: <3d375d730809251024x3a89191ge4dd7a1c2b43eaf1@mail.gmail.com>

On Thu, Sep 25, 2008 at 11:42, Paul Langevin <kkwweett at hotmail.fr> wrote:
> Hi,
>
> Going on my investigation, I'm still wondering if it  will be possible to
> specify the desired boundary for the triangulated meshes  in order to design
> holes.

No, it's a pure Delaunay triangulation. In order to handle specified
boundary edges, you would need a constrained Delaunay triangulation.

-- 
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


From fperez.net at gmail.com  Thu Sep 25 23:59:20 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 25 Sep 2008 20:59:20 -0700
Subject: [SciPy-dev] weave.inline broken by setuptools?
Message-ID: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>

Howdy,

for a scipy workshop I'm going to teach in a few weeks I made a little
checklist in  the form of a nose test suite:

https://cirl.berkeley.edu/fperez/py4science/workshop_checklist.py

I've started getting reports of failures from students using EPD, and
I was finally able to reproduce the problem.  Since I've been known to
launch into unjustified setuptools rants before, I'd like some
guidance from those wiser than me...

If you clean fully your weave cache:

rm -rf ~/.python25_compiled/

and then try running this:

maqroll[~]> cat wsbug.py
from scipy import weave
import setuptools

weave.inline('int x=1;x++;')
# EOF

maqroll[~]> python wsbug.py
<weave: compiling>
Traceback (most recent call last):
  File "wsbug.py", line 4, in <module>
    weave.inline('int x=1;x++;')
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/inline_tools.py",
line 333, in inline
    **kw)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/inline_tools.py",
line 459, in compile_function
    verbose=verbose, **kw)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/ext_tools.py",
line 365, in compile
    verbose = verbose, **kw)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/build_tools.py",
line 271, in build_extension
    setup(name = module_name, ext_modules = [ext],verbose=verb)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/numpy/distutils/core.py",
line 184, in setup
    return old_setup(**new_attr)
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 992, in run_command
    cmd_obj = self.get_command_obj(command)
  File "/usr/lib/python2.5/distutils/dist.py", line 869, in get_command_obj
    cmd_obj = self.command_obj[command] = klass(self)
  File "/usr/lib/python2.5/distutils/cmd.py", line 62, in __init__
    raise TypeError, "dist must be a Distribution instance"
TypeError: dist must be a Distribution instance


Doing it in ipython and debugging shows:

TypeError: dist must be a Distribution instance
WARNING: Failure executing file: <wsbug.py>

In [2]: %debug
> /usr/lib/python2.5/distutils/cmd.py(62)__init__()
     61         if not isinstance(dist, Distribution):
---> 62             raise TypeError, "dist must be a Distribution instance"
     63         if self.__class__ is Command:

ipdb> p dist
<numpy.distutils.numpy_distribution.NumpyDistribution instance at 0x90974ec>
ipdb> p Distribution
<class setuptools.dist.Distribution at 0x908b86c>

It seems that all the setuptools monkeypatching is trhrowing
weave/numpy.distutils for a loop.

Any advice?

Note that I found a workaround: importing setuptools *before* weave
makes the problem go away, so for now I have a solution for my
students.  But I think it would be good to know if this is a weave or
a setuptools problem.  It took a while to understand what was going
on, and fixing it might save others some time...

Thanks,

f


From robert.kern at gmail.com  Fri Sep 26 00:03:15 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 25 Sep 2008 23:03:15 -0500
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
Message-ID: <3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>

On Thu, Sep 25, 2008 at 22:59, Fernando Perez <fperez.net at gmail.com> wrote:
> Howdy,
>
> for a scipy workshop I'm going to teach in a few weeks I made a little
> checklist in  the form of a nose test suite:
>
> https://cirl.berkeley.edu/fperez/py4science/workshop_checklist.py
>
> I've started getting reports of failures from students using EPD, and
> I was finally able to reproduce the problem.  Since I've been known to
> launch into unjustified setuptools rants before, I'd like some
> guidance from those wiser than me...

> Note that I found a workaround: importing setuptools *before* weave
> makes the problem go away, so for now I have a solution for my
> students.  But I think it would be good to know if this is a weave or
> a setuptools problem.  It took a while to understand what was going
> on, and fixing it might save others some time...

It's not a workaround; it's just the correct thing to do. You must
always import setuptools before you import numpy.distutils.
numpy.distutils knows about setuptools, but setuptools doesn't know
about numpy.distutils, so the only way that the two get merged
correctly is by importing setuptools first so numpy.distutils knows to
merge the two.

-- 
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


From fperez.net at gmail.com  Fri Sep 26 00:25:48 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 25 Sep 2008 21:25:48 -0700
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
Message-ID: <db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>

Howdy,

On Thu, Sep 25, 2008 at 9:03 PM, Robert Kern <robert.kern at gmail.com> wrote:

> It's not a workaround; it's just the correct thing to do. You must
> always import setuptools before you import numpy.distutils.
> numpy.distutils knows about setuptools, but setuptools doesn't know
> about numpy.distutils, so the only way that the two get merged
> correctly is by importing setuptools first so numpy.distutils knows to
> merge the two.

Well, the problem is that I didn't even know that I was importing
numpy.distutils and that it had a non-commutative behavior with
setuptools.  I had test code that  checked for weave's presence and
for setuptools  and they happened to be in that order.  I could easily
see someone doing an

import scipy.weave

and then

import something.else # that unbeknownst to them, imports setuptools

and boom.  The weirdest bugs.  Especially hard because if they happen
to  be loading inlined code that had already been compiled before
setuptools showed up, it will get picked up off the module cache just
fine.  This is what happened to me: the bug only appeared on student's
computers, because as I built the test suite I got the cache primed,
and only later did I add the setuptools loading.

I wonder  if numpy.distutils couldn't do a

try: import setuptools
except ImportError: pass

since otherwise we basically get a ticking time bomb.  On the other
hand, I imagine this might have its own nasty problems, so perhaps
it's a dumb idea.

This level of hidden magic/side effects really does bother me a lot.
There may be not much we can do about it, so I guess I'll just keep on
rasing my alertness regarding setuptools.

Basically if your python installation starts behaving inexplicably,
chances are very, very good that the issue has something to do with
setuptools.  At least that's been my (by now very long running)
story....  Here's one hoping that the fork will eventually produce a
viable long-term solution to this horrid mess.

Thanks for the clarification!

Cheers,

f


From david at ar.media.kyoto-u.ac.jp  Fri Sep 26 00:16:37 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 26 Sep 2008 13:16:37 +0900
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
Message-ID: <48DC6225.5000602@ar.media.kyoto-u.ac.jp>

Fernando Perez wrote:
> I wonder  if numpy.distutils couldn't do a
>
> try: import setuptools
> except ImportError: pass
>
>   

Please, no. I don't want setuptools imported when I use/built scipy/numpy.

cheers,

David


From robert.kern at gmail.com  Fri Sep 26 00:34:45 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 25 Sep 2008 23:34:45 -0500
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
Message-ID: <3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>

On Thu, Sep 25, 2008 at 23:25, Fernando Perez <fperez.net at gmail.com> wrote:
> Howdy,
>
> On Thu, Sep 25, 2008 at 9:03 PM, Robert Kern <robert.kern at gmail.com> wrote:
>
>> It's not a workaround; it's just the correct thing to do. You must
>> always import setuptools before you import numpy.distutils.
>> numpy.distutils knows about setuptools, but setuptools doesn't know
>> about numpy.distutils, so the only way that the two get merged
>> correctly is by importing setuptools first so numpy.distutils knows to
>> merge the two.
>
> Well, the problem is that I didn't even know that I was importing
> numpy.distutils and that it had a non-commutative behavior with
> setuptools.  I had test code that  checked for weave's presence and
> for setuptools  and they happened to be in that order.  I could easily
> see someone doing an
>
> import scipy.weave
>
> and then
>
> import something.else # that unbeknownst to them, imports setuptools
>
> and boom.  The weirdest bugs.  Especially hard because if they happen
> to  be loading inlined code that had already been compiled before
> setuptools showed up, it will get picked up off the module cache just
> fine.  This is what happened to me: the bug only appeared on student's
> computers, because as I built the test suite I got the cache primed,
> and only later did I add the setuptools loading.
>
> I wonder  if numpy.distutils couldn't do a
>
> try: import setuptools
> except ImportError: pass
>
> since otherwise we basically get a ticking time bomb.  On the other
> hand, I imagine this might have its own nasty problems, so perhaps
> it's a dumb idea.

You personally asked us not to do that. That meant that you would
always be using setuptools to install numpy just because you had it on
your system rather than because you chose to use it to install numpy.

The appropriate fix is to document that weave uses numpy.distutils and
that if one is going to use both setuptools and numpy.distutils that
setuptools must be imported first. I believe you have commit access.

> This level of hidden magic/side effects really does bother me a lot.
> There may be not much we can do about it, so I guess I'll just keep on
> rasing my alertness regarding setuptools.
>
> Basically if your python installation starts behaving inexplicably,
> chances are very, very good that the issue has something to do with
> setuptools.

<shrug> It equally has something to do with numpy.distutils.

> At least that's been my (by now very long running)
> story....  Here's one hoping that the fork will eventually produce a
> viable long-term solution to this horrid mess.

Nope. This is intrinsic to the design of distutils. The only way to
extend the commands is to subclass. Multiple extensions at the same
time need to be merged manually. If they are implemented without
knowledge of the other, it doesn't matter how good or careful the
authors of each are. In fact, the fork just made things a little
worse. Now we have to check for both distribute and setuptools.

-- 
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


From fperez.net at gmail.com  Fri Sep 26 00:47:51 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 25 Sep 2008 21:47:51 -0700
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
	<3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>
Message-ID: <db6b5ecc0809252147l697b3e77r6382af9fdc652df6@mail.gmail.com>

On Thu, Sep 25, 2008 at 9:34 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> since otherwise we basically get a ticking time bomb.  On the other
>> hand, I imagine this might have its own nasty problems, so perhaps
>> it's a dumb idea.
>
> You personally asked us not to do that. That meant that you would
> always be using setuptools to install numpy just because you had it on
> your system rather than because you chose to use it to install numpy.

Hence the 'dumb idea' note, I kind of knew that :)  I know I've been
one of the most vocal complainers about hidden setuptools imports...
But I'm wondering if there couldn't be a clean solution to this at
least in the new forked setuptools: if setuptools is so dangerous to
pull in once distutils has been loaded, perhaps it  could check that
it's always the first to do the distutils import?  Something like

if 'distutils' in sys.modules:
  raise ImportError("setuptools can't be imported *after* distutils
has already been loaded.  Please move it earlier in your import
chain.")

This would at least force you to know that you need to pull setuptools
 in early in your code if you have distutils-using code anywhere (even
implicitly, like via weave).

Dumb idea too? (likely...)

> The appropriate fix is to document that weave uses numpy.distutils and
> that if one is going to use both setuptools and numpy.distutils that
> setuptools must be imported first. I believe you have commit access.

Yup, I'll try to add a note to that effect.  I can still see this
biting some unsuspecting soul, even if it's documented.  It's a very,
very easy trap to fall into.

>> At least that's been my (by now very long running)
>> story....  Here's one hoping that the fork will eventually produce a
>> viable long-term solution to this horrid mess.
>
> Nope. This is intrinsic to the design of distutils. The only way to
> extend the commands is to subclass. Multiple extensions at the same
> time need to be merged manually. If they are implemented without
> knowledge of the other, it doesn't matter how good or careful the
> authors of each are. In fact, the fork just made things a little
> worse. Now we have to check for both distribute and setuptools.

Worse for now, but I dream it will kickstart activity for a proper
long-term solution,  even if that means that someone bites the bullet
of fixing distutils.  I know that's a crazy long shot, but you never
know.  There *has* to be a better long-term solution to this problem
in Python...

Cheers,

f


From robert.kern at gmail.com  Fri Sep 26 00:57:24 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 25 Sep 2008 23:57:24 -0500
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <db6b5ecc0809252147l697b3e77r6382af9fdc652df6@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
	<3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>
	<db6b5ecc0809252147l697b3e77r6382af9fdc652df6@mail.gmail.com>
Message-ID: <3d375d730809252157q465803b2lfb3974e087fb83cd@mail.gmail.com>

On Thu, Sep 25, 2008 at 23:47, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, Sep 25, 2008 at 9:34 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>> since otherwise we basically get a ticking time bomb.  On the other
>>> hand, I imagine this might have its own nasty problems, so perhaps
>>> it's a dumb idea.
>>
>> You personally asked us not to do that. That meant that you would
>> always be using setuptools to install numpy just because you had it on
>> your system rather than because you chose to use it to install numpy.
>
> Hence the 'dumb idea' note, I kind of knew that :)  I know I've been
> one of the most vocal complainers about hidden setuptools imports...
> But I'm wondering if there couldn't be a clean solution to this at
> least in the new forked setuptools: if setuptools is so dangerous to
> pull in once distutils has been loaded,

*bzzrt!* No. That's not the problem. It's dangerous to pull in
setuptools after *numpy.distutils*. It's the particular combination of
those two that needs to be managed carefully. Importing distutils
before setuptools is harmless.

> perhaps it  could check that
> it's always the first to do the distutils import?  Something like
>
> if 'distutils' in sys.modules:
>  raise ImportError("setuptools can't be imported *after* distutils
> has already been loaded.  Please move it earlier in your import
> chain.")
>
> This would at least force you to know that you need to pull setuptools
>  in early in your code if you have distutils-using code anywhere (even
> implicitly, like via weave).
>
> Dumb idea too? (likely...)

Probably. One could equally make the same case for any extension to
distutils, like numpy.distutils. If they all raised such an error,
*none* of them could be combined with each other.

-- 
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


From fperez.net at gmail.com  Fri Sep 26 01:04:09 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 25 Sep 2008 22:04:09 -0700
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <3d375d730809252157q465803b2lfb3974e087fb83cd@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
	<3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>
	<db6b5ecc0809252147l697b3e77r6382af9fdc652df6@mail.gmail.com>
	<3d375d730809252157q465803b2lfb3974e087fb83cd@mail.gmail.com>
Message-ID: <db6b5ecc0809252204i113c11f5n9b0cedf3e36d1fb0@mail.gmail.com>

Hey,

On Thu, Sep 25, 2008 at 9:57 PM, Robert Kern <robert.kern at gmail.com> wrote:

> *bzzrt!* No. That's not the problem. It's dangerous to pull in
> setuptools after *numpy.distutils*. It's the particular combination of
> those two that needs to be managed carefully.

Ok, thanks a lot for the clarifications.  At least I understand the
problem a bit better now.  But I'm going to light up a candle to the
coding gods so that someone finds a cleaner long-term solution.  This
really should *not* be that hard, we should not have to tiptoe around
toxic cross-module interactions like this, knowing all these details.

Oh well, I'll crawl back into my hole.

Thanks again for the info, it does truly help.

Cheers,

f


From david at ar.media.kyoto-u.ac.jp  Fri Sep 26 01:02:45 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 26 Sep 2008 14:02:45 +0900
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <db6b5ecc0809252204i113c11f5n9b0cedf3e36d1fb0@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>	<3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>	<db6b5ecc0809252147l697b3e77r6382af9fdc652df6@mail.gmail.com>	<3d375d730809252157q465803b2lfb3974e087fb83cd@mail.gmail.com>
	<db6b5ecc0809252204i113c11f5n9b0cedf3e36d1fb0@mail.gmail.com>
Message-ID: <48DC6CF5.7040909@ar.media.kyoto-u.ac.jp>

Fernando Perez wrote:
> Hey,
>
> On Thu, Sep 25, 2008 at 9:57 PM, Robert Kern <robert.kern at gmail.com> wrote:
>
>> *bzzrt!* No. That's not the problem. It's dangerous to pull in
>> setuptools after *numpy.distutils*. It's the particular combination of
>> those two that needs to be managed carefully.
>
> Ok, thanks a lot for the clarifications.  At least I understand the
> problem a bit better now.  But I'm going to light up a candle to the
> coding gods so that someone finds a cleaner long-term solution.  This
> really should *not* be that hard

Any half-decent python programmer could build something with a design
which is much better than distutils (as a proof, there is at least 4-5
projects which do precisely that in python, like scons, vellum, paver,
waf to name the ones still in existence and maintained today). The
problem is how to deal with the corner cases, and with existing
packages, as mentioned by Guido about the distribute fork.

I note that the open source community at large is stucked with an
arguably worse tool, the autotools suite, for something like 20 years
now. Distribution tools are very difficult to engineer right and being
useful in a lot of projects at the same time. The devil really is in the
details; this is even more true for build tools than for most softwares
I think,

cheers,

David



From millman at berkeley.edu  Fri Sep 26 02:08:11 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Thu, 25 Sep 2008 23:08:11 -0700
Subject: [SciPy-dev] ANN: NumPy 1.2.0
Message-ID: <c7009a550809252308n190872e2l642519073ac121d4@mail.gmail.com>

I'm pleased to announce the release of NumPy 1.2.0.

NumPy is the fundamental package needed for scientific computing with
Python.  It contains:

 * a powerful N-dimensional array object
 * sophisticated (broadcasting) functions
 * basic linear algebra functions
 * basic Fourier transforms
 * sophisticated random number capabilities
 * tools for integrating Fortran code.

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.

This minor release comes almost four months after the 1.1.0
release. The major features of this release are a new
testing framework and huge amount of documentation work. It
also includes a some minor API breakage scheduled in the
1.1 release.

Please note that NumPy 1.2.0 requires Python 2.4 or greater.

For information, please see the release notes:
http://sourceforge.net/project/shownotes.php?group_id=1369&release_id=628858

You can download the release from here:
http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103

Thank you to everybody who contributed to this release.

Enjoy,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From david at ar.media.kyoto-u.ac.jp  Fri Sep 26 03:29:37 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 26 Sep 2008 16:29:37 +0900
Subject: [SciPy-dev] VS revamp: it runs
Message-ID: <48DC8F61.2040805@ar.media.kyoto-u.ac.jp>

Hi,

    I finally took the time to finish basic support of new VS versions
(8 and 9). At this point, I believe it can be merged into the trunk, to
solve remaining problems. From a user POV, this should be transparent: I
use the new support in msvc.py (I did not remove all the magic code in
there, but I don't use it; can it be removed ?). So:

env = Environment()
env.Program('hello.c')

Should work if you have Visual Studio installed (tested with 8 and 9,
express versions). You can set the version used by using MSVS_VERSION as
before, this works as expected.

Detailed comments
=================

    - New code to find Visual Studio properties is < 200 lines. This is
the most important point IMHO, because it means normal people like me
can finally understand what's going on instead of hundred of lines of
registry magic only a MS guru would know about.
    - Should support 7.1, and maybe 6.0 (I don't have easy access to
7.1, and no access at all to 6.0). This needs testing.
    - Does not support cross compilation yet, but this should be doable
without too much hassle. Someone more familiar with MS platforms should
do it IMO, because I don't know what's expected there. AFAIU, it is just
a matter of finding a different .bat file, everything else would be the
same. I don't know if this can be ready for 1.1.
    - Does not automatically support manifest. This is a new MS feature
which is awfully complicated and not well documented if at all, and will
be hard to support in a clean, proper way. I think at this point (1.1),
it is outside the scope of this work. People will have to deal with MS
crap manually (more importantly for me, this also means we can't help
people using mingw for this, unfortunately).

There was discussion about making some function to get the internals
(MergeBatFile, etc...); I did implement the functions as asked, but
believe it should not be made public for 1.1. There are some things
which are not quite right (how to handle errors, for example); the
internal API simply is not ready to be published. But because it brings
support for VS 8 and 9, and does not impact scons scripts users/writers
as long as they stay with the published API, I think the support itself
should be there.

thanks to people who helped this: Gary Oberbrunner for updated
PrependENVPath, Matthieu Brucher and Kenny Jason L for windows
expertise, and of course G. Noel and Steve Knight for scons knowledge.
This would not have happened without their help,

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Fri Sep 26 03:31:39 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 26 Sep 2008 16:31:39 +0900
Subject: [SciPy-dev] VS revamp: it runs
In-Reply-To: <48DC8F61.2040805@ar.media.kyoto-u.ac.jp>
References: <48DC8F61.2040805@ar.media.kyoto-u.ac.jp>
Message-ID: <48DC8FDB.2060001@ar.media.kyoto-u.ac.jp>

David Cournapeau wrote:
> Hi,
>
>     I finally took the time to finish basic support of new VS versions
> (8 and 9). At this point, I believe it can be merged into the trunk, to
> solve remaining problems. From a user POV, this should be transparent: I
> use the new support in msvc.py (I did not remove all the magic code in
> there, but I don't use it; can it be removed ?). So:
>   

Grr, sorry, wrong ML. Sorry for the noise,

David


From fperez.net at gmail.com  Fri Sep 26 04:38:21 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 26 Sep 2008 01:38:21 -0700
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
	<3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>
Message-ID: <db6b5ecc0809260138m412bd161y1b3499fa74bd452@mail.gmail.com>

On Thu, Sep 25, 2008 at 9:34 PM, Robert Kern <robert.kern at gmail.com> wrote:

> Nope. This is intrinsic to the design of distutils. The only way to
> extend the commands is to subclass. Multiple extensions at the same
> time need to be merged manually. If they are implemented without
> knowledge of the other, it doesn't matter how good or careful the
> authors of each are. In fact, the fork just made things a little
> worse. Now we have to check for both distribute and setuptools.

Actually I do have a question here.  Isn't the problem with the
non-commutativity of

import setuptools
import numpy.distutils

that setuptools monkeypatches python's plain distutils?  The error I
originally gave was because an isinstance() check failed due to
setuptools having overwritten a distutils class by monkeypatching:

In [1]: import distutils.dist

In [2]: id(distutils.dist.Distribution)
Out[2]: 147586284

In [3]: import setuptools

In [4]: id(distutils.dist.Distribution)
Out[4]: 148038444

If setuptools didn't monkeypatch distutils itself but only subclassed
things, then different extensions would still have normal inheritance
diagrams and wouldn't confuse isinstance() checks, no?

It may well be that there are reasons why setuptools can't avoid to
monkeypatch, I don't know.  But it seems to me that this particular
issue stems from the monkeypatching and  not because of subclassing.
Am I missing something?

Cheers,

f


From david at ar.media.kyoto-u.ac.jp  Fri Sep 26 04:37:27 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 26 Sep 2008 17:37:27 +0900
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <db6b5ecc0809260138m412bd161y1b3499fa74bd452@mail.gmail.com>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>	<3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>
	<db6b5ecc0809260138m412bd161y1b3499fa74bd452@mail.gmail.com>
Message-ID: <48DC9F47.5050804@ar.media.kyoto-u.ac.jp>

Fernando Perez wrote:
>
> It may well be that there are reasons why setuptools can't avoid to
> monkeypatch, I don't know.  But it seems to me that this particular
> issue stems from the monkeypatching and  not because of subclassing.

Yes, it is because of monkeypatching, but setuptools needs to monkey
patch Distribution to handle some things with eggs at least (and
possibly other things which I am not aware of).

There are also things which are not monkey-patch per se, but are related
to mungling with sys.path, although it is not involved in the precise
case you are showing (but explain a lot of breakings of setuptools, at
least in my own experience).

Robert is right: most of setuptools ugliness comes from distutils (and
lack of proper features from python itself). Not only is it difficult to
extend distutils by design, but it is also difficult to reuse parts of
it on your own extensions (because there are long functions with data
embedded in the code; see for example msvccompiler for some fun). That's
the whole problem: the only way to be clean is to avoid distutils, but
avoiding distutils means nobody will use the tool.

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Fri Sep 26 04:41:01 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 26 Sep 2008 17:41:01 +0900
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <48DC9F47.5050804@ar.media.kyoto-u.ac.jp>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>	<3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>	<db6b5ecc0809260138m412bd161y1b3499fa74bd452@mail.gmail.com>
	<48DC9F47.5050804@ar.media.kyoto-u.ac.jp>
Message-ID: <48DCA01D.2070100@ar.media.kyoto-u.ac.jp>

David Cournapeau wrote:
> Fernando Perez wrote:
>   
>> It may well be that there are reasons why setuptools can't avoid to
>> monkeypatch, I don't know.  But it seems to me that this particular
>> issue stems from the monkeypatching and  not because of subclassing.
>>     
>
>   

http://www.mailinglistarchive.com/python-dev at python.org/msg04693.html

For more information why setuptools does monkey patching (in your case
and a few others) from the man himself :)

cheers,

David


From fperez.net at gmail.com  Fri Sep 26 05:01:32 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 26 Sep 2008 02:01:32 -0700
Subject: [SciPy-dev] weave.inline broken by setuptools?
In-Reply-To: <48DC9F47.5050804@ar.media.kyoto-u.ac.jp>
References: <db6b5ecc0809252059y660789fs9ceda962518b1448@mail.gmail.com>
	<3d375d730809252103i134d41f7vf891a137b90164a6@mail.gmail.com>
	<db6b5ecc0809252125l37b0130bq19aa57d01cb1c2f4@mail.gmail.com>
	<3d375d730809252134w523c1884v313ae34ee36e1765@mail.gmail.com>
	<db6b5ecc0809260138m412bd161y1b3499fa74bd452@mail.gmail.com>
	<48DC9F47.5050804@ar.media.kyoto-u.ac.jp>
Message-ID: <db6b5ecc0809260201n73de8e3cl571956339741e44b@mail.gmail.com>

On Fri, Sep 26, 2008 at 1:37 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Fernando Perez wrote:
>>
>> It may well be that there are reasons why setuptools can't avoid to
>> monkeypatch, I don't know.  But it seems to me that this particular
>> issue stems from the monkeypatching and  not because of subclassing.
>
> Yes, it is because of monkeypatching, but setuptools needs to monkey
> patch Distribution to handle some things with eggs at least (and
> possibly other things which I am not aware of).

Thanks for the info, that was my impression.

> There are also things which are not monkey-patch per se, but are related
> to mungling with sys.path, although it is not involved in the precise
> case you are showing (but explain a lot of breakings of setuptools, at
> least in my own experience).

Oh yes, I've seen my share of those.  Now I clean up the .pth files
very often to try to keep these gremlins under control :)

> Robert is right: most of setuptools ugliness comes from distutils (and
> lack of proper features from python itself). Not only is it difficult to
> extend distutils by design, but it is also difficult to reuse parts of
> it on your own extensions (because there are long functions with data
> embedded in the code; see for example msvccompiler for some fun). That's
> the whole problem: the only way to be clean is to avoid distutils, but
> avoiding distutils means nobody will use the tool.

I know this is an unfortunately very nasty problem.  I have dug into
the tar pit that is distutils in the past, and I know exactly what you
mean.  It's impossible to follow how and when data and state change,
since many methods just modify things on the fly without ever
indicating what they're doing (flags, variables, etc).  I've since
given up on fighting much on this front, since braver souls than me
showed up (i.e., you :)

Cheers,

f


From dave.hirschfeld at gmail.com  Fri Sep 26 05:58:48 2008
From: dave.hirschfeld at gmail.com (Dave)
Date: Fri, 26 Sep 2008 09:58:48 +0000 (UTC)
Subject: [SciPy-dev] Error in timeseries Date class
Message-ID: <loom.20080926T095643-117@post.gmane.org>

It appears that the strftime function as applied to the timeseries Date class
gives incorrect results for the day of week c.f.

In [1]: import scikits.timeseries as ts

In [2]: from datetime import datetime

In [3]: ts.Date('D', datetime=datetime.now()).strftime('%a %d-%b-%Y')
Out[3]: 'Thu 26-Sep-2008'

-Dave



From dpeterson at enthought.com  Sat Sep 27 02:09:40 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Sat, 27 Sep 2008 01:09:40 -0500
Subject: [SciPy-dev] ANNOUNCE: EPD (Enthought Python Distribution) 4.0.300
	Beta 3 available
Message-ID: <48DDCE24.3040103@enthought.com>

Hello,

We've recently posted the third beta release of EPD (the Enthought
Python Distribution) with Python 2.5 version 4.0.300.  You may download
the beta from here:

	http://www.enthought.com/products/epdbeta.php

Please help us test it out and provide feedback on the EPD Trac
instance: https://svn.enthought.com/epd  You can check out the release
notes here: http://www.enthought.com/products/epdbetareleasenotes.php


About EPD
---------
The Enthought Python Distribution (EPD) is a "kitchen-sink-included"
distribution of the Python? Programming Language, including over 60
additional tools and libraries. The EPD bundle includes NumPy, SciPy,
IPython, 2D and 3D visualization, database adapters, and a lot of
other tools right out of the box.

	http://www.enthought.com/products/epd.php

It is currently available as a single-click installer for Windows XP
(x86), Mac OS X (a universal binary for OS X 10.4 and above), and
RedHat 3 and 4 (x86 and amd64).

EPD is free for academic use.  An annual subscription and installation
support are available for individual commercial use.  An enterprise
subscription with support for particular deployment environments is also
available for commercial purchase.  The beta versions of EPD are
available for indefinite free trial.


-- Dave





From nwagner at iam.uni-stuttgart.de  Sat Sep 27 12:14:09 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 27 Sep 2008 18:14:09 +0200
Subject: [SciPy-dev] Next scipy release 0.7
Message-ID: <web-111958955@uni-stuttgart.de>

Hi Jarrod,

Just curious. Is there a new deadline for scipy 0.7 ?

Cheers,

            Nils


From mattknox.ca at gmail.com  Sat Sep 27 16:05:50 2008
From: mattknox.ca at gmail.com (Matt Knox)
Date: Sat, 27 Sep 2008 20:05:50 +0000 (UTC)
Subject: [SciPy-dev] Error in timeseries Date class
References: <loom.20080926T095643-117@post.gmane.org>
Message-ID: <loom.20080927T200447-863@post.gmane.org>

> It appears that the strftime function as applied to the timeseries Date class
> gives incorrect results for the day of week c.f.
> 
> In [1]: import scikits.timeseries as ts
> 
> In [2]: from datetime import datetime
> 
> In [3]: ts.Date('D', datetime=datetime.now()).strftime('%a %d-%b-%Y')
> Out[3]: 'Thu 26-Sep-2008'
> 
> -Dave
> 

Hi Dave. This should be fixed in the latest revision now. Thanks for the bug
report.

- Matt




From ondrej at certik.cz  Mon Sep 29 03:39:33 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 29 Sep 2008 09:39:33 +0200
Subject: [SciPy-dev] Next scipy release 0.7
In-Reply-To: <web-111958955@uni-stuttgart.de>
References: <web-111958955@uni-stuttgart.de>
Message-ID: <85b5c3130809290039t3b3c6680t82eca2e5b053ed3a@mail.gmail.com>

On Sat, Sep 27, 2008 at 6:14 PM, Nils Wagner
<nwagner at iam.uni-stuttgart.de> wrote:
> Hi Jarrod,
>
> Just curious. Is there a new deadline for scipy 0.7 ?

Curious about this too. :)

Ondrej


From josef.pktd at gmail.com  Mon Sep 29 08:51:27 2008
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 29 Sep 2008 08:51:27 -0400
Subject: [SciPy-dev] Fwd: tests and partial patch for
	scipy.stats.distributions
In-Reply-To: <1cd32cbb0809282100x75eccfb9la109e92032f798ac@mail.gmail.com>
References: <1cd32cbb0809282100x75eccfb9la109e92032f798ac@mail.gmail.com>
Message-ID: <1cd32cbb0809290551g7c00a5ddh44369352ece506d2@mail.gmail.com>

removed patch because of file size, mail bounced

---------- Forwarded message ----------
From: josef.pktd at gmail.com
Date: Mon, 29 Sep 2008 00:00:25 -0400
Subject: tests and partial patch for scipy.stats.distributions
To: scipy-dev at scipy.org

To help in bug hunting and patching of the discrete distribution in
scipy.stats, I wrote several test scripts that could be incorporated
in scipy tests. The attachment contains the corrected
scipy.stats.distributions.py file and 2 test files.

The tests check all discrete distributions at predefined (not randomly
chosen) values. Some distributions have some wrong results for some
other range of parameters.

To try out the patch, it is possible just to backup the current
scipy.stats.distributions.py
and copy the patched version in its place.

Right now, I still left many comments (and some commented out failed
attempts for fixing some persistent bugs). In direct comparison with
the current trunk file this might help in understanding what the
underlying bug is.

Since there are a large number of bug fixes in this patch, if any of
them get incorporated in scipy, then they can be selectively copied.
Many bugs only show up once other bugs are fixed.

In terms of importance and sequence the bug fix categories are roughly:

* nin correction for vectorize with *args: without this, some methods
raise exceptions, e.g. _ppf (I think after many shaky attempts, I
found the correct solution)
* _ppf did not handle infinite support properly and requires a .tolist
in call to ``place`` (no idea why, but this works)
* _drv2_moment(self, n, *args) was completely broken, it didn't even
have a return and is the base for generic moment calculations

individual fixes:
* recipinvgauss_gen: rvs added, didn't work before
* def moment: for 2nd moment returned the mean (both discrete and
continuous distribution
* randint: -1 missing in _ppf, definitions differs from those in description pdf
* dlaplace: _ppf gives wrong results in tests, replace with generic calculation

(Note: the first vectorize nin correction in continuous distributions
is still at the wrong spot. I was only looking at discrete
distributions in the last few days, since I figured out how vectorize
nin works)

If you want a cleaner patch or more information, I can provide it next
week. Because, I never used numpy/scipy heavily, it took me a long
time to figure out what is going on, but it should be more obvious to
an expert. But overall my impression is, that using features in
numpy.stats.distribution, that are not commonly used, is pretty risky,
and until recently didn't have any stringent tests and does not have
any reasonably large test coverage. For serious work, I would want to
make sure that the results are actually correct.

There are still several things that are not covered, e.g. handling of
loc and scale, other methods, correctness over full range of
parameters. I haven't checked the continuous distributions since the
initial fuzz tests, but the test coverage for all methods looks pretty
low.

Josef

Test f Basic Properties
----------------------

The first test just tests for basic properties and their consistency,
e.g. cdf, pmf, ppf, stats and moments and the internal methods e.g
_ppf. The tests check quite a bit for internal consistency (private
methods) since I used the tests for debugging and trying out fixes.


>python C:\Programs\Python25\Scripts\nosetests-script.py  -s test_discrete_basic.py
...

with current trunk, I get for this test:

Ran 112 tests in 0.140s
FAILED (errors=41, failures=15)


after the bugfixes, I get:

Ran 112 tests in 8.672s
FAILED (failures=5)

some failures in binom, dlaplace, zipf are still remaining

Chisquare Test
--------------

the second test is a chisquare test for the random variables to be
close to the theoretical distribution as defined by .cdf

with current trunk I get for this test:

>python C:\Programs\Python25\Scripts\nosetests-script.py  -s test_ndiscrete.py

Ran 12 tests in 0.453s
FAILED (errors=5)

after patching scipy.stats.distribution the only test failure left is
in logser, where I think the numpy.random random numbers are wrong

>python C:\Programs\Python25\Scripts\nosetests-script.py  -s test_ndiscrete.py

bernoulli. binom. boltzmann. dlaplace. geom. hypergeom. logserF nbinom. planck.
poisson. randint. zipf.
======================================================================
FAIL: test_ndiscrete.test_discrete_rvscdf('logser', (0.59999999999999998,))
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.10.3-py2.5.egg\nose\case.p
y", line 182, in runTest
    self.test(*self.arg)
  File "C:\Josef\work-oth\sort\pypi\test_ndiscrete.py", line 76, in checkchisqua
re_discrete
    assert (pval > alpha), 'chisquare - test for %s at arg = %s' % (distname,str
(arg))
AssertionError: chisquare - test for logser at arg = (0.59999999999999998,)

----------------------------------------------------------------------
Ran 12 tests in 19.781s

FAILED (failures=1)


scipy.stats tests: no failures
-----------------------------------------

running the current trunk test for scipy.stats on the pre- and post
patch distributions.py gives no errors:

>>> from scipy import stats
>>> stats.test()
Running unit tests for scipy.stats
NumPy version 1.2.0rc2
NumPy is installed in C:\Programs\Python25\lib\site-packages\numpy
SciPy version 0.7.0.dev
SciPy is installed in C:\Josef\_progs\virtualpy25\envscipy\lib\site-packages\sci
py
Python version 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Int
el)]
nose version 0.10.3
................................................................................
C:\Josef\_progs\virtualpy25\envscipy\lib\site-packages\scipy\stats\morestats.py:
618: UserWarning: Ties preclude use of exact statistic.
  warnings.warn("Ties preclude use of exact statistic.")
............................................................C:\Programs\Python25
\lib\site-packages\numpy\lib\function_base.py:343: Warning:
            The semantics of histogram has been modified in
            the current release to fix long-standing issues with
            outliers handling. The main changes concern
            1. the definition of the bin edges,
               now including the rightmost edge, and
            2. the handling of upper outliers, now ignored rather
               than tallied in the rightmost bin.
            The previous behaviour is still accessible using
            `new=False`, but is scheduled to be deprecated in the
            next release (1.3).

            *This warning will not printed in the 1.3 release.*

            Use `new=True` to bypass this warning.

            Please read the docstring for more information.

  """, Warning)
................................................................................
.............
----------------------------------------------------------------------
Ran 233 tests in 2.266s

OK
<nose.result.TextTestResult run=233 errors=0 failures=0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_discrete_basic.py
Type: text/x-python
Size: 4568 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080929/7d56cff8/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_ndiscrete.py
Type: text/x-python
Size: 3252 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080929/7d56cff8/attachment-0001.py>

From josef.pktd at gmail.com  Mon Sep 29 10:49:45 2008
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 29 Sep 2008 10:49:45 -0400
Subject: [SciPy-dev] tests and partial patch for
	scipy.stats.distributions
In-Reply-To: <1cd32cbb0809290741y18d75695xdea21ba284c9e854@mail.gmail.com>
References: <1cd32cbb0809282100x75eccfb9la109e92032f798ac@mail.gmail.com>
	<1cd32cbb0809290551g7c00a5ddh44369352ece506d2@mail.gmail.com>
	<1cd32cbb0809290737t31d0d4adk3462064987a3bea9@mail.gmail.com>
	<1cd32cbb0809290741y18d75695xdea21ba284c9e854@mail.gmail.com>
Message-ID: <1cd32cbb0809290749o5b4e2eccq67114222779a6586@mail.gmail.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: distributions.py.bz2
Type: application/x-bzip2
Size: 28120 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080929/5a0ee990/attachment.bin>

From josef.pktd at gmail.com  Mon Sep 29 10:55:17 2008
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 29 Sep 2008 10:55:17 -0400
Subject: [SciPy-dev] tests and partial patch for
	scipy.stats.distributions
In-Reply-To: <1cd32cbb0809290749o5b4e2eccq67114222779a6586@mail.gmail.com>
References: <1cd32cbb0809282100x75eccfb9la109e92032f798ac@mail.gmail.com>
	<1cd32cbb0809290551g7c00a5ddh44369352ece506d2@mail.gmail.com>
	<1cd32cbb0809290737t31d0d4adk3462064987a3bea9@mail.gmail.com>
	<1cd32cbb0809290741y18d75695xdea21ba284c9e854@mail.gmail.com>
	<1cd32cbb0809290749o5b4e2eccq67114222779a6586@mail.gmail.com>
Message-ID: <1cd32cbb0809290755i68b75f63s618dcf8387f9d7a3@mail.gmail.com>

On 9/29/08, josef.pktd at gmail.com <josef.pktd at gmail.com> wrote:
>
>
This is my corrected version of scipy.stats.distribution.py  (with my
mess mostly cleaned up), heavily compressed (using 7zip) to avoid
being bounced again.

Josef


From josef.pktd at gmail.com  Mon Sep 29 11:52:58 2008
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 29 Sep 2008 11:52:58 -0400
Subject: [SciPy-dev] tests and partial patch for
	scipy.stats.distributions
In-Reply-To: <1cd32cbb0809290755i68b75f63s618dcf8387f9d7a3@mail.gmail.com>
References: <1cd32cbb0809282100x75eccfb9la109e92032f798ac@mail.gmail.com>
	<1cd32cbb0809290551g7c00a5ddh44369352ece506d2@mail.gmail.com>
	<1cd32cbb0809290737t31d0d4adk3462064987a3bea9@mail.gmail.com>
	<1cd32cbb0809290741y18d75695xdea21ba284c9e854@mail.gmail.com>
	<1cd32cbb0809290749o5b4e2eccq67114222779a6586@mail.gmail.com>
	<1cd32cbb0809290755i68b75f63s618dcf8387f9d7a3@mail.gmail.com>
Message-ID: <1cd32cbb0809290852n68e0eca6v4a5bd747cb01cedc@mail.gmail.com>

I just saw that there were 2 change sets in
scipy.stats.distributions.py since I installed the trunk version from
2008-09-25  revision 4741.
After merging these 2 changes into my version of distributions.py I
still get the same test results as before.

Josef


From millman at berkeley.edu  Mon Sep 29 12:55:58 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Mon, 29 Sep 2008 09:55:58 -0700
Subject: [SciPy-dev] Next scipy release 0.7
In-Reply-To: <web-111958955@uni-stuttgart.de>
References: <web-111958955@uni-stuttgart.de>
Message-ID: <c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>

On Sat, Sep 27, 2008 at 9:14 AM, Nils Wagner
<nwagner at iam.uni-stuttgart.de> wrote:
> Just curious. Is there a new deadline for scipy 0.7 ?

I just haven't had any free time.  My plan at this point is to release
an alpha first with binaries.  Since the trunk has had so many
changes, I would like to see more testing before releasing a beta.

If anyone has time and interest in helping, it would make a huge
difference in getting this release out.  If someone could hunt down
the and fix the test failures and clean up all the deprecation
warnings, we would be much closer to getting this release out the
door.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From david at ar.media.kyoto-u.ac.jp  Mon Sep 29 22:52:32 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 30 Sep 2008 11:52:32 +0900
Subject: [SciPy-dev] Next scipy release 0.7
In-Reply-To: <c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>
References: <web-111958955@uni-stuttgart.de>
	<c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>
Message-ID: <48E19470.8030509@ar.media.kyoto-u.ac.jp>

Jarrod Millman wrote:
>
> I just haven't had any free time.  My plan at this point is to release
> an alpha first with binaries.  Since the trunk has had so many
> changes, I would like to see more testing before releasing a beta.
>

Before an alpha, there are several things which I consider a blocker for
a release and would like to fix (and seeing fixed):
   
    - http://projects.scipy.org/scipy/scipy/ticket/244 -> fft gives
wrong results with some axes parameters
    - http://projects.scipy.org/scipy/scipy/ticket/691 -> valgrind warnings
    - http://projects.scipy.org/scipy/scipy/ticket/688 -> fftpack revamp
    - http://projects.scipy.org/scipy/scipy/ticket/725 -> arpack
crashes/gives wrong result on Mac OS X

For windows binaries: taking the same approach as for numpy would work,
but would give a big installer (~40 Mb). I don't see any other approach,
except just linking with netlib (having a net installer sounds like a
support nightmare with all the proxy, firewall, etc...)

cheers,

David


From peridot.faceted at gmail.com  Mon Sep 29 23:24:01 2008
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Mon, 29 Sep 2008 23:24:01 -0400
Subject: [SciPy-dev] Proposal: scipy.spatial
Message-ID: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>

Hi,

Once again there has been a thread on the numpy/scipy mailing lists
requesting (essentially) some form of spatial data structure. Pointers
have been posted to ANN (sadly LGPLed and in C++) as well as a handful
of pure-python implementations of kd-trees. I suggest the creation of
a new submodule of scipy, scipy.spatial, to contain spatial data
structures and algorithms. Specifically, I propose it contain a
kd-tree implementation providing nearest-neighbor, approximate
nearest-neighbor, and all-points-near queries. I have a few other
suggestions for things it might contain, but kd-trees seem like a good
first step.

2008/9/27 Nathan Bell <wnbell at gmail.com>:
> On Sat, Sep 27, 2008 at 11:18 PM, Anne Archibald
> <peridot.faceted at gmail.com> wrote:
>>
>> I think a kd-tree implementation would be a valuable addition to
>> scipy, perhaps in a submodule scipy.spatial that might eventually
>> contain other spatial data structures and algorithms. What do you
>> think? Should we have one? Should it be based on Sturla Molden's code,
>> if the license permits? I am willing to contribute one, if not.
>
> +1

Judging that your vote and mine are enough in the absence of
dissenting voices, I have written an implementation based on yours,
Sturla Molden's, and the algorithms described by the authors of the
ANN library. Before integrating it into scipy, though, I'd like to
send it around for comments.

Particular issues:

* It's pure python right now, but with some effort it could be
partially or completely cythonized. This is probably a good idea in
the long run. In the meantime I have crudely vectorized it so that
users can at least avoid looping in their own code.
* It is able to return the r nearest neighbors, optionally subject to
a maximum distance limit, as well as approximate nearest neighbors.
* It is not currently set up to conveniently return all points within
some fixed distance of the target point, but this could easily be
added.
* It returns distances and indices of nearest neighbors in the original array.
* The testing code is, frankly, a mess. I need to look into using nose
in a sensible fashion.
* The license is the scipy license.

I am particularly concerned about providing a convenient return
format. The natural return from a query is a list of neighbors, since
it may have variable length (there may not be r elements in the tree,
or you might have supplied a maximum distance which doesn't contain r
points). For a single query, it's simple to return a python list
(should it be sorted? currently it's a heap). But if you want to
vectorize the process, storing the results in an array becomes
cumbersome. One option is an object array full of lists; another,
which, I currently use, is an array with nonexistent points marked
with an infinite distance and an invalid index. A third would be to
return masked arrays. How do you recommend handling this variable (or
potentially-variable) sized output?

> If you're implementing one, I would highly recommend the
> "left-balanced" kd-tree.
> http://www2.imm.dtu.dk/pubdb/views/edoc_download.php/2535/pdf/imm2535.pdf

Research suggests that at least in high dimension a more geometric
balancing criterion can produce vastly better results. I used the
"sliding midpoint" rule, which doesn't allow such a numerical
balancing but does ensure that you don't have too many long skinny
cells (since a sphere tends to cut very many of these).

I've also been thinking about what else would go in scipy.spatial. I
think it would be valuable to have a reasonably efficient distance
matrix function (we seem to get that question a lot, and the answer's
not trivial) as well as a sparse distance matrix function based on the
kd-trees. The module could potentially also swallow the (currently
sandboxed?) delaunay code.

Anne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdtree.py
Type: text/x-python
Size: 10591 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080929/80b2d018/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_kdtree.py
Type: text/x-python
Size: 4369 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080929/80b2d018/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plot_kdtree.py
Type: text/x-python
Size: 1403 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080929/80b2d018/attachment-0002.py>

From wnbell at gmail.com  Tue Sep 30 00:40:04 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Tue, 30 Sep 2008 00:40:04 -0400
Subject: [SciPy-dev] Proposal: scipy.spatial
In-Reply-To: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>
References: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>
Message-ID: <d05265cb0809292140n27592a76gea1786c90756365b@mail.gmail.com>

On Mon, Sep 29, 2008 at 11:24 PM, Anne Archibald
<peridot.faceted at gmail.com> wrote:

Thanks for taking the initiative on scipy.spatial Anne.  I have no
doubt that it will become an important and widely used part of scipy.

Have you considered starting a "spatial" branch off the scipy trunk?

>
> I am particularly concerned about providing a convenient return
> format. The natural return from a query is a list of neighbors, since
> it may have variable length (there may not be r elements in the tree,
> or you might have supplied a maximum distance which doesn't contain r
> points). For a single query, it's simple to return a python list
> (should it be sorted? currently it's a heap). But if you want to
> vectorize the process, storing the results in an array becomes
> cumbersome. One option is an object array full of lists; another,
> which, I currently use, is an array with nonexistent points marked
> with an infinite distance and an invalid index. A third would be to
> return masked arrays. How do you recommend handling this variable (or
> potentially-variable) sized output?
>

I'd go with an array of lists for now.  If you support an "all points
in a given sphere" query, then you'll need something that can
accommodate the potentially large size imbalance among query results.

FWIW you could encode this information in a sparse matrix.  For
instance, the lil_matrix format is essentially an array of lists with
entries of the form (column index,value).  I don't know if this sort
of approach would simplify matters or not.

>
> Research suggests that at least in high dimension a more geometric
> balancing criterion can produce vastly better results. I used the
> "sliding midpoint" rule, which doesn't allow such a numerical
> balancing but does ensure that you don't have too many long skinny
> cells (since a sphere tends to cut very many of these).

I will defer to your judgment here.  My experience, and the paper I
referenced, is oriented towards low dimensional cases that arise in
graphics applications.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From nwagner at iam.uni-stuttgart.de  Tue Sep 30 02:43:11 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Sep 2008 08:43:11 +0200
Subject: [SciPy-dev] NNLS.f
Message-ID: <web-112063361@uni-stuttgart.de>

Hi all,

I cannot build scipy from svn due to

g77:f77: scipy/optimize/slsqp/slsqp_optmz.f
scipy/optimize/slsqp/slsqp_optmz.f: In subroutine `nnls':
In file included from 
scipy/optimize/slsqp/slsqp_optmz.f:0:
scipy/optimize/slsqp/slsqp_optmz.f:1058: warning: 'izmax' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f: In subroutine `hfti':
scipy/optimize/slsqp/slsqp_optmz.f:1244: warning: 'hmax' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f: In subroutine `ldl':
scipy/optimize/slsqp/slsqp_optmz.f:1455: warning: 'tp' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f: In function `linmin':
scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'd' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'e' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'u' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'w' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'x' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f:1557: warning: 'fv' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f:1557: warning: 'fw' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f:1557: warning: 'fx' 
might be used uninitialized in this function
scipy/optimize/slsqp/slsqp_optmz.f: In function `dnrm2_':
scipy/optimize/slsqp/slsqp_optmz.f:1855: warning: 'xmax' 
might be used uninitialized in this function
/usr/bin/g77 -g -Wall -g -Wall -shared 
build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/scipy/optimize/slsqp/_slsqpmodule.o 
build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/fortranobject.o 
build/temp.linux-x86_64-2.5/scipy/optimize/slsqp/slsqp_optmz.o 
-Lbuild/temp.linux-x86_64-2.5 -lg2c -o 
build/lib.linux-x86_64-2.5/scipy/optimize/_slsqp.so
building 'scipy.optimize._nnls' extension
compiling C sources
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g 
-O3 -Wall -Wstrict-prototypes -fPIC

creating 
build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/scipy/optimize/nnls
compile options: '-Ibuild/src.linux-x86_64-2.5 
-I/data/home/nwagner/local/lib/python2.5/site-packages/numpy/core/include 
-I/data/home/nwagner/local/include/python2.5 -c'
gcc: 
build/src.linux-x86_64-2.5/scipy/optimize/nnls/_nnlsmodule.c
compiling Fortran sources
Fortran f77 compiler: /usr/bin/g77 -g -Wall 
-fno-second-underscore -fPIC -O3 -funroll-loops 
-march=nocona -mmmx -msse2 -msse -msse3 
-fomit-frame-pointer
creating build/temp.linux-x86_64-2.5/nnls
compile options: '-Ibuild/src.linux-x86_64-2.5 
-I/data/home/nwagner/local/lib/python2.5/site-packages/numpy/core/include 
-I/data/home/nwagner/local/include/python2.5 -c'
error: nnls/NNLS.f: No such file or directory
  
Cheers,

              Nils


From matthieu.brucher at gmail.com  Tue Sep 30 03:26:47 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Tue, 30 Sep 2008 09:26:47 +0200
Subject: [SciPy-dev] Proposal: scipy.spatial
In-Reply-To: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>
References: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>
Message-ID: <e76aa17f0809300026t59016e56r1abf3549aac06615@mail.gmail.com>

2008/9/30 Anne Archibald <peridot.faceted at gmail.com>:
> Hi,
>
> Once again there has been a thread on the numpy/scipy mailing lists
> requesting (essentially) some form of spatial data structure. Pointers
> have been posted to ANN (sadly LGPLed and in C++) as well as a handful
> of pure-python implementations of kd-trees. I suggest the creation of
> a new submodule of scipy, scipy.spatial, to contain spatial data
> structures and algorithms. Specifically, I propose it contain a
> kd-tree implementation providing nearest-neighbor, approximate
> nearest-neighbor, and all-points-near queries. I have a few other
> suggestions for things it might contain, but kd-trees seem like a good
> first step.

There is also a kd-tree implementation in the learn scikit (in the
manifold_learning.regression module). It does not create a balanced
tree though, as it aims at having square nodes (the dimensions of a
node are equal in each direction so as to select the adequate nodes to
be searched) and it can be upgraded to the search of the nearest
neighbors in a sphere.

Matthieu
-- 
French PhD student
Information System Engineer
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher


From pav at iki.fi  Tue Sep 30 03:34:56 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 30 Sep 2008 07:34:56 +0000 (UTC)
Subject: [SciPy-dev] tests and partial patch
	for	scipy.stats.distributions
References: <1cd32cbb0809282100x75eccfb9la109e92032f798ac@mail.gmail.com>
	<1cd32cbb0809290551g7c00a5ddh44369352ece506d2@mail.gmail.com>
	<1cd32cbb0809290737t31d0d4adk3462064987a3bea9@mail.gmail.com>
	<1cd32cbb0809290741y18d75695xdea21ba284c9e854@mail.gmail.com>
	<1cd32cbb0809290749o5b4e2eccq67114222779a6586@mail.gmail.com>
	<1cd32cbb0809290755i68b75f63s618dcf8387f9d7a3@mail.gmail.com>
	<1cd32cbb0809290852n68e0eca6v4a5bd747cb01cedc@mail.gmail.com>
Message-ID: <gbskr0$toe$1@ger.gmane.org>

Mon, 29 Sep 2008 11:52:58 -0400, josef.pktd wrote:
> I just saw that there were 2 change sets in scipy.stats.distributions.py
> since I installed the trunk version from 2008-09-25  revision 4741.
> After merging these 2 changes into my version of distributions.py I
> still get the same test results as before.

When you find errors etc., could in addition to reporting you also file a 
corresponding ticket in the Scipy trac [1], so that it is easier to 
follow which bugs still need addressing. Discussions on mailing lists are 
easy to miss or forget.

.. [1] http://scipy.org/scipy/scipy

-- 
Pauli Virtanen



From uschmitt at mineway.de  Tue Sep 30 03:59:49 2008
From: uschmitt at mineway.de (Uwe Schmitt)
Date: Tue, 30 Sep 2008 09:59:49 +0200
Subject: [SciPy-dev] [mailinglist]  NNLS.f
In-Reply-To: <web-112063361@uni-stuttgart.de>
References: <web-112063361@uni-stuttgart.de>
Message-ID: <48E1DC75.5010709@mineway.de>

Hi,

this is my fault. I mixed upper and lower case
letters in the filename NNLS.f, which caused
no trouble on my Mac.
@Nils: which platform are you using ?

I guess that gfortran and g77 behave different
in this case.

I fixed the filename and checked the changes in.
Nils reported that it builds on his computer now.

Greetings, Uwe


Nils Wagner schrieb:
> Hi all,
>
> I cannot build scipy from svn due to
>
> g77:f77: scipy/optimize/slsqp/slsqp_optmz.f
> scipy/optimize/slsqp/slsqp_optmz.f: In subroutine `nnls':
> In file included from 
> scipy/optimize/slsqp/slsqp_optmz.f:0:
> scipy/optimize/slsqp/slsqp_optmz.f:1058: warning: 'izmax' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f: In subroutine `hfti':
> scipy/optimize/slsqp/slsqp_optmz.f:1244: warning: 'hmax' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f: In subroutine `ldl':
> scipy/optimize/slsqp/slsqp_optmz.f:1455: warning: 'tp' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f: In function `linmin':
> scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'd' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'e' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'u' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'w' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f:1556: warning: 'x' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f:1557: warning: 'fv' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f:1557: warning: 'fw' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f:1557: warning: 'fx' 
> might be used uninitialized in this function
> scipy/optimize/slsqp/slsqp_optmz.f: In function `dnrm2_':
> scipy/optimize/slsqp/slsqp_optmz.f:1855: warning: 'xmax' 
> might be used uninitialized in this function
> /usr/bin/g77 -g -Wall -g -Wall -shared 
> build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/scipy/optimize/slsqp/_slsqpmodule.o 
> build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/fortranobject.o 
> build/temp.linux-x86_64-2.5/scipy/optimize/slsqp/slsqp_optmz.o 
> -Lbuild/temp.linux-x86_64-2.5 -lg2c -o 
> build/lib.linux-x86_64-2.5/scipy/optimize/_slsqp.so
> building 'scipy.optimize._nnls' extension
> compiling C sources
> C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g 
> -O3 -Wall -Wstrict-prototypes -fPIC
>
> creating 
> build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/scipy/optimize/nnls
> compile options: '-Ibuild/src.linux-x86_64-2.5 
> -I/data/home/nwagner/local/lib/python2.5/site-packages/numpy/core/include 
> -I/data/home/nwagner/local/include/python2.5 -c'
> gcc: 
> build/src.linux-x86_64-2.5/scipy/optimize/nnls/_nnlsmodule.c
> compiling Fortran sources
> Fortran f77 compiler: /usr/bin/g77 -g -Wall 
> -fno-second-underscore -fPIC -O3 -funroll-loops 
> -march=nocona -mmmx -msse2 -msse -msse3 
> -fomit-frame-pointer
> creating build/temp.linux-x86_64-2.5/nnls
> compile options: '-Ibuild/src.linux-x86_64-2.5 
> -I/data/home/nwagner/local/lib/python2.5/site-packages/numpy/core/include 
> -I/data/home/nwagner/local/include/python2.5 -c'
> error: nnls/NNLS.f: No such file or directory
>   
> Cheers,
>
>               Nils
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   


-- 
Dr. rer. nat. Uwe Schmitt
F&E Mathematik
 
mineway GmbH
Science Park 2
D-66123 Saarbr?cken
 
Telefon: +49 (0)681 8390 5334
Telefax: +49 (0)681 830 4376
 
uschmitt at mineway.de
www.mineway.de
 
Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer
Amtsgericht Saarbr?cken HRB 12339




From david at ar.media.kyoto-u.ac.jp  Tue Sep 30 04:01:45 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 30 Sep 2008 17:01:45 +0900
Subject: [SciPy-dev] [mailinglist]  NNLS.f
In-Reply-To: <48E1DC75.5010709@mineway.de>
References: <web-112063361@uni-stuttgart.de> <48E1DC75.5010709@mineway.de>
Message-ID: <48E1DCE9.6040108@ar.media.kyoto-u.ac.jp>

Uwe Schmitt wrote:
> Hi,
>
> this is my fault. I mixed upper and lower case
> letters in the filename NNLS.f, which caused
> no trouble on my Mac.

Yes, because mac os X fs is not case sensitive. Because of this, it is a
good idea *not* to mix case at all in filenames (using lower-case all
the time would be best, but a lot of fortran code use upper case filenames).

> @Nils: which platform are you using ?
>
> I guess that gfortran and g77 behave different
> in this case.

No, gfortran and g77 behave the same. This is just platform oddities
with the fs here.

cheers,

David


From uschmitt at mineway.de  Tue Sep 30 04:16:40 2008
From: uschmitt at mineway.de (Uwe Schmitt)
Date: Tue, 30 Sep 2008 10:16:40 +0200
Subject: [SciPy-dev] [mailinglist]  NNLS.f
In-Reply-To: <48E1DCE9.6040108@ar.media.kyoto-u.ac.jp>
References: <web-112063361@uni-stuttgart.de> <48E1DC75.5010709@mineway.de>
	<48E1DCE9.6040108@ar.media.kyoto-u.ac.jp>
Message-ID: <48E1E068.6080008@mineway.de>

David Cournapeau schrieb:
> Uwe Schmitt wrote:
>   
>> Hi,
>>
>> this is my fault. I mixed upper and lower case
>> letters in the filename NNLS.f, which caused
>> no trouble on my Mac.
>>     
>
> Yes, because mac os X fs is not case sensitive. Because of this, it is a
> good idea *not* to mix case at all in filenames (using lower-case all
> the time would be best, but a lot of fortran code use upper case filenames).
>   
Thats what I learned from this. I just wondered that filenames
like "SConscript" seem to cause no trouble.

Greetings, Uwe
>   
>> @Nils: which platform are you using ?
>>
>> I guess that gfortran and g77 behave different
>> in this case.
>>     
>
> No, gfortran and g77 behave the same. This is just platform oddities
> with the fs here.
>
> cheers,
>
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   


-- 
Dr. rer. nat. Uwe Schmitt
F&E Mathematik
 
mineway GmbH
Science Park 2
D-66123 Saarbr?cken
 
Telefon: +49 (0)681 8390 5334
Telefax: +49 (0)681 830 4376
 
uschmitt at mineway.de
www.mineway.de
 
Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer
Amtsgericht Saarbr?cken HRB 12339


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080930/bd157b12/attachment.html>

From nwagner at iam.uni-stuttgart.de  Tue Sep 30 13:56:58 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Sep 2008 19:56:58 +0200
Subject: [SciPy-dev] Next scipy release 0.7
In-Reply-To: <48E19470.8030509@ar.media.kyoto-u.ac.jp>
References: <web-111958955@uni-stuttgart.de>
	<c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>
	<48E19470.8030509@ar.media.kyoto-u.ac.jp>
Message-ID: <web-112102973@uni-stuttgart.de>

On Tue, 30 Sep 2008 11:52:32 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Jarrod Millman wrote:
>>
>> I just haven't had any free time.  My plan at this point 
>>is to release
>> an alpha first with binaries.  Since the trunk has had 
>>so many
>> changes, I would like to see more testing before 
>>releasing a beta.
>>
> 
> Before an alpha, there are several things which I 
>consider a blocker for
> a release and would like to fix (and seeing fixed):
>   
>    - http://projects.scipy.org/scipy/scipy/ticket/244 -> 
>fft gives
> wrong results with some axes parameters
>    - http://projects.scipy.org/scipy/scipy/ticket/691 -> 
>valgrind warnings
>    - http://projects.scipy.org/scipy/scipy/ticket/688 -> 
>fftpack revamp
>    - http://projects.scipy.org/scipy/scipy/ticket/725 -> 
>arpack
> crashes/gives wrong result on Mac OS X
> 
>For windows binaries: taking the same approach as for 
>numpy would work,
> but would give a big installer (~40 Mb). I don't see any 
>other approach,
> except just linking with netlib (having a net installer 
>sounds like a
> support nightmare with all the proxy, firewall, etc...)
> 
> cheers,
> 
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
  

Hi all,

IMHO,

http://projects.scipy.org/scipy/scipy/ticket/709

should be resolved, too.

Nils


From pav at iki.fi  Tue Sep 30 14:36:12 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 30 Sep 2008 18:36:12 +0000 (UTC)
Subject: [SciPy-dev] Ticket #709 (was: Re: Next scipy release 0.7)
References: <web-111958955@uni-stuttgart.de>
	<c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>
	<48E19470.8030509@ar.media.kyoto-u.ac.jp>
	<web-112102973@uni-stuttgart.de>
Message-ID: <gbtris$tgm$1@ger.gmane.org>

Tue, 30 Sep 2008 19:56:58 +0200, Nils Wagner wrote:
> IMHO,
> 
> http://projects.scipy.org/scipy/scipy/ticket/709
> 
> should be resolved, too.

Short summary about this one: it's about a special matrix pair for which 
LAPACK's generalized eigenvalue problem solver DGGEV returns bogus 
output, losing one eigenvalue from a complex eigenpair. (The eigenvalue 
problem should nonetheless be well-defined, AFAIK, this looks like a bug 
in LAPACK.)

The question here is what we should/can do:

1. Raise LinAlgError if we detect this condition.

2. Try to repair the returned data by filling in the other eigenvalue of
   the pair, as we know all complex eigenvalues come in pairs.

3. Try to return as much as we can make sense of, but put NaN in place of
   the missing eigenvalue.


Details:

Instead of expected complex eigenvalue pair (a_R +- i a_I)/beta, the 
LAPACK routine instead returns the values

	a_R  = whatever
	a_I  = [0., -2.18645248e-16j]
	beta = [0., 7.95804395e-17]

The correct result would have been something like

	a_R  = whatever
	a_I  = [+2.18645248e-16j, -2.18645248e-16j]
	beta = [7.95804395e-17, 7.95804395e-17]

but one eigenvalue of the pair was lost, apparently due to rounding etc.

Eigenvector data corresponding to zeros in a_I are interpreted 
differently than for positive entries, so the zero in the wrong place 
messed up the Scipy routine. We could detect this and raise an error (1), 
substitute in the missing eigenvalue based on the correctly calculated 
one (2), or leave the missing eigenvalue as corrupted and return only the 
correct one (3).

-- 
Pauli Virtanen



From nwagner at iam.uni-stuttgart.de  Tue Sep 30 15:21:38 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Sep 2008 21:21:38 +0200
Subject: [SciPy-dev] Ticket #709 (was: Re: Next scipy release 0.7)
In-Reply-To: <gbtris$tgm$1@ger.gmane.org>
References: <web-111958955@uni-stuttgart.de>
	<c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>
	<48E19470.8030509@ar.media.kyoto-u.ac.jp>
	<web-112102973@uni-stuttgart.de> <gbtris$tgm$1@ger.gmane.org>
Message-ID: <web-112105748@uni-stuttgart.de>

On Tue, 30 Sep 2008 18:36:12 +0000 (UTC)
  Pauli Virtanen <pav at iki.fi> wrote:
> Tue, 30 Sep 2008 19:56:58 +0200, Nils Wagner wrote:
>> IMHO,
>> 
>> http://projects.scipy.org/scipy/scipy/ticket/709
>> 
>> should be resolved, too.
> 
> Short summary about this one: it's about a special 
>matrix pair for which 
> LAPACK's generalized eigenvalue problem solver DGGEV 
>returns bogus 
> output, losing one eigenvalue from a complex eigenpair. 
>(The eigenvalue 
> problem should nonetheless be well-defined, AFAIK, this 
>looks like a bug 
> in LAPACK.)

In that case the LAPACK developers should be informed as 
soon as possible. Did you check a FORTRAN implementation
of the test case ?

Can someone run the test (2dof.py) in Matlab, Octave, 
Scilab ?

> 
> The question here is what we should/can do:
> 
> 1. Raise LinAlgError if we detect this condition.
> 
> 2. Try to repair the returned data by filling in the 
>other eigenvalue of
>   the pair, as we know all complex eigenvalues come in 
>pairs.

Well, this holds for real matrices but what could be done 
in case of complex matrices ?


Nils

> 
> 3. Try to return as much as we can make sense of, but 
>put NaN in place of
>   the missing eigenvalue.
> 
> 
> Details:
> 
> Instead of expected complex eigenvalue pair (a_R +- i 
>a_I)/beta, the 
> LAPACK routine instead returns the values
> 
> 	a_R  = whatever
> 	a_I  = [0., -2.18645248e-16j]
> 	beta = [0., 7.95804395e-17]
> 
> The correct result would have been something like
> 
> 	a_R  = whatever
> 	a_I  = [+2.18645248e-16j, -2.18645248e-16j]
> 	beta = [7.95804395e-17, 7.95804395e-17]
> 
> but one eigenvalue of the pair was lost, apparently due 
>to rounding etc.
> 
> Eigenvector data corresponding to zeros in a_I are 
>interpreted 
> differently than for positive entries, so the zero in 
>the wrong place 
> messed up the Scipy routine. We could detect this and 
>raise an error (1), 
> substitute in the missing eigenvalue based on the 
>correctly calculated 
> one (2), or leave the missing eigenvalue as corrupted 
>and return only the 
> correct one (3).
> 
> -- 
> Pauli Virtanen
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
  


From pav at iki.fi  Tue Sep 30 15:43:10 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 30 Sep 2008 19:43:10 +0000 (UTC)
Subject: [SciPy-dev] Ticket #709 (was: Re: Next scipy release 0.7)
References: <web-111958955@uni-stuttgart.de>
	<c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>
	<48E19470.8030509@ar.media.kyoto-u.ac.jp>
	<web-112102973@uni-stuttgart.de>
	<gbtris$tgm$1@ger.gmane.org> <web-112105748@uni-stuttgart.de>
Message-ID: <gbtvge$tgm$2@ger.gmane.org>

Tue, 30 Sep 2008 21:21:38 +0200, Nils Wagner wrote:

> On Tue, 30 Sep 2008 18:36:12 +0000 (UTC)
>   Pauli Virtanen <pav at iki.fi> wrote:
>> Tue, 30 Sep 2008 19:56:58 +0200, Nils Wagner wrote:
>>> IMHO,
>>> 
>>> http://projects.scipy.org/scipy/scipy/ticket/709
>>> 
>>> should be resolved, too.
>> 
>> Short summary about this one: it's about a special
>>matrix pair for which
>> LAPACK's generalized eigenvalue problem solver DGGEV
>>returns bogus
>> output, losing one eigenvalue from a complex eigenpair.
>>(The eigenvalue
>> problem should nonetheless be well-defined, AFAIK, this
>>looks like a bug
>> in LAPACK.)
> 
> In that case the LAPACK developers should be informed as soon as
> possible. Did you check a FORTRAN implementation of the test case ?

I didn't contact LAPACK devs yet. I'll try to see if I can reduce this to 
a simple Fortran testcase.

But to my understanding, LAPACK's DGEEV has also some other known issues, 
see eg. http://icl.cs.utk.edu/lapack-forum/viewtopic.php?
f=2&t=317&p=1060&hilit=dggev

> Can someone run the test (2dof.py) in Matlab, Octave, Scilab ?

I got similar suspect result from Octave's QZ when I tried it (Octave 
dropped one of the eigenvalues, too).

Matlab AFAIK does not use Lapack's DGGEV, so the testcase probably will 
not fail in the same way with it.

>> The question here is what we should/can do:
>> 
>> 1. Raise LinAlgError if we detect this condition.
>> 
>> 2. Try to repair the returned data by filling in the
>>other eigenvalue of
>>   the pair, as we know all complex eigenvalues come in
>>pairs.
> 
> Well, this holds for real matrices but what could be done in case of
> complex matrices ?

For complex matrices the eigenvectors are returned by LAPACK as complex 
data directly (and don't need to be separately constructed from real 
data, as in the real case), so they are simply passed throught by Scipy. 
If the results are wrong, we probably can't do anything to fix or detect 
this.

-- 
Pauli Virtanen



From nwagner at iam.uni-stuttgart.de  Tue Sep 30 16:23:49 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Sep 2008 22:23:49 +0200
Subject: [SciPy-dev] Ticket #709 (was: Re: Next scipy release 0.7)
In-Reply-To: <gbtvge$tgm$2@ger.gmane.org>
References: <web-111958955@uni-stuttgart.de>
	<c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>
	<48E19470.8030509@ar.media.kyoto-u.ac.jp>
	<web-112102973@uni-stuttgart.de> <gbtris$tgm$1@ger.gmane.org>
	<web-112105748@uni-stuttgart.de> <gbtvge$tgm$2@ger.gmane.org>
Message-ID: <web-112107529@uni-stuttgart.de>

On Tue, 30 Sep 2008 19:43:10 +0000 (UTC)
  Pauli Virtanen <pav at iki.fi> wrote:
> Tue, 30 Sep 2008 21:21:38 +0200, Nils Wagner wrote:
> 
>> On Tue, 30 Sep 2008 18:36:12 +0000 (UTC)
>>   Pauli Virtanen <pav at iki.fi> wrote:
>>> Tue, 30 Sep 2008 19:56:58 +0200, Nils Wagner wrote:
>>>> IMHO,
>>>> 
>>>> http://projects.scipy.org/scipy/scipy/ticket/709
>>>> 
>>>> should be resolved, too.
>>> 
>>> Short summary about this one: it's about a special
>>>matrix pair for which
>>> LAPACK's generalized eigenvalue problem solver DGGEV
>>>returns bogus
>>> output, losing one eigenvalue from a complex eigenpair.
>>>(The eigenvalue
>>> problem should nonetheless be well-defined, AFAIK, this
>>>looks like a bug
>>> in LAPACK.)
>> 
>> In that case the LAPACK developers should be informed as 
>>soon as
>> possible. Did you check a FORTRAN implementation of the 
>>test case ?
> 
> I didn't contact LAPACK devs yet. I'll try to see if I 
>can reduce this to 
> a simple Fortran testcase.
> 
> But to my understanding, LAPACK's DGEEV has also some 
>other known issues, 
> see eg. 
>http://icl.cs.utk.edu/lapack-forum/viewtopic.php?
> f=2&t=317&p=1060&hilit=dggev
> 
>> Can someone run the test (2dof.py) in Matlab, Octave, 
>>Scilab ?
> 
> I got similar suspect result from Octave's QZ when I 
>tried it (Octave 
> dropped one of the eigenvalues, too).
> 
> Matlab AFAIK does not use Lapack's DGGEV, so the 
>testcase probably will 
> not fail in the same way with it.
> 
>>> The question here is what we should/can do:
>>> 
>>> 1. Raise LinAlgError if we detect this condition.
>>> 
>>> 2. Try to repair the returned data by filling in the
>>>other eigenvalue of
>>>   the pair, as we know all complex eigenvalues come in
>>>pairs.
>> 
>> Well, this holds for real matrices but what could be 
>>done in case of
>> complex matrices ?
> 
>For complex matrices the eigenvectors are returned by 
>LAPACK as complex 
> data directly (and don't need to be separately 
>constructed from real 
> data, as in the real case), so they are simply passed 
>throught by Scipy. 
> If the results are wrong, we probably can't do anything 
>to fix or detect 
> this.
> 
> -- 
> Pauli Virtanen
> 
  
Hi Pauli,

Please find attached an u n t e s t e d FORTRAN 
implementation of 2dof.py.

Cheers,
          Nils
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_lapack.f
Type: text/x-fortran
Size: 2428 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080930/d68955fc/attachment.bin>

From peridot.faceted at gmail.com  Tue Sep 30 17:31:17 2008
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Tue, 30 Sep 2008 17:31:17 -0400
Subject: [SciPy-dev] [Numpy-discussion] Proposal: scipy.spatial
In-Reply-To: <320fb6e00809300129j1b45ee21k6756b4c2b1945d84@mail.gmail.com>
References: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>
	<48E1A6A2.4050406@noaa.gov>
	<320fb6e00809300129j1b45ee21k6756b4c2b1945d84@mail.gmail.com>
Message-ID: <ce557a360809301431g58fd7a7dsca15e27828522d95@mail.gmail.com>

2008/9/30 Peter <numpy-discussion at maubp.freeserve.co.uk>:
> On Tue, Sep 30, 2008 at 5:10 AM, Christopher Barker
> <Chris.Barker at noaa.gov> wrote:
>>
>> Anne Archibald wrote:
>>> I suggest the creation of
>>> a new submodule of scipy, scipy.spatial,
>>
>> +1
>>
>> Here's one to consider:
>> http://pypi.python.org/pypi/Rtree
>> and perhaps other stuff from:
>> http://trac.gispython.org/spatialindex/wiki
>> which I think is LGPL -- can scipy use that?
>
> There is also a KDTree module in Biopython (which is under a BSD/MIT
> style licence),
> http://biopython.org/SRC/biopython/Bio/KDTree/
>
> The current version is in C, there is an older version available in
> the CVS history in C++ too,
> http://cvs.biopython.org/cgi-bin/viewcvs/viewcvs.cgi/biopython/Bio/KDTree/?cvsroot=biopython

I think the profusion of different implementations is an argument for
including this in scipy. I think it is also an argument for providing
a standard interface with (at least potentially) several different
implementations. At the moment, that proposed interface looks like:

T = KDTree(data)

distances, indices = T.query(xs) # single nearest neighbor

distances, indices = T.query(xs, k=10) # ten nearest neighbors

distances, indices = T.query(xs, k=None, distance_upper_bound=1.0) #
all within 1 of x

In the first two cases, missing neighbors are represented with an
infinite distance and an invalid index. In the last case, distances
and indices are both either lists (if there's only one query point) or
object arrays of lists (if there are many query points). If only one
neighbor is requested, the array does not have a dimension of length 1
in the which-neighbor position. If (potentially) many neighbors are
returned, they are sorted by distance, nearest first.

What do you think of this interface?

It may make sense to provide additional kinds of query - nearest
neighbors between two trees, for example - some of which would be
available only for some implementations.

Anne


From pav at iki.fi  Tue Sep 30 17:52:55 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 30 Sep 2008 21:52:55 +0000 (UTC)
Subject: [SciPy-dev] Ticket #709 (was: Re: Next scipy release 0.7)
References: <web-111958955@uni-stuttgart.de>
	<c7009a550809290955i125cb6c4tb7350edf54e036be@mail.gmail.com>
	<48E19470.8030509@ar.media.kyoto-u.ac.jp>
	<web-112102973@uni-stuttgart.de>
	<gbtris$tgm$1@ger.gmane.org> <web-112105748@uni-stuttgart.de>
	<gbtvge$tgm$2@ger.gmane.org> <web-112107529@uni-stuttgart.de>
Message-ID: <gbu73n$tgm$3@ger.gmane.org>

Tue, 30 Sep 2008 22:23:49 +0200, Nils Wagner wrote:
>
> Please find attached an u n t e s t e d FORTRAN implementation of
> 2dof.py.

Tested pure-Fortran testcase is here:

	http://scipy.org/scipy/scipy/attachment/ticket/709/2dof.f?format=raw

Could you check that it reproduces the problem for you, and list
the problematic values of Omega on your platform?

So far, I've seen the following pattern:

	platform 1 (32-bit x86 AMD, Ubuntu Interpid, Lapack 3.1.1)
		Omega = 25/99, 110/99, 155/99, 265/99

	platform 2 (64-bit x86 Intel, Debian etch, Lapack 3.0)
		Omega = 185/99

-- 
Pauli Virtanen



From fperez.net at gmail.com  Tue Sep 30 20:39:20 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 30 Sep 2008 17:39:20 -0700
Subject: [SciPy-dev] Fwd: [sage-devel] Sage Days 11: November 7-10, Austin,
	Texas
In-Reply-To: <a8c4ff4c0809212047x78111fabw418acc020ea0dedf@mail.gmail.com>
References: <a8c4ff4c0809212047x78111fabw418acc020ea0dedf@mail.gmail.com>
Message-ID: <db6b5ecc0809301739t323914e7s73cfe16b3b5cb82f@mail.gmail.com>

Hi all,

I think the original announcement only went to the Sage lists, but
this should be of interest to this crowd as well.

Cheers,

f

---------- Forwarded message ----------
From: Craig Citro <craigcitro at gmail.com>
Date: Sun, Sep 21, 2008 at 8:47 PM
Subject: [sage-devel] Sage Days 11: November 7-10, Austin, Texas
To: sage-devel at googlegroups.com, sage-support at googlegroups.com



Hi all,

This is a reminder that Sage Days 11 is fast approaching! The topic is
"Special functions and computational number theory meet scientific
computing." The plan is to bring together a bunch of number theorists
and scientific computing/supercomputing experts, and Austin's
incredible supercomputing facilities make this the perfect place for
it.

If you're new to Sage, and interested in this topic, attending a Sage
Days is the perfect way to get more involved. (For those of you who've
been around a while, you know the drill -- just go ahead and skip this
paragraph.) Sage Days are friendly and very intensive focused
development workshops, which are probably fairly different from other
math-related conferences and workshops you've attended. There are
usually only one to two talks per day, in order to allow for the
maximum time for working discussions and coding sprints. The groups
are organized on the first day, and there are regular progress reports
throughout the workshop.

We have a webpage:

 http://www.math.utexas.edu/sage

and a wiki page:

 http://wiki.sagemath.org/days11

If you're planning on joining us in Austin, please register soon at
http://www.ma.utexas.edu/sage/rform1.php, and add your name to the
wiki. We do have some limited funding available, so please let us know
if you'll need funding. We have a block of rooms reserved at the
Doubletree Guest Suites in Austin, and we'll let you know more details
on that soon.

If you have any questions, feel free to email me or any of the other organizers!

On behalf of the organizing committee,
-Craig Citro


From peridot.faceted at gmail.com  Tue Sep 30 20:45:53 2008
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Tue, 30 Sep 2008 20:45:53 -0400
Subject: [SciPy-dev] Proposal: scipy.spatial
In-Reply-To: <d05265cb0809292140n27592a76gea1786c90756365b@mail.gmail.com>
References: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>
	<d05265cb0809292140n27592a76gea1786c90756365b@mail.gmail.com>
Message-ID: <ce557a360809301745x786457d4v9956a2803620bd8d@mail.gmail.com>

2008/9/30 Nathan Bell <wnbell at gmail.com>:
> On Mon, Sep 29, 2008 at 11:24 PM, Anne Archibald
> <peridot.faceted at gmail.com> wrote:
>
> Thanks for taking the initiative on scipy.spatial Anne.  I have no
> doubt that it will become an important and widely used part of scipy.
>
> Have you considered starting a "spatial" branch off the scipy trunk?

For now I have simply added it to the trunk, since I have code which
is documented and tested. (Also I have no experience with SVN and
merging, but reports suggest it's a horrible experience.)

> I will defer to your judgment here.  My experience, and the paper I
> referenced, is oriented towards low dimensional cases that arise in
> graphics applications.

It's quite possible that the best algorithms for low-dimensional cases
differ. It's probably worth implementing a very simple and
space-efficient kd-tree, possibly in a compiled language, to
complement what's there now.

Anne


From guyer at nist.gov  Tue Sep 30 21:40:10 2008
From: guyer at nist.gov (Jonathan Guyer)
Date: Tue, 30 Sep 2008 21:40:10 -0400
Subject: [SciPy-dev] Proposal: scipy.spatial
In-Reply-To: <ce557a360809301745x786457d4v9956a2803620bd8d@mail.gmail.com>
References: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>
	<d05265cb0809292140n27592a76gea1786c90756365b@mail.gmail.com>
	<ce557a360809301745x786457d4v9956a2803620bd8d@mail.gmail.com>
Message-ID: <11F5C399-FE46-4321-AC9E-8B0699D06A84@nist.gov>


On Sep 30, 2008, at 8:45 PM, Anne Archibald wrote:

> (Also I have no experience with SVN and
> merging, but reports suggest it's a horrible experience.)

It is not a horrible experience. It involves a little bookkeeping, but  
it's entirely manageable. Our collected instructions for handling  
branches of FiPy (derived largely from the SVN book at red-bean) is at http://matforge.org/fipy/browser/trunk/documentation/ADMINISTRATA.txt 
. We branch all the time.




From robert.kern at gmail.com  Tue Sep 30 22:03:02 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 30 Sep 2008 21:03:02 -0500
Subject: [SciPy-dev] Proposal: scipy.spatial
In-Reply-To: <ce557a360809301745x786457d4v9956a2803620bd8d@mail.gmail.com>
References: <ce557a360809292024o121be824nfc3d015b54c48ed1@mail.gmail.com>
	<d05265cb0809292140n27592a76gea1786c90756365b@mail.gmail.com>
	<ce557a360809301745x786457d4v9956a2803620bd8d@mail.gmail.com>
Message-ID: <3d375d730809301903i68704ea0w276699b67449ac9f@mail.gmail.com>

On Tue, Sep 30, 2008 at 19:45, Anne Archibald <peridot.faceted at gmail.com> wrote:
> 2008/9/30 Nathan Bell <wnbell at gmail.com>:
>> On Mon, Sep 29, 2008 at 11:24 PM, Anne Archibald
>> <peridot.faceted at gmail.com> wrote:
>>
>> Thanks for taking the initiative on scipy.spatial Anne.  I have no
>> doubt that it will become an important and widely used part of scipy.
>>
>> Have you considered starting a "spatial" branch off the scipy trunk?
>
> For now I have simply added it to the trunk, since I have code which
> is documented and tested. (Also I have no experience with SVN and
> merging, but reports suggest it's a horrible experience.)

It's not all that bad, particularly for cases like this, where you are
mostly adding new new directories rather than modifying code that's
already there. We would like to make a 0.7 release not too long from
now, and I'd like to do it without a completely new subpackage in the
mix.

-- 
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