Can we contextualize `parent_type`?
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 20/100
Piste de recherche
Commencez par lire la PR liée et la discussion de l’issue sur parent(x), parent_type(x) et les catégories BufferStyle proposées. Comparez les exemples cités —SubArray, Tridiagonal et FillArrays— et déterminez s’il est possible de spécifier un trait concret ou une conception générique f(x) = f(parent(x)). Le travail est terminé lorsqu’une proposition d’interface arrêtée et implémentable a été définie.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
When I made this PR to base some good points were brought up about what we knew about parent(x) compared to x. With a few exceptions (that we should probably clean up), we simply use parent_type as convenient syntax for communicating the type of the underlying data buffer/collection. An informal search through juliahub shows that a handful of packages define something very similar independent of this package, so it's clearly something that has utility already. I'd like to know if we could do better.
The biggest hangup here is how we succinctly describe what assumptions persists between x and parent(x). The only approachable idea I have is a method like is_lazy_wrapper when we can assume that the wrapper type changes nothing. However, that seems extremely limiting and questionably useful.
A more approachable aspect to this is describing the kind of type that is parent_type(x). For example, sub-typing something like BufferStyle with these subtypes:
WrappedBuffer: single wrapped buffer likeSubArray.MultiBuffer: multiple distinct buffers likeTridiagonalComputedBuffer: buffer is computed on the fly and isn't stored in memory (e.g., FillArrays).
However, creating traits for describing parent_type(x) isn't terribly useful until we have a generic approach for doing f(x) = f(parent(x)).
- Langage dominant
- Julia
- Étoiles
- 14
- Forks
- 8
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de JuliaArrays/StaticArrayInterface.jl
-
tagbot-manual
Difficulté 1/5 Moins d'une heure Accessibilité débutants 68/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 35/100
-
Storage OrderOuverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
JuliaArrays/StaticArrayInterface.jl#4 · 1 commentaire ·
-
Size of StaticArray typeOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 32/100
JuliaArrays/StaticArrayInterface.jl#3 · 10 commentaires ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
JuliaArrays/StaticArrayInterface.jl#10 · 2 commentaires ·
Toutes les issues de JuliaArrays/StaticArrayInterface.jl
Issues similaires
-
Difficulté 2/5 Moins d'une heure Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
CliMA/ClimaAtmos.jl#4891 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
tagbot-manual
Difficulté 1/5 Moins d'une heure Accessibilité débutants 75/100
tshort/StaticCompiler.jl#191 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
SciML/SciMLSensitivity.jl#1703 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
JuliaGPU/GPUCompiler.jl#1008 ·
Les mainteneurs répondent en général sous 1 jour