On Thu, 2022-11-10 at 14:55 +0100, Oscar Gustafsson wrote: > Den tors 10 nov. 2022 kl 13:10 skrev Sebastian Berg < > sebast...@sipsolutions.net>: > > > On Thu, 2022-11-10 at 11:08 +0100, Oscar Gustafsson wrote: > > > > > > > > I'm not an expert, but I never encountered rounding floating > > > > point > > > > numbers > > > > in bases different from 2 and 10. > > > > > > > > > > I agree that this is probably not very common. More a possibility > > > if > > > one > > > would supply a base argument to around. > > > > > > However, it is worth noting that Matlab has the quant function, > > > https://www.mathworks.com/help/deeplearning/ref/quant.html which > > > basically > > > supports arbitrary bases (as a special case of an even more > > > general > > > approach). So there may be other use cases (although the example > > > basically > > > just implements around(x, 1)). > > > > > > To be honest, hearing hardware design and data compression does > > make me > > lean towards it not being mainstream enough that inclusion in NumPy > > really makes sense. But happy to hear opposing opinions. > > > > Here I can easily argue that "all" computations are limited by finite > word > length and as soon as you want to see the effect of any type of > format not > supported out of the box, it will be beneficial. (Strictly, it makes > more > sense to quantize to a given number of bits than a given number of > decimal > digits, as we cannot represent most of those exactly.) But I may not > do > that. > > > > It would be nice to have more of a culture around ufuncs that do > > not > > live in NumPy. (I suppose at some point it was more difficult to > > do C- > > extension, but that is many years ago). > > > > I do agree with this though. And this got me realizing that maybe > what I > actually would like to do is to create an array-library with fully > customizable (numeric) data types instead. That is, sort of, the > proper way > to do it, although the proposed approach is indeed simpler and in > most > cases will work well enough. > > (Am I right in believing that it is not that easy to piggy-back > custom data > types onto NumPy arrays? Something different from using object as > dtype or > the "struct-like" custom approach using the existing scalar types.)
NumPy is pretty much fully customizeable (beyond just numeric data types). Admittedly, to not have weird edge cases and have more power you have to use the new API (NEP 41-43 [1]) and that is "experimental" and may have some holes. "Experimental" doesn't mean it is expected to change significantly, just that you can't ship your stuff broadly really. The holes may matter for some complicated dtypes (custom memory allocation, parametric...). But at this point many should be rather fixable, so before you do your own give NumPy a chance? - Sebastian [1] https://numpy.org/neps/nep-0041-improved-dtype-support.html > > BR Oscar Gustafsson > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: sebast...@sipsolutions.net _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
