Hi Sebastian,
One way to avoid an ugly lookup table and special cases is to store the amount
of sign bits, the amount of integer/mantissa bits and the amount of exponent
bits for each numeric style. A safe cast can only happen if all three are
exceeded or equal. Just a thought.
Best Regards,
H
On Wed, 2019-06-12 at 17:34 -0700, Nathaniel Smith wrote:
> On Wed, Jun 12, 2019 at 12:58 PM Marten van Kerkwijk
> wrote:
> > Overall, in favour of splitting the large files, but I don't like
> > that the notes stop being under version control (e.g., a follow-up
> > PR slightly changes things, how
On Wed, Jun 12, 2019 at 5:55 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> You're right, the problem is with the added keyword argument (which would
> appear also if we did not still have to support the old .sum method
> override but just dispatched to __array_ufunc__ w
The attrs like you sent definitely sounded like it would translate to numpy
nearly trivially. I'm very much in favour!
-- Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
Hi Ralf,
You're right, the problem is with the added keyword argument (which would
appear also if we did not still have to support the old .sum method
override but just dispatched to __array_ufunc__ with `np.add.reduce` -
maybe worse given that it seems likely the reduce method has seen much less
On Wed, Jun 12, 2019 at 12:58 PM Marten van Kerkwijk
wrote:
>
> Overall, in favour of splitting the large files, but I don't like that the
> notes stop being under version control (e.g., a follow-up PR slightly changes
> things, how does the note gets edited/reverted?).
>
> Has there been any di
On Wed, 12 Jun 2019 15:57:48 -0400, Marten van Kerkwijk wrote:
> Overall, in favour of splitting the large files, but I don't like that the
> notes stop being under version control (e.g., a follow-up PR slightly
> changes things, how does the note gets edited/reverted?).
>
> Has there been any dis
On Wed, Jun 12, 2019 at 12:02 AM Stefan van der Walt
wrote:
> On Tue, 11 Jun 2019 15:10:16 -0400, Marten van Kerkwijk wrote:
> > In a way, I brought it up mostly as a concrete example of an internal
> > implementation which we cannot change to an objectively cleaner one
> because
> > other packag
Overall, in favour of splitting the large files, but I don't like that the
notes stop being under version control (e.g., a follow-up PR slightly
changes things, how does the note gets edited/reverted?).
Has there been any discussion of having, e.g., a directory
`docs/1.17.0-notes/`, and everyone s
On Wed, 2019-06-12 at 12:03 -0500, Sebastian Berg wrote:
> On Tue, 2019-06-11 at 22:08 -0400, Marten van Kerkwijk wrote:
> > HI Sebastian,
> >
> > Thanks for the overview! In the value-based casting, what perhaps
> > surprises me most is that it is done within a kind; it would seem
> > an
> > impr
On Wed, 2019-06-12 at 11:45 -0700, Nathaniel Smith wrote:
> It might be worth considering a tool like 'towncrier'. It's
> automation to support the workflow where PRs that make changes also
> include their release notes, so when the release comes you've already
> done all the work and just have to
It's worth linking to the issue where this discussion started, so we avoid
repeating ourselves -
https://github.com/numpy/numpy/issues/13707.
Eric
On Wed, Jun 12, 2019, 11:51 Nathaniel Smith wrote:
> It might be worth considering a tool like 'towncrier'. It's automation to
> support the workfl
It might be worth considering a tool like 'towncrier'. It's automation to
support the workflow where PRs that make changes also include their release
notes, so when the release comes you've already done all the work and just
have to hit the button.
On Wed, Jun 12, 2019, 07:59 Sebastian Berg
wrote
On Wed, 2019-06-05 at 15:41 -0500, Sebastian Berg wrote:
> Hi all,
>
> TL;DR:
>
> Value based promotion seems complex both for users and ufunc-
> dispatching/promotion logic. Is there any way we can move forward
> here,
> and if we do, could we just risk some possible (maybe not-existing)
> corne
> 3. After merging, the release notes are copied into the wiki by the
> user or a contributor. After the copy happened, the label could/should
> be removed?
In astropy we keep our "whats-new-needed" label around, so people
doing the release can double check that everything is indeed ended up
in t
On Tue, 2019-06-11 at 22:08 -0400, Marten van Kerkwijk wrote:
> HI Sebastian,
>
> Thanks for the overview! In the value-based casting, what perhaps
> surprises me most is that it is done within a kind; it would seem an
> improvement to check whether a given integer scalar is exactly
> representabl
On Wed, Jun 12, 2019 at 8:59 AM Sebastian Berg
wrote:
> Hi all,
>
> we had discussed trying a new strategy to gather release notes on the
> last community call, but not followed up on it on the list yet.
>
> For the next release, we decided to try a strategy of using a wiki page
> to gather relea
On Wed, Jun 12, 2019 at 4:59 PM Sebastian Berg
wrote:
> Hi all,
>
> we had discussed trying a new strategy to gather release notes on the
> last community call, but not followed up on it on the list yet.
>
> For the next release, we decided to try a strategy of using a wiki page
> to gather relea
Hi all,
we had discussed trying a new strategy to gather release notes on the
last community call, but not followed up on it on the list yet.
For the next release, we decided to try a strategy of using a wiki page
to gather release notes. The main purpose for this is to avoid merge
conflicts in t
19 matches
Mail list logo
