In the first version this line:
ax.bar3d([i], [0], [i], [.9], [.1], [.9], color='y', linewidth=.1)
is responsible for diagonal in N, and it is inverted.
In the second version you quoted this is corrected with:
ax.bar3d([3-i], [0], [i], [.9], [.1], [.9], color='y', linewidth=.1)
Also sn
On Thu, Jun 28, 2012 at 12:38 AM, astronomer wrote:
>
> Hi All,
> I am wondering if there any difference in memory overhead between the
> following code.
> a=numpy.arange(10)
> b=numpy.arange(10)
> c=a+b
>
> and
> a=numpy.arange(10)
> b=numpy.arange(10)
> c=numpy.empty_likes(a)
> c[:]=a+b
>
> Does
I've submitted a pull request ( https://github.com/numpy/numpy/pull/326 ).
I'm new to the numpy and python internals, so feedback is greatly
appreciated.
On Tue, Jun 26, 2012 at 12:10 PM, Travis Oliphant wrote:
>
> On Jun 26, 2012, at 1:34 PM, Frédéric Bastien wrote:
>
> > Hi,
> >
> > I think he
Hi All,
I am wondering if there any difference in memory overhead between the
following code.
a=numpy.arange(10)
b=numpy.arange(10)
c=a+b
and
a=numpy.arange(10)
b=numpy.arange(10)
c=numpy.empty_likes(a)
c[:]=a+b
Does the later code make a temproray array for the result of (a+b) and then
copy it
On Wed, Jun 27, 2012 at 4:38 PM, wrote:
> Hi list.
> I have got completely cunfused with the numpy.dot() function.
> dot(A,B) does:
> - matrix multiplication if A and B are of MxN and NxK sizey
> - dot product if A and B are of size M
> How how can I perform matrix multiplication of two vectors?
Hi list.
I have got completely cunfused with the numpy.dot() function.
dot(A,B) does:
- matrix multiplication if A and B are of MxN and NxK sizey
- dot product if A and B are of size M
How how can I perform matrix multiplication of two vectors?
(in matlab I do it like a*a')
Thanks.
Petro.
_
I've promoted gfortran to be the default compiler on OS X over vendor
compilers (to be more compatible with Linux), and made a similar adjustment
for the platform detection. I've promoted gfortran over g77 but not vendor
compilers on the other 'nixes. I left the Windows compiler options alone.
h
On Mon, Jun 18, 2012 at 9:47 AM, Aron Ahmadia wrote:
> f2py, by default, seems to prefer g77 (no longer maintained, deprecated,
> speedy, doesn't support Fortran 90 or Fortran 95) over gfortran
> (maintained, slower, Fortran 90 and Fortran 95 support).
>
> This causes problems when we try to comp
On Wed, Jun 27, 2012 at 1:45 PM, Charles R Harris wrote:
>
>
> On Tue, Jun 26, 2012 at 11:08 PM, Travis Oliphant wrote:
>
>> In my enthusiasm of finding someone to help with the release of NumPy 1.7
>> and my desire to get something released by the SciPy conference, I was
>> hasty and didn't gath
Thanks nathaniel, that does tricky...
On Wed, Jun 27, 2012 at 9:25 AM, Nathaniel Smith wrote:
> On Tue, Jun 26, 2012 at 10:53 PM, John Salvatier
> wrote:
> > I want to support multiple types in the index_increment function that
> I've
> > written here:
> >
> https://github.com/jsalvatier/numpy/
On Wed, Jun 27, 2012 at 8:57 PM, Dag Sverre Seljebotn
wrote:
> On 06/27/2012 09:53 PM, Nathaniel Smith wrote:
>> On Wed, Jun 27, 2012 at 8:29 PM, David Cournapeau wrote:
>>> On Wed, Jun 27, 2012 at 8:07 PM, Nathaniel Smith wrote:
On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau
wrot
On Wed, Jun 27, 2012 at 8:53 PM, Nathaniel Smith wrote:
> On Wed, Jun 27, 2012 at 8:29 PM, David Cournapeau wrote:
>> On Wed, Jun 27, 2012 at 8:07 PM, Nathaniel Smith wrote:
>>> On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau
>>> wrote:
On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith
On 06/27/2012 09:53 PM, Nathaniel Smith wrote:
> On Wed, Jun 27, 2012 at 8:29 PM, David Cournapeau wrote:
>> On Wed, Jun 27, 2012 at 8:07 PM, Nathaniel Smith wrote:
>>> On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau
>>> wrote:
On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith wrote:
>>>
On Wed, Jun 27, 2012 at 8:29 PM, David Cournapeau wrote:
> On Wed, Jun 27, 2012 at 8:07 PM, Nathaniel Smith wrote:
>> On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau wrote:
>>> On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith wrote:
Currently the numpy build system(s) support two ways of
On Wed, Jun 27, 2012 at 8:07 PM, Nathaniel Smith wrote:
> On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau wrote:
>> On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith wrote:
>>> Currently the numpy build system(s) support two ways of building
>>> numpy: either by compiling a giant concatenated C
On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau wrote:
> On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith wrote:
>> Currently the numpy build system(s) support two ways of building
>> numpy: either by compiling a giant concatenated C file, or by the more
>> conventional route of first compiling
On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith wrote:
> Currently the numpy build system(s) support two ways of building
> numpy: either by compiling a giant concatenated C file, or by the more
> conventional route of first compiling each .c file to a .o file, and
> then linking those together.
According to the Travis-CI build logs, this code produces
non-deterministic behaviour in master:
a = np.arange(5)
a[:3] = a[2:]
assert_equal(a, [2, 3, 4, 3, 4])
Sometimes 'a' is [2, 3, 4, 3, 4], and sometimes it is [4, 3, 4, 3, 4].
The latter is what you get if the assignment is done 'backw
Currently the numpy build system(s) support two ways of building
numpy: either by compiling a giant concatenated C file, or by the more
conventional route of first compiling each .c file to a .o file, and
then linking those together. I gather from comments in the source code
that the former is the
On Tue, Jun 26, 2012 at 10:02 PM, Ralf Gommers
wrote:
> I agree with what you're arguing for here (as little impact as possible on
> existing users), but your view of especially 1.6.x seems to be skewed by
> regressions and changes that were either unintended or thought to be okay
> because the af
On 27-Jun-2012 08:04, klo uo wrote:
> from numpy import arange, ones
> import matplotlib.pyplot as plt
> from mpl_toolkits.mplot3d import Axes3D
>
> fig = plt.figure()
> ax = fig.add_subplot(111, projection='3d')
>
> o = ones(4)
> r = arange(4)
>
> # planes:
> for z in arange(3)+1:
> ax.bar(r,
On Tue, Jun 26, 2012 at 10:53 PM, John Salvatier
wrote:
> I want to support multiple types in the index_increment function that I've
> written here:
> https://github.com/jsalvatier/numpy/blob/master/numpy/core/src/multiarray/mapping.c
>
> I need to check that the first argument's type can support
This is cool. It would be nice to put these things somewhere where they could
be available for reference.
-Travis
On Jun 27, 2012, at 10:20 AM, Virgil Stokes wrote:
> On 27-Jun-2012 11:40, klo uo wrote:
>> I continued in this mpl trip, with small animation sequence:
>>
>> ===
On 27-Jun-2012 11:40, klo uo wrote:
I continued in this mpl trip, with small animation sequence:
# animation
ax.view_init(90,-90)
plt.ion()
plt.draw()
plt.show()
for l in arange(25):
ax.set_xlim3d(1.5-.1*l,2.5+.1*l)
ax.set_ylim3d(1.5-.1*l,2.5+.
On Wed, Jun 27, 2012 at 8:43 AM, Peter Wang wrote:
> On Wed, Jun 27, 2012 at 9:33 AM, Charles R Harris
> wrote:
> > On Wed, Jun 27, 2012 at 7:20 AM, John Hunter wrote:
> >> because the original developers are gone. So people are loathe to
> >> upgrade. It is certainly true that deprecations t
On Wed, Jun 27, 2012 at 9:33 AM, Charles R Harris
wrote:
> On Wed, Jun 27, 2012 at 7:20 AM, John Hunter wrote:
>> because the original developers are gone. So people are loathe to
>> upgrade. It is certainly true that deprecations that have lived for a
>> single point release cycle have not bee
On Wed, Jun 27, 2012 at 7:20 AM, John Hunter wrote:
> > Some examples would be nice. A lot of people did move already. And I
> haven't
> > seen reports of those that tried and got stuck. Also, Debian and
> Python(x,
> > y) have 1.6.2, EPD has 1.6.1.
>
> In my company, the numpy for our production
> Some examples would be nice. A lot of people did move already. And I haven't
> seen reports of those that tried and got stuck. Also, Debian and Python(x,
> y) have 1.6.2, EPD has 1.6.1.
In my company, the numpy for our production python install is well
behind 1.6. In the world of trading, the u
On 06/26/2012 06:15 PM, Skipper Seabold wrote:
> My uninformed opinion from the sidelines: For me, this begged the
> question of why projects would wait so long and be upgrading 1.5.x ->
> 1.7.x. it sounded to me like an outreach problem.
lenny: none
squeeze: 1.4.1
wheezy: 1.6.2
hardy: 1.0.4
luci
Great. Yes, the Travis-CI stuff looks great. There are a lot of good CI
things happening on a lot of fronts.
It is encouraging to see.
It would be good to consolidate them --- or at least have a place to go to look
at output from many of them.
Travis
--
Travis Oliphant
(on a mobile)
On Tue, Jun 26, 2012 at 11:08 PM, Travis Oliphant wrote:
> In my enthusiasm of finding someone to help with the release of NumPy 1.7
> and my desire to get something released by the SciPy conference, I was
> hasty and didn't gather enough feedback from others about the release of
> NumPy 1.7. I'm
Yeah, camera is in cliche, I know :D
Something more original can be done, perhaps some idea of transforming
grid in 2D (in Z plane) for opening sequence and then emerging latices
in some analogy with numpy arrays, finishing with complete figure, but
I guess not in matplotlib ;)
You're now reminding me of the old spinning SGI logo
http://www.youtube.com/watch?v=Nqf6TjE49N8
Brennan
On 27/06/2012 10:40 a.m., klo uo wrote:
I continued in this mpl trip, with small animation sequence:
# animation
ax.view_init(90,-90)
plt.ion()
I continued in this mpl trip, with small animation sequence:
# animation
ax.view_init(90,-90)
plt.ion()
plt.draw()
plt.show()
for l in arange(25):
ax.set_xlim3d(1.5-.1*l,2.5+.1*l)
ax.set_ylim3d(1.5-.1*l,2.5+.1*l)
ax.view_init(90-3*l, -90+l)
On 6/26/2012 8:13 PM, Travis Oliphant wrote:
>> For the main repos we use buildbot and test on:
>>
>> Ubuntu Maverick 32-bit
>> Debian sid 64-bit
>> OSX 10.4 PPC
>> OSX 10.5 Intel
>> Debian wheezy PPC
>> Debian squeeze ARM (a Raspberry PI no less)
>> WIndows XP 32 bit
>> SPARC (courtesy of our frie
35 matches
Mail list logo
