You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found that writing generic arithmetic with alga involves some extra clones. The reason is, that there is no way to apply operators to references. Therefore you have to pass ownership to the operator, which requires a clone, as soon as you need a value more than once.
For example, given two (large) vectors, a: T and b: U, where T: ClosedAdd<U>, I would like to be able to do all of these operations:
// possible today
a + b
a += b
// not possible without adding extra trait bounds
a + &b
&a + b
&a + &b
a += &b
That would probably require the ClosedAdd trait to be extended to this
Of course, this adds extra burden on trait implementors. It is also a backwards-incompatible change, as it breaks implementations that do not fulfill the extra bounds yet. (afaik, at least nalgebra should be fine.)
I would argue, that any arithmetic type should be able to handle these cases. Happy to hear a counter-example, but I can't really think of any yet.
The text was updated successfully, but these errors were encountered:
Unfortunately, Rust has an odd way of dealing with "where" constraints on traits. Adding this constraint to ClosedAdd, for example, would require that every time the user makes a function generic on T: ClosedAdd, they'd have to copy and paste the same "where for<'a>..." constraints on their functions.
Take a look at this playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b1cb034e035155b015dc1bc89b11de9a
I've encountered this issue several times myself and am always annoyed by it. I can't seem to find the link right now,but there's an issue on the Rust repo that says that this should be fixed
I found that writing generic arithmetic with alga involves some extra clones. The reason is, that there is no way to apply operators to references. Therefore you have to pass ownership to the operator, which requires a clone, as soon as you need a value more than once.
For example, given two (large) vectors,
a: T
andb: U
, whereT: ClosedAdd<U>
, I would like to be able to do all of these operations:That would probably require the
ClosedAdd
trait to be extended to thisOf course, this adds extra burden on trait implementors. It is also a backwards-incompatible change, as it breaks implementations that do not fulfill the extra bounds yet. (afaik, at least nalgebra should be fine.)
I would argue, that any arithmetic type should be able to handle these cases. Happy to hear a counter-example, but I can't really think of any yet.
The text was updated successfully, but these errors were encountered: