Optimized numerical evaluation
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 技术栈
- csharp
- 领域
- performance
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- C#
- 星标
- 831
- 派生
- 79
- 平均合并
- 2 小时 22 分钟
- 30 天内合并 PR
- 507
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ASC-Community/AngouriMath 的其他 Issue
-
难度 5/5 一周以上 新手友好度 30/100
ASC-Community/AngouriMath#1807 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
ASC-Community/AngouriMath#1692 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 30/100
ASC-Community/AngouriMath#1690 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
ASC-Community/AngouriMath#1689 · 5 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
ASC-Community/AngouriMath#1684 ·
维护者通常 1 天内回复
查看 ASC-Community/AngouriMath 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
AvaloniaUI/Avalonia#22420 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 90/100
dotnet/SqlClient#4823 · 1 条评论 ·
维护者通常 2 天内回复
-
type/automation type/tech-debt
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
clockworklabs/SpacetimeDB#6124 ·
维护者通常 1 天内回复
-
area-integrations
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复