The public interfaces MathEx and LinAlgEx use a Java-style Ex suffix, and their type-specific methods use single-letter suffixes that are not Kotlin-idiomatic:
MathEx: expF, expCF, expCD (and the same for log, sin, cos)LinAlgEx: invF, invC, solveF, solveC, dotMMF, dotMMComplex, …
Convenience overloads on Math/LinAlg and MultiArray extensions (a.exp(), mk.math.exp(a)) already dispatch by element type, so end users rarely need to call expF/invC directly — but the interfaces remain public API that engine implementations (KEEngine, NativeEngine) depend on.
Suggested approach
Any of the following, or a combination:
- Rename
MathEx/LinAlgEx to non-Ex names (e.g., ExtendedMath, ExtendedLinAlg).
- Replace
F/CF/CD/C suffix methods with type-based overloads (the MultiArray<Float, D> parameter type is sufficient to disambiguate on the JVM).
- Or mark these as
@InternalMultikApi / SPI-only and keep the user surface on Math/LinAlg.
Whatever we pick will be a breaking change, so it needs the standard deprecation path (WARNING → ERROR → HIDDEN).
The public interfaces
MathExandLinAlgExuse a Java-styleExsuffix, and their type-specific methods use single-letter suffixes that are not Kotlin-idiomatic:MathEx:expF,expCF,expCD(and the same forlog,sin,cos)LinAlgEx:invF,invC,solveF,solveC,dotMMF,dotMMComplex, …Convenience overloads on
Math/LinAlgandMultiArrayextensions (a.exp(),mk.math.exp(a)) already dispatch by element type, so end users rarely need to callexpF/invCdirectly — but the interfaces remain public API that engine implementations (KEEngine,NativeEngine) depend on.Suggested approach
Any of the following, or a combination:
MathEx/LinAlgExto non-Exnames (e.g.,ExtendedMath,ExtendedLinAlg).F/CF/CD/Csuffix methods with type-based overloads (theMultiArray<Float, D>parameter type is sufficient to disambiguate on the JVM).@InternalMultikApi/ SPI-only and keep the user surface onMath/LinAlg.Whatever we pick will be a breaking change, so it needs the standard deprecation path (WARNING → ERROR → HIDDEN).