On 10/17/06, David Huard <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'd like to poll the list to see what people want from numpy.histogram(),
> since I'm currently writing a contender.
>
> My main complaints with the current version are:
> 1. upper outliers are stored in the last bin, while lower out
Hi all -
I think I speak for many when I say that this is a huge step
for those who have desired to switch to numerical python
from other languages (IDL, MATLAB, etc) but have been
waiting for that 1.0 release. Many thanks to everyone
involved.
Erin Sheldon
On 10/26/06, Charles R Harris
Hi Alan -
I have not had luck with the binary distros. There is always
something that doesn't work, so I will be interested in
the results of your efforts.
The biggest problem with compiling things yourself is going
to be dealing with LAPACK and fortran issues, and the
backends in matplotlib.
F
On 10/31/06, Brian Granger <[EMAIL PROTECTED]> wrote:
> Nice binaries for gfortran can be found here:
>
> hpc.sourceforge.net/
Do you know how to make macports recognize this compiler if
it is outside the macports tree? I had a version of gfortran (4.2.0)
already on my system, but it insisted on c
Hi all-
I want to take the result from a database query,
and create a numpy array with field names and types
corresponding to the returned columns.
The DBI 2.0 compliant interfaces return lists
of lists. E.g.
[[94137100072000193L, 94, 345.5721510002, -0.8367320809996],
[94137100072000
I have to not ammend my statement a bit:
DBI 2.0 actually returns a lists of tuples, which would
work. It appears to just be pgdb, the postgres interface,
that is returning lists of lists. Still, I need to
interact with this database.
Erin
On Sun, Nov 12, 2006 at 06:56:29PM -0500, Erin
On 11/12/06, Pierre GM <[EMAIL PROTECTED]> wrote:
>
> You could try the fromarrays function of numpy.core.records
>
> >>> mydescriptor = {'names': (a','b','c','d'), 'formats':('f4', 'f4', 'f4',
> 'f4')}
> >>> a = N.core.records.fromarrays(N.transpose(yourlist), dtype=mydescriptor)
>
> The 'transpos
On 11/12/06, Erin Sheldon <[EMAIL PROTECTED]> wrote:
> On 11/12/06, Pierre GM <[EMAIL PROTECTED]> wrote:
> >
> > You could try the fromarrays function of numpy.core.records
> >
> > >>> mydescriptor = {'names': (a',
On 11/12/06, Charles R Harris <[EMAIL PROTECTED]> wrote:
> > 94137100072000193L
> > which ends up as
> > 94137100072000192
> > after going to a float and then back to an integer.
>
> Out of curiosity, where does that large integer come from?
It is a unique object identifier. It is a combination
On 11/12/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> I haven't been following this too closely, but if you need to transpose
> your data without converting all to one type, I can think of a couple of
> different approaches:
>
> 1. zip(*yourlist)
> 2. numpy.transpose(numpy.array(yourlist,
dtype)
That said, is there some compelling reason that the array
function doesn't support this operation?
Thanks again,
Erin
On 11/12/06, Robert Kern <[EMAIL PROTECTED]> wrote:
> Pierre GM wrote:
> > On Sunday 12 November 2006 20:10, Erin Sheldon wrote:
> >> Actu
On 11/13/06, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
>
> On 11/12/06, Erin Sheldon <[EMAIL PROTECTED]> wrote:
> > Hi all -
> >
> > Thanks to everyone for the suggestions.
> > I think map(tuple, list) is probably the most compact,
&
On 11/13/06, Francesc Altet <[EMAIL PROTECTED]> wrote:
> In any case, you can also use rec.fromrecords for build recarrays from
> lists of lists. This breaks the aforementioned rule, but Travis allowed
> this because rec.* had to mimic numarray behaviour as much as possible.
> Here is an example of
On 11/13/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Here's one more approach that's marginally faster than the map based
> solution and also won't chew up an extra memory since it's based on from
> iter:
>
> numpy.fromiter(itertools.imap(tuple, results), dtype=mydescriptor,
> count=len(results))
On 11/14/06, John Hunter <[EMAIL PROTECTED]> wrote:
>
> Has anyone written any code to facilitate dumping mysql query results
> (mainly arrays of floats) into numpy arrays directly at the extension
> code layer. The query results->list->array conversion can be slow.
>
> Ideally, one could do this
On 11/14/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Tim Hochberg wrote:
> > John Hunter wrote:
> >
> >>>>>>> "Erin" == Erin Sheldon <[EMAIL PROTECTED]> writes:
> >>>>>>>
> >>>>>>>
>
On 11/14/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
SNIP
> > Interesting results Tim. From Pierre's results
> > we saw that fromiter is the fastest way to get data
> > into arrays. With your results we see there is a
> > difference between iterating over the cursor and
> > doing a fetchall() as
Hi everyone -
(this is my fourth try in the last 24 hours to post this.
Apparently, the gmail smtp server is in the blacklist!!
this is bad).
Anyway - Recarrays have convenience attributes such that
fields may be accessed through "." in additioin to
the "field()" method. These attributes are des
Hi everyone -
(this is my third try in the last 24 hours to post this.
For some reason it hasn't been making it through)
Recarrays have convenience attributes such that
fields may be accessed through "." in additioin to
the "field()" method. These attributes are designed for
read only; one canno
rn <[EMAIL PROTECTED]> wrote:
> Erin Sheldon wrote:
> > Hi everyone -
> >
> > (this is my fourth try in the last 24 hours to post this.
> > Apparently, the gmail smtp server is in the blacklist!!
> > this is bad).
>
> I doubt it since that's where
Hi everyone -
Recarrays have convenience attributes such that
fields may be accessed through "." in additioin to
the "field()" method. These attributes are designed for
read only; one cannot alter the data through them.
Yet they are writeable:
>>> tr=numpy.recarray(10, formats='i4,f8,f8', names=
Hi everyone -
Recarrays have convenience attributes such that
fields may be accessed through "." in additioin to
the "field()" method. These attributes are designed for
read only; one cannot alter the data through them.
Yet they are writeable:
>>> tr=numpy.recarray(10, formats='i4,f8,f8', names=
This reply sent 9:36 AM, Jun 17 (because it may not show up
for a day or so from my gmail account, if it shows up at all)
On 6/17/06, Francesc Altet <[EMAIL PROTECTED]> wrote:
> El dv 16 de 06 del 2006 a les 14:46 -0700, en/na Andrew Straw va
> escriure:
> > Erin Sheldon wrot
The numpy example page still has dtype=Float and dtype=Int
all over it. Is there a generic replacement for Float, Int or should
these be changed to something more specific such as int32?
Erin
On 6/20/06, Stefan van der Walt <[EMAIL PROTECTED]> wrote:
> Hi Simon
>
> On Tue, Jun 20, 2006 at 08:22:3
OK, I have changed all the examples that used dtype=Float or
dtype=Int to float and int.
Erin
On 6/20/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 20, 2006 at 09:00:52PM -0400, Erin Sheldon wrote:
> > The numpy example page still has dtype=Float and dtype=Int
>
On 6/20/06, Bill Baxter <[EMAIL PROTECTED]> wrote:
> I think that one's on the NumPy for Matlab users, no?
>
> http://www.scipy.org/NumPy_for_Matlab_Users
>
> >>> import numpy as num
> >>> a = num.arange (10).reshape(2,5)
> >>> a
> array([[0, 1, 2, 3, 4],
>[5, 6, 7, 8, 9]])
> >>> v = num.r
ANTLR was also used for GDL http://gnudatalanguage.sourceforge.net/
with amazing results.
Erin
On 6/28/06, Mathew Yeates <[EMAIL PROTECTED]> wrote:
> I've been looking at a project called ANTLR (www.antlr.org) to do the
> translation. Unfortunately, although I may have a Matlab grammar, it
> woul
On 6/30/06, Simon Burton <[EMAIL PROTECTED]> wrote:
>
> General confusion in the community. The whole numeric->numarray->numpy story
> is a little strange for people to believe. Or at least the source for
> many jokes.
> Also, there is no mention of numpy on the numarray page. The whole
> thing sme
On 6/30/06, Erin Sheldon <[EMAIL PROTECTED]> wrote:
>http://www.numpy.org/-- is empty
I see this is now pointing to the sourceforge site. Must have been a
glitch there earlier as it was returning an empty page.
Using Tomcat but need to do more? Need to support web services, secu
It was suggested that I put off this discussion until we were closer
to the 1.0 release. Perhaps now is a good time to bring it up once
again? The quick summary: accessing field names has some
oddness that needs cleaning up.
On 3/15/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Fernando Perez
Hi everyone -
(sigh) These gmail issues are really annoying...so I apologize
if the gmail version of this message shows up in a few days.
I brought up the issue a while back of having a simple way to
access the field names of an array. The quick summary: accessing
field names has some oddness th
__() got an unexpected keyword argument 'dtype'
I understand that I could use the formats and names keywords, but
this seems a little inconsistent.
Erin
On 7/10/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> John Parejko wrote:
>
> >Howdy! I just wanted t
On 7/11/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Erin Sheldon wrote:
> > Just tested the lastest SVN and it works as advertised. Thanks
> > Travis.
> >
> > An unrelated question: why does this work for arrays but not recarrays?
> >
> >
&g
33 matches
Mail list logo
