On Wed, Nov 26, 2008 at 8:54 AM, Peter Norton
<[EMAIL PROTECTED]> wrote:
>
> scons: warning: Ignoring missing SConscript
> 'build/scons/numpy/core/SConscript'
> File
> "/usr/local/python-2.5.1/lib/python2.5/site-packages/numscons-0.9.4-py2.5.egg/numscons/core/numpyenv.py",
> line 108, in Distutils
Is there a 2D phase unwrapping for python?
I read a presentation by GERI (http://www.ljmu.ac.uk/GERI) that their code is
implemented in scipy, but I could not find it.
Nadav.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://project
I'm pleased to announce the first beta release of SciPy 0.7.0.
SciPy is a package of tools for science and engineering for Python.
It includes modules for statistics, optimization, integration, linear
algebra, Fourier transforms, signal and image processing, ODE solvers,
and more.
This beta relea
Pierre GM wrote:
On Nov 25, 2008, at 10:02 PM, Ryan May wrote:
Pierre GM wrote:
* Your locked version of update won't probably work either, as you
force
the converter to output a string (you set the status to largest
possible, that's the one that outputs strings). Why don't you set the
status
Charles R Harris wrote:
>
>
> What happens if you go the usual python setup.py {build,install} route?
Won't go far since it does not handle sunperf.
David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/lis
On Tue, Nov 25, 2008 at 21:57, Ryan May <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm running on a 64-bit machine, and see the following:
>
> >numpy.array(64.6).dtype
> dtype('float64')
>
> >numpy.array(64).dtype
> dtype('int64')
>
> Is there any function/setting to make these default to 32-bit types
Hi,
I'm running on a 64-bit machine, and see the following:
>numpy.array(64.6).dtype
dtype('float64')
>numpy.array(64).dtype
dtype('int64')
Is there any function/setting to make these default to 32-bit types
except where necessary? I don't mean by specifying dtype=numpy.float32
or dtype=num
Pierre GM wrote:
> On Nov 25, 2008, at 10:02 PM, Ryan May wrote:
>> Pierre GM wrote:
>>> * Your locked version of update won't probably work either, as you
>>> force
>>> the converter to output a string (you set the status to largest
>>> possible, that's the one that outputs strings). Why don't y
On Nov 25, 2008, at 10:02 PM, Ryan May wrote:
> Pierre GM wrote:
>>
>> * Your locked version of update won't probably work either, as you
>> force
>> the converter to output a string (you set the status to largest
>> possible, that's the one that outputs strings). Why don't you set the
>> status
Pierre GM wrote:
> Ryan,
> Quick comments:
>
> * I already have some unittests for StringConverter, check the file I
> attach.
Ok, great.
> * Your str2bool will probably mess things up in upgrade compared to the
> one JDH had written (the one I send you): you don't wanna use
> int(bool(value)
On Tue, Nov 25, 2008 at 4:54 PM, Peter Norton <
[EMAIL PROTECTED]> wrote:
> Back in the beginning of the summer, I jumped through a lot of hoops to
> build numpy+scipy on solaris, 64-bit with gcc. I received a lot of help from
> David C., and ended up, by some very ugly hacking, building an accept
Back in the beginning of the summer, I jumped through a lot of hoops to
build numpy+scipy on solaris, 64-bit with gcc. I received a lot of help from
David C., and ended up, by some very ugly hacking, building an acceptable
numpy+scipy+matplotlib trio for use at my company.
However, I'm back at it
On Tue, Nov 25, 2008 at 5:00 PM, Pierre GM <[EMAIL PROTECTED]> wrote:
> All, another question:
> What's the best way to have some kind of sandbox for code like the one Ryan
> is writing ? So that we can try it, modify it, without commiting anything to
> SVN yet ?
>
Probably make a branch and do
Ryan,
Quick comments:
* I already have some unittests for StringConverter, check the file I
attach.
* Your str2bool will probably mess things up in upgrade compared to
the one JDH had written (the one I send you): you don't wanna use
int(bool(value)), as it'll always give you 0 or 1 when
Pierre GM wrote:
Sounds like a plan. Wouldn't mind getting more feedback from fellow
users before we get too deep, however...
Ok, I've attached, as a first cut, a diff against SVN HEAD that does (I
think) what I'm looking for. It passes all of the old tests and passes
my own quick test. A
Oh don't mention...
However, I'd be quite grateful if you could give an eye to the pb of
mixing np.scalars and 0d subclasses of ndarray: looks like it's a C
pb, quite out of my league...
http://scipy.org/scipy/numpy/ticket/826
http://article.gmane.org/gmane.comp.python.numeric.general/26354/ma
Pierre GM wrote:
> OK then, I'll take care of that over the next few weeks...
>
>
Thanks Pierre.
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
John Hunter wrote:
> On Tue, Nov 25, 2008 at 12:16 PM, Pierre GM <[EMAIL PROTECTED]> wrote:
>
>
>> A la mlab.csv2rec ? It could work with a bit more tweaking, basically
>> following John Hunter's et al. path. What happens when the column names are
>> unknown (read from the header) or wrong ?
>>
OK then, I'll take care of that over the next few weeks...
On Nov 25, 2008, at 4:56 PM, John Hunter wrote:
> On Tue, Nov 25, 2008 at 2:01 PM, Pierre GM <[EMAIL PROTECTED]>
> wrote:
>>
>> On Nov 25, 2008, at 2:26 PM, John Hunter wrote:
>>>
>>> Yes, I've said on a number of occasions I'd like to
On Tue, Nov 25, 2008 at 2:01 PM, Pierre GM <[EMAIL PROTECTED]> wrote:
>
> On Nov 25, 2008, at 2:26 PM, John Hunter wrote:
>>
>> Yes, I've said on a number of occasions I'd like to see these
>> functions in numpy, since a number of them make more sense as numpy
>> methods than as stand alone functio
On Nov 25, 2008, at 3:33 PM, Ryan May wrote:
>
> You couldn't run this loop on the array returned by np.loadtxt() (by
> masking on the appropriate fill value)?
Yet an extra loop... Doable, yes... But meh.
___
Numpy-discussion mailing list
Numpy-discuss
Pierre GM wrote:
> Nope, we still need to double check whether there's any missing data
> in any field of the line we process, independently of the conversion.
> So there must be some extra loop involved, and I'd need a special
> function in numpy.ma to take care of that. So our options are
>
>> It shouldn't create any *extra* temporaries since we already make a
>> list
> of lists before creating the final array. It just introduces an extra
> looping step. (I'd reuse the existing list of lists).
Cool then, go for it.
> If my understanding of
> StringConverter is correct, tweaking
> On Nov 25, 2008, at 2:37 PM, Ryan May wrote:
>> What about doing the parsing and type inference in a loop and holding
>> onto the already split lines? Then loop through the lines with the
>> converters that were finally chosen? In addition to making my usecase
>> work, this has the benefit of n
On Nov 25, 2008, at 2:26 PM, John Hunter wrote:
>
> Yes, I've said on a number of occasions I'd like to see these
> functions in numpy, since a number of them make more sense as numpy
> methods than as stand alone functions.
Great. Could we think about getting that on for 1.3x, would you have
t
Pierre GM wrote:
> On Nov 25, 2008, at 2:06 PM, Ryan May wrote:
>> 1) It looks like the function returns a structured array rather than a
>> rec array, so that fields are obtained by doing a dictionary access.
>> Since it's a dictionary access, is there any reason that the header
>> needs to be mun
On Tue, Nov 25, 2008 at 12:16 PM, Pierre GM <[EMAIL PROTECTED]> wrote:
> A la mlab.csv2rec ? It could work with a bit more tweaking, basically
> following John Hunter's et al. path. What happens when the column names are
> unknown (read from the header) or wrong ?
>
> Actually, I'd like John to co
On Nov 25, 2008, at 2:06 PM, Ryan May wrote:
>
> 1) It looks like the function returns a structured array rather than a
> rec array, so that fields are obtained by doing a dictionary access.
> Since it's a dictionary access, is there any reason that the header
> needs to be munged to replace chara
Pierre GM wrote:
> Ryan,
> FYI, I've been coding over the last couple of weeks an extension of
> loadtxt for a better support of masked data, with the option to read
> column names in a header. Please find an example below (I also have
> unittest). Most of the work is actually inspired from mat
Thx Pierre,
don't worry about it it's not a show stopper at all
C.
On Nov 24, 2008, at 12:04 PM, Pierre GM wrote:
> Charles,
> Confirmed on my machine...
> I gonna have to clean ma.sort, as there are indeed some temporaries
> that probably don't need to be created. I must warn you however that
Pierre GM wrote:
>> would it possible to specify column header, rather than number here?
>
> A la mlab.csv2rec ?
I'll have to take a look at that.
> following John Hunter's et al. path. What happens when the column
> names are unknown (read from the header) or wrong ?
well, my use case is tha
On Nov 25, 2008, at 12:30 PM, Christopher Barker wrote:
>
> """
> missing : string, optional
> A string representing a missing value, irrespective of the
> column where it appears (e.g., ``'missing'`` or ``'unused'``.
> """
>
> It might be nice if "missing" could be a sequence of strings,
On Wed, Nov 26, 2008 at 12:59 AM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> Apart from the Mac, the ppc can be configured to run either bigendian or
> littleendian, so the hardware encompasses more than just the cpu, it's the
> whole darn board.
Yep, many CPU families have double endian supp
Pierre GM wrote:
> FYI, I've been coding over the last couple of weeks an extension of
> loadtxt for a better support of masked data, with the option to read
> column names in a header. Please find an example below
great, thanks! this could be very useful to me.
Two comments:
"""
missing : st
All,
Sorry to bump my own post, and I was kinda threadjacking anyway:
Some functions of numy.ma (eg, ma.max, ma.min...) accept explicit
outputs that may not be MaskedArrays.
When such an explicit output is not a MaskedArray, a value that should
have been masked is transformed into np.nan.
Tha
Ryan,
FYI, I've been coding over the last couple of weeks an extension of
loadtxt for a better support of masked data, with the option to read
column names in a header. Please find an example below (I also have
unittest). Most of the work is actually inspired from matplotlib's
mlab.csv2re
On 24 Nov 2008, at 19:45 , Francesc Alted wrote:
> standards in computer science. For example, where Python writes:
>
> asin, acos, atan, asinh, acosh, atanh
>
> NumPy choose:
>
> arcsin, arccos, arctan, arcsinh, arccosh, arctanh
>
> So, IMHO, I think it would be better to rename the inverse
>
On Nov 24, 2008, at 5:55 PM, Jarrod Millman wrote:
> On Mon, Nov 24, 2008 at 10:45 AM, Francesc Alted
> <[EMAIL PROTECTED]> wrote:
>> So, IMHO, I think it would be better to rename the inverse
>> trigonometric
>> functions from ``arc*`` to ``a*`` prefix. Of course, in order to do
>> that cor
Hi Nadav
2008/8/6 Nadav Horesh <[EMAIL PROTECTED]>:
> I made the following modification to the source code, I hope it is ready to
> be included in scipy.
>
> Added a BSD licence declaration.
> Small optimisation.
> The code is split into a cython back-end and a python front-end.
>
> All remarks a
On Tue, Nov 25, 2008 at 8:03 AM, David Cournapeau <[EMAIL PROTECTED]>wrote:
> On Tue, Nov 25, 2008 at 10:55 PM, David Cournapeau
> <[EMAIL PROTECTED]> wrote:
>
> >
> > I used the path of least resistance: instead of using the
> > WORDS_BIGENDIAN macro, I added a numpy header which gives the endian
On Tue, Nov 25, 2008 at 10:55 PM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
>
> I used the path of least resistance: instead of using the
> WORDS_BIGENDIAN macro, I added a numpy header which gives the endianness
> every time it is included. IOW, instead of the endianness to be fixed at
> numpy
Hi,
I have a couple more changes to loadtxt() that I'd like to code up in time
for 1.3, but I thought I should run them by the list before doing too much
work. These are already implemented in some fashion in
matplotlib.mlab.csv2rec(), but the code bases are different enough, that
pretty much onl
David Cournapeau wrote:
> Pierre GM wrote:
>
>> FYI,
>> I can't reproduce David's failures on my machine (intel core2 duo w/
>> 10.5.5)
>> * python 2.6 from macports
>>
>>
>
> I think that's the main difference. I feel more and more that the
> problem is linked to fat binaries (more ex
Exactly what I thought this morning ;)
I'm reading your PhD thesis, Chris, it's great !
Matthieu
2008/11/25 Brian Granger <[EMAIL PROTECTED]>:
> Chris,
>
> Wow, this is fantastic...both the BSD license and the x86 support. I
> look forward to playing with this!
>
> Cheers,
>
> Brian
>
> On Mon,
2008/11/24 Sébastien Barthélemy <[EMAIL PROTECTED]>:
> Are you sure ? Here it reports
> ValueError: setting an array element with a sequence.
> probably because theta, sintheta and costheta are 1-d arrays of n>1 elements.
Sorry, I missed that detail.
Cheers
Stéfan
2008/11/24 Chris Barker <[EMAIL PROTECTED]>:
> Robert Kern wrote:
>>> Jim Vickroy wrote:
>>> While using the PIL interface to numpy, I rediscovered a logic error
>>> in the PIL.Image.fromarray() procedure. The problem (and a solution)
>>> was mentioned earlier at:
>
>> Tell them that we approve of
Pierre GM wrote:
> FYI,
> I can't reproduce David's failures on my machine (intel core2 duo w/
> 10.5.5)
> * python 2.6 from macports
>
I think that's the main difference. I feel more and more that the
problem is linked to fat binaries (more exactly multi arch build in one
autoconf run: since
FYI,
I can't reproduce David's failures on my machine (intel core2 duo w/
10.5.5)
* python 2.6 from macports
* numpy svn 6098
* GCC 4.0.1 (Apple Inc. build 5488)
I have only 1 failure:
FAIL: test_umath.TestComplexFunctions.test_against_cmath
--
A Monday 24 November 2008, Jarrod Millman escrigué:
> On Mon, Nov 24, 2008 at 10:45 AM, Francesc Alted <[EMAIL PROTECTED]>
wrote:
> > So, IMHO, I think it would be better to rename the inverse
> > trigonometric functions from ``arc*`` to ``a*`` prefix. Of course,
> > in order to do that correctly
49 matches
Mail list logo
