Ruben Salvador wrote:
> Great! Thanks for all your answers!
>
> I actually have the files created as .npy (appending a new array eact
> time). I know it's weird, and it's not its intended use. But, for
> whatsoever reasons, I came to use that. No turn back now.
>
> Fortunately, I am able to read
Great! Thanks for all your answers!
I actually have the files created as .npy (appending a new array eact time).
I know it's weird, and it's not its intended use. But, for whatsoever
reasons, I came to use that. No turn back now.
Fortunately, I am able to read the files correctly, so being weird
2010/6/28 Keith Goodman :
> How about using h5py? It's not part of numpy but it gives you a
> dictionary-like interface to your archive:
Yeaa, or PyTables (is that equivalent)? It's also a hdf (or whatever,
I don't recall precisely) interface.
There were [ANN]s on the list about PyTables.
Fried
On Wed, Jun 23, 2010 at 3:46 AM, Ruben Salvador wrote:
> Hi there,
>
> I have a .npy file built by succesively adding results from different test
> runs of an algorithm. Each time it's run, I save a numpy.array using
> numpy.save as follows:
>
> fn = 'file.npy'
> f = open(fn, 'a+b')
> np.save(f, a
ma, 2010-06-28 kello 15:48 -0400, Anne Archibald kirjoitti:
[clip]
> That said, good exception hygiene argues that np.load should throw
> EOFErrors rather than the more generic IOErrors, but I don't know how
> difficult this would be to achieve.
np.load is in any case unhygienic, since it tries to
On 28 June 2010 10:52, Ruben Salvador wrote:
> Sorry I had no access during these days.
>
> Thanks for the answer Friedrich, I had already checked numpy.savez, but
> unfortunately I cannot make use of it. I don't have all the data needed to
> be saved at the same time...it is produced each time I
2010/6/28 Ruben Salvador :
> Thanks for the answer Friedrich, I had already checked numpy.savez, but
> unfortunately I cannot make use of it. I don't have all the data needed to
> be saved at the same time...it is produced each time I run a test.
Yes, I thought of something like:
all_data = numpy
ke, 2010-06-23 kello 12:46 +0200, Ruben Salvador kirjoitti:
[clip]
> how can I detect the EOF to stop reading
r = f.read(1)
if not r:
break # EOF
else:
f.seek(-1, 1)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.or
Sorry I had no access during these days.
Thanks for the answer Friedrich, I had already checked numpy.savez, but
unfortunately I cannot make use of it. I don't have all the data needed to
be saved at the same time...it is produced each time I run a test.
Thanks anyway!
Any other idea why this is
2010/6/23 Ruben Salvador :
> Therefore, is this a bug? Shouldn't EOFError be raised instead of IOError?
> Or am I missunderstanding something? If this is not a bug, how can I detect
> the EOF to stop reading (I expect a way for this to work without tweaking
> the code with saving first in the file
Sorry, I forgot to include versions info:
Python 2.5.5
Numpy Version: 1:1.3.0-3+b1 (actual debian testing)
On Wed, Jun 23, 2010 at 12:46 PM, Ruben Salvador wrote:
> Hi there,
>
> I have a .npy file built by succesively adding results from different test
> runs of an algorithm. Each time it's run
Hi there,
I have a .npy file built by succesively adding results from different test
runs of an algorithm. Each time it's run, I save a numpy.array using
numpy.save as follows:
fn = 'file.npy'
f = open(fn, 'a+b')
np.save(f, arr)
f.close()
When I try to read the file with the following code, for
12 matches
Mail list logo
