I once wrote a generic n-dimensional binning routine in C that I could find if
anyone is interested in integrating it into numpy... it didn't do size
increases though... and I think I implemented it so that binning by a
non-divisible factor trimmed the extras. It was very-very fast though.
O
records? Must have been an invalid
name, or a different error on my part. Out of curiosity, what does recarray
consider an invalid field name?
On Aug 2, 2011, at 12:31 PM, Skipper Seabold wrote:
> On Tue, Aug 2, 2011 at 3:19 PM, Craig Yoshioka wrote:
>> duplicate column in dtype?
&
duplicate column in dtype?
I just consolidated some of the columns and the error went away... none had
duplicate field names... hence the question.
On Aug 1, 2011, at 11:18 PM, Pierre GM wrote:
>
> On Aug 2, 2011, at 1:20 AM, Craig Yoshioka wrote:
>
>> Is there a limit t
Is there a limit to the number of fields a numpy recarray can have? I was
getting a strange error about a duplicate column name, but it wasn't a
duplicate.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/lis
eader().iteritems():
> setattr(self, key, value)
>
> @property
> def data(self):
> try:
> return self._data
> except AttributeError:
> self._data = self._read_data()
> return self._data
>
> Hop
I want to subclass ndarray to create a class for image and volume data, and
when referencing a file I'd like to have it load the data only when accessed.
That way the class can be used to quickly set and manipulate header values, and
won't load data unless necessary. What is the best way to do
Wow, that makes for a great howto example. Thanks.
On Jul 16, 2011, at 7:50 AM, Martin Ling wrote:
> Hi all,
>
> I have just pushed a package to GitHub which adds a quaternion dtype to
> NumPy: https://github.com/martinling/numpy_quaternion
>
> Some backstory: on Wednesday I gave a talk at Sc
I did take a look at it. It looked way heavier than I needed or wanted, plus
last time I looked it didn't support fancy indexing on axes... It does support
indexing on 'ticks' though.
There is a bit of wheel inventing going on, but I think that's OK, since things
should be well worked out an
ven ndarray, whether it just be
> a label or some more complex structure, would definitely be something I (and
> likely others) would find useful...
>
> That said, I'd love to know more about how the idx_axes() structure in your
> workaround works...
>
> - Sam
>
I brought up a while ago about how it would be nice if numpy arrays could have
their axes 'labeled'.= I got an implementation that works pretty well for
me and in the process learned quite a few things, and was hoping to foster some
more discussion on this topic, as I think I have found a si
aster than setting the accumulator
type!, I would imagine having the type-casting being done on the fly during the
mean computation would be even faster.
On Jun 1, 2011, at 9:11 AM, Bruce Southey wrote:
> On 06/01/2011 11:01 AM, Robert Kern wrote:
>> On Wed, Jun 1, 2011 at 10:44, Cr
would anyone object to fixing the numpy mean and stdv functions, so that they
always used a 64-bit value to track sums, or so that they used a running
calculation. That way
np.mean(np.zeros([4000,4000],'f4')+500)
would not equal 511.493408?
`
On May 31, 2011, at 6:08 PM, Charles R Harris w
Thanks, I will. I was just seeing if there was any intention of adding this to
type of support to numpy directly. It would be faster, and I'm sure it would
make projects like dataarray much simpler to implement (dataarray does a lot
more than my suggestion).
On May 26, 2011, at 4:53 AM, Wes Mc
Hi all,
I've read some discussions about adding labeled axes, and even ticks, to numpy
arrays (such as in Luis' dataarray).
I have recently found that the ability to label axes would be very helpful to
me, but I'd like to keep the implementation as lightweight as possible.
The reason I woul
14 matches
Mail list logo
