Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Idea: support virtual table of LAPACK functions

Ouverte
  • Quelque chose ne va pas ?
#413 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
30/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Active
Stack technique
python, rust
Domaine
hpc

Piste de recherche

Start by reviewing the proposed lax::init_from_python(py) entry point, SciPy's scipy.linalg.cython_blas and scipy.linalg.cython_lapack interfaces, and the working approach linked in lenskit/lkpy#960. Define how a PyO3 module would obtain and install the function pointers so lax and ndarray-linalg can reuse SciPy's BLAS and LAPACK without a separate copy.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

This might more properly belong in lapack-sys, but it would be very useful to be able to reuse BLAS and LAPACK from SciPy when using lax and ndarray-linalg to build Python extension modules with PyO3.

SciPy exposes routines from the BLAS and LAPACK it was linked against in a manner that can be imported with Cython's cimport, in the modules scipy.linalg.cython_blas and scipy.linalg.cython_lapack, to allow other Python extension modules implemented using Cython to reuse BLAS and LAPACK instead of needing to supply their own copy. I am not sure the best way to identify and properly link against these functions; I have one working method at lenskit/lkpy#960, fishing a pointer to sposv out of Python at runtime (the Cython modules expose them in a Python dictionary).

I imagine an interface where a PyO3 extension module can do something like use lax with a python feature, then call a method like lax::init_from_python(py) in a module initializer to grab the proper function pointers and set them up for lax to use, after which the lax methods (and therefore ndarray-linalg) will work without needing to compile or link against a separate BLAS and LAPACK.

In shared-library settings, like Pixi/Conda or system packages, all of the different modules can directly link against the same "system" BLAS. However, Python binary wheels do not make that easy, and the general solution is for each package to statically link against BLAS, or to use SciPy's export if it depends on SciPy.

Langage dominant
Rust
Étoiles
452
Forks
95
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

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de rust-ndarray/ndarray-linalg

Toutes les issues de rust-ndarray/ndarray-linalg

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.