Design discussion

まず src/NestedNumbers.jl と examples/usage_demo.jl から始め、その後、リンクされている draft PRs と Reactant および Discourse のコンテキストを確認します。この issue は、範囲を限定した変更を指定するのではなく、パッケージ名、型階層、全体的なアプローチに対するコミュニティからの批評を求めています。完了には、合意された方向性または具体的なフォローアップ提案が必要です。

We have some number types in the Julia ecosystem that are "a bit special". The one's I have encountered most often are quantities (numbers with units), opaque/traced/symbolic numbers (value not accessible at all) and numbers that are "remote", i.e. that live on a separate compute-node/device/system (value accessible only with substantial latency).

Making such numbers subtypes of Real and Integer is tricky, dispatch wise, but also semantically not ideal - one might argue that a traced number with a real value is not actually a real number itself - I can operate on it, but I can't compare values and make a branching decision based on it (at least not during tracing). Likewise, a real number with a unit is clearly not a real number itself. On the other hand, user code often needs to restrict numerical type, both for semtantic and dispatch reasons - a function that will behave wrong for complex values should ideally not use Number at the argument type.

Also see https://github.com/EnzymeAD/Reactant.jl/issues/1570 and https://discourse.julialang.org/t/flexunits-jl-0-3-0-support-for-unitful-like-inference/134903/38 for context.

NestedNumbers is an attempt to create a bridge here - a super-lightweight package that user code can depend on and use for dispatch, while only minimal changes are required for unit packages or packages that use traced numbers like Reactant.

See the NestedNumbers demo, which requires these draft PRs:

• https://github.com/JuliaPhysics/Unitful.jl/pull/837
• https://github.com/Deduction42/FlexUnits.jl/pull/52
• https://github.com/JuliaPhysics/DynamicQuantities.jl/pull/198
• https://github.com/EnzymeAD/Reactant.jl/pull/2434

The final approach should ideally involve UnitsBase as well.

(Note that Reactant doesn't seem to work with unitful numbers in general yet, so the demo doesn't show a combination of both. )

The basic approach is this: NestedNumbers defines

• Abstract types like OpaqueNumber{T} RemoteNumber{T} QuantityNumber{T} that packages that define number types can subtype.
• Union typedefs like AReal, AInteger, AComplex, ABool and QReal, QInteger, QComplex, QBool for user/downstream code to dispatch on.

It's all in the single short source file.

Everyone involved/interested is more than welcome to comment and critique here, propose radical changes (feel free to open PRs), etc. NestedNumbers is not registered yet on purpose, everything is up for change including the package name. This is an attempt to see if this kind of approach can work and would be acceptable, and it's meant to involve the whole community.