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

Left multiplication for vector spaces #24

Open
milibopp opened this issue Aug 23, 2017 · 4 comments
Open

Left multiplication for vector spaces #24

milibopp opened this issue Aug 23, 2017 · 4 comments

Comments

@milibopp
Copy link

This code example fails:

fn foo<V: VectorSpace<Field=f64>>(a: V, b: V, c: f64) -> V {
    a * c + c * b
}

with this error:

error[E0277]: the trait bound `f64: std::ops::Mul<V>` is not satisfied
   |
   |     a * c + c * b
   |               ^ no implementation for `f64 * V`
   |
   = help: the trait `std::ops::Mul<V>` is not implemented for `f64`
   = help: consider adding a `where f64: std::ops::Mul<V>` bound

(omitted source location in my project for clarity)

Is there a reason, why this can't be made work? As multiplication on the field commutes anyway, the operator should generally be available in this way.

@WaDelma
Copy link
Contributor

WaDelma commented Aug 23, 2017

I was going to say how orphan rules makes it impossible, but then I realised you can actually require the Mul implementation.

Not sure if it generalises to the actual VectorSpace trait, but it seems to be doable.

@milibopp
Copy link
Author

milibopp commented Aug 23, 2017

Looks like that is not enough for the example above. The compiler does not interpret the where clause as an implication, forcing you to explicitly add it again.

To reduce it a bit further, this does not work. I have a hunch that fixing it would be a huge problem for the type system or something.

@milibopp
Copy link
Author

milibopp commented Aug 23, 2017

@milibopp
Copy link
Author

I would argue that before this implication works, it is hardly useful to users to change this. Type authors would have to provide the implementation on the ring or field right away and everybody would have to write down the trait bound no matter whether it is used or not.

So perhaps this should be deferred to a time, when implied bounds stabilize.

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

No branches or pull requests

2 participants