On Thu, Nov 2, 2017 at 3:35 PM Nathan Goldbaum
wrote:
> Ah, but what if the dtype modifies the interface? That might sound evil,
> but it's something that's been proposed. For example, if I wanted to
> replace yt's YTArray in a backward compatibile way with a dtype and just
> use plain ndarrays e
Maybe the best of both worlds would require explicit opt-in for classes
that shouldn't be coerced, e.g.,
xarray.register_data_type(MyArray)
or maybe better yet ;)
xarray.void_my_nonexistent_warranty_its_my_fault_if_my_buggy_duck_array_breaks_everything(MyArray)
On Thu, Nov 2, 2017 at 3:39 PM Mart
I guess my argument boils down to it being better to state that a
function only accepts arrays and happily let it break on, e.g.,
matrix, than use `asarray` to make a matrix into an array even though
it really isn't.
I do like the dtype ideas, but think I'd agree they're likely to come
with their
On Thu, Nov 2, 2017 at 5:21 PM, Stephan Hoyer wrote:
> On Thu, Nov 2, 2017 at 12:42 PM Nathan Goldbaum
> wrote:
>
>> Would this issue be ameliorated given Nathaniel's proposal to try to move
>> away from subclasses and towards storing data in dtypes? Or would that just
>> mean that xarray would
On Thu, Nov 2, 2017 at 12:42 PM Nathan Goldbaum
wrote:
> Would this issue be ameliorated given Nathaniel's proposal to try to move
> away from subclasses and towards storing data in dtypes? Or would that just
> mean that xarray would need to ban dtypes it doesn't know about?
>
Yes, I think custo
On Thu, Nov 2, 2017 at 5:09 PM, Benjamin Root wrote:
> Duck typing is great and all for classes that implement some or all of the
> ndarray interface but remember what the main reason for asarray() and
> asanyarray(): to automatically promote lists and tuples and other
> "array-likes" to ndar
On Thu, Nov 2, 2017 at 5:09 PM, Benjamin Root wrote:
> Duck typing is great and all for classes that implement some or all of the
> ndarray interface but remember what the main reason for asarray() and
> asanyarray(): to automatically promote lists and tuples and other
> "array-likes" to ndarr
Duck typing is great and all for classes that implement some or all of the
ndarray interface but remember what the main reason for asarray() and
asanyarray(): to automatically promote lists and tuples and other
"array-likes" to ndarrays. Ignoring the use-case of lists of lists is
problematic at
My 2ยข here is that all code should feel free to assume certain type of
input, as long as it is documented properly, but there is no reason to
enforce that by, e.g., putting `asarray` everywhere. Then, for some
pieces ducktypes and subclasses will just work like magic, and uses
you might never have
Numpy already does support a specific unit, datetime64 and timedelta64,
think through that very mechanism. Its also probably the most complicated
unit since at least there is no such thing as leap meters. And it works
well and is very useful IMHO
On Thu, Nov 2, 2017 at 3:40 PM, Nathan Goldbaum
Dear SciPythonists and NumPythonists,
FOSDEM is a free event for software developers to meet, share ideas and
collaborate. Every year, 6500+ of developers of free and open source software
from all over the world gather at the event in Brussels.
Every year, 6500+ of developers of free and open sou
On Thu, Nov 2, 2017 at 2:37 PM, Stephan Hoyer wrote:
> On Thu, Nov 2, 2017 at 9:45 AM wrote:
>
>> similar, scipy.special has ufuncs
>> what units are those?
>>
>> Most code that I know (i.e. scipy.stats and statsmodels) does not use only
>> "normal mathematical operations with ufuncs"
>> I guess
On Thu, Nov 2, 2017 at 9:45 AM wrote:
> similar, scipy.special has ufuncs
> what units are those?
>
> Most code that I know (i.e. scipy.stats and statsmodels) does not use only
> "normal mathematical operations with ufuncs"
> I guess there are a lot of "abnormal" mathematical operations
> where j
On Thu, Nov 2, 2017 at 2:39 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Josef,
>
> Indeed, for some applications one would like to have different units
> for different parts of an array. And that means that, at present, the
> quantity implementations that we have are no good a
Hi Josef,
Indeed, for some applications one would like to have different units
for different parts of an array. And that means that, at present, the
quantity implementations that we have are no good at storing, say, a
covariance matrix involving parameters with different units, where
thus each ele
On Thu, Nov 2, 2017 at 12:46 PM, Ryan May wrote:
> On Thu, Nov 2, 2017 at 6:56 AM, wrote:
>
>> On Thu, Nov 2, 2017 at 8:46 AM, wrote:
>>
>>> On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum
>>> wrote:
>>>
I think the biggest issues could be resolved if __array_concatenate__
were finis
On Thu, Nov 2, 2017 at 12:23 PM, Ryan May wrote:
> On Thu, Nov 2, 2017 at 6:46 AM, wrote:
>
>>
>>
>> On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum
>> wrote:
>>
>>> I think the biggest issues could be resolved if __array_concatenate__
>>> were finished. Unfortunately I don't feel like I can ta
On Thu, Nov 2, 2017 at 6:56 AM, wrote:
> On Thu, Nov 2, 2017 at 8:46 AM, wrote:
>
>> On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum
>> wrote:
>>
>>> I think the biggest issues could be resolved if __array_concatenate__
>>> were finished. Unfortunately I don't feel like I can take that on right
On Thu, Nov 2, 2017 at 11:51 AM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Josef,
>
> astropy's Quantity is well developed and would give similar results to
> pint; all those results make sense if one wants to have consistent
> units. A general library code will actually do the
On Thu, Nov 2, 2017 at 6:46 AM, wrote:
>
>
> On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum
> wrote:
>
>> I think the biggest issues could be resolved if __array_concatenate__
>> were finished. Unfortunately I don't feel like I can take that on right now.
>>
>> See Ryan May's talk at scipy abou
Hi Josef,
astropy's Quantity is well developed and would give similar results to
pint; all those results make sense if one wants to have consistent
units. A general library code will actually do the right thing as long
as it just uses normal mathematical operations with ufuncs - and as
long as it
On Thu, Nov 2, 2017 at 8:46 AM, wrote:
>
>
> On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum
> wrote:
>
>> I think the biggest issues could be resolved if __array_concatenate__
>> were finished. Unfortunately I don't feel like I can take that on right now.
>>
>> See Ryan May's talk at scipy abou
On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum
wrote:
> I think the biggest issues could be resolved if __array_concatenate__ were
> finished. Unfortunately I don't feel like I can take that on right now.
>
> See Ryan May's talk at scipy about using an ndarray subclass for units and
> the issues
23 matches
Mail list logo
