Hi Jacob,
This is not a solely PyTables issue. As described the methods you mention
all involve attribute (or metadata) access, which is notaoriously slow in
HDF5. Or rather, much slower that read/write from the datasets (Tables,
Arrays) themselves.Generally, having a single table with 3E8
On Thu, Jun 28, 2012 at 10:41 AM, Jacob Bennett
jacob.bennet...@gmail.comwrote:
Hey Anthony,
Awesome, I think I'm going to take your advice for aiming towards larger
tables. Just an inquiry though, let's say you keep track of a
dictionary/hashtable that maps node identifiers (keys) to
Hi Alvaro,
I think if you save the table as a record array, it should return you a
record array. Or does it return a structured array? Have you tried this?
Be Well
Anthony
On Thu, Jun 28, 2012 at 11:22 AM, Alvaro Tejero Cantero alv...@minin.eswrote:
Hi,
I've noticed that tables are loaded
I just tested: passing an object of type numpy.core.records.recarray
to the constructor of createTable and then reading back it into memory
via slicing (h5f.root.myobj[:] ) returns to me a numpy.ndarray.
Best,
-á.
On Thu, Jun 28, 2012 at 5:30 PM, Anthony Scopatz scop...@gmail.com wrote:
Hi
Hmmm Ok. Maybe there needs to be a recarray flavor.
I kind of like just returning a normal ndarray, though I see your argument
for returning a recarray. Maybe some of the other devs can jump in here
with an opinion.
Be Well
Anthony
On Thu, Jun 28, 2012 at 12:37 PM, Alvaro Tejero Cantero
Yes, I think it would make more sense to return a recarray too.
However, I remember many time ago (3, 4 years?) that NumPy developers
were recommending using structured arrays instead of recarrays. I don't
remember exactly the arguments, but I think that was the reason why the
structured
On Thu, Jun 28, 2012 at 3:23 PM, Francesc Alted fal...@pytables.org wrote:
Yes, I think it would make more sense to return a recarray too. However,
I remember many time ago (3, 4 years?) that NumPy developers were
recommending using structured arrays instead of recarrays. I don't
remember
Hello Again Jacob,
Hmm are they of Python type long? Also, what exactly is the number that is
failing?
Be Well
Anthony
On Thu, Jun 28, 2012 at 4:18 PM, Jacob Bennett jacob.bennet...@gmail.comwrote:
Hello PyTables Users,
I have a concern with a very strange error that references that my
Thank you Josh, that is representative enough. In my system the
speedup of structured arrays is ~30x. A copy of the whole array is
still ~6x faster.
-á.
On Thu, Jun 28, 2012 at 10:13 PM, Josh Ayers josh.ay...@gmail.com wrote:
import time
import numpy as np
dtype = np.format_parser(['i4',
It's strange really. It seems like anything int 64 in python (greater than
4billion) fails to convert and throws this message; however, for numbers
that can be represented by int 32 can convert fine. Btw, this is for a
field that is defined as UInt64 in pytables and only fails if I do
Thanks Jacob,
This definitely sounds like a bug. if you come up with a self contained
example, please report it at https://github.com/PyTables/PyTables/issues
Thanks!
Anthony
On Thu, Jun 28, 2012 at 7:40 PM, Jacob Bennett jacob.bennet...@gmail.comwrote:
It's strange really. It seems like
11 matches
Mail list logo
