Support for Data.Complex #490
Conversation
aspiwack
left a comment
aspiwack
left a comment
There was a problem hiding this comment.
Welcome and thanks for your contribution.
I have a bunch of (contradictory) comments below. Which really boils down to me not really using numerical calculation that much in my programming. So I don't really know what the intended use of complex numbers with linear type is.
So my suggestion is to discuss a bit what your motivation is, so that we can make an informed decision about what's best to support you.
| instance | ||
| (Movable a, Prelude.RealFloat a) => Additive (Complex a) |
There was a problem hiding this comment.
I would like to question the value of this class instance (and those below). Since you only derive Additive when a is Movable (hence Complex is Movable), you're basically saying that this isn't a linear type class. If you can move the whole Complex a it's probably better to do so rather than doing your arithmetic with linear functions.
I would rather use a more general instance such as
instance (Additive a) => Additive (Complex a)This instance comes from the fact that Complex is an applicative functor. So it should work fine (maybe we were thoughtful enough to add a way to derive all these instance from the Applicative instance). It should be more useful, shouldn't it? Though I don't know your use case so I'm not sure.
There was a problem hiding this comment.
Thanks for replying. Actually, this PR has become unnecessary for me in the last few days.
My use case was to represent a complex vector for quantum computation, i.e. datatype Complex is only used like type CC = Complex Double.
Reading your comments, I thought the type Complex a alone where a is arbitrary does not need to be treated like a complex number.
In this respect, it may be more appropriate to view Complex as quadratic extension field rather than a complex number. This is because complex numbers are quadratic extensions of real numbers, whereas Complex is defined like for any field.
However I don't know this view suggest a reasonable solution.
Either way, this is no longer necessary at this point.
| instance | ||
| (Movable a, Prelude.RealFloat a) => AdditiveGroup (Complex a) |
There was a problem hiding this comment.
The obvious counterargument to my point above is that you can't define complex multiplication without a being at least dupable. So maybe the whole deal about addition isn't so important.
| deriving via | ||
| MovableNum (Complex a) | ||
| instance | ||
| (Movable a, Prelude.RealFloat a) => Multiplicative (Complex a) |
There was a problem hiding this comment.
Sorry, we can't just derive Multiplicative.
This is probably calculated as (x1+iy1)*(x2+iy2)=(x1*x2)+i(y1*y2)
There was a problem hiding this comment.
Indeed, but the MovableNum implementation takes care of that just fine. It's just unclear how useful it is to add these instances.
|
In absence of strong motivation, I'm going to close this PR. Don't hesitate to reopen if it becomes useful to you again. |
2 participants
I'm aiming to make Data.Complex in the base package to be an instance of each linear version of type class.
I would like your opinion on which type classes are preferable for
Complex aand which functions inData.Complexshould be reimplemented in linear-base.