Well that's fine for binops with the same types, but it's not so
obvious which type to cast to when mixing signed and unsigned types.
Should the type of N.int32(10)+N.uint32(10) be int32, uint32 or int64?
Given your answer what should the type of N.int64(10)+N.uint64(10) be
(which is the case in th
(please copy to the trace page)
On Sat, Mar 22, 2008 at 6:08 PM, James Philbin <[EMAIL PROTECTED]> wrote:
> I'm not sure that #669
> (http://projects.scipy.org/scipy/numpy/ticket/669) is a bug, but
> probably needs some discussion (see the last reply on that page). The
> cast is made because we do
I'm not sure that #669
(http://projects.scipy.org/scipy/numpy/ticket/669) is a bug, but
probably needs some discussion (see the last reply on that page). The
cast is made because we don't know that the LHS is non-negative.
However it could be argued that operations involving two integers
should nev
On 21 Mar 2008, at 12:29, Sebastian Haase wrote:
> ... and what does the "p" stand for in
N.intp
>
It stands for "pointer". An intp is an integer large enough to contain
a pointer address.
J.
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
___
I think the bug was referring to the fact that some types have
duplicate names *explicitly* containing the letter "c" --
as in
>>> repr(N.intc)
''
Is this supposed to be consistent naming scheme (i.e. any C type ""
is accessible as "N.c") ?
Then c float-type should consequently be named N.float
I think the bug was referring to the fact that some types have
duplicate names *explicitly* containing the letter "c" --
as in
>>> repr(N.intc)
''
Is this supposed to be consistent naming scheme (i.e. any C type ""
is accessible as "N.c") ?
Then c float-type should consequently be named N.float
For the not blocker bugs, I think that #420 should be closed : float32 is
the the C float type, isn't it ?
Matthieu
2008/3/13, Jarrod Millman <[EMAIL PROTECTED]>:
>
> Hello,
>
> I am sure that everyone has noticed that 1.0.5 hasn't been released
> yet. The main issue is that when I was getting r
Hi David
On Fri, Mar 14, 2008 at 9:19 AM, David Huard <[EMAIL PROTECTED]> wrote:
> I added a test for ticket 691. Problem is, there seems to be a new bug. I
> don't know it its related to the change or if it was there before. Please
> check this out.
Fantastic, thanks for jumping in and addressin
I added a test for ticket 691. Problem is, there seems to be a new bug. I
don't know it its related to the change or if it was there before. Please
check this out.
David
2008/3/14, David Huard <[EMAIL PROTECTED]>:
>
> I added a test for ticket 690.
>
> 2008/3/13, Barry Wark <[EMAIL PROTECTED]>:
>
I added a test for ticket 690.
2008/3/13, Barry Wark <[EMAIL PROTECTED]>:
>
> I appologize that the Mac OSX buildbot has been so flakey. For some
> reason it stops being able to resolve scipy.org on a regular basis
> (though other processes on the same machine don't seem to have
> trouble). Restar
I appologize that the Mac OSX buildbot has been so flakey. For some
reason it stops being able to resolve scipy.org on a regular basis
(though other processes on the same machine don't seem to have
trouble). Restarting the slave fixes the issue. Anyways, if anyone is
testing an OS X issue and the s
On Wed, Mar 12, 2008 at 10:43 PM, Jarrod Millman <[EMAIL PROTECTED]> wrote:
> Stefan and I also triaged the remaining tickets--closing several and
> turning others in to release blockers:
>
> http://scipy.org/scipy/numpy/query?status=new&severity=blocker&milestone=1.0.5&order=priority
>
> I th
Hello,
I am sure that everyone has noticed that 1.0.5 hasn't been released
yet. The main issue is that when I was getting ready to tag the
release I noticed that the buildbot had a few failing tests:
http://buildbot.scipy.org/waterfall?show_events=false
Stefan van der Walt added tickets for the
13 matches
Mail list logo
