Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

BudgetOutcome has no consumer: the object that names which limit fired is never read outside Core/Budgets

Đang mở
#1,253 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu với Core/Budgets/BudgetOutcome.cs và luồng ngân sách hiện có qua WorkBudget.cs, BudgetLedger.cs và BudgetRecording.cs, sau đó theo dõi các lối thoát do tài nguyên chi phối trong Solve. Chọn đường đi của bên tiêu thụ Solve được mô tả trong issue và chạy một lệnh gọi cố ý cấp ngân sách không đủ. Được xem là hoàn tất khi bên gọi có thể đọc được subsystem hoặc limit nào đã dừng quá trình tìm kiếm, với một test bảo toàn báo cáo đó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Measured on 2dbeedf7.

BudgetOutcome (#1035) exists to name where a budget was exhausted and why. Grepping the kernel for it finds four files:

Core/Budgets/WorkBudget.cs
Core/Budgets/BudgetLedger.cs
Core/Budgets/BudgetOutcome.cs
Core/Budgets/BudgetRecording.cs

All four are the budget layer itself. It has no consumer. The object that says which limit fired is built, tested and read by nothing.

WorkBudget itself does slightly better, reaching four call sites outside its folder:

Core/Transformations/Saturation.cs
Core/Transformations/Transformation.Catalogue.cs
Functions/Simplification/Patterns/Patterns.ExpandFactorize.cs
Functions/Algebra/Groebner/Buchberger.cs
Functions/Continuous/Solvers/EquationSolver.cs
Convenience/MathS.cs

so a budget can be spent in saturation, expansion, Gröbner and the solver — and when it runs out, the outcome that would say so is not the thing that reaches the caller.

Why re-open this rather than read it off #1036

#1036 ("giving up on a resource is spelled the same as a mathematical negative") was closed as completed on 2026-08-24, and #896 with it. Its step 1 landed in #1046 and is real: Solve's two resource-driven exits answer with the equation as a set builder instead of { }, so an empty set means an established emptiness again.

But #1036 was about one chokepoint, and the survey behind it found roughly seventy sites that give up on a resource, of which one threw and one recorded which limit fired. Closing the issue closed the Solve boundary, not the class. This is filed as its own thing because the remaining work is not "finish #1036" — it is that the mechanism to do it exists and is unused, which is a different and much cheaper starting position than the survey described.

What it costs a caller today

A caller who hits a budget gets the shape of a mathematical answer with none of the provenance: which subsystem stopped, which limit it was, how much had been spent. WorkBudget carries an inherited ledger precisely so that a nested search can attribute its spend to the caller that granted it, and none of that reaches an API.

This is also #746 tier 4's prerequisite. A strategy engine picks between alternatives on the evidence of what the last one did; "it did not work" and "it ran out of room after 40,000 steps in Buchberger" select different next moves, and only the second is actionable.

Smallest first step, for discussion

Pick one consumer and take it end to end rather than sweeping seventy sites:

  • Solve is the obvious one — it already distinguishes the two exits since #1046, so it has the branch and only lacks the payload.
  • Surface the outcome somewhere a caller can read it without changing the return type of anything (a property on the result, or an out-parameter overload) — the return types are the reason this stalls, and it should not be a breaking change to find out why a search stopped.
  • Then a test asserting a deliberately under-budgeted call reports the subsystem by name, which is what stops the field going stale again.

The four sites where exhaustion is currently rendered as a mathematical claim, named in #1036's table, are the ones worth checking first — those are wrong answers rather than missing metadata.

Part of #746, tier 4.

Ngôn ngữ chính
C#
Star
831
Fork
79
Merge trung bình
2 giờ 22 phút
Pull request đã merge (30 ngày)
507

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ASC-Community/AngouriMath

Tất cả issue của ASC-Community/AngouriMath

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.