On Thu, Dec 1, 2011 at 17:39, Charles R Harris
wrote:
> Given that strings should be the result, this looks like a bug. It's a bit
> of a corner case that probably slipped through during the recent work on
> casting. There needs to be tests for these sorts of things, so if you find
> more oddities
On Fri, Dec 2, 2011 at 8:23 AM, Thouis (Ray) Jones wrote:
> On Thu, Dec 1, 2011 at 17:39, Charles R Harris
> wrote:
> > Given that strings should be the result, this looks like a bug. It's a
> bit
> > of a corner case that probably slipped through during the recent work on
> > casting. There nee
OK - here is the status update on this problem:
1. To test for bad RAM, I saved the code plus data onto a usb drive and
manually transferred it to a colleague's desktop machine with same specs as
mine. The NaN values continued to appear at random, so it is unlikely to be
bad RAM - unless its cont
If save/load actually makes a reliable difference, then it would be useful
to do something like this, and see what you see:
save("X", X)
X2 = load("X.npy")
diff = (X == X2)
# did save/load change anything?
any(diff)
# if so, then what changed?
X[diff]
X2[diff]
# any subtle differences in floating
I need to take an array - derived from raster GIS data - and upsample or scale
it. That is, I need to repeat each value in each dimension so that, for
example, a 2x2 array becomes a 4x4 array as follows:
[[1, 2],
[3, 4]]
becomes
[[1,1,2,2],
[1,1,2,2],
[3,3,4,4]
[3,3,4,4]]
It seems like so
On Sat, Dec 3, 2011 at 12:35 AM, Robin Kraft wrote:
> I need to take an array - derived from raster GIS data - and upsample or
> scale it. That is, I need to repeat each value in each dimension so that,
> for example, a 2x2 array becomes a 4x4 array as follows:
>
> [[1, 2],
> [3, 4]]
>
> becomes
