On Sat, Jul 24, 2010 at 6:38 PM, Pauli Virtanen wrote:
> Sat, 24 Jul 2010 18:22:33 +0800, Ralf Gommers wrote:
> > There is a bug report asking for the example files under doc/cython,
> > doc/swig etc. to be included in the released binaries. This thread,
> > http://thread.gmane.org/gmane.comp.pyt
On 7/29/10 1:37 PM, Robert Kern wrote:
> (Book of Guido, 7:42)
That's intriguing. Do you happen to have a link to it?
Thanks,
Jason
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Jul 29, 2010 at 19:26, Sturla Molden wrote:
>> On Thu, Jul 29, 2010 at 16:03, Alan G Isaac
>
>> New sampling algorithms aren't invented *all* that often.
>
> No, but it seems George Marsaglia posted a new prng called KISS4691 to
> sci.math last saturday :)
Of course. :-)
> KISS4691 has
On Fri, Jul 30, 2010 at 10:08 PM, rif wrote:
> Hi numpy-discuss
> .
> I've distilled my problem down to a very simple program that segfaults.
> I'm sure I'm doing something silly, but hopefully someone can point me in
> the right direction. I create a program called numpy_test.cc:
>
>
You must c
Hi numpy-discuss
.
I've distilled my problem down to a very simple program that segfaults. I'm
sure I'm doing something silly, but hopefully someone can point me in the
right direction. I create a program called numpy_test.cc:
-
#include
#include "numpy/arrayobject.h"
int m
Fri, 30 Jul 2010 19:48:45 +0200, Guillaume Chérel wrote:
> Your solution is really good. It's almost exactly what I was doing, but
> shorter and I didn't know about the mgrid thing.
It's a very brute-force solution and probably won't be very fast with
many circles or large grids.
> There is an e
-- Forwarded message --
From: George Nurser
Date: 30 July 2010 22:37
Subject: Re: [Matplotlib-users] Vectorization
To: Nicolas Bigaouette , Discussion of
Numerical Python
> I want to do the same for the calculation of the kinetic energy:
> /2m. There is a laplacian in the volume
On Fri, Jul 30, 2010 at 13:22, Darren Dale wrote:
> I just upgraded my svn checkout and did a fresh install. When I try to
> run the test suite, I get a ton of errors:
>
>
> np.test()
> Running unit tests for numpy
> NumPy version 2.0.0.dev8550
> NumPy is installed in /Users/darren/.local/lib/pyth
>On 30 July 2010 19:08, Ralf Gommers wrote:
> Commit r8541 broke building with numscons for me, does this fix look okay:
> http://github.com/rgommers/numpy/commit/1c88007ab00cf378ebe19fbe54e9e868212c73d1
>
> I am puzzled though why my endian.h is not picked up in the build - I have a
> good collec
This seems to me to be a bug, or rather, two bugs. 1D arrays are
automatically Fortran-ordered, so isfortran should return True for
them (incidentally, the documentation should be edited to indicate
that the data must also be contiguous in memory). Whether or not this
change is made, there's no poi
I just upgraded my svn checkout and did a fresh install. When I try to
run the test suite, I get a ton of errors:
np.test()
Running unit tests for numpy
NumPy version 2.0.0.dev8550
NumPy is installed in /Users/darren/.local/lib/python2.6/site-packages/numpy
Python version 2.6.5 (r265:79063, Jul 1
Hi David,
Commit r8541 broke building with numscons for me, does this fix look okay:
http://github.com/rgommers/numpy/commit/1c88007ab00cf378ebe19fbe54e9e868212c73d1
I am puzzled though why my endian.h is not picked up in the build - I have a
good collection of those on my system, at least in all
2010/7/2 Charles R Harris
>
>
> On Fri, Jul 2, 2010 at 12:15 PM, Nicolas Bigaouette > wrote:
>
>> Hi all,
>>
>> I don't really know where to ask, so here it is.
>>
>> I was able to vectorize the normalization calculation in quantum
>> mechanics: . Basically it's a volume integral of a scalar fie
I assume this is addressed to David C., correct?
DG
On Fri, Jul 30, 2010 at 10:08 AM, Ralf Gommers
wrote:
> Hi David,
>
> Commit r8541 broke building with numscons for me, does this fix look okay:
>
> http://github.com/rgommers/numpy/commit/1c88007ab00cf378ebe19fbe54e9e868212c73d1
>
> I am puzzl
2010/7/30 Guillaume Chérel
> On Fri, Jul 30, 2010 at 6:15 PM, Christopher Barker
> wrote:
> > Guillaume Chérel wrote:
> >> As for the details about my problem, I'm trying to compute the total
> >> surface of overlapping disks. I approximate the surface with a grid and
> >> count how many points
Fri, 30 Jul 2010 14:21:23 +0200, Guillaume Chérel wrote:
[clip]
> As for the details about my problem, I'm trying to compute the total
> surface of overlapping disks. I approximate the surface with a grid and
> count how many points of the grid fall into at least one disk.
HTH,
import numpy as np
What are the rules for when 'np.asarray' and 'np.asfortranarray' make a copy?
This makes sense to me:
In [3]: carr = np.arange(3)
In [6]: carr2 = np.asarray(carr)
In [8]: carr2[0] = 1
In [9]: carr
Out[9]: array([1, 1, 2])
No copy is made.
But doing the same with a fortran array makes a copy:
Hi Pauli,
Your solution is really good. It's almost exactly what I was doing,
but shorter and I didn't know about the mgrid thing.
There is an extra optimization step I perform in my code to avoid the
computation of the many points of the grid (assuming the circles are
relatively small) which you
On 7/30/2010 12:59 PM, Guillaume Chérel wrote:
> my problem may involve
> many more than 2 disks at a time
You cd approximate each disc by a polygon, as accurately
as you need, and test each point for membership in each disc:
from matplotlib.nxutils import pnpoly
hth,
Alan Isaac
_
On Fri, Jul 30, 2010 at 6:15 PM, Christopher Barker
wrote:
> Guillaume Chérel wrote:
>> As for the details about my problem, I'm trying to compute the total
>> surface of overlapping disks. I approximate the surface with a grid and
>> count how many points of the grid fall into at least one disk.
Guillaume Chérel wrote:
> As for the details about my problem, I'm trying to compute the total
> surface of overlapping disks. I approximate the surface with a grid and
> count how many points of the grid fall into at least one disk.
That is a highly approximate way to do it - which may be fine,
2010/7/30 Guillaume Chérel :
> Hello,
>
> I ran into a difficulty with floating point arithmetic in python. Namely
> that:
>
> >>> 0.001 + 1 - 1
> 0.00088987
>
> And, as a consequence, in python:
>
> >>> 0.001 + 1 - 1 == 0.001
> False
>
> In more details, my problem is that I have a
2010/7/30 Guillaume Chérel :
> Hi,
>
> Thanks for all your answers and the references (and yes, I have to admit
> that I've been a bit lazy with Goldberg's article, though it looks very
> thorough).
>
> But as numpy is designed for scientific computing, is there no
> implementation of an "exact ty
On 7/30/2010 8:21 AM, Guillaume Chérel wrote:
> is there no
> implementation of an "exact type"
You could use the fraction module:
>>> f = [Fraction(i,10) for i in range(10)]
>>> a = np.array(f, dtype=object)
>>> a
array([0, 1/10, 1/5, 3/10, 2/5, 1/2, 3/5, 7/10, 4/5, 9/10], dtype=object)
But I d
Hi,
Thanks for all your answers and the references (and yes, I have to admit
that I've been a bit lazy with Goldberg's article, though it looks very
thorough).
But as numpy is designed for scientific computing, is there no
implementation of an "exact type"
(http://floating-point-gui.de/form
Fri, 30 Jul 2010 19:52:37 +0900, David wrote:
[clip]
> Indeed, it is not, and that's expected. There are various pitfalls using
> floating point. Rational and explanations:
>
> http://docs.sun.com/source/806-3568/ncg_goldberg.html
In case of tl;dr, see also http://floating-point-gui.de/
--
Paul
2010/7/30 Guillaume Chérel :
>
> Hello,
>
> I ran into a difficulty with floating point arithmetic in python. Namely
> that:
>
> >>> 0.001 + 1 - 1
> 0.00088987
>
> And, as a consequence, in python:
>
> >>> 0.001 + 1 - 1 == 0.001
> False
>
> In more details, my problem is that I have
Hi Guillaume,
On 07/30/2010 07:45 PM, Guillaume Chérel wrote:
>Hello,
>
> I ran into a difficulty with floating point arithmetic in python.
This is not python specific, but true in any language which uses the
floating point unit of your hardware, assuming you have "conventional"
hardware.
Hello,
I ran into a difficulty with floating point arithmetic in python. Namely
that:
>>> 0.001 + 1 - 1
0.00088987
And, as a consequence, in python:
>>> 0.001 + 1 - 1 == 0.001
False
In more details, my problem is that I have a fonction which needs to
compute (a + b - c) % a.
On 06/15/10 04:06 AM, Chris LeBlanc wrote:
> Hi,
>
> Firstly thanks to everyone that has helped bring NumPy to the point it
> is today. Its an excellent bit of software.
>
> I've recently managed to get NumPy to compile on a 64 bit Solaris 10
> (sparc) machine. We've embedded 64 bit Python in som
On 06/17/10 02:53 PM, Ralf Gommers wrote:
> On Tue, Jun 15, 2010 at 11:06 AM, Chris LeBlanc wrote:
>
>> Hi,
>>
>> Firstly thanks to everyone that has helped bring NumPy to the point it
>> is today. Its an excellent bit of software.
>>
>> I've recently managed to get NumPy to compile on a 64 bit S
31 matches
Mail list logo
