Hi,
I was a bit confused by this on 32 bit linux:
In [30]:sctypes['int']
Out[30]:
[,
,
,
,
]
Is it easy to explain the two entries for int32 here? I notice there
is only one int32 entry for the same test on my 64 bit system.
Thanks a lot,
Matthew
__
Hi,
Would it be easy and / or sensible for - say - int32.itemsize to
return the same as dtype(int32).itemsize, rather than the that it returns at the moment?
Best,
Matthew
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.sc
Hi,
Sorry to keep cluttering the list, but I was a bit surprised by this
behavior of allclose:
In [25]:allclose([1.0], [1.0], rtol=0)
Out[25]:True
In [26]:allclose([1.0], [1.0], rtol=0, atol=0)
Out[26]:False
The docstring seems to imply that atol will not be used in this
comparison - or did I m
Hi,
> > wxPython -- Robin Dunn
> > PIL -- Fredrik Lundh
> > PyOpenGL -- Who?
> > PyObjC -- would it be useful there? (Ronald Oussoren)
> > MatplotLib (but maybe it's already married to numpy...)
> > PyGtk ?
> >
>
> It's a good start, but their is also
>
> PyMedia, PyVoxel, any video-library i
Hi,
I don't know if people remember this thread, but my memory was that
there might be some interest in including numpy / matlab benchmark
code somewhere in the distribution, to check on performance and allow
matlab people to do a direct comparison. Is this still of interest?
If so, what should b
Hi,
> import plab
>
> plab.plot() #etc.
>
> and interactive use could do from plab import *.
Yes... It's a hard call of course. I am a long term matlab user, and
switched to python relatively recently. I do see the attraction of
persuading people that you can get something very similar to matl
> > My problem is not space, but time.
> > I am creating a small array over and over,
> > and this is turning out to be a bottleneck.
How about making one large random number array and taking small views?
Matthew
___
Numpy-discussion mailing list
Numpy-
Oh dear, sorry, I should have read your email more carefully.
Matthew
On 3/8/07, Daniel Mahler <[EMAIL PROTECTED]> wrote:
> On 3/8/07, Matthew Brett <[EMAIL PROTECTED]> wrote:
> > > > My problem is not space, but time.
> > > > I am creating a small a
Hi,
On 4/25/07, Neal Becker <[EMAIL PROTECTED]> wrote:
> I'm interested in this comparison (not in starting yet another flame fest).
> I actually know nothing about matlab, but almost all my peers use it. One
> of the things I recall reading on this subject is that matlab doesn't
> support OO sty
Well - these threads always go on for a long time, but...
I've used matlab heavily for 10 years. I found that I had to use perl
and C fairly heavily to get things done that matlab could not do well.
Now I've switched to numpy, scipy, matplotlib, there is really
nothing I miss in matlab. We woul
Hi,
> However, I would disagree that Python with all its tools going to
> replace Matlab well for everything. For large projects, for advanced
> programmers and for non-standard things such as complex database
> handling (in my case) it is definitly a clear winner. However, I would
> be weary of g
On 4/27/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
>
> Is there really no single method to call on an ndarray that asks: "what
> endian are you"
>
> I know not every two-liner should be made into a convenience method, but
> this seems like a good candidate to me.
+1
I came across this sour
> I would very much link the Getting Started wiki page (
> http://scipy.org/Getting_Started ) to the front page. But I am not sure
> it is of good enough quality so far. Could people please have a look and
> make comments, or edit the page.
Thank you for doing this. It's pitched very well.
Matthe
Hi,
Does anyone else find this unexpected?
In [93]: import numpy as N
In [94]: a = N.arange(10).reshape(5,2)
In [95]: N.mean(a)
Out[95]: 4.5
In [96]: N.median(a)
Out[96]: array([4, 5])
i.e. shouldn't median have the same axis, dtype, default axis=None
behavior as mean?
Best,
Matthew
__
> Regarding dtype, I disagree. Why do you want to force the result to be a
> float?
Fair comment - I really meant the axis, and axis=None difference.
Matthew
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/
Can I resurrect this thread then by agreeing with Chris, and my
original post, that it would be better if median had the same behavior
as mean, accepting axis and dtype as inputs?
Best,
Matthew
On 5/24/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> Sven Schreiber wrote:
> >> (Zar, Jerrold H
Hi,
> > This doesn't make any sense. The numbers have changed but the dtype
> > is now incorrect. If you byteswap and correct the dtype the numbers
> > have still changed, but you now can actually use the object.
>
> By "numbers have still changed" I mean the underlying byte order is
> still dif
Hi,
> > I can see your point I think, that situation 1 seems to be the more
> > common and obvious, and coming at it from outside, you would have
> > thought that a.byteswap would change both.
>
> I think the reason that byteswap behaves the way it does is that for
> situation 1 you often don't ac
Hi,
> That would get them all built as a cohesive set. Then I'd repeat the
> installs without PYTHONPATH:
Is that any different from:
cd ~/src
cd numpy
python setup.py build
cd ../scipy
python setup.py build
...
cd ../numpy
python setup.py install
cd ../scipy
python setup.py
Ah, yes, I was typing too fast, thinking too little.
On 5/31/07, John Hunter <[EMAIL PROTECTED]> wrote:
> On 5/31/07, Matthew Brett <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > > That would get them all built as a cohesive set. Then I'd repeat the
> >
Hi,
>Following an ongoing discussion with S. Johnson, one of the developer
> of fftw3, I would be interested in what people think about adding
> infrastructure in numpy related to SIMD alignement (that is 16 bytes
> alignement for SSE/ALTIVEC, I don't know anything about other archs).
> The pr
Hi,
Thanks for looking into this because we (neuroimaging.scipy.org) use
mmaps a lot. I am very away from my desk at the moment but please do
keep us all informed, and we'll try and pitch in if we can...
Matthew
On 8/15/07, Glen W. Mabey <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 14, 2007 at 12:2
Hi,
I noticed that allclose does not always behave correctly for arrays with infs.
I've attached a test script for allclose, and here's an alternative
implementation that I believe behaves correctly.
Obviously the test script could be a test case in core/tests/test_numeric.py
I wonder if we sho
Hi again,
> I noticed that allclose does not always behave correctly for arrays with infs.
Sorry, perhaps I should have been more specific; this is the behavior
of allclose that I was referring to (documented in the tests I
attached):
In [6]:N.allclose([N.inf, 1, 2], [10, 10, N.inf])
Out[6]:arra
Hi,
>Starting thinking over the whole distutils thing, I was thinking
> what people would think about using scons inside distutils to build
> extension.
In general this seems like an excellent idea. If we can contribute
what we need to scons, that would greatly ease the burden of
maintenance
On 10/2/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> Jarrod Millman wrote:
> > I am hoping that most of you agree with the general principle of
> > bringing NumPy and SciPy into compliance with the standard naming
> > conventions.
Excellent plan - and I think it will make the code considera
Hi,
> I seem to have tracked down a memory leak in the string conversion mechanism
> of numpy. It is demonstrated using the following code:
>
> import numpy as np
>
> a = np.array([1.0, 2.0, 3.0])
> while True:
> b = str(a)
Would you not expect python rather than numpy to be dealing with the
Hi, again (sorry),
On Fri, Feb 17, 2012 at 10:18 PM, Christopher Jordan-Squire
wrote:
> On the broader topic of recruitment...sure, cython has a lower barrier
> to entry than C++. But there are many, many more C++ developers and
> resources out there than cython resources. And it likely will stay
Hi,
On Sat, Feb 18, 2012 at 9:06 AM, Dag Sverre Seljebotn
wrote:
> On 02/18/2012 08:52 AM, Benjamin Root wrote:
>>
>>
>> On Saturday, February 18, 2012, Sturla Molden wrote:
>>
>>
>>
>> Den 18. feb. 2012 kl. 17:12 skrev Alan G Isaac > >:
>>
>> >
>> >
>> > How does "stream-l
Hi.
On Sat, Feb 18, 2012 at 12:18 AM, Christopher Jordan-Squire
wrote:
> On Fri, Feb 17, 2012 at 11:31 PM, Matthew Brett
> wrote:
>> Hi,
>>
>> On Fri, Feb 17, 2012 at 10:18 PM, Christopher Jordan-Squire
>> wrote:
>>> On Fri, Feb 17, 2012 at 8:30 PM, Stur
Hi,
On Sat, Feb 18, 2012 at 12:35 PM, Charles R Harris
wrote:
>
>
> On Sat, Feb 18, 2012 at 12:21 PM, Matthew Brett
> wrote:
>>
>> Hi.
>>
>> On Sat, Feb 18, 2012 at 12:18 AM, Christopher Jordan-Squire
>> wrote:
>> > On Fri, Feb 17, 20
Hi,
On Sat, Feb 18, 2012 at 12:45 PM, Charles R Harris
wrote:
>
>
> On Sat, Feb 18, 2012 at 1:39 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Sat, Feb 18, 2012 at 12:35 PM, Charles R Harris
>> wrote:
>> >
>> >
>>
On Sat, Feb 18, 2012 at 1:40 PM, Charles R Harris
wrote:
>
>
> On Sat, Feb 18, 2012 at 2:17 PM, David Cournapeau
> wrote:
>>
>> On Sat, Feb 18, 2012 at 8:45 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Sat, Feb 18, 2012 at 1:39 PM,
Hi,
On Sat, Feb 18, 2012 at 1:57 PM, Travis Oliphant wrote:
> The C/C++ discussion is just getting started. Everyone should keep in mind
> that this is not something that is going to happening quickly. This will
> be a point of discussion throughout the year. I'm not a huge supporter of
> C
Hi,
On Sat, Feb 18, 2012 at 2:03 PM, Robert Kern wrote:
> On Sat, Feb 18, 2012 at 21:51, Matthew Brett wrote:
>> On Sat, Feb 18, 2012 at 1:40 PM, Charles R Harris
>> wrote:
>>>
>>>
>>> On Sat, Feb 18, 2012 at 2:17 PM, David Cournapeau
>>&g
Hi,
On Sat, Feb 18, 2012 at 2:20 PM, Robert Kern wrote:
> On Sat, Feb 18, 2012 at 22:06, Matthew Brett wrote:
>> Hi,
>>
>> On Sat, Feb 18, 2012 at 2:03 PM, Robert Kern wrote:
>>> On Sat, Feb 18, 2012 at 21:51, Matthew Brett
>>> wrote:
>>>>
Hi,
On Sat, Feb 18, 2012 at 2:51 PM, Robert Kern wrote:
> On Sat, Feb 18, 2012 at 22:29, Matthew Brett wrote:
>> Hi,
>>
>> On Sat, Feb 18, 2012 at 2:20 PM, Robert Kern wrote:
>>> On Sat, Feb 18, 2012 at 22:06, Matthew Brett
>>> wrote:
>>>
Hi,
On Sat, Feb 18, 2012 at 2:54 PM, Travis Oliphant wrote:
>
> On Feb 18, 2012, at 4:03 PM, Matthew Brett wrote:
>
>> Hi,
>>
>> On Sat, Feb 18, 2012 at 1:57 PM, Travis Oliphant wrote:
>>> The C/C++ discussion is just getting started. Everyone should keep in
On Sat, Feb 18, 2012 at 5:18 PM, Matthew Brett wrote:
> Hi,
>
> On Sat, Feb 18, 2012 at 2:54 PM, Travis Oliphant wrote:
>>
>> On Feb 18, 2012, at 4:03 PM, Matthew Brett wrote:
>>
>>> Hi,
>>>
>>> On Sat, Feb 18, 2012 at 1:57 PM, Travis O
Hi,
On Sat, Feb 18, 2012 at 8:38 PM, Travis Oliphant wrote:
> We will need to see examples of what Mark is talking about and clarify some
> of the compiler issues. Certainly there is some risk that once code is
> written that it will be tempting to just use it. Other approaches are
> certain
Hi,
On Sat, Feb 18, 2012 at 9:47 PM, Benjamin Root wrote:
>
>
> On Saturday, February 18, 2012, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Sat, Feb 18, 2012 at 8:38 PM, Travis Oliphant
>> wrote:
>>
>> > We will need to see examples of what M
Hi,
On Sat, Feb 18, 2012 at 10:09 PM, Charles R Harris
wrote:
>
>
> On Sat, Feb 18, 2012 at 9:38 PM, Travis Oliphant
> wrote:
>>
>> Sure. This list actually deserves a long writeup about that. First,
>> there wasn't a "Cython-refactor" of NumPy. There was a Cython-refactor of
>> SciPy. I
Hi,
Thanks for this - it's very helpful.
On Sat, Feb 18, 2012 at 11:18 PM, Mark Wiebe wrote:
> The suggestion of transitioning the NumPy core code from C to C++ has
> sparked a vigorous debate, and I thought I'd start a new thread to give my
> perspective on some of the issues raised, and descri
Hi,
On Sun, Feb 19, 2012 at 12:49 AM, Mark Wiebe wrote:
> On Sun, Feb 19, 2012 at 2:32 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> Thanks for this - it's very helpful.
>>
>> On Sat, Feb 18, 2012 at 11:18 PM, Mark Wiebe wrote:
>> > The sug
Hi,
On Sun, Feb 19, 2012 at 7:35 AM, Pauli Virtanen wrote:
> 19.02.2012 05:38, Travis Oliphant kirjoitti:
> [clip]
Sure. This list actually deserves a long writeup about that.
First, there wasn't a "Cython-refactor" of NumPy. There was a
Cython-refactor of SciPy. I'm not sure
Hi,
I was gaily using np.longlong for casting to the highest available
float type when I noticed this:
In [4]: np.array([2.1], dtype=np.longlong)
Out[4]: array([2], dtype=int64)
whereas:
In [5]: np.array([2.1], dtype=np.float128)
Out[5]: array([ 2.1], dtype=float128)
This on OSX snow leopard n
2012/2/22 Stéfan van der Walt :
> On Wed, Feb 22, 2012 at 2:47 PM, Matthew Brett
> wrote:
>> In [4]: np.array([2.1], dtype=np.longlong)
>> Out[4]: array([2], dtype=int64)
>
> Maybe just a typo:
>
> In [3]: np.array([2.1], dtype=np.longfloat)
> Out[3]: array(
Hi,
On Thu, Feb 23, 2012 at 4:23 AM, Francesc Alted wrote:
> On Feb 23, 2012, at 6:06 AM, Francesc Alted wrote:
>> On Feb 23, 2012, at 5:43 AM, Nathaniel Smith wrote:
>>
>>> On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted
>>> wrote:
Exactly. I'd update this to read:
float96
Hi,
On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
wrote:
> Le 23/02/2012 17:28, Charles R Harris a écrit :
>> That's correct. They are both extended precision (80 bits), but
>> aligned on 32bit/64bit boundaries respectively. Sun provides a true
>> quad precision, also called float128, while on
Hi,
On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe wrote:
> On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
>> wrote:
>> > Le 23/02/2012 17:28, Charles R Harris a écrit :
Hi,
On Thu, Feb 23, 2012 at 2:56 PM, Pierre Haessig
wrote:
> Le 23/02/2012 20:08, Mark Wiebe a écrit :
>> +1, I think it's good for its name to correspond to the name in C/C++,
>> so that when people search for information on it they will find the
>> relevant information more easily. With a bunch
Hi,
On Mon, Feb 27, 2012 at 2:43 PM, Alan G Isaac wrote:
> On 2/27/2012 2:28 PM, Pauli Virtanen wrote:
>> ISO specifies comma to be used in international standards
>> (ISO/IEC Directives, part 2 / 6.6.8.1):
>>
>> http://isotc.iso.org/livelink/livelink?func=ll&objId=10562502&objAction=download
>
>
Hi,
On Mon, Feb 27, 2012 at 2:58 PM, Pauli Virtanen wrote:
> Hi,
>
> 27.02.2012 20:43, Alan G Isaac kirjoitti:
>> On 2/27/2012 2:28 PM, Pauli Virtanen wrote:
>>> ISO specifies comma to be used in international standards
>>> (ISO/IEC Directives, part 2 / 6.6.8.1):
>>>
>>> http://isotc.iso.org/live
Hi,
On Wed, Feb 29, 2012 at 12:13 PM, Jonathan Rocher wrote:
> Thanks to your question, I discovered that there is a float128 dtype in
> numpy
>
> In[5]: np.__version__
> Out[5]: '1.6.1'
>
> In[6]: np.float128?
> Type: type
> Base Class:
> String Form:
> Namespace: Interactive
> File:
> /
Hi,
On Wed, Feb 29, 2012 at 1:46 AM, Travis Oliphant wrote:
> We already use the NEP process for such decisions. This discussion came
> from simply from the *idea* of writing such a NEP.
>
> Nothing has been decided. Only opinions have been shared that might
> influence the NEP. This is all
Hi,
Sorry that this report is not complete, I don't have full access to
this box but, on a Debian squeeze machine running linux
2.6.32-5-sparc64-smp:
nosetests
~/usr/local/lib/python2.6/site-packages/numpy/lib/tests/test_io.py:TestFromTxt.test_user_missing_values
test_user_missing_values (test_
Hi,
On Fri, Mar 2, 2012 at 9:05 PM, Charles R Harris
wrote:
>
>
> On Fri, Mar 2, 2012 at 4:36 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> Sorry that this report is not complete, I don't have full access to
>> this box but, on a Debian squeez
Hi,
On Sat, Mar 3, 2012 at 12:07 AM, Matthew Brett wrote:
> Hi,
>
> On Fri, Mar 2, 2012 at 9:05 PM, Charles R Harris
> wrote:
>>
>>
>> On Fri, Mar 2, 2012 at 4:36 PM, Matthew Brett
>> wrote:
>>>
>>> Hi,
>>>
>>> Sorry th
Hi,
On Sun, Mar 4, 2012 at 11:41 AM, Mark Wiebe wrote:
> On Sun, Mar 4, 2012 at 11:27 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Sat, Mar 3, 2012 at 12:07 AM, Matthew Brett
>> wrote:
>> > Hi,
>> >
>> > On Fri, Mar 2, 2012 at
Hi,
On Sun, Mar 4, 2012 at 8:32 PM, Mark Wiebe wrote:
> On Sun, Mar 4, 2012 at 10:08 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Sun, Mar 4, 2012 at 11:41 AM, Mark Wiebe wrote:
>> > On Sun, Mar 4, 2012 at 11:27 AM, Matthew Brett
>> > wrote:
&g
Hi,
On Sun, Mar 4, 2012 at 11:53 PM, Mark Wiebe wrote:
> On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett
> wrote:
>>
>>
>> > $ export NPY_SEPARATE_COMPILATION=1
>>
>> Thanks, that did it:
>>
>> 9194b3af704df71aa9b1ff2f53f169848d0f9dc7 is th
Hi,
On Mon, Mar 5, 2012 at 11:11 AM, Matthew Brett wrote:
> Hi,
>
> On Sun, Mar 4, 2012 at 11:53 PM, Mark Wiebe wrote:
>> On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett
>> wrote:
>>>
>>>
>>> > $ export NPY
And simplifying:
In [1]: import numpy as np
In [2]: control = np.array([(1, 2, 3), (0, 5, 6)], dtype=[('f0',
bool), ('f1', bool), ('f2', int)])
In [3]: control == control
Out[3]: array([ True, True], dtype=bool)
In [4]: from numpy import ma
In [5]: control = ma.array([(1, 2, 3), (0, 5, 6)], d
Hi,
On Mon, Mar 5, 2012 at 8:04 PM, Mark Wiebe wrote:
> I've pushed a bugfix to github, can you confirm that the crash goes away on
> your test box? Thanks for tracking that down, the stack trace was very
> helpful. Since x86 machines don't have as strict alignment requirements,
> bugs like this
Hi,
I found this test caused a bus error on current trunk:
import numpy as np
from StringIO import StringIO as BytesIO
from numpy.testing import assert_array_equal
def test_2d_buf():
dtt = np.complex64
arr = np.arange(10, dtype=dtt)
# 2D array
arr2 = np.reshape(arr, (2, 5))
Hi,
On Wed, Mar 7, 2012 at 11:37 AM, Charles R Harris
wrote:
>
>
> On Wed, Mar 7, 2012 at 12:26 PM, Nathaniel Smith wrote:
>>
>> On Wed, Mar 7, 2012 at 5:17 PM, Charles R Harris
>> wrote:
>> > On Wed, Mar 7, 2012 at 9:35 AM, Pierre Haessig
>> >
>> >> Coming back to Travis proposition "bit-patt
Hi,
I noticed a casting change running the test suite on our image reader,
nibabel:
https://github.com/nipy/nibabel/blob/master/nibabel/tests/test_casting.py
For this script:
import numpy as np
Adata = np.zeros((2,), dtype=np.uint8)
Bdata = np.zeros((2,), dtype=np.int16)
Bzero = np.int16(0)
B
Hi,
On Wed, Mar 7, 2012 at 4:08 PM, Matthew Brett wrote:
> Hi,
>
> I noticed a casting change running the test suite on our image reader,
> nibabel:
> https://github.com/nipy/nibabel/blob/master/nibabel/tests/test_casting.py
>
> For this script:
>
>
> import numpy
Hi,
On Tue, Mar 6, 2012 at 8:07 PM, Matthew Brett wrote:
> Hi,
>
> I found this test caused a bus error on current trunk:
>
>
> import numpy as np
>
> from StringIO import StringIO as BytesIO
>
> from numpy.testing import assert_array_equal
>
>
> def
Hi,
On Thu, Mar 8, 2012 at 3:14 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Mar 7, 2012 at 4:08 PM, Matthew Brett wrote:
>> Hi,
>>
>> I noticed a casting change running the test suite on our image reader,
>> nibabel:
>> https://github.com/nipy/nibabel/bl
Hi,
Am I right in thinking that float96 on windows 32 bit is a float64
padded to 96 bits? If so, is it useful? Has anyone got a windows64
box to check float128 ?
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license
Hi,
On Thu, Mar 15, 2012 at 9:17 PM, David Cournapeau wrote:
>
>
> On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> Am I right in thinking that float96 on windows 32 bit is a float64
>> padded to 96 bits?
>
>
> Yes
&g
Hi,
On Thu, Mar 15, 2012 at 9:24 PM, Charles R Harris
wrote:
>
>
> On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau
> wrote:
>>
>>
>>
>> On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett
>> wrote:
>>>
>>> Hi,
>>>
>>>
Hi,
On Thu, Mar 15, 2012 at 9:33 PM, Val Kalatsky wrote:
>
> I just happened to have an xp64 VM running:
> My version of numpy (1.6.1) does not have float128 (see more below what I
> get in ipython session).
> If you need to test something else please let me know.
Thanks a lot - that's helpful.
Hi,
On Thu, Mar 15, 2012 at 9:41 PM, Val Kalatsky wrote:
> I does look like a joke.
> Here is print np.finfo(np.longdouble)
>
> In [2]: np.__version__
> Out[2]: '1.6.1'
>
> In [3]: np.flo
> np.float np.float32 np.float_ np.floor
> np.float16 np.float64 np.floating
Hi,
On Thu, Mar 15, 2012 at 10:17 PM, Ilan Schnell wrote:
> I'm seeing the same thing on both (64 and 32-bit) Windows
> EPD test machines. I guess Windows does not support 128
> bit floats.
Do you mean there is no float96 on windows 32 bit as I described at
the beginning of the thread?
> I did
Hi,
On Thu, Mar 15, 2012 at 10:26 PM, Ilan Schnell wrote:
> To be more precise. On both 32-bit and 64-bit Windows
> machines I don't see.float96 as well as np.float128
Do you have any idea why I am seeing float96 and you are not? I'm on
XP with the current sourceforge 1.6.1 exe installer with
Hi,
On Fri, Mar 16, 2012 at 5:36 AM, wrote:
> On Fri, Mar 16, 2012 at 2:10 AM, Ilan Schnell wrote:
>> I just did a quick test across all supported EPD platforms:
>> win-64: float96 No, float128 No
>> win-32: float96 No, float128 No
>> osx-64: float96 No, float128 Yes
>> osx-32: float96 No, floa
Hi,
As of commit 72c6fbd, I am getting the appended build error on OSX
10.6.8. I couldn't immediately see what might have caused the
problem.
Cheers,
Matthew
...
creating build/temp.macosx-10.3-fat-2.6/numpy/core/blasdot
compile options: '-DNO_ATLAS_INFO=3 -Inumpy/core/blasdot
-Inumpy/core/inc
Hi,
On Sat, Mar 17, 2012 at 2:10 AM, Ralf Gommers
wrote:
>
>
> On Sat, Mar 17, 2012 at 9:24 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> As of commit 72c6fbd, I am getting the appended build error on OSX
>> 10.6.8. I couldn't immediately see what
Hi,
2012/4/2 Hongbin Zhang :
> Dear Python-users,
>
> I am currently very confused about the Scipy routine to obtain the
> eigenvectors of a complex matrix.
> In attached you find two files to diagonalize a 2X2 complex Hermitian
> matrix, however, on my computer,
>
> If I run python, I got:
>
> [[
Hi,
On Mon, Apr 2, 2012 at 5:38 PM, Val Kalatsky wrote:
> Both results are correct.
> There are 2 factors that make the results look different:
> 1) The order: the 2nd eigenvector of the numpy solution corresponds to the
> 1st eigenvector of your solution,
> note that the vectors are written in c
Hi,
On Fri, Apr 6, 2012 at 1:12 PM, Tony Yu wrote:
>
>
> On Fri, Apr 6, 2012 at 8:54 AM, Benjamin Root wrote:
>>
>>
>>
>> On Friday, April 6, 2012, Val Kalatsky wrote:
>>>
>>>
>>> The only slicing short-cut I can think of is the Ellipsis object, but
>>> it's not going to help you much here.
>>>
Hi,
On Fri, Apr 6, 2012 at 3:50 PM, cgraves wrote:
>
> It seems that the speed of append_fields() in numpy.lib.recfunctions is much
> slower than rec_append_fields() in matplotlib.mlab. See the following code:
As I remember it (Pierre M can probably correct me) the recfunctions
are not ports of
Hi,
On Mon, Apr 16, 2012 at 3:06 PM, Travis Oliphant wrote:
> I have heard from a few people that they are not excited by the growth of
> the NumPy data-structure by the 3 pointers needed to hold the masked-array
> storage. This is especially true when there is talk to potentially add
> additi
Hi,
On Mon, Apr 16, 2012 at 6:03 PM, Matthew Brett wrote:
> Hi,
>
> On Mon, Apr 16, 2012 at 3:06 PM, Travis Oliphant wrote:
>
>> I have heard from a few people that they are not excited by the growth of
>> the NumPy data-structure by the 3 pointers needed to hold the
Hi,
On Mon, Apr 16, 2012 at 7:46 PM, Travis Oliphant wrote:
>
> On Apr 16, 2012, at 8:03 PM, Matthew Brett wrote:
>
>> Hi,
>>
>> On Mon, Apr 16, 2012 at 3:06 PM, Travis Oliphant wrote:
>>
>>> I have heard from a few people that they are not excited by
Hi,
On Mon, Apr 16, 2012 at 8:40 PM, Travis Oliphant wrote:
>>>
>>> I think the answer to this is yes, but it could be as a feature-filled
>>> sub-class (like the current numpy.ma, except in C).
>>
>> I'd love to hear that argument fleshed out in more detail - do you have time?
>
>
> My proposal
Hi,
On Tue, Apr 17, 2012 at 7:24 AM, Nathaniel Smith wrote:
> On Tue, Apr 17, 2012 at 5:59 AM, Matthew Brett
> wrote:
>> Hi,
>>
>> On Mon, Apr 16, 2012 at 8:40 PM, Travis Oliphant wrote:
>>> Mark and I will have conversations about NumPy while he is in Au
Hi,
On Tue, Apr 17, 2012 at 12:04 PM, Fernando Perez wrote:
> On Tue, Apr 17, 2012 at 11:40 AM, Matthew Brett
> wrote:
>> I'm glad to hear that discussion is happening, but please do have it
>> on list. If it's off list it easy for people to feel they are bei
On Tue, Apr 17, 2012 at 12:32 PM, Fernando Perez wrote:
> On Tue, Apr 17, 2012 at 12:10 PM, Matthew Brett
> wrote:
>> Right - but that would be an absurd overstatement of what I said.
>> There's no point in addressing something I didn't say and no sensible
>>
Hi,
I just wanted to point out a situation where the scalar casting rules
can be a little confusing:
In [113]: a - np.int16(128)
Out[113]: array([-256, -1], dtype=int16)
In [114]: a + np.int16(-128)
Out[114]: array([ 0, -1], dtype=int8)
This is predictable from the nice docs here:
http://doc
Oops, sorry, Keith Goodman kindly pointed out that I had missed out:
On Wed, Apr 18, 2012 at 11:03 AM, Matthew Brett wrote:
> Hi,
>
> I just wanted to point out a situation where the scalar casting rules
> can be a little confusing:
In [110]: a = np.array([-128, 127], dtype=np.int8
Hi,
On Fri, Apr 20, 2012 at 11:04 AM, Charles R Harris
wrote:
> Hi All,
>
> Given the amount of new stuff coming in 1.7 and the slip in it's schedule, I
> wonder if it would be worth putting out a 1.6.2 release with fixes for
> einsum, ticket 1578, perhaps some others. My reasoning is that the fa
Hi,
On Sun, Apr 22, 2012 at 3:15 PM, Nathaniel Smith wrote:
> If you hang around big FOSS projects, you'll see the word "consensus"
> come up a lot. For example, the glibc steering committee recently
> dissolved itself in favor of governance "directly by the consensus of
> the people active in gl
Hi,
On Mon, Apr 23, 2012 at 12:33 PM, Nathaniel Smith wrote:
> On Mon, Apr 23, 2012 at 1:04 AM, Charles R Harris
> wrote:
>> Linux is Linus' private tree. Everything that goes in is his decision,
>> everything that stays out is his decision. Of course, he delegates much of
>> the work to people
Hi,
On Mon, Apr 23, 2012 at 3:08 PM, Travis Oliphant wrote:
>>
>>> Linux: Technically, everything you say is true. In practice, good luck
>>> convincing Linus or a subsystem maintainer to accept your patch when
>>> other people are raising substantive complaints. Here's an email I
>>> googled up
Hi,
On Tue, Apr 24, 2012 at 6:14 AM, Charles R Harris
wrote:
>
>
> On Mon, Apr 23, 2012 at 11:35 PM, Fernando Perez
> wrote:
>>
>> On Mon, Apr 23, 2012 at 8:49 PM, Stéfan van der Walt
>> wrote:
>> > If you are referring to the traditional concept of a fork, and not to
>> > the type we frequentl
Hi,
On Tue, Apr 24, 2012 at 2:25 PM, Charles R Harris
wrote:
>
>
> 2012/4/24 Stéfan van der Walt
>>
>> On Tue, Apr 24, 2012 at 11:12 AM, Charles R Harris
>> wrote:
>> > The advantage of nans, I suppose, is that they are in the hardware and
>> > so
>>
>> Why are we having a discussion on NAN's i
Hi,
On Tue, Apr 24, 2012 at 6:12 PM, Charles R Harris
wrote:
>
>
> On Tue, Apr 24, 2012 at 6:56 PM, Nathaniel Smith wrote:
>>
>> On Tue, Apr 24, 2012 at 2:14 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Mon, Apr 23, 2012 at 11:35 PM, Fernando Perez
>> > wrote:
>> >>
>> >> On Mon, Apr 23, 2
1 - 100 of 1080 matches
Mail list logo
