| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
As per comment by Ross. float64 can be put at the same precision
as "uint64". This is incorrect, but it is the practical choice
that NumPy uses.
|
| | |
|
| |
|
|
|
|
| |
Even if I prefer not to mention the word "category" too much, integral vs. inexact
is the "magic" boundary when it comes to Python promoting an numpy
scalar to the higher category.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This NEP proposes adoption the array API standard
(https://data-apis.github.io/array-api/latest/) in NumPy.
This will add a new `numpy.array_api` submodule containing that
standardized API.
The main purpose of this API is to be able to write code that is
portable to other array/tensor libraries like CuPy, PyTorch,
JAX, TensorFlow, Dask, and MXNet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* NEP: Initial draft for NEP 43
* NEP: Small updates to NEP 43
* Partial iteration on some content, mostly updates the calling convention
Its not quite settled, I don't quite like the `npy_intp *` as a default
"user-data" yet, but I think I may warm up to it, and I think some kind
of default like that is really very convenient.
Split out `user_data *`, since I think Marten has a point that
separating "constant" and volatile data is conceptionally easier.
* Add a bit more overview-intro at the start and refactor "bound" method section
* Small fixups based on Marten and also Hameers comments
* Revise the "promotion and dispatching" section a bit.
* Fix back-compat section and add a tiny bit of implementation
* WIP: Further updates nep 43
* Revise NEP 43 and expand on arraymethod (previously the dispatching/promotion was more fleshed out)
* Update image and make sure it is included at the right place.
* small fixups
* Update doc/neps/nep-0043-extensible-ufuncs.rst
Co-authored-by: Dave Hirschfeld <dave.hirschfeld@gmail.com>
* Fix comment which was missing the final part of sentence
* Pass through, up to "steps involved in a ufunc call"
* Review up to ArrayMethod
* Review up to ArrayMethod Specs
* Review up to loop reuse
* Review most of the remaining document
* Fix title typo
* Wording updates and minor fixups.
* Apply suggestions from code review
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
* Address Ross's additional comments
Co-authored-by: Dave Hirschfeld <dave.hirschfeld@gmail.com>
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* DOC: Edit NEP-42 for clarity
* DOC: Further edits of NEP 42
* DOC: Edit NEP-42 for clarity
* DOC: Further edits of NEP 42
* WIP: Work out structure a bit and make intro longer
* DOC: Round 3 of NEP 42 edits
* Start with a new motivation/overview to be forced upon the rest
* restructure along "top-level" categories and rename adjust_descriptors
* Small fixups
* Small clarity/correctness edits
* Use `PyArrayMethod` instead of UFuncImpl
I am starting to feel that calling this "array method" (even if
it is in no way numpy array specific) is probably the best name.
It is not ufunc specific, because ufuncs are dispatching + array method.
Calling it ufuncimpl makes sense, but since the UFunc name which would
also work perfectly is already taken, maybe a whole new name is better.
* DOC: Fold in @seberg revisions
* Fix typo
* Make first example/overview inherit dtype instead of metaclass
it could say `metaclass=DTypeMeta`, but its implicit.
* DOC: Add "checklist" to NEP 42
Also anchor NEP 40 figure for reference in NEP 42.
* Delete duplicated dtype-discovery section
The section must have been duplicated in an merge conflict :/,
I scanned through, and I think the version that was in the right place
got most edits, although not 100% sure.
* DOC: Reorganize scope, standardize heds
* DOC: Retitle, revisions up to Casting
Also anchor for parametric type discussion in NEP 40
* Some smaller changes/additions
* DOC: Reorganize for better flow
Also adds a NEP anchor at top.
* DOC: Glossary, shuffle "Additional information" bullets
* DOC: Small updates for sense and case
* Fixup merge (some changes were not saved when finishing merge)
* Answer bjnath's questions and motivate user impact
It seems most answers bjnath already included himself, this adds
a few tweaks.
Added a note that tusers will basically have to implement the
DType class as outlined is basically what the user will have to
implement, so spell that out both at the top and in the C-API to
clarify that.
* NEP 41: Add subsection on dtype organization with parameters
This might go a bit far, but I think the image goes very far in
giving people the right idea of how to think of dtypes and
DType instances.
The question is if we want to even show the "alternative"...
* Add bjnath as author
* Add new header also to NEP 41
* DOC: Minor: delete horiz rules, tweak 2 headings
* Rephrase NEP 41 bullt points in terms of NEP 42
Also changes those for NEP 43, to represent what is done, rather
than what is solved (and thus fit better to the way its written
for the NEP 42 part)
* Try to rewerd paragraphs around setitem/getitem a bit
some of these were very confusing, hopefully they are a bit better
now.
* Make a pass over the array-coercion part
* Make careful pass up until array-coercion
* Pass over the second half of the NEP 42 draft.
* Use "given_descrs" which seems clearer and fix casting
I always thought returning the casting safety is an awesome idea, but
right now I am actually not so sure it helps much with anything.
Its usually simpler, I guess. But if the user requested safe casting
and we have an unsafe cast, for example for structured dtypes we
will end up doing a lot of work for no reason.
If we accept an error return without an error already set this is
solved. My original reason was that setting a generic error in the
resolve descriptor function would really be pretty annoying, so
that returning the casting safety seemed like a good way to
avoid worrying about most errors there.
The "cast-is-view" output is important though.
* Fix copy new intro note to NEP 40 (and fix it in NEP 41)
Co-authored-by: Ben Nathanson <github@bigriver.xyz>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This NEP may require some thought and technical changes. There are also a few other things as to how we exactly implement e.g. lookup of which cast to use.
I currently envision that we accept NEP 41, with the decision to start on this NEP. However, we keep most of the proposal here private API, and thus somewhat flexible to changes before we finalize the API.
Some changes (i.e. the exact "methods", we need to define) should probably not be included here, but rather incrementally added later. Maybe by modifying the document, or adding a new NEP depending on the size of the change.
* NEP: Technical decisions for new DTypes
* Add datetime to the dtype hierarchy plot
* Some clarifications and smaller updates (not a proofread and not examples yet)
* clarify how casting will be signalled
* Updates to the NEP, hopefully answer a lot of Martens questions
Also uses datetime64 as an example in a few places, which
is hopefully useful.
* Apply suggestions from code review
Commit mainly grammer/style fixes from ross (direct suggestions)
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
* Incorporate second chunk of Ross' feedback
* Apply suggestions from code review
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
* Minor adjustment, add example for how promote_types works...
* Apply suggestions from code review
Apply suggestions from Joris.
Co-authored-by: Joris Van den Bossche <jorisvandenbossche@gmail.com>
* Incorporate feedback from Marten and Joris
Mainly adds a figure for the casting section, and tries to rephrase
the first part of it almost entirely around that figure, which should
also simplify it a lot, although at this time possible loses a tiny
bit precision/details.
* NEP: Apply suggestions from Ross
<Many fixups from Ross>
* NEP: Fix the last section and missing link.
Also clarify the ``kind`` and ``char`` a bit, suggesting to
use ``__qualname__``. While this is weird for ``char``, it
is at least guaranteed to be be unique and to fail when used
inapproprioatly.
* NEP: Type edits for NEP 42 and Eric Wiesers suggestions
Some type edits for the first part mainly and fixups based on
Eric's review.
* Fixup links
Co-Authored-By: Marten van Kerkwijk <mhvk@astro.utoronto.ca>
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
Co-authored-by: Joris Van den Bossche <jorisvandenbossche@gmail.com>
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
|
| |
|
|
|
|
| |
* NEP: Create informational NEP 40 about current DTypes
Co-Authored-By: Ross Barnowski <rossbar@berkeley.edu>
Co-Authored-By: Eric Wieser <wieser.eric@gmail.com>
Co-authored-by: mattip <matti.picus@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This NEP is supposed to:
1. Motivate the whole DType change and lay out a rough plan.
2. Clarify a few mainly high level decision/plans.
3. Get inertia on starting to implement espeically a DTypeMeta class in C, and slowly add new private API working towards Phase II, which is planned t be better specified by NEP 42 and 43.
Full list of squashed commits (including suggestions below):
* NEP: Create NEP41, proposing a rough plan for new DTypes
* Try to clarify how datatypes are "natural" compared to array likes and clean up API breakage section
* Fix references (mostly at least)
* Add a first draft of a few examples.
* Reorganize examples as per suggestion by Marten and add ufunc loop note
* Make a pass on the first chunk and number the later stuff to match
* Some minaor adjustments
* Add, probably silly, picture.
* Add pngs, since it is probably easier to render...
* Small changes, mainly to see if I can make it render...
* Apply suggestions from code review
Thanks @crusaderky especially for type reading and all the reference, etc. issues!
Co-Authored-By: crusaderky <crusaderky@gmail.com>
Co-Authored-By: Maximilian Roos <5635139+max-sixty@users.noreply.github.com>
* Tiny fixes, mainly fix title levels hopefully
It seems I am not allowd to skip a title level in one point
but not another.
* Small changes/fixups
* Reorganize sections to better fit template.
* Further swapping of Detailed Information part.
* Make motivation clear and mention user impact section
the user impact section is more useful than the actual motivation
section.... since the motivation is more technical in nature
* Small editing of the first few sections
* Some further small type-edits for the later sections
* Add a small paragraph mentioning the intention of a fallback
* Smaller changes, rework phases at beginning of scopes section
* Mention which NEP is to define which bullet point in Phase II
* Consolidate point 1+2 into a single point and clarify the incompatible change
* Mention the change of how methods are defined in the backcompat section
* Add a note at the top of the NEP (will need to be links to other NEPs)
This note will almost identiclaly be added to the other NEPs then..
* Fixups mainly based on comments from Ross (large chunks are directly using his suggestions)
* Apply suggestions from code review
Co-Authored-By: Eric Wieser <wieser.eric@gmail.com>
* Incorporate most of Erics comments (which were not already suggestions)
* Update doc/neps/nep-0041-improved-dtype-support.rst
Co-Authored-By: Eric Wieser <wieser.eric@gmail.com>
* Apply suggestions from code review
Co-Authored-By: Eric Wieser <wieser.eric@gmail.com>
* Small reformatting, fix authors and add drafty acknowledgments
Ross does not want authorship, so he has to suffer through this ;).
Co-authored-by: crusaderky <crusaderky@gmail.com>
Co-authored-by: Maximilian Roos <5635139+max-sixty@users.noreply.github.com>
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
|
| | |
|
| | |
|
| |
|
