numpy-discussion — Discussion list for all users of Numerical Python

[Numpy-discussion] Re: [SciPy-user] Release of SciPy Core 0.4 (Beta)

[Brian G. <bgr...@sc...>]

Which version of gccc are you using?  As I understand it, g77 3.4 is not =
compatible with gcc 4.0 (the default on OS X).  Switching to gcc 3.4 migh=
t help:

gcc_select 3.3


I will soon try scipy_core on Tiger with Python 2.4.1.

Brian





Brian Granger, Ph.D.
Assistant Professor of Physics
Santa Clara University
bgr...@sc...
Phone: 408-551-1891
Fax: 408-554-6965
>>> ma...@ll... 09/30/05 11:21 AM >>>
OK, I am giving this a go.

I seem to be not setting a flag about some math functions availability.

Here are the details (aorry about the length of it but I snipped a lot!):

OSX 10.3.9, Python 2.4.1

Installed g77v3.4-bin.tar.gz from http://hpc.sourceforge.net/ as=20
described into /usr/local/...
Installed fftw-3.0.1-fma.tar.gz from=20
http://www.fftw.org/download.html into ~/Documents/local/... where I=20
have other libraries I have installed.

Got scipy_core-0.4.1.tar.gz from=20
http://sourceforge.net/project/showfiles.php?group_id=3D1369&package_id=3D=
6222,=20
wanted to try out the new replacement for Numeric

tar -zxvf scipy_core-0.4.1.tar.gz
cd scipy_core-0.4.1
python setup.py build
Assuming default configuration=20
(scipy/distutils/command/{setup_command,setup}.py was not found)
Appending scipy.distutils.command configuration to scipy.distutils
Assuming default configuration=20
(scipy/distutils/fcompiler/{setup_fcompiler,setup}.py was not found)
=2E..
Appending scipy.base configuration to scipy
blas_opt_info:
   FOUND:
     extra_link_args =3D ['-Wl,-framework', '-Wl,Accelerate']
     define_macros =3D [('NO_ATLAS_INFO', 3)]
     extra_compile_args =3D ['-faltivec',=20
'-I/System/Library/Frameworks/vecLib.framework/Headers']

lapack_opt_info:
   FOUND:
     extra_link_args =3D ['-Wl,-framework', '-Wl,Accelerate']
     define_macros =3D [('NO_ATLAS_INFO', 3)]
     extra_compile_args =3D ['-faltivec']

Appending scipy.lib configuration to scipy
Assuming default configuration=20
(scipy/fftpack/{setup_fftpack,setup}.py was not found)

=2E..
scipy_core version 0.4.1
running build
running config_fc
running build_src
building extension "scipy.base.multiarray" sources
creating build
creating build/src
creating build/src/scipy
creating build/src/scipy/base
Generating build/src/scipy/base/config.h
customize NAGFCompiler
customize AbsoftFCompiler
customize IbmFCompiler
Could not locate executable f77
customize GnuFCompiler
customize GnuFCompiler
=2E..
compiling C sources
gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp=20
-mno-fused-madd -fno-common -dynamic
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes'
creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build
creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src
creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy
creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base
creating build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base=
/src
compile options: '-Ibuild/src/scipy/base/src -Iscipy/base/include=20
-Ibuild/src/scipy/base -Iscipy/base/src
  -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -=
c'
gcc: build/src/scipy/base/src/umathmodule.c
In file included from build/src/scipy/base/src/umathmodule.c:8:
scipy/base/include/scipy/arrayobject.h:84: warning: redefinition of `usho=
rt'
/usr/include/sys/types.h:82: warning: `ushort' previously declared here
scipy/base/include/scipy/arrayobject.h:85: warning: redefinition of `uint=
'
/usr/include/sys/types.h:83: warning: `uint' previously declared here
build/src/scipy/base/src/umathmodule.c: In function `nc_floor_quotl':
build/src/scipy/base/src/umathmodule.c:1257: warning: implicit=20
declaration of function `floorl'
build/src/scipy/base/src/umathmodule.c: In function `nc_sqrtl':
build/src/scipy/base/src/umathmodule.c:1269: warning: implicit=20
declaration of function `sqrtl'
=2E..
build/src/scipy/base/__umath_generated.c:171: error: initializer=20
element is not constant
build/src/scipy/base/__umath_generated.c:171: error: (near=20
initialization for `arccosh_data[2]')
error: Command "gcc -fno-strict-aliasing -Wno-long-double=20
-no-cpp-precomp -mno-fused-madd -fno-common -dy
namic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes=20
-Ibuild/src/scipy/base/src -Iscipy/base/include -Ibuild/s
rc/scipy/base -Iscipy/base/src=20
-I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4=20
-c b
uild/src/scipy/base/src/umathmodule.c -o=20
build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/scipy/base
/src/umathmodule.o" failed with exit status 1


At 12:59 AM -0600 9/30/05, Travis Oliphant wrote:
>This is to announce the release of SciPy Core 0.4.X (beta)
>
>It is available at sourceforge which you can access by going to
>
>http://numeric.scipy.org
>
>Thanks to all who helped me with this release, especially
>
>Robert Kern
>Pearu Peterson
>
>Now, let's start getting this stable....
>
>-Travis Oliphant
>
>
>
>_______________________________________________
>SciPy-user mailing list
>Sci...@sc...
>http://www.scipy.net/mailman/listinfo/scipy-user


--=20
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Rob Managan               email managan at llnl.gov
LLNL                      phone: 925-423-0903
P.O. Box 808, L-095       FAX:   925-422-3389
Livermore, CA  94551-0808

_______________________________________________
SciPy-user mailing list
Sci...@sc...
http://www.scipy.net/mailman/listinfo/scipy-user


This message scanned for viruses and SPAM by GWGuardian at SCU (MGW1)

[Numpy-discussion] Release of SciPy Core 0.4 (Beta)

[Travis O. <oli...@ee...>]

This is to announce the release of SciPy Core 0.4.X (beta)

It is available at sourceforge which you can access by going to

http://numeric.scipy.org

Thanks to all who helped me with this release, especially

Robert Kern
Pearu Peterson

Now, let's start getting this stable....

-Travis Oliphant

Re: [Numpy-discussion] numarray: Possible hash collision problem

[<co...@ph...>]

"Edward C. Jones" <edc...@co...> writes:

> hash(numarray.arange(1000)) == hash(numarray.arange(10000))
>
> The hash value changes each time I enter the Python interpreter. I have 
> always assumed that hashing was deterministic. Is it?


Not suprising: I also get this:

hash(object()) == hash(object())

Looking through the source, I think the hash for an array is
determined by the object base class, and hence is the id() of the
array. The code above can be written long hand as

a = numarray.arange(1000)
ha = hash(a) # in this case, hash(a) == id(a)
del a
b = numarray.arange(10000)
hb = hash(b) # in this case, hash(b) == id(b)
del b
ha == hb

It's those (implicit) del statements that mean that a and b are stored
to the same location in memory, and hence have the same id(): there's
no other object created in the interpreter between when a is deleted
and b is created.

Basically, id() of a object is guaranteed to be unique *amongst all
active objects*. It is _not_ guaranteed to be different from objects
that have been created and destroyed.

This will return false:
a = numarray.arange(1000)
b = numarray.arange(10000)
hash(a) == hash(b)

as a and b still both exist.

Since arrays are mutable, there's no good way to get a content-based hash.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

[Numpy-discussion] numarray: Possible hash collision problem

[Edward C. J. <edc...@co...>]

hash(numarray.arange(1000)) == hash(numarray.arange(10000))

The hash value changes each time I enter the Python interpreter. I have 
always assumed that hashing was deterministic. Is it?

Re: [Numpy-discussion] Determining the condition number of matrix

[Piotr L. <lus...@cs...>]

Neilen Marais wrote:
> Hi
> 
> Does numeric have a facility to estimate the condition number of a matrix?
> 
> Thanks
> Neilen

The only way I can think of is through SVD:

import RandomArray as RA
import LinearAlgebra as LA

n = 100
a = RA.random((n, n))
vt, s, u = LA.singular_value_decomposition(a)

cond2 = s[0] / s[-1]
print cond2

The above code computes 2-norm condition number.

Since Numeric has only limited binding to LAPACK you should
probably look into SciPy that might have bindings to LAPACK's
condition number estimators.

Piotr

[Numpy-discussion] Determining the condition number of matrix

[Neilen M. <jun...@ch...>]

Hi

Does numeric have a facility to estimate the condition number of a matrix?

Thanks
Neilen


-- 
you know its kind of tragic 
we live in the new world
but we've lost the magic
-- Battery 9 (www.battery9.co.za)

Re: [Numpy-discussion] Piecewise functions.

[Andrea R. <ari...@pi...>]

On Sep 26, 2005, at 7:43 PM, Travis Oliphant wrote:

> This is not a trivial problem in current versions of Numeric.
>
> What are you using, Numeric, numarray?
>
> In new scipy core (which replaces Numeric) and, I think, in  
> numarray, you could say
>
> gta = x>a
> lea = x<=a
> y = x.copy()
> y[gta] = f2(x[gta])
> y[lea] = f1(x[lea])
>
> I've also just written a piecewise function for the new scipy core  
> so you could write
>
> y = piecewise(x, x<=a, [f1,f2])
>
> -Travis Oliphant

Yes I'm using Numeric, and in the short to middle term I'll stay with  
it. Anyway I'm aware of the effort you are spending in putting  
together a Numeric replacement, and I'll look forward for a stable  
release of it. In the meanwhile I'll use the tricks already suggested  
here.

Thanks again for your effort,
  Andrea.

Re: [Numpy-discussion] Piecewise functions.

[Travis O. <oli...@ee...>]

Andrea Riciputi wrote:

> Hi all,
> this is probably an already discussed problem, but I've not been able  
> to find a solution even after googling a lot.
>
> I've a piecewise defined function:
>
>        /
>        | f1(x)    if x <= a
> f(x) = |
>        | f2(x)    if x > a
>        \
>
> where f1 and f2 are not defined outside the above range. How can I  
> define such a function in Python in order to apply (map) it to an  
> array ranging from values smaller to values bigger than a?

This is not a trivial problem in current versions of Numeric.

What are you using, Numeric, numarray?

In new scipy core (which replaces Numeric) and, I think, in numarray, 
you could say

gta = x>a
lea = x<=a
y = x.copy()
y[gta] = f2(x[gta])
y[lea] = f1(x[lea])

I've also just written a piecewise function for the new scipy core so 
you could write

y = piecewise(x, x<=a, [f1,f2])

-Travis Oliphant

Re: [Numpy-discussion] Release of scipy core beta will happen next week.

[Gerard V. <ger...@gr...>]

On Sun, 25 Sep 2005 19:59:23 -0700
Robert Kern <rk...@uc...> wrote:

> > typedef unsigned char bool;
> > 
> > in arrayobject.h, because bool is a predefined type in C++.
> > 
> > I see the offending line is still in SVN (did not try to build it though).
> 
> Will this do the trick?
> 
> #ifndef __cplusplus
> typedef unsigned char bool;
> #define false 0
> #define true 1
> #endif /* __cplusplus */
> 
It works for my g++, but it may not be a general solution.

See footnote 15 under item 2 of section 5.3.3 of
http://www.open-std.org/jtc1/sc22/open/n2356/
(ISO C++ draft) saying that sizeof(bool) is 
not required to be 1.

Gerard

Re: [Numpy-discussion] python-numeric in FC4: good idea?

[Stephen W. <ste...@cs...>]

Fernando Perez wrote:

> Robert Kern wrote:
>
>> Can you make an RPM of python-numeric compiled against ATLAS and install
>> it yourself?
>
>
> You can.  In fact, Numeric builds out of the box with
>
> python bdist_rpm,
>
> though the package name comes out to be named 'Numeric', but that 
> should not be a problem, since the setup.cfg file reads:
>
> [bdist_rpm]
> provides=python-numeric, python-numeric-devel
> build_script=rpm_build.sh
> install_script=rpm_install.sh
>
> which means that the python-numeric dependency should be satisfied.

Yes, it is, and I sort of found that out myself.  Yum is much smarter 
about this than RPM apparently;  if I do

rpm -U Numeric-23.8-i386.rpm

rpm refuses to replace python-numeric-23.7 as distributed with FC4, but 
"yum install Numeric" when pointed at my local repo works fine.  As does 
"rpm -i --force" of course.

There is at least a verbal commitment at bugzilla.redhat.com from Redhat 
to migrate pygtk2 to the new array object when it comes out.

Re: [Numpy-discussion] python-numeric in FC4: good idea?

[Travis O. <oli...@ee...>]

Robert Kern wrote:

>Greg Ewing wrote:
>  
>
>>Chris Barker wrote:
>>
>>    
>>
>>>This is a Darn Good example of why we need the new array protocol.
>>>      
>>>
>>I came across another one the other day when working on
>>pygui. I wanted to use glReadPixels to read data into a
>>buffer belonging to an NSBitmapImageRep, but PyOpenGL's
>>glReadPixels can only read data into an existing memory
>>block if it's a Numeric array, and PyObjC doesn't know
>>anything about Numeric...
>>    
>>
>
>I've taken the liberty of adding these to a new Wiki page. Let's record
>these "Oh I wish everyone used the array protocol" moments when we come
>across them.
>
>http://www.scipy.org/wikis/featurerequests/ArrayInterfaceUseCases/
>  
>
This is a great idea.  It will help me sell an array_protocol_in_Python 
PEP to the Python Powers.

-Travis

Re: [Numpy-discussion] python-numeric in FC4: good idea?

[Robert K. <rk...@uc...>]

Greg Ewing wrote:
> Chris Barker wrote:
> 
>> This is a Darn Good example of why we need the new array protocol.
> 
> I came across another one the other day when working on
> pygui. I wanted to use glReadPixels to read data into a
> buffer belonging to an NSBitmapImageRep, but PyOpenGL's
> glReadPixels can only read data into an existing memory
> block if it's a Numeric array, and PyObjC doesn't know
> anything about Numeric...

I've taken the liberty of adding these to a new Wiki page. Let's record
these "Oh I wish everyone used the array protocol" moments when we come
across them.

http://www.scipy.org/wikis/featurerequests/ArrayInterfaceUseCases/

This will probably migrate to the Trac instance for scipy whenever that
comes about.

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

Re: [Numpy-discussion] python-numeric in FC4: good idea?

[Greg E. <gre...@ca...>]

Chris Barker wrote:

> This is a Darn Good example of why we need the new array protocol.

I came across another one the other day when working on
pygui. I wanted to use glReadPixels to read data into a
buffer belonging to an NSBitmapImageRep, but PyOpenGL's
glReadPixels can only read data into an existing memory
block if it's a Numeric array, and PyObjC doesn't know
anything about Numeric...

Greg

Re: [Numpy-discussion] python-numeric in FC4: good idea?

[Chris B. <Chr...@no...>]

Robert Kern wrote:
> Stephen Walton wrote:

>>So, questions are:  can someone more familiar with pygtk2 than me tell
>>me what parts of it depend on Numeric and why?  Can we start a campaign
>>to put ATLAS into Fedora Core if Numeric is going to be there too?
> 

> It's for returning a Numeric array from a pixbuf. 

This is a Darn Good example of why we need the new array protocol. Let's 
make sure to make sure it gets used as widely as possible.

-Chris

Re: [Numpy-discussion] python-numeric in FC4: good idea?

[Fernando P. <Fer...@co...>]

Robert Kern wrote:

> Can you make an RPM of python-numeric compiled against ATLAS and install
> it yourself? Or can you install Numeric yourself and make a dummy
> package to tell RPM that yes, indeed, Numeric is installed? I'm terribly
> unfamiliar with Fedora and RPM; I've always prefered Debian.

You can.  In fact, Numeric builds out of the box with

python bdist_rpm,

though the package name comes out to be named 'Numeric', but that should not 
be a problem, since the setup.cfg file reads:

[bdist_rpm]
provides=python-numeric, python-numeric-devel
build_script=rpm_build.sh
install_script=rpm_install.sh

which means that the python-numeric dependency should be satisfied.

If you really need to have the rpm be named python-numeric, this can be done 
by either writing out the spec file and fixing it by hand via:

python setup.py bdist_rpm --spec-only

or by changing the 'name' flag in the setup.py by hand to read 'python-config' 
instead of 'Numeric'.  If changing this name for rpms is a common need,  we 
can patch up setup.py to take an optional argument.

Cheers,

f

Re: [Numpy-discussion] Release of scipy core beta will happen next week.

[Robert K. <rk...@uc...>]

Gerard Vermeulen wrote:
> On Sat, 24 Sep 2005 22:51:27 -0600
> Travis Oliphant <oli...@ee...> wrote:
> 
>>At the SciPy 2005 conference I announced that I was hoping to get a beta 
>>of the new scipy (core) (aka Numeric3 aka Numeric Next Generation) 
>>released by the end of the conference.  
>>
>>This did not happen.  Some last minute features were suggested by 
>>Fernando Perez that I think will be relatively easy to add and make the 
>>release that much stronger. 
>>
>>Look for the beta announcement next week.
>>
>>For the impatient,  the svn server is always available:
>>
>>http://svn.scipy.org/svn/scipy_core/branches/newcore
>  
> Hi Travis,
> 
> when I tried a few months ago to compile one of my C++ Python modules with
> Numeric3, g++-3.4.3 choked on the line
> 
> typedef unsigned char bool;
> 
> in arrayobject.h, because bool is a predefined type in C++.
> 
> I see the offending line is still in SVN (did not try to build it though).

Will this do the trick?

#ifndef __cplusplus
typedef unsigned char bool;
#define false 0
#define true 1
#endif /* __cplusplus */

> Sorry for sitting on the bug so long;  the main reason is that at the time
> (I suppose it is still the case) Numeric3 does not coexist well with
> Numeric in the same Python interpreter (I remember import conflicts).
> If a typical Linux user wants to play with Numeric3, he has either to remove
> Numeric (and break possible dependencies) or build his own Python for Numeric3.
> I think that most Linux users are not going to do this and that it will take more
> than a year before distros make the move.  Hence, my lack of motivation for
> reporting bugs or giving it a real try.

scipy_core does not interfere with Numeric anymore. It's installed as
scipy (so it *will* interfere with previous versions of scipy).

While we're on the subject of bugs (for reference, I'm on OS X 10.4 with
Python 2.4.1):

* When linking umath.so, distutils is including a bare "-l" that causes
the link to fail (gcc can't interpret the argument). I have no idea
where it's coming from. Just after the Extension object for umath.so is
created, the libraries attribute is empty, just like the other Extension
objects.

* When linking against Accelerate.framework, it can't find cblas.h . I
have a patch in scipy.distutils.system_info for that (and also to remove
the -framework arguments for compiling; they're solely linker flags).

* setup.py looks for an optimized BLAS through blas_info, but getting
lapack_info is commented out. Is this deliberate?

* Despite comment lines claiming the contrary, scipy.linalg hasn't been
converted yet. basic_lite.py tries to import lapack and flapack.

* scipy.base.limits is missing (and is used in basic_lite.py).

Feature request:

* Bundle the include directory in with the package itself and provide a
function somewhere that returns the appropriate directory. People
writing setup.py scripts for extension modules that use scipy_core can
then do the following:

    from scipy.distutils import get_scipy_include
    ...
    someext = Extension('someext', include_dirs=[get_scipy_include(),
                                                 ...], ...)

This would help people who can't write to
sys.prefix+'/include/python2.4' and people like me who are trying to
package scipy_core into a PythonEgg (which doesn't yet support
installing header files to the canonical location).

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

Re: [Numpy-discussion] python-numeric in FC4: good idea?

[Robert K. <rk...@uc...>]

Stephen Walton wrote:
> In my ongoing struggles with FC4, I now find that the Fedora developers
> have put Numeric 23.7 into the core as python-numeric and built pygtk2
> against it, so the latter has a dependency on the former.
> 
> I think this is a bad idea unless the core developers are going to
> include ATLAS and build Numeric against it.  After all, this community
> and the Scipy one have gone to great lengths to optimize ATLAS and build
> Numeric and numarray (and presumably the new scipy core) against it. 
> But I'm probably not going to convince the Redhat folks on my own.
> 
> So, questions are:  can someone more familiar with pygtk2 than me tell
> me what parts of it depend on Numeric and why?  Can we start a campaign
> to put ATLAS into Fedora Core if Numeric is going to be there too?

It's for returning a Numeric array from a pixbuf. Strictly speaking,
it's optional, but it looks like the package maintainers decided to
compile it in for FC4.

Can you make an RPM of python-numeric compiled against ATLAS and install
it yourself? Or can you install Numeric yourself and make a dummy
package to tell RPM that yes, indeed, Numeric is installed? I'm terribly
unfamiliar with Fedora and RPM; I've always prefered Debian.

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

[Numpy-discussion] python-numeric in FC4: good idea?

[Stephen W. <ste...@cs...>]

In my ongoing struggles with FC4, I now find that the Fedora developers 
have put Numeric 23.7 into the core as python-numeric and built pygtk2 
against it, so the latter has a dependency on the former.

I think this is a bad idea unless the core developers are going to 
include ATLAS and build Numeric against it.  After all, this community 
and the Scipy one have gone to great lengths to optimize ATLAS and build 
Numeric and numarray (and presumably the new scipy core) against it.  
But I'm probably not going to convince the Redhat folks on my own.

So, questions are:  can someone more familiar with pygtk2 than me tell 
me what parts of it depend on Numeric and why?  Can we start a campaign 
to put ATLAS into Fedora Core if Numeric is going to be there too?

Re: [Numpy-discussion] Release of scipy core beta will happen next week.

[Gerard V. <ger...@gr...>]

On Sat, 24 Sep 2005 22:51:27 -0600
Travis Oliphant <oli...@ee...> wrote:

> 
> At the SciPy 2005 conference I announced that I was hoping to get a beta 
> of the new scipy (core) (aka Numeric3 aka Numeric Next Generation) 
> released by the end of the conference.  
> 
> This did not happen.  Some last minute features were suggested by 
> Fernando Perez that I think will be relatively easy to add and make the 
> release that much stronger. 
> 
> Look for the beta announcement next week.
> 
> For the impatient,  the svn server is always available:
> 
> http://svn.scipy.org/svn/scipy_core/branches/newcore
>
 
Hi Travis,

when I tried a few months ago to compile one of my C++ Python modules with
Numeric3, g++-3.4.3 choked on the line

typedef unsigned char bool;

in arrayobject.h, because bool is a predefined type in C++.

I see the offending line is still in SVN (did not try to build it though).


Sorry for sitting on the bug so long;  the main reason is that at the time
(I suppose it is still the case) Numeric3 does not coexist well with
Numeric in the same Python interpreter (I remember import conflicts).
If a typical Linux user wants to play with Numeric3, he has either to remove
Numeric (and break possible dependencies) or build his own Python for Numeric3.
I think that most Linux users are not going to do this and that it will take more
than a year before distros make the move.  Hence, my lack of motivation for
reporting bugs or giving it a real try.

Gerard

[Numpy-discussion] Release of scipy core beta will happen next week.

[Travis O. <oli...@ee...>]

At the SciPy 2005 conference I announced that I was hoping to get a beta 
of the new scipy (core) (aka Numeric3 aka Numeric Next Generation) 
released by the end of the conference.  

This did not happen.  Some last minute features were suggested by 
Fernando Perez that I think will be relatively easy to add and make the 
release that much stronger. 

Look for the beta announcement next week.

For the impatient,  the svn server is always available:

http://svn.scipy.org/svn/scipy_core/branches/newcore

-Travis O.

Re: [Numpy-discussion] Piecewise functions.

[Andrea R. <ari...@pi...>]

On Sep 23, 2005, at 1:24 PM, Paulo J. S. Silva wrote:

> Here is a slightly different solution, that is easier to my eyes and
> that can handle arguments in arbitrary order.
>
> It requires numarray (as it uses array indexing). If I understand well

> [snip]

Thanks,
it is exactly what I'm looking for. Unfortunately, I'm using Numeric,  
and I won't switch to numarray only for these feature; small arrays  
are too frequent in my applications. Anyway the method proposed by  
Gerard Vermeulen works too (thanks a lot Gerard!), and I'll stay with  
it, at least until Numeric3 won't be ready for the root-mean-square  
users. ;-)

Cheers,
  Andrea.

Re[2]: [Numpy-discussion] Piecewise functions.

[Alan G I. <ai...@am...>]

On Fri, 23 Sep 2005, Andrea Riciputi apparently wrote: 
> What I really need is a way to prevent f1 and f2 from 
> acting on those values of the 'x' array for which the 
> functions are not defined. 

The example I posted works with an array, which I called d. 
If you must feed the array to the function, just move the 
list comprehension inside of f.  Of course, you may find
list comprehension too slow for your application.
Alan Isaac 

Re: [Numpy-discussion] Piecewise functions.

[Paulo J. S. S. <pjs...@im...>]

Here is a slightly different solution, that is easier to my eyes and
that can handle arguments in arbitrary order. 

It requires numarray (as it uses array indexing). If I understand well
it should work woth the new scipy-core (Numeric3), but I haven't it
compiled here.

Obs: Probably f2 implementation is faster than f1.

Best,

Paulo

----

from numarray import *

def f1(x):
    """Implementation of:
    -1/(x-pi) for x < pi
    1/(x-pi) for x > pi
    """
    result = zeros(len(x), x.typecode())

    # First solution, probably slower, but clear.
    result[x < pi] = -1/(x[x < pi]-pi)
    result[x > pi] = 1/(x[x > pi]-pi)
    return result

def f2(x):
    """Second Iplementation of:
    -1/(x-pi) for x < pi
    1/(x-pi) for x > pi
    """
    result = zeros(len(x), x.typecode())

    # Second solution, probably faster as where returns only
    # the correct indexes.
    small = where(x < pi)
    big = where(x > pi)
    result[small] = -1/(x[small]-pi)
    result[big] = 1/(x[big]-pi)
    return result

x = arange(0, 10, 1, Float)
print f1(x)
print f2(x)
print abs(1/(x-pi))

# It uses the default value for pi.
api = array([pi])
print f1(api)
print f2(api)

Re: [Numpy-discussion] Piecewise functions.

[Gerard V. <ger...@gr...>]

On Thu, 22 Sep 2005 17:44:59 +0200
Andrea Riciputi <ari...@pi...> wrote:

> Hi all,
> this is probably an already discussed problem, but I've not been able  
> to find a solution even after googling a lot.
> 
> I've a piecewise defined function:
> 
>         /
>         | f1(x)    if x <= a
> f(x) = |
>         | f2(x)    if x > a
>         \
> 
> where f1 and f2 are not defined outside the above range. How can I  
> define such a function in Python in order to apply (map) it to an  
> array ranging from values smaller to values bigger than a?
> 
This does maybe what you want:

from scipy import *

def f(x):
    """Approximative implementation of:
    -1/(x-pi) for x < pi
    1/(x-pi) for x > pi
    """
    result = zeros(len(x), x.typecode())
    i = argmin(abs(x-pi))
    # you may have to tweak i here, because it may be off by 1
    result[:i+1] = -1/(x[:i+1]-pi)
    result[i+1:] = 1/(x[i+1:]-pi)
    return result

x = arange(0, 10, 1, Float)
print f(x)
print abs(1/(x-pi))

Gerard

[Numpy-discussion] array indexing in numarray

[Joost v. E. <joo...@gm...>]

Hi list,

I have two questions on numarray indexing:
1) does anyone know an elegant way to assign values to a non-contiguous
slice. Like:

        In [1]:from numarray import *
        
        In [2]:a = arange(25).resize((5,5))
        
        In [3]:a
        Out[3]:
        array([[ 0,  1,  2,  3,  4],
               [ 5,  6,  7,  8,  9],
               [10, 11, 12, 13, 14],
               [15, 16, 17, 18, 19],
               [20, 21, 22, 23, 24]])
        
        In [4]:i = [1,3]
        
        In [5]:transpose(a[i])[i]=1

	----------------------------------------------------------------
        exceptions.ValueError                                Traceback
        (most recent call last)
        
        ...
        
        ValueError: Invalid destination array: partial indices require
        contiguous non-byteswapped destination
        
2) And second: why didn't you choose to return all combinations of
indices:

        In [8]:a[i,i]
        Out[8]:array([ 6, 18])

Where I, in my humble opinion, would prefer to see all possible
combinations. e.g. a[[1,3],[1,3]] = a[[1,1,3,3],[1,3,1,3]]

Anyone has an idea how to easyly obtain this behaviour?

Greets+thanks,
Joost