Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any reason why Scale(..) is necessary for Mul and Div? #155

Open
blag01 opened this issue Oct 22, 2024 · 3 comments
Open

Any reason why Scale(..) is necessary for Mul and Div? #155

blag01 opened this issue Oct 22, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@blag01
Copy link

blag01 commented Oct 22, 2024

Is your feature request related to a problem? Please describe.
I am trying to abstract over several different Matrix types and it's awkward to wrap scalars in Scale(..).
I can understand the desire for a separate type for less obvious operations like Add, Sub, etc. but Mul/Div by scalars are mathematically a part of the vector space axioms.

Describe the solution you'd like
Ideally, I would just like to be able to write the formulas as in maths, 0.5 * M1 + M2, etc.

Describe alternatives you've considered
Maybe have From<E> for Scale<E> and back so generic code can at least rely on this?

Additional context

@blag01 blag01 added the enhancement New feature or request label Oct 22, 2024
@sarah-quinones
Copy link
Owner

because Mul<Mat<T>> for T is forbidden due to the orphan rule

@blag01
Copy link
Author

blag01 commented Oct 22, 2024

Ah yeah. But this only stops the Mat on RHS case. Are you opposed to adding support for the Mat * T case as a shortcut for scale?

@sarah-quinones
Copy link
Owner

yeah, instead i have an f64 operand on both sides. this is nice for symmetry and should cover simple cases

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants