Open sethaxen opened 2 years ago
Would a trait system identifying numerical types as being commutative/associative/etc. be tractable to solve this?
To elaborate: I'm not familiar with just how many rules require commutativity/associativity, but the properties are inferrable at the type level. Checks like iscommutative
and isassociative
should essentially compile away, and asserting the presence of these properties should also compile away, if I understand correctly.
Depending on how many rules require these properties, it might start to built up a large amount of boilerplate. Is there a technical reason to avoid asserting the presence of properties?
Asserting the behavour is less useful than dispatching on the behavour.
Dispatching on the behavour is an unreasonable amount of boiler plate.
But yes were such properties implemented i would be down with adding some @assert
s on them for defensive programming purposes.
And asserting the properties is better than just assuming everything is commutative, because at least an error is thrown instead of derivatives being silently wrong.
To elaborate: I'm not familiar with just how many rules require commutativity/associativity,
I was recently reminded that some number types are not even associative under multiplication, e.g.
Quaternions.Octonion
. So fixes like #504, #540, which would support numbers that don't commute under multiplication, like quaternions, would still do the wrong thing for octonions. On the other hand, there are number types likeUnitful.Quantity
, which areNumber
s, for which we want our rules to work.So I see 2 ways forward: