On Tue, Sep 15, 2009 at 12:26 PM, Robert Kern wrote:
> On Tue, Sep 15, 2009 at 12:50, Charles R
> Harris wrote:
> >
> >
> > On Tue, Sep 15, 2009 at 11:38 AM, Michael Gilbert
> > wrote:
> >>
> >> hi,
> >>
> >> when using numpy.random.multivariate_normal, would it make sense to warn
> >> the user
> My bad, sorry. I already always forget to check tickets on the trac
> site for numpy/scipy, adding yet another site to check seems to be way
> too much for my caffeine-affected memory. However, there should be an
> option to allocate tickets to specific people, right ? And then I
> should
On Tue, Sep 15, 2009 at 6:06 PM, Tim Michelsen
wrote:
>
> > It already exists in the docs:
> > http://docs.scipy.org/numpy/docs/numpy.lib.io.genfromtxt/
> > Did you mean you tried to edit this page?
> But cannot be found in here:
> http://docs.scipy.org/doc/numpy/reference/routines.io.html
>
> So
> It already exists in the docs:
> http://docs.scipy.org/numpy/docs/numpy.lib.io.genfromtxt/
> Did you mean you tried to edit this page?
But cannot be found in here:
http://docs.scipy.org/doc/numpy/reference/routines.io.html
So it just needs to be added in
http://docs.scipy.org/doc/numpy/_source
On Tue, Sep 15, 2009 at 4:33 PM, Pierre GM wrote:
>
> On Sep 15, 2009, at 4:22 PM, Ralf Gommers wrote:
> >
> > There's a ticket for this functionality on the pydocweb tracker
> > already. Hopefully it gets implemented at some point.
>
> My bad, sorry. I already always forget to check tickets on t
On Sep 15, 2009, at 4:30 PM, Tim Michelsen wrote:
> We shall all thank for having genfromtxt and derived!
You should really thank John Hunter, the original writer of
mlab.csv2rec (I thnk). I just polished the code and add a few extra
functionalities.
__
On Sep 15, 2009, at 4:22 PM, Ralf Gommers wrote:
>
> There's a ticket for this functionality on the pydocweb tracker
> already. Hopefully it gets implemented at some point.
My bad, sorry. I already always forget to check tickets on the trac
site for numpy/scipy, adding yet another site to che
> I actually figured out a workaround with converters, since my missing
> values are " "," "," " ie., irregular number of spaces and the
> values aren't stripped of white spaces. I just define {# : lambda s:
> float(s.strip() or 0)}, and I have a loop build all of the converters,
> but then I h
On Sep 15, 2009, at 4:19 PM, Tim Michelsen wrote:
>> Check the archives of the mailing list, there's an example using
>> dateutil.parser that may be just what you need.
> How is this dateutil.parser used in timeseries?
It's left in a corner. The use of dateutil.parser comes from
matplotlib. (g
On Tue, Sep 15, 2009 at 3:52 PM, Tim Michelsen
wrote:
> > I just wanted to point out that there is an easy way of making a
> > difference, and making sure that the docstrings get fixed (which is
> > indeed very important). If you go to http://docs.scipy.org/ and
> register,
> > send your login nam
> Check the archives of the mailing list, there's an example using
> dateutil.parser that may be just what you need.
How is this dateutil.parser used in timeseries?
Can it not be used to make the dateconverter obsolte for the most simple
cases?
___
Nu
> I just wanted to point out that there is an easy way of making a
> difference, and making sure that the docstrings get fixed (which is
> indeed very important). If you go to http://docs.scipy.org/ and register,
> send your login name on this mailing list, we will add you to the list of
> editors,
On 15-Sep-09, at 3:30 PM, Charles سمير Doutriaux wrote:
> Thanks Robert,
>
> That's exactly what I recommended her. Except I usually get gfortran
> from http://hpc.sourceforge.net
The hpc.sourceforge.net one is known to generate buggy SciPy binaries,
apparently:
http://projects.scipy.org/scipy
2009/9/15 Charles سمير Doutriaux :
> Thanks Robert,
>
> That's exactly what I recommended her. Except I usually get gfortran
> from http://hpc.sourceforge.net
I cannot recommend and cannot support the compilers on the hpc site.
They are often compiled from buggy, unreleased and unofficial versions
On Tue, 15 Sep 2009 13:31:21 -0600, Charles R Harris wrote:
> On Tue, Sep 15, 2009 at 1:28 PM, Michael Gilbert <
> michael.s.gilb...@gmail.com> wrote:
>
> > On Tue, 15 Sep 2009 13:17:43 -0600, Charles R Harris wrote:
> > > On Tue, Sep 15, 2009 at 12:57 PM, Michael Gilbert <
> > > michael.s.gilb...
On Tue, Sep 15, 2009 at 1:28 PM, Michael Gilbert <
michael.s.gilb...@gmail.com> wrote:
> On Tue, 15 Sep 2009 13:17:43 -0600, Charles R Harris wrote:
> > On Tue, Sep 15, 2009 at 12:57 PM, Michael Gilbert <
> > michael.s.gilb...@gmail.com> wrote:
> >
> > > On Tue, 15 Sep 2009 13:26:23 -0500, Robert
Thanks Robert,
That's exactly what I recommended her. Except I usually get gfortran
from http://hpc.sourceforge.net
C.
On Sep 15, 2009, at 12:24 PM, Robert Kern wrote:
> 2009/9/15 Charles سمير Doutriaux :
>> Hi there,
>>
>> I have a user that failed to install numpy 1.3.0 on her Mac 10.5.8.
>
On Tue, 15 Sep 2009 13:17:43 -0600, Charles R Harris wrote:
> On Tue, Sep 15, 2009 at 12:57 PM, Michael Gilbert <
> michael.s.gilb...@gmail.com> wrote:
>
> > On Tue, 15 Sep 2009 13:26:23 -0500, Robert Kern wrote:
> > > On Tue, Sep 15, 2009 at 12:50, Charles R
> > > Harris wrote:
> > > >
> > > >
>
2009/9/15 Charles سمير Doutriaux :
> Hi there,
>
> I have a user that failed to install numpy 1.3.0 on her Mac 10.5.8.
>
> Turns out she is not using gfortran but g95.
>
> Is it a known feature? Is g95 not supposed to work with numpy?
Probably not for Mac. Most likely no one has done the work nece
On Tue, Sep 15, 2009 at 12:57 PM, Michael Gilbert <
michael.s.gilb...@gmail.com> wrote:
> On Tue, 15 Sep 2009 13:26:23 -0500, Robert Kern wrote:
> > On Tue, Sep 15, 2009 at 12:50, Charles R
> > Harris wrote:
> > >
> > >
> > > On Tue, Sep 15, 2009 at 11:38 AM, Michael Gilbert
> > > wrote:
> > >>
>
Hi there,
I have a user that failed to install numpy 1.3.0 on her Mac 10.5.8.
Turns out she is not using gfortran but g95.
Is it a known feature? Is g95 not supposed to work with numpy?
She did set FC to g95 before,
Here's the log.
Thanks,
C.
numpy.LOG
Description: Binary data
_
On Tue, 15 Sep 2009 13:26:23 -0500, Robert Kern wrote:
> On Tue, Sep 15, 2009 at 12:50, Charles R
> Harris wrote:
> >
> >
> > On Tue, Sep 15, 2009 at 11:38 AM, Michael Gilbert
> > wrote:
> >>
> >> hi,
> >>
> >> when using numpy.random.multivariate_normal, would it make sense to warn
> >> the user
On Tue, Sep 15, 2009 at 12:50, Charles R
Harris wrote:
>
>
> On Tue, Sep 15, 2009 at 11:38 AM, Michael Gilbert
> wrote:
>>
>> hi,
>>
>> when using numpy.random.multivariate_normal, would it make sense to warn
>> the user that they have entered a non-physical covariance matrix? i was
>> recently wo
On Tue, Sep 15, 2009 at 1:56 PM, Pierre GM wrote:
>
> On Sep 15, 2009, at 10:44 AM, Skipper Seabold wrote:
> How do you specify different dtypes in genfromtxt?
>>> I could not see the information in the docstring and the dtype
>>> argument
>>> does not appear to allow multiple dtypes.
>
> Just
On Sep 15, 2009, at 10:44 AM, Skipper Seabold wrote:
How do you specify different dtypes in genfromtxt?
>> I could not see the information in the docstring and the dtype
>> argument
>> does not appear to allow multiple dtypes.
Just give a regular dtype, or something that could be interpret
On Tue, Sep 15, 2009 at 11:38 AM, Michael Gilbert <
michael.s.gilb...@gmail.com> wrote:
> hi,
>
> when using numpy.random.multivariate_normal, would it make sense to warn
> the user that they have entered a non-physical covariance matrix? i was
> recently working on a problem and getting very stra
hi,
when using numpy.random.multivariate_normal, would it make sense to warn
the user that they have entered a non-physical covariance matrix? i was
recently working on a problem and getting very strange results until i
finally realized that i had actually entered a bogus covariance matrix.
its e
On Tue, Sep 15, 2009 at 09:22:41AM -0400, Skipper Seabold wrote:
> Yes, of course. I have a login already, thanks. How quickly I
> forget. I will have a look at the docs and add some examples.
Thanks a lot. Such contributions are very valuable to the community.
Gaël
___
Added: an inline grid
y,x = np.ogrid[ j:j+n, k:k+n ]
a[ j:j+n, k:k+n ] = f(x,y)
is 3* faster than a[y,x] = f(x,y) for 256x256,
about the same for little 8x8 squares (on mac ppc.)
So ogrids are not "objects" -- you can't
g = xxgrid[j:j+n, k:k+n]
...
use g, pass it just like i
On 09/15/2009 09:44 AM, Skipper Seabold wrote:
> On Tue, Sep 15, 2009 at 9:43 AM, Bruce Southey wrote:
>
>> On 09/14/2009 09:31 PM, Skipper Seabold wrote:
>>
>>> On Mon, Sep 14, 2009 at 9:59 PM, Pierre GMwrote:
>>>
>>>
>> [snip]
>>
OK, I see the problem...
Whe
On Tuesday 15 September 2009 16:30:43 Rick White wrote:
> You're not supposed to write to the locals() dictionary. Sometimes
> it works, but sometimes it doesn't. From the Python library docs:
>
> locals()
> Update and return a dictionary representing the current local symbol
> table.
>
On Tue, Sep 15, 2009 at 10:44 AM, Skipper Seabold wrote:
> On Tue, Sep 15, 2009 at 9:43 AM, Bruce Southey wrote:
>> On 09/14/2009 09:31 PM, Skipper Seabold wrote:
>>> On Mon, Sep 14, 2009 at 9:59 PM, Pierre GM wrote:
>>>
>> [snip]
OK, I see the problem...
When no dtype is defined, we t
On Tue, Sep 15, 2009 at 10:44 AM, Skipper Seabold wrote:
> On Tue, Sep 15, 2009 at 9:43 AM, Bruce Southey wrote:
>> On 09/14/2009 09:31 PM, Skipper Seabold wrote:
>>> On Mon, Sep 14, 2009 at 9:59 PM, Pierre GM wrote:
>>>
>> [snip]
OK, I see the problem...
When no dtype is defined, we t
I spent much time on similar issues, so my policy became to keep all the
packages strictly under the same tree.
Nadav
-הודעה מקורית-
מאת: numpy-discussion-boun...@scipy.org בשם Ryan May
נשלח: ג 15-ספטמבר-09 17:08
אל: Discussion of Numerical Python
נושא: Re: [Numpy-discussion] Error in
On Tue, Sep 15, 2009 at 9:43 AM, Bruce Southey wrote:
> On 09/14/2009 09:31 PM, Skipper Seabold wrote:
>> On Mon, Sep 14, 2009 at 9:59 PM, Pierre GM wrote:
>>
> [snip]
>>> OK, I see the problem...
>>> When no dtype is defined, we try to guess what a converter should
>>> return by testing its inpu
You're not supposed to write to the locals() dictionary. Sometimes
it works, but sometimes it doesn't. From the Python library docs:
locals()
Update and return a dictionary representing the current local symbol
table.
Note: The contents of this dictionary should not be modifi
Keep in mind that you can still have a problem with a conflict between your
SVN copy and system copy, if the SVN copy is visible by default (like, say,
installed to ~/.local under python 2.6) In my case, there was a problem
where a gnome panel applet used a feature in pygtk which called to numpy.
On 09/14/2009 09:31 PM, Skipper Seabold wrote:
> On Mon, Sep 14, 2009 at 9:59 PM, Pierre GM wrote:
>
[snip]
>> OK, I see the problem...
>> When no dtype is defined, we try to guess what a converter should
>> return by testing its inputs. At first we check whether the input is a
>> boolean, the
On Tue, Sep 15, 2009 at 3:37 AM, Gael Varoquaux
wrote:
> On Tue, Sep 15, 2009 at 12:50:55AM -0400, Skipper Seabold wrote:
>> Doh, so it does! The docstring could probably note this unless I just
>> missed it somewhere.
>
> Hey Skipper,
>
> You sent a patch a while ago to fix a docstring. I am not
On 09/15/2009 07:46 AM, Stéfan van der Walt wrote:
> Hi Bruce
>
> 2009/9/14 Bruce Southey:
>
>> I would like to change the dtype of just one field of a structured or
>> record array without copying the original array. I can not change the
>> creation of the original array because it was created
Hi Bruce
2009/9/14 Bruce Southey :
> I would like to change the dtype of just one field of a structured or
> record array without copying the original array. I can not change the
> creation of the original array because it was created using genfromtxt.
You can't do that, unfortunately. You can v
On 9/15/2009 7:07 AM, Sebastien Binet wrote:
> usage of the exec statement is usually frown upon and can be side stepped.
> e.g:
>
> for m in meat:
> for c in cut:
>locals()['consumed_%s_%s' % (m,c)] = some_array
Additionally, name construction can be pointless.
Maybe::
info = dict(
hi John,
> I have a bit of code where I create arrays with meaningful names via:
>
> meat = ['beef','lamb','pork']
> cut = ['ribs','cutlets']
>
> for m in meat:
>for c in cut:
> exec("consumed_%s_%s = np.zeros((numxgrid,numygrid,nummeasured))"
> % (m,c))
>
> Is this 'pythonic'? Or
Hello,
I have a bit of code where I create arrays with meaningful names via:
meat = ['beef','lamb','pork']
cut = ['ribs','cutlets']
for m in meat:
for c in cut:
exec("consumed_%s_%s = np.zeros((numxgrid,numygrid,nummeasured))" %
(m,c))
Is this 'pythonic'? Or is it bad practice (and
That it!
Thanks,
Nadav
-הודעה מקורית-
מאת: numpy-discussion-boun...@scipy.org בשם Citi, Luca
נשלח: ג 15-ספטמבר-09 11:32
אל: Discussion of Numerical Python
נושא: Re: [Numpy-discussion] Error in numpy 1.4.0 dev 07384
I got the same problem when compiling a new svn revision with som
I got the same problem when compiling a new svn revision with some intermediate
files left from the build of a previous revision.
Removing the content of the build folder before compiling the new version
solved the issue.
___
NumPy-Discussion mailing li
On Tue, Sep 15, 2009 at 12:50:55AM -0400, Skipper Seabold wrote:
> Doh, so it does! The docstring could probably note this unless I just
> missed it somewhere.
Hey Skipper,
You sent a patch a while ago to fix a docstring. I am not sure it has
been applied ( :( ).
I just wanted to point out that
47 matches
Mail list logo
