Sebastian Haase wrote:
> Hi!
> Do numpy memmap have a way of explicitly
> flushing data to disk
> and/or
> closing the memmap.
>
There is a sync method that performs the flush. To close the memmap,
delete it.
More detail:
The memmap sub-class has a _mmap attribute that is the Python
mem
Hi!
Do numpy memmap have a way of explicitly
flushing data to disk
and/or
closing the memmap.
In numarray these were methods called
memmappedArr.flush()
and
memmappedArr.close()
Thanks,
Sebastian
___
Numpy-discussion mailing list
Numpy-discussion@scipy.
Tim Churches wrote:
> Robert Kern wrote:
>> I don't see why. RPy will use numpy internally to communicate with R. Your
>> code
>> will use Numeric internally to do whatever you do. As of Numeric 24.2, each
>> can
>> consume the other's arrays seamlessly.
>
> OK, if that is the case, then it migh
Robert Kern wrote:
> I don't see why. RPy will use numpy internally to communicate with R. Your
> code
> will use Numeric internally to do whatever you do. As of Numeric 24.2, each
> can
> consume the other's arrays seamlessly.
OK, if that is the case, then it might be OK for us if RPy dropped
N
Tim Churches wrote:
> Travis Oliphant wrote:
>> I've added a patch to the Porting to NumPy page so that RPy uses NumPy
>> instead of Numeric. It would be very helpful for unification if these
>> package authors would accept these patches. NumPy is far enough along
>> in development that I don'
Travis Oliphant wrote:
> I've added a patch to the Porting to NumPy page so that RPy uses NumPy
> instead of Numeric. It would be very helpful for unification if these
> package authors would accept these patches. NumPy is far enough along
> in development that I don't think there is any reaso
I'm trying to help out the conversion to NumPy by offering patches to
various third-party packages that have used Numeric in the past.
Does anybody here have requests for which packages they would like to
see converted to use NumPy? Ultimately, we are at the mercy of the
package-owners to com
I've added a patch to the Porting to NumPy page so that RPy uses NumPy
instead of Numeric. It would be very helpful for unification if these
package authors would accept these patches. NumPy is far enough along
in development that I don't think there is any reason for new releases
of package
Robert Kern wrote:
> Note that this is a hack. It won't work for the ufuncs in scipy.special, for
> example.
>
> We should look into including __module__ information in ufuncs. This is how
> regular functions are pickled.
>
>
This sounds like a good idea. Would it be possible to add a "dict"
o
Gary Ruben wrote:
> One question, which may be an issue: Should ones, zeros and empty be
> generating arrays of floats by default now?
>>> import numpy as N
>>> N.ones((3,)).dtype
dtype('float64')
>>> N.zeros((3,)).dtype
dtype('float64')
>>> N.__version__
'1.0.1'
-Chris
--
Christopher
On Tue, 30 Jan 2007, Gary Ruben apparently wrote:
> One question, which may be an issue: Should ones, zeros
> and empty be generating arrays of floats by default now?
>>> import numpy as n
>>> z = n.zeros((2,2))
>>> z.dtype
dtype('float64')
>>> o = n.ones((2,2))
>>> o.dtype
dtype('float64')
>>>
Hi all,
Thank you for your replies ... my question was initially unclear in
that I knew that using normal slicing would do the trick, but it was
rather a list of indices that couldn't be represented as a slice that
was bugging me. Luckily, Robert's solution solves this problem for
the gene
One question, which may be an issue: Should ones, zeros and empty be
generating arrays of floats by default now?
Gary R.
Travis Oliphant wrote:
> I think it's time for the 1.0.2 release of NumPy.
>
> What outstanding issues need to be resolved before we do it?
>
> Hopefully, we can do it by
13 matches
Mail list logo