On Sun, May 25, 2008 at 12:12 AM, Charles R Harris <
[EMAIL PROTECTED]> wrote:
>
>
> On Sat, May 24, 2008 at 11:29 PM, <[EMAIL PROTECTED]> wrote:
>
>> Hi all,
>>
>> I'm trying to write a Gauss-Seidel function in C++. The function works
>> however it is too slow because I'm not using any accelerati
On Sat, May 24, 2008 at 11:29 PM, <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm trying to write a Gauss-Seidel function in C++. The function works
> however it is too slow because I'm not using any acceleration for the
> vector multiplication. I'm not really sure how to access the dot function
> in
? bool
b signed char
h short
i integer
l long integer
q long long integer
p p
B unsigned char
H unsigned short
I unsigned integer
L unsigned long integer
Q unsigned long long integer
P P
f single precision
d double precision
g long precision
F complex single precision
D complex double pre
Hi all,
I'm trying to write a Gauss-Seidel function in C++. The function works
however it is too slow because I'm not using any acceleration for the
vector multiplication. I'm not really sure how to access the dot function
in my extension, nor what all the arguments are for.
Is this the right fun
On Sat, May 24, 2008 at 10:08 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > On Sat, May 24, 2008 at 9:21 PM, Alan G Isaac <[EMAIL PROTECTED]>
> wrote:
> >> If you want bools, change the accumulator dtype::
> >>>>> x.sum(dtype=bool)
>
>
> On Sat, 24 May 2008, Charles R Harris apparently wrote
On Sat, May 24, 2008 at 10:00 PM, Nathan Bell <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 10:48 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > You can't overflow in modular arithmetic, which is how numpy is supposed
> to
> > work. Try
> >
> > In [51]: x
> > Out[51]: array([2147
> On Sat, May 24, 2008 at 9:21 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>> If you want bools, change the accumulator dtype::
>>>>> x.sum(dtype=bool)
On Sat, 24 May 2008, Charles R Harris apparently wrote:
> Shouldn't that be the other way round? If you want integers, do
> x.sum(dtype=int
On Sat, May 24, 2008 at 9:50 PM, Nathan Bell <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 10:40 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > The question is consistency. A programmer should just have to remember a
> few
> > simple rules, not a host of special cases. It makes t
On Sat, May 24, 2008 at 10:48 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> You can't overflow in modular arithmetic, which is how numpy is supposed to
> work. Try
>
> In [51]: x
> Out[51]: array([2147483647, 2147483647])
>
> In [52]: x.sum()
> Out[52]: -2
>
I would call that an overflow.
H
On Sat, May 24, 2008 at 10:40 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> The question is consistency. A programmer should just have to remember a few
> simple rules, not a host of special cases. It makes things easier to learn
> and the code easier to understand because the intent is alway
On Sat, May 24, 2008 at 9:40 PM, Nathan Bell <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 10:32 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > But the accumalator is of the same kind unless the kind is boolean, in
> which
> > case it is integer. Clear as a bell.
> >
>
> I believ
On Sat, May 24, 2008 at 10:32 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> But the accumalator is of the same kind unless the kind is boolean, in which
> case it is integer. Clear as a bell.
>
I believe the rule is that any integer type smaller than the machine
word size is effectively upca
On Sat, May 24, 2008 at 9:35 PM, Nathan Bell <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 10:24 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > Shouldn't that be the other way round? If you want integers, do
> > x.sum(dtype=int). Ints don't sum in float64 by default.
> >
>
>
On Sat, May 24, 2008 at 10:24 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
>
> Shouldn't that be the other way round? If you want integers, do
> x.sum(dtype=int). Ints don't sum in float64 by default.
>
The default behavior (x.sum() -> int) is more useful than (x.sum() ->
bool) since x.any()
On Sat, May 24, 2008 at 9:18 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 10:12 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, May 24, 2008 at 9:06 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> >>
> >> On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
>
On Sat, May 24, 2008 at 9:21 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Sat, 24 May 2008, Keith Goodman apparently wrote:
> >>> x = np.array([True, True], dtype=bool)
> >>> x.sum()
> >2
>
>
>
> If you want bools, change the accumulator dtype::
>
>>>> x.sum(dtype=bool)
Shouldn't tha
On Sat, May 24, 2008 at 10:12 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> On Sat, May 24, 2008 at 9:06 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>>
>> On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
>> <[EMAIL PROTECTED]> wrote:
>> > So what about the rule that the array type takes prec
On Sat, 24 May 2008, Keith Goodman apparently wrote:
>>> x = np.array([True, True], dtype=bool)
>>> x.sum()
>2
If you want bools, change the accumulator dtype::
>>> x.sum(dtype=bool)
True
Cheers,
Alan Isaac
___
Numpy-discussion mailin
On Sat, May 24, 2008 at 10:15 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> On Sat, May 24, 2008 at 9:11 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>>
>> On Sat, May 24, 2008 at 10:06 PM, Robert Kern <[EMAIL PROTECTED]>
>> wrote:
>> > On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
>> > <[
On Sat, May 24, 2008 at 9:11 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 10:06 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> > On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
> > <[EMAIL PROTECTED]> wrote:
> >> So what about the rule that the array type takes precedenc
On Sat, May 24, 2008 at 9:06 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > So what about the rule that the array type takes precedence over the
> scalar
> > type? That is broken for booleans.
>
> Yes, and if it wasn
On Sat, May 24, 2008 at 10:06 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
>> So what about the rule that the array type takes precedence over the scalar
>> type? That is broken for booleans.
>
> Yes, and if it wasn't a
On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> So what about the rule that the array type takes precedence over the scalar
> type? That is broken for booleans.
Yes, and if it wasn't an intentional special case (I don't recall
discussing it on the list, but it might
On Sat, May 24, 2008 at 8:59 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 9:45 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >> I'm not sure why you're showing me numpy C code. I am talking about
> >> the Python bools True and False.
> >
> > Because I'm talking about
On Sat, May 24, 2008 at 9:57 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> How about
>
> In [14]: x += 5
>
> In [15]: x
> Out[15]: array([ True, True], dtype=bool)
Output = bool.
> In [16]: x.tostring()
> Out[16]: '\x01\x01'
>
>
> In [17]: x + 5
> Out[17]: array([6, 6])
Output != bool.
> I
On Sat, May 24, 2008 at 9:45 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>> I'm not sure why you're showing me numpy C code. I am talking about
>> the Python bools True and False.
>
> Because I'm talking about ufuncs. The original question was about ufuncs
> and, since array booleans are not tr
On Sat, May 24, 2008 at 8:48 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 9:46 PM, Keith Goodman <[EMAIL PROTECTED]>
> wrote:
> > On Sat, May 24, 2008 at 7:36 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> >> On Sat, May 24, 2008 at 9:28 PM, Keith Goodman <[EMAIL PROTECTED]
On Sat, May 24, 2008 at 9:46 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 7:36 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>> On Sat, May 24, 2008 at 9:28 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
>>> I think it's interesting how python and numpy bools behave differently
On Sat, May 24, 2008 at 7:36 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 9:28 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
>> I think it's interesting how python and numpy bools behave differently.
>>
x = np.array([True, True], dtype=bool)
x[0] + x[1]
>> True
>>
On Sat, May 24, 2008 at 8:40 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 9:37 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Sat, May 24, 2008 at 8:25 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> >>
> >> On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
On Sat, May 24, 2008 at 9:37 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
>
> On Sat, May 24, 2008 at 8:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>>
>> On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
>> <[EMAIL PROTECTED]> wrote:
>> >
>> > On Sat, May 24, 2008 at 7:47 PM, Robert Kern <[E
On Sat, May 24, 2008 at 8:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, May 24, 2008 at 7:47 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> >>
> >> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
> >
On Sat, May 24, 2008 at 9:28 PM, Keith Goodman <[EMAIL PROTECTED]> wrote:
> I think it's interesting how python and numpy bools behave differently.
>
>>> x = np.array([True, True], dtype=bool)
>>> x[0] + x[1]
> True
>>> x[0] & x[1]
> True
>>>
>>> x = [True, True]
>>> x[0] + x[1]
> 2
>>> x[0]
On Sat, May 24, 2008 at 7:09 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
>
> On Sat, May 24, 2008 at 7:47 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>>
>> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> <[EMAIL PROTECTED]> wrote:
>> > Hi All,
>> >
>> > I'm writing tests for ufuncs and tu
On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> On Sat, May 24, 2008 at 7:47 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>>
>> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> <[EMAIL PROTECTED]> wrote:
>> > Hi All,
>> >
>> > I'm writing tests for ufuncs and turn
On Sat, May 24, 2008 at 7:47 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > Hi All,
> >
> > I'm writing tests for ufuncs and turned up some oddities:
> >
> > In [4]: degrees(True)
> > Out[4]: 57.29578
> >
> > In [5]:
On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm writing tests for ufuncs and turned up some oddities:
>
> In [4]: degrees(True)
> Out[4]: 57.29578
>
> In [5]: radians(True)
> Out[5]: 0.017453292
>
> In [6]: sin(True)
> Out[6]: 0.84147096
>
> Do we want
On Sat, May 24, 2008 at 7:31 PM, Charles R Harris <[EMAIL PROTECTED]>
wrote:
> Hi All,
>
> I'm writing tests for ufuncs and turned up some oddities:
>
> In [4]: degrees(True)
> Out[4]: 57.29578
>
> In [5]: radians(True)
> Out[5]: 0.017453292
>
> In [6]: sin(True)
> Out[6]: 0.84147096
>
> Do we wan
Hi All,
I'm writing tests for ufuncs and turned up some oddities:
In [4]: degrees(True)
Out[4]: 57.29578
In [5]: radians(True)
Out[5]: 0.017453292
In [6]: sin(True)
Out[6]: 0.84147096
Do we want numeric functions to apply to booleans?
Chuck
___
Nump
On Sat, May 24, 2008 at 9:12 AM, Charles R Harris <[EMAIL PROTECTED]>
wrote:
> David,
>
> I merged the OBJECT_API and MULTIARRAY_API lists and fixed the SConstruct
> file in numpy/core, but you should check if I got it right.
>
I've since renamed generate_array_api to generate_numpy_api which led
On Sat, May 24, 2008 at 1:33 PM, Anne Archibald <[EMAIL PROTECTED]>
wrote:
> 2008/5/24 Charles R Harris <[EMAIL PROTECTED]>:
> >
> > I take that back, I got confused looking through the output. The errors
> are
> > the same and only seem to happen when valgrind runs the tests.
>
> Sounds like may
2008/5/24 Jarrod Millman <[EMAIL PROTECTED]>:
> On Fri, May 23, 2008 at 11:16 PM, David Cournapeau
> <[EMAIL PROTECTED]> wrote:
>> Where do those errors appear ? I don't see them on the builbot. Are they
>> 2.6 specific ? If yes, I would say ignore them, because 2.6 is not
>> released yet, and is s
2008/5/24 Charles R Harris <[EMAIL PROTECTED]>:
>
> I take that back, I got confused looking through the output. The errors are
> the same and only seem to happen when valgrind runs the tests.
Sounds like maybe valgrind is not IEEE clean:
"""
As of version 3.0.0, Valgrind has the following limit
Hi Andrea
2008/5/24 Andrea Gavana <[EMAIL PROTECTED]>:
> Number Of Cells: 5
> -
> | Rank | Method Name | Execution Time | Relative Slowness |
> --
Hi All,
I was about to close ticket #164 when I found this thread from almost a year
ago:
http://thread.gmane.org/gmane.comp.python.numeric.general/16296/focus=16302.
Does anyone know if these issues have all been resolved?
Chuck
___
Numpy-discussion ma
Hi All,
On Fri, May 23, 2008 at 4:50 PM, Andrea Gavana wrote:
> Hi Peter & All,
>
> On Fri, May 23, 2008 at 4:16 PM, Peter Creasey wrote:
>> Hi Andrea,
>>
>> 2008/5/23 "Andrea Gavana" <[EMAIL PROTECTED]>:
>>> And so on. The probelm with this approach is that I lose the original
>>> indices for wh
That's all.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Sat, 24 May 2008 08:49:12 -0600
"Charles R Harris" <[EMAIL PROTECTED]> wrote:
> On Sat, May 24, 2008 at 6:54 AM, Nils Wagner
><[EMAIL PROTECTED]>
> wrote:
>
>> Hi all,
>>
>> I found two failures and three errors wrt numpy.test()
>>
>> numpy.__version__
>>
>> '1.2.0.dev5228'
>>
>
> > The following line: array([6.95e-5]).astype('S')
> > returns: array(['6'], dtype='|S1')
> I don't know what it should do. Issue a warning, maybe?
> What are you trying to do?
At the very least a warning would not hurt. When I first started
using the numpy arrays it looked like conversion to
David,
I merged the OBJECT_API and MULTIARRAY_API lists and fixed the SConstruct
file in numpy/core, but you should check if I got it right.
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/nu
On Sat, May 24, 2008 at 8:47 AM, Charles R Harris <[EMAIL PROTECTED]>
wrote:
>
>
> On Sat, May 24, 2008 at 12:25 AM, Jarrod Millman <[EMAIL PROTECTED]>
> wrote:
>
>> On Thu, May 22, 2008 at 11:25 PM, Charles R Harris
>> <[EMAIL PROTECTED]> wrote:
>> > On Fri, May 23, 2008 at 12:10 AM, Charles R Ha
On Sat, May 24, 2008 at 2:48 AM, Jarrod Millman <[EMAIL PROTECTED]>
wrote:
> On Fri, May 23, 2008 at 11:28 PM, David Cournapeau
> <[EMAIL PROTECTED]> wrote:
> > I too think we should make the release ASAP, I am tired of it (as you
> > certainly are :) ).
>
> Absolutely! I just created the 1.1.x m
On Sat, May 24, 2008 at 6:54 AM, Nils Wagner <[EMAIL PROTECTED]>
wrote:
> Hi all,
>
> I found two failures and three errors wrt numpy.test()
>
> numpy.__version__
>
> '1.2.0.dev5228'
>
Hi Nils, can you try a clean install? Remove the build directory and maybe
the numpy folder in site
On Sat, May 24, 2008 at 12:25 AM, Jarrod Millman <[EMAIL PROTECTED]>
wrote:
> On Thu, May 22, 2008 at 11:25 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > On Fri, May 23, 2008 at 12:10 AM, Charles R Harris
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> The python 2.6 buildbots are showing 5 failu
> ==
> ERROR: test_hdquantiles
> (numpy.ma.tests.test_morestats.TestQuantiles)
> --
You have some kind of franken-build going on there. test_morestats has long
s
Hi all,
I found two failures and three errors wrt numpy.test()
numpy.__version__
'1.2.0.dev5228'
==
ERROR: Ticket #396
--
Traceback (most recent c
On Fri, May 23, 2008 at 11:28 PM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> I too think we should make the release ASAP, I am tired of it (as you
> certainly are :) ).
Absolutely! I just created the 1.1.x maintenance branch:
http://projects.scipy.org/scipy/numpy/changeset/5227
The trunk is n
Anne Archibald wrote:
> This particular
> feature - seterr - is the sort of thing an overaggressive optimizer
> can easily butcher, though, so it could easily be the result of the
> particular configuration on the buildbot machine.
gcc claims to be IEEE compliant at all level of optimizations (-O*
Anne Archibald wrote:
They do not appear on my machine (a pentium-M running Ubuntu). I
should point out that they are only actually three distinct errors,
because one of the test suites is being run twice.They are not exactly
subtle tests; they're checking that seterr induces the raising of
exce
2008/5/24 Jarrod Millman <[EMAIL PROTECTED]>:
> On Thu, May 22, 2008 at 11:25 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
>> On Fri, May 23, 2008 at 12:10 AM, Charles R Harris
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> The python 2.6 buildbots are showing 5 failures that are being hidden by
>>> va
60 matches
Mail list logo
