2008/9/16 David Cournapeau <[EMAIL PROTECTED]>:
>> I expanded the mathml module in the reference guide source to handle
>> constructs as they came up. I never did try to do matrices, though,
>> so it's quite likely that it hasn't been implemented.
>
> Does that mean you have to implement latex par
Hi Brendan
2008/9/16 brendan simons <[EMAIL PROTECTED]>:
> #interpolate the green pixels from the bayer filter image ain
> g = greenMask * ain
> gi = g[:-2, 1:-1].astype('uint16')
> gi += g[2:, 1:-1]
> gi += g[1:-1, :-2]
> gi += g[1:-1, 2:]
> gi /= 4
> gi += g[1:-1, 1:-1]
> return gi
I may be com
Hi David
2008/9/16 David Cournapeau <[EMAIL PROTECTED]>:
> I managed to get further, but I don't get what I want. A minimal latex
> code which has the problem is the following
>
> .. math:: \begin{matrix}x \\ y \end{array}
>
> This shows correctly with latex, but not with html (which shows xy
> in
2008/9/15 Achim Gaedke <[EMAIL PROTECTED]>:
> Hi there!
>
> Consider this python program (saved as locale_trouble.py):
This has already been filed as
http://projects.scipy.org/scipy/numpy/ticket/902
Please add any additional info to that ticket.
Thanks!
Stéfan
__
2008/9/15 Gael Varoquaux <[EMAIL PROTECTED]>:
>> I agree. But that means that we can only include it in 1.3 (which is
>> currently being developed on trunk, IIRC?).
>
> I'd prefer not seeing any non-backwards-compatible API change before 2.0.
> I think we would be breaking the contract that we hav
Promotion Market – this is an incredible income opportunity never
seen
before.
- No special skills required
- No Up Front Investment Required
- Work from home
- We build you a team first before you decide to start the business
- We provide two websites for you to operate which are two internet
ma
2008/9/13 Travis E. Oliphant <[EMAIL PROTECTED]>:
> Generally, it is O.K. except that he changes the output from a numpy
> array to a list of numpy arrays. This is a small change, but it is an
> API change. I'm not sure why he found it necessary to do that, but it
> would be easier to apply the
Hey all,
David Kaplan implemented a generalised ogrid/mgrid, and would like to
have some feedback. See
http://projects.scipy.org/pipermail/numpy-discussion/2008-August/036691.html
for his original email and attachment.
If no one objects to such functionality, I shall review the patch and apply
2008/9/10 Christopher Barker <[EMAIL PROTECTED]>:
> http://scipy.org/scipy/numpy/ticket/909
>
> ( By the way, is there a way to fix the typo in the ticket title? --oops!)
Fixed.
Thanks a lot for writing this up!
Cheers
Stéfan
___
Numpy-discussion maili
2008/9/10 Travis E. Oliphant <[EMAIL PROTECTED]>:
> The post is
>
> http://blog.enthought.com/?p=62
Very cool post, thank you! I agree that it would be great to have
such a mechanism in NumPy.
Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discu
2008/9/9 Christopher Barker <[EMAIL PROTECTED]>:
> Jarrod Millman wrote:
>> So if there is something that you would like to work on during this
>> release cycle, please bring it up now.
>
> Anyone want to help with improvements to fromfile() for text files?
This is low hanging fruit for anyone wi
2008/9/4 Robert Kern <[EMAIL PROTECTED]>:
> I am confused. add() and subtract() *do* take an out argument.
So it does. We both tried a keyword-style argument, which I think is
a reasonable expectation?
Cheers
Stéfan
___
Numpy-discussion mailing list
Nu
Hey all,
Gael just asked me why `add`, `subtract` etc. didn't have out
arguments like `cos` and `sin`. I couldn't give him a good answer.
Could we come to an agreement to add a uniform interface to ufuncs for
1.3? Either all or none of them should support the out argument.
I see a couple of "d
2008/8/31 Alan G Isaac <[EMAIL PROTECTED]>:
> Thanks. So if I wish to determine the current
> state of documentation, is the right place to go:
> http://sd-2116.dedibox.fr/pydocweb/doc/ ?
Jarrod,
Could we set up a reverse proxy on doc.scipy.org to serve these pages
(until we move the app over to
2008/8/29 Christopher Barker <[EMAIL PROTECTED]>:
> How can I do this without another line of code special casing the 0,
> which isn't that big I deal, but it seems kind of ugly...
>
> >>> a[a==0] = min_value
> >>> np.sign(a) * np.maximum(np.abs(a), min_value)
> array([ 2, 2, 2, 3, 4, -5])
M
2008/8/29 Charles R Harris <[EMAIL PROTECTED]>:
>> I like that idea. A lot of numpy functions return a reference to the
>> modified array when the output array (out) is specified.
>
> Google up the various discussions of python sort to see why Guido doesn't
> like that sort of thing. We've had that
2008/8/28 Andrew Straw <[EMAIL PROTECTED]>:
> Jarrod Millman wrote:
>> On Thu, Aug 28, 2008 at 7:48 AM, Travis E. Oliphant
>> <[EMAIL PROTECTED]> wrote:
>>
>>> +1 on what Andrew said.
>>>
>>
>> I don't really care that much, but I do think API is better than
>> FEATURE. I would think that there ma
2008/8/28 Matthew Brett <[EMAIL PROTECTED]>:
> np.multiply.outer, always returns an ndarray type, regardless of the
> subtypes it is passed.
Sorry, I don't know what I was thinking. You are right!
Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-d
2008/8/26 Anne Archibald <[EMAIL PROTECTED]>:
> 2008/8/22 Catherine Moroney <[EMAIL PROTECTED]>:
>> I'm looking for a way to acccomplish the following task without lots
>> of loops involved, which are really slowing down my code.
>>
>> I have a 128x512 array which I want to break down into 2x2 squa
Hi Neil
2008/8/26 Neil Crighton <[EMAIL PROTECTED]>:
>>
>> - Should we have a separate User manual and a Reference manual, or only
>> a single manual?
>>
>
> Are there still plans to write a 10 page 'Getting started with NumPy'
> document? I think this would be very useful. Ideally a 'getting st
Hey Matthew
2008/8/27 Matthew Brett <[EMAIL PROTECTED]>:
> In [148]: type(np.multiply(arr, obj)) # this is what I expected
> Out[148]:
>
> In [149]: type(np.multiply.outer(arr, obj)) # this is not - I expected
> class A again
> Out[149]:
Since both those objects have an __array_priority__ of 0.
2008/8/23 Travis E. Oliphant <[EMAIL PROTECTED]>:
> By the way, as promised, the NumPy book is now available for download
> and the source to the book is checked in to the numpy SVN tree:
>
> http://svn.scipy.org/svn/numpy/trunk/numpy/doc/numpybook
We just reorganised the docs somewhat, so this U
Hey all,
Now that we have switched to Nose as a test framework, we should look
into deprecating ParametricTestCase. Alan, have you looked into this
before?
Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy
2008/8/21 William Reade <[EMAIL PROTECTED]>:
> Line 532 of numerictypes.py reads "_unicodesize =
> array('u','U1').itemsize", but _unicodesize itself does not appear to be
> referenced anywhere else. My questions are:
I removed this in r5674.
Regards
Stéfan
___
Hi all,
This is my personal recollection of the documentation BoF. Feel free to
comment or correct the text below.
Regards
Stéfan
Summary of the Documentation Birds-of-a-Feather Session
===
Topics proposed for discussion
Hi Hanno
2008/8/22 Hanno Klemm <[EMAIL PROTECTED]>:
> yes, indeed, that's what I thought. This result is odd. Has correlate
> been changed since version 1.0.4, or should I submit this as a bug?
Is there any way that you could try out the latest release on your
machine and see if it solves your pr
2008/8/21 Stéfan van der Walt <[EMAIL PROTECTED]>:
> I currently have "Solaris 10 SPARC" reserved for you. Would you like
> another one for MacOSX 64?
I have re-activated the configuration for Solaris 10 SPARC.
Regards
Stéfan
__
2008/8/21 Michael Abshoff <[EMAIL PROTECTED]>:
> Stéfan van der Walt wrote:
>> 2008/8/21 Michael Abshoff <[EMAIL PROTECTED]>:
>>> William Stein is at Scipy 08 and there seems to be at least some
>>> interest in 64 bit OSX binaries. If anyone wants one let
2008/8/21 Michael Abshoff <[EMAIL PROTECTED]>:
> William Stein is at Scipy 08 and there seems to be at least some
> interest in 64 bit OSX binaries. If anyone wants one let me know and I
> can put one together once Scipy 0.7 and Numpy 1.1.2 are out.
There is still interest in having a 64-bit OSX b
2008/8/20 Hanno Klemm <[EMAIL PROTECTED]>:
> In [29]: x = array([0.,0.,1, 0, 0])
> In [35]: y1 = array([1,0,0,0,0])
>
> In [36]: correlate(x,y1,mode='full')
> Out[36]: array([ 0., 0., 0., 0., 0., 0., 1., 0., 0.])
That doesn't look right. Under r5661:
In [60]: np.convolve([0, 0, 1, 0, 0],
Hi Mark
2008/8/19 mark <[EMAIL PROTECTED]>:
> Hello List -
>
> I am looking for a good polygon class.
>
> My main interest it to be able to figure out if a point is inside or
> outside the polygon, which can have any shape (well, as long as it is
> a polygon).
>
> Any suggestions?
I have optimise
2008/8/18 Gael Varoquaux <[EMAIL PROTECTED]>:
> I actually think PEP 225 is pretty good. I have not big opinion about "~"
> vs "@".
Both of these already have meanings ("boolean not" and "decorator"),
so it's pretty much a toss-up for me. In a way, the concept of a
decorator could still apply:
@
2008/8/18 Andrew Dalke <[EMAIL PROTECTED]>:
> How do users know that those are present? How do users
> view those docs? You're the one who added that directory, yes?,
> so you've probably got the most experience with it. I
> couldn't figure out it, and the README in the doc/ directory
> wasn't h
2008/8/18 Travis E. Oliphant <[EMAIL PROTECTED]>:
>> I still think we are going about this the wrong way. We have two
>> different sets of expectations, and we can't satisfy both by ripping
>> everything apart. I'd much prefer two entry points into NumPy: one
>> for people who need speed, and one
2008/8/18 Travis E. Oliphant <[EMAIL PROTECTED]>:
> I say go ahead including changing #1 and #4. Let's leave 5 for the moment.
I ran several benchmarks and made sure that these imports take a
minimal amount of time. Wouldn't we want users to have access with
the doc framework without doing anyth
2008/8/17 Robert Kern <[EMAIL PROTECTED]>:
> I suggested that we move it to a branch for the time being so we can
> play with it and come up with examples of its use.
That branch is here:
http://[EMAIL PROTECTED]/svn/numpy/branches/gen_ufuncs
Stéfan
__
2008/8/17 Charles R Harris <[EMAIL PROTECTED]>:
> I have nothing against extensions when they can be made to serve. If a
> dictionary gets added to ndarrays I hope it is done that way, likewise for
> generalized ufuncs. In the present case I think Travis wants to preserve the
> functionality while
2008/8/16 Andrew Straw <[EMAIL PROTECTED]>:
> Looking at the code, but not testing it -- this looks fine to me. (I
> wrote the original NPY_VERSION stuff and sent it to Travis, who modified
> and included it.)
>
> I have added a couple of extremely minor points to the code review tool
> -- as much
Hi all,
I have moved the generalised ufuncs functionality off to a branch:
http://svn.scipy.org/svn/numpy/branches/gen_ufuncs
Please try it out and give us your feedback. We shall also pound on
it at the sprint during SciPy'08, and thereafter decide how and when
to best integrate it into NumPy.
The current NumPy API number, stored as NPY_VERSION in the header files, needs
to be incremented every time the NumPy C-API changes. The counter tells
developers with exactly which revision of the API they are dealing. NumPy does
some checking to make sure that it does not run against an old vers
2008/8/15 Andrew Dalke <[EMAIL PROTECTED]>:
> I don't think it's enough. I don't like environmental
> variable tricks like that. My tests suggest:
> current SVN: 0.12 seconds
> my patch: 0.10 seconds
> removing some top-level imports: 0.09 seconds
> my patch and removing some
> addit
2008/8/15 Robert Kern <[EMAIL PROTECTED]>:
> I'm afraid that I still don't understand. Please expand on the
Sorry, it's late. My explanation is probably not too lucid.
The variable should rather read something like NUMPY_VIA_API, but here goes.
> 1) NUMPY_FAST_IMPORT=0 (or simply absent)
> i
2008/8/15 Robert Kern <[EMAIL PROTECTED]>:
> The devil is in the details. What exactly do you propose? When we
> discussed this last time, the participants more or less agreed that
> environment variables could cause more fragility than they're worth.
> It also breaks the first time you try to impo
2008/8/15 Travis E. Oliphant <[EMAIL PROTECTED]>:
> So, what is the attitude of people here? Here's my take:
I wonder if we are going about this process the right way. We will
forever be adjusting imports to improve load times. Why don't we
provide an alternate API, something like numpy.api fr
2008/8/15 Jarrod Millman <[EMAIL PROTECTED]>:
> On Thu, Aug 14, 2008 at 9:05 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
>> Can we fix the ticket notification mailings some day? It's been almost four
>> months now.
>
> It should work now. Let me know if you aren't getting them now.
Thanks,
2008/8/14 Charles R Harris <[EMAIL PROTECTED]>:
> I notice that you have merged some new ufunc infrastructure. I think these
For those of you who were wondering, this is the ticket that this
conversation refers to:
http://projects.scipy.org/scipy/numpy/ticket/887
Stéfan
_
Hi Charles
2008/8/14 Charles R Harris <[EMAIL PROTECTED]>:
> Re: the patch. I noticed the replacement of the signed type int by an
> unsigned size_t. This is a risky sort of thing and needs to be checked. Nor
> is it clear we should use size_t instead of one of the python or numpy
> types. The use
2008/8/13 Robert Cimrman <[EMAIL PROTECTED]>:
>> Yeah, that's why I think not many people used the extra return anyway.
>> I will do as you say unless somebody steps in.
>
> ... but not before August 25, as I am about to leave on holidays and
> have not managed to do it yet. I do not want to mess w
2008/8/12 Barry Wark <[EMAIL PROTECTED]>:
> Stefan,
>
> I'm sorry I dropped the ball on this one. I didn't have time to get
> things working again before I left town for a month and, obviously,
> there it sat. Again, sorry.
No worries, Barry. That machine was troublesome, and I didn't want to
bot
Hi Andrew
2008/8/12 Andrew Dalke <[EMAIL PROTECTED]>:
> This is buggy for the case of a list containing only NaNs.
>
> >>> import numpy as np
> >>> np.NAN
> nan
> >>> np.min([np.NAN])
> nan
> >>> np.nanmin([np.NAN])
> inf
> >>>
Thanks for the report. This should be fixed in r5630.
Regards
Hi all,
I've given ticket #750 a shot. Since I was not previously familiar
with SWIG, I would appreciate it if those of you who know it could
take a look at the proposed patch:
http://codereview.appspot.com/2890
Thanks for your time,
Stéfan
___
Numpy-
2008/8/11 Charles Doutriaux <[EMAIL PROTECTED]>:
> Seems to me like min should automagically call nanmin if it spots any
> nan no ?
Nanmin is quite a bit slower:
In [2]: x = np.random.random((5000))
In [3]: timeit np.min(x)
1 loops, best of 3: 24.8 µs per loop
In [4]: timeit np.nanmin(x)
1
Hi all,
Due to hardware failure, we recently lost another of our build slaves.
OSX is one of our primary deployment platforms, so I'd like to
replace this one. If you have a mac available with good network
connectivity, please consider volunteering it as a buildslave (setup
should not take more
2008/8/11 Robert Cimrman <[EMAIL PROTECTED]>:
>>> Note also that the order of outputs has changed (previously unique1d()
>>> returned (i, b) for return_index=True).
>>
>> Does this not constitute an API change?
>
> It does. Are there many users of unique1d( a, return_index=True ) out there?
>
> The
2008/8/7 Nadav Horesh <[EMAIL PROTECTED]>:
> The 0 padding is easy in numpp/pylab as in octave/matlab, by just adding one
> argument. In pylab it is the "a" keyword:
>
> y = fft(x, n=2*len(x))
Just be careful about using the n parameter for `ifft`; in that case
it does not pad correctly.
Stéfan
Hey Zach
2008/8/7 Zachary Pincus <[EMAIL PROTECTED]>:
> Hello all,
>
> numpy.unpackbits has a docstring that states that it returns a boolean
> array, but the function instead returns a uint8 array. Should I enter
> this in trac as a documentation bug or a functionality bug?
Would you mind fixing
Hi Robert
2008/8/6 Robert Cimrman <[EMAIL PROTECTED]>:
> Note also that the order of outputs has changed (previously unique1d()
> returned (i, b) for return_index=True).
Does this not constitute an API change?
Stéfan
___
Numpy-discussion mailing list
N
2008/8/6 Matthieu Brucher <[EMAIL PROTECTED]>:
> Exactly. Using FFT to do a convolution should be done after some
> signal processing readings ;)
When you convolve two signals, of lengths N and M, you need to pad the
FFTs to length (N+M-1) before multiplication.
You can take a look at my linear p
2008/8/6 Dag Sverre Seljebotn <[EMAIL PROTECTED]>:
>>> cdef numpy.ndarray[numpy.int64, ndim=2]
>>
>> I'd definitely prefer a comma between the two, and an (optional) ndim
>> keyword argument if possible.
>
> I'm taking this as a vote in favor of this and against "2D" and <>?
>
> The keyword is alre
2008/8/6 Dag Sverre Seljebotn <[EMAIL PROTECTED]>:
> - Require an ndim keyword:
>
> cdef numpy.ndarray[numpy.int64, ndim=2]
I'd definitely prefer a comma between the two, and an (optional) ndim
keyword argument if possible.
Looking forward to hearing more!
Regards
Stéfan
2008/8/5 Jarrod Millman <[EMAIL PROTECTED]>:
>> If new=None (default)
Could you put in a check for new=True, and suppress those messages? A
user that knows about the changes wouldn't want to see anything.
Regards
Stéfan
___
Numpy-discussion mailing li
Hi Thomas
2008/8/4 Thomas Hrabe <[EMAIL PROTECTED]>:
> I need to convert a 3d array from c alingment to fortran and was wandering
> for the simplest code available.
> Its all about python and an interfaced C++ program, which, however,
> processes fortran aligned arrays.
>
> Is there a simple code
2008/8/4 David Cournapeau <[EMAIL PROTECTED]>:
> On Mon, Aug 4, 2008 at 8:14 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
>
>>
>> I agree -- seeing the NumPy-related build warnings would be very useful.
>
> I did not anticipate people would disagree on t
Hi David
2008/8/4 David Cournapeau <[EMAIL PROTECTED]>:
> Also, having hundred of bogus warnings mean you never see the
> interesting ones (building numpy core alone with -W generates > 1500
> such bogus warnings...)
I agree -- seeing the NumPy-related build warnings would be very useful.
Do you
2008/8/3 Greg Novak <[EMAIL PROTECTED]>:
> First of all, my desired operation is well-posed: I'd like f(ar1,
> ar2) to return something in the shape of ar1 with True if the value at
> that position appears anywhere in ar2 (regardless of duplication) and
> False otherwise.
Just because one-liners
2008/8/2 Jarrod Millman <[EMAIL PROTECTED]>:
> I'm pleased to announce the release of NumPy 1.1.1.
A big thank you to Charles and Jarrod for all the time they put into
this release!
Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.
2008/7/31 Andrew Dalke <[EMAIL PROTECTED]>:
> I don't see a place to submit patches. Is there a patch manager for
> numpy?
>
> Here's a patch to defer importing 'tempfile' until needed. I
> previously mentioned one other place that didn't need tempfile. With
> this there is no 'import tempfile'
2008/7/31 Andrew Dalke <[EMAIL PROTECTED]>:
> The user base for numpy might be .. 10,000 people? 100,000 people?
> Let's go with the latter, and assume that with command-line scripts,
> CGI scripts, and the other programs that people write in order to
> help do research means that numpy is started
2008/7/31 Andrew Dalke <[EMAIL PROTECTED]>:
>> Numpy has a very flat namespace, for better or worse, which implies
>> many imports.
>
> I don't get the feeling that numpy is flat. Python's stdlib is flat.
> Numpy has many 2- and 3-level modules.
With 500+ functions in the root namespace, I'd call
2008/7/30 Alan McIntyre <[EMAIL PROTECTED]>:
> On Wed, Jul 30, 2008 at 5:01 PM, Stéfan van der Walt <[EMAIL PROTECTED]>
> wrote:
>> If others agree, could we suppress the output of skipped tests unless
>> specifically requested? They clutter the output, and mak
Alan,
If others agree, could we suppress the output of skipped tests unless
specifically requested? They clutter the output, and makes it more
difficult to see which "real" tests fail.
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
2008/7/30 Andrew Dalke <[EMAIL PROTECTED]>:
> Based on those results I've been digging into the code trying to
> figure out why numpy imports so many files, and at the same time I've
> been trying to guess at the use case Robert Kern regards as typical
> when he wrote:
>
> Your use case isn't s
2008/7/29 Hans Meine <[EMAIL PROTECTED]>:
> On Dienstag 29 Juli 2008, Stéfan van der Walt wrote:
>> > One way to achieve this is partial flattening, which I did like this:
>> >
>> > dat.reshape((numpy.prod(dat.shape[:3]), dat.shape[3])).sum(0)
>> >
2008/7/29 Hans Meine <[EMAIL PROTECTED]>:
> with a multidimensional array (say, 4-dimensional), I often want to project
> this onto one single dimension, i.e.. let "dat" be a 4D array, I am
> interested in
>
> dat.sum(0).sum(0).sum(0) # equals dat.sum(2).sum(1).sum(0)
>
> However, creating interme
2008/7/29 Felix Richter <[EMAIL PROTECTED]>:
> I learned a few things in the meantime:
>
> In my installation, NumPy uses fftpack_lite while SciPy uses FFTW3. There are
> more test cases in SciPy which all pass. So I am confirmed my problem is a
> pure usage problem.
> One thing I was confused abou
Hi Damian
2008/7/29 Damian Eads <[EMAIL PROTECTED]>:
> I ran into a little problem in some type checking code for a C extension
> I'm writing. I construct X as a C-long array and then I cast it to a C-int
> array Y, however the type code does not change. However, when I try
> constructing the arra
Hi Felix
This doesn't look quite right:
# Re-Transform to frequency domain
fftdata = fftpack.fft(ifftdata)
fftdata = fftpack.fftshift(ifftdata) # not the "i"
You probably want fftshift(fft(ifftdata))?
As an aside, you also don't need vectorise, since those functions are
all "vectori
2008/7/25 Thomas J. Duck <[EMAIL PROTECTED]>:
> Hi,
>
> There is some unexpected behaviour (to me) when 0-dimensional
> arrays are compared with values. For example:
>
> >>> numpy.array([0]).squeeze() == 0
> True
>
> >>> numpy.array([None]).squeeze() == None
> False
>
> >>> numpy.array(['a
Hi,
Does anybody know how Zipf's law or how Zipfian distributions work,
and how they relate
to NumPy's `np.random.zipf`? I'm afraid I can't make head or tail of
these results:
In [106]: np.random.zipf(2, size=(10))
Out[106]: array([ 1, 1, 1, 29, 1, 1, 1, 1, 1, 2])
(8x1, 1x2, 1x29)
In [
2008/7/24 Neil Crighton <[EMAIL PROTECTED]>:
> Ok, thanks.
>
> I meant the amount of vertical space between lines of text - for
> example, the gaps between parameter values and their description, or
> the large spacing between both lines of text and and the text boxes in
> the examples section. If
2008/7/23 Fernando Perez <[EMAIL PROTECTED]>:
> I'm just reposting here to see if anyone with a stake in f2py has an
> opinion/advice on the points below. F2py feels very much in
> autopilot/drifting into the icebergs mode right now. Is that correct
> assessment?
>
> If there's any guidance on wh
Hi all,
Should we document character arrays? Does anybody still use them?
I think their behaviour can largely be duplicated by object arrays.
They also seem to be broken:
>>> x = np.array(['1', '2', '3', '4']).view(np.chararray)
>>> x*3
chararray(['111', '222', '333', '444'],
dtype='|S4'
2008/7/23 Alan McIntyre <[EMAIL PROTECTED]>:
> There's a function (_test_unique1d_speed) in numpy/lib/arraysetops.py
> that looks to me like it should be in a benchmark suite instead of in
> the library module. Would anyone mind if I moved it to
> numpy/lib/benchmarks?
No, please go ahead.
Cheer
Hi all,
I noticed that subclasses are not represented correctly:
In [8]: np.chararray([1, 2, 3])
Out[8]:
chararray([[['\x03', '', ''],
['\xc0', '\x03', '']]],
dtype='|S1')
Notice how the indentation of the second row is completely wrong.
I tried to fix this in array_repr_builtin (
2008/7/22 Stéfan van der Walt <[EMAIL PROTECTED]>:
>> Could you post a patch against current mainline svn, which already has your
>> previous patch applied? I'm also curious why we need tuples, are we using
>> these values as hashes someplace.
>
> Applied.
2008/7/22 Charles R Harris <[EMAIL PROTECTED]>:
>> That's easy to fix. New patch attached.
>
> Yep, but I wanted you to look it over and find all the problems ;)
Ah, you have your managerial hat on!
> Could you post a patch against current mainline svn, which already has your
> previous patch ap
2008/7/22 Charles R Harris <[EMAIL PROTECTED]>:
> This bit is illegal syntax in Python 2.3
>
> X.append(tuple(conv(val) for (conv, val) in zip(converterseq,
> vals)))
>
> So this isn't going to work for 1.1.1
That's easy to fix. New patch attached.
Cheers
Stéfan
loadtxt.patch
Descripti
2008/7/20 Ryan May <[EMAIL PROTECTED]>:
>>arr
> array([('JOE', 25.301), ('BOB', 27.899)],
> dtype=[('stid', '|S4'), ('temp', '
loadtxt.patch
Description: Binary data
___
Numpy-discussion mailing list
Numpy-discussion@scipy.or
2008/7/21 Suchindra Sandhu <[EMAIL PROTECTED]>:
> Is that the recommended way of checking the type of the array? Ususally for
> type checkin, I use the isinstance built-in in python, but I see that will
> not work in this case. I must admit that I am a little confused by this. Why
> is type differe
Hi all,
A new copy of the reference guide is now available at
http://mentat.za.net/numpy/refguide/
and
http://mentat.za.net/numpy/refguide/NumPy.pdf
I'd like to thank Pauli Virtanen, who put in a lot of effort to
improve Sphinx interaction and document layout.
The guide is not yet complete, b
2008/7/20 Michael Abbott <[EMAIL PROTECTED]>:
> On Sun, 20 Jul 2008, Stéfan van der Walt wrote:
>> 2008/7/20 Michael Abbott <[EMAIL PROTECTED]>:
>> > C, then C++ (which I now regard as a serious mistake) and finally shell
>> It's scary how many of us were s
2008/7/20 Michael Abbott <[EMAIL PROTECTED]>:
>> I'm very impressed with your ability to follow these reference count
>> issues. Especially given that you only started learning about the
>> Python C-API a few months ago (if I remember correctly).
> Alas no. I'm a bit of an old lag really, I did d
2008/7/19 Charles R Harris <[EMAIL PROTECTED]>:
> In [2]: type(conjugate(array(8+7j)))
> Out[2]:
>
> In [3]: type((array(8+7j)))
> Out[3]:
>
> So I think all that needs to be done is fix the return type conjugate if we
> agree that it should be an array.
I think it should be an array.
Stéfan
__
2008/7/18 Suchindra Sandhu <[EMAIL PROTECTED]>:
> Can someone please explain to me this oddity?
>
> In [1]: import numpy as n
>
> In [8]: a = n.array((1,2,3), 'i')
>
> In [9]: type(a[0])
> Out[9]:
There's more than one int32 type lying around. Rather, compare *dtypes*:
In [19]: a.dtype == np.in
2008/7/18 Alan McIntyre <[EMAIL PROTECTED]>:
> This seems odd to me:
>
A=np.array([['%.3f','%d'],['%s','%r']]).view(np.chararray)
A % np.array([[1,2],[3,4]])
> Traceback (most recent call last):
> File "", line 1, in
> File "/opt/local/lib/python2.5/site-packages/numpy/core/defchararra
2008/7/18 Arnar Flatberg <[EMAIL PROTECTED]>:
> ... and instead of just complaining, I can do something about it :-) Could
> you add permissions to me for the documentation editor, username:
That's the spirit! You are now added.
But I'm worried: I had a bet with Joe that we won't get more than
2008/7/18 Arnar Flatberg <[EMAIL PROTECTED]>:
> I need to check if my array (a) is of type `string`. That is, I dont know
> the number of characters beforehand, so I cant do a.dtype == '|S*' (* =
> (max) number of characters)
> Looking at my options, I see either a.dtype.kind == 'S' or a.dtype.typ
Hi Amir
2008/7/18 Amir <[EMAIL PROTECTED]>:
> A very beginner question about indexing: let x be an array where n =
> len(x). I would like to create a view y of x such that:
>
> y[i] = x[i:i+m,...] for each i and a fixed m << n
>
> so I can do things like numpy.cov(y). With n large, allocating y i
2008/7/17 Charles R Harris <[EMAIL PROTECTED]>:
> I'm thinking it would nice to backport as many documentation updates to
> 1.1.1 as possible. It looks like the following steps should do the trick.
>
> 1) Make ptvirtan's changes for ufunc documentation.
> 2) Copy add_newdocs.py
> 3) Copy fromnumeri
Hi Pierre,
2008/7/17 Pierre GM <[EMAIL PROTECTED]>:
>> Otherwise, you can already
>> save the array and mask separately.
>
> An other possibility is to store the MaskedArray as a record array, with one
> field for the data and one field for the mask.
What about the other parameters, such as fill
501 - 600 of 805 matches
Mail list logo
