Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Optimized numerical evaluation

Abierto
  • ¿Algo no está bien?
#1,338 20 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
csharp
Área
performance

Línea de trabajo

Start by reviewing the existing numerical evaluation benchmarks mentioned in the issue and the current use of PeterO.Numbers. Compare speed, memory, accuracy, and precision across the proposed evaluation approaches, then identify concrete improvements and validate them with the benchmark suite; the issue is done only when all visible improvements are complete.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

The default precision today enables precise computation without necessarily merging terms just because they differ in floating point computation.

However, for some applications we may opt for less precision, because if we can use hardware floating point types for example, then the speedups will be great.

The same applies for some workloads on some computers that may benefit from specialized instructions or GPU delegation.

This is separate from function compilation because we are optimizing on node manipulation here.

So here are the following items to be determined:

  • Are the numerical evaluation types (PeterO.Numbers) the best available for C#? Have there been new work, or work that we can port over, on arbitrary precision evaluation?
  • How much can we optimize for each numerical precision (e.g. say 10 digits - would double evaluation suffice then cast back? may internals use double precision evaluation for speed at 10 digits precision?)
  • What is the Pareto frontier of (speed, memory) vs accuracy vs precision, on each workload (presumably this is the benchmarks that we currently track?)
  • How would available computing resources, say multiple cores, or GPU availability, change this? Can we take advantage of it?
  • What applications should choose what precisions? Does this relate to other settings we provide?
  • How should precision be tuned? Is it a good idea for it to be auto tuned by default?

Use this issue to track improvements; only close when all visible improvements are done.

Lenguaje dominante
C#
Estrellas
831
Forks
79
Merge medio
2 h 22 min
PR fusionados (30 d)
507

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ASC-Community/AngouriMath

Todos los issues de ASC-Community/AngouriMath

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.