Fit complex y-data

[mzaffalon]

Automatically reinterpret complex data and model to fit complex data. Domain and parameters are strictly real.

[mzaffalon]

I haven't seen the fix proposed in #163 by @kagalenko-m-b. This PR deals only with complex y-data; PR 163 with complex domain too; I have not seen any literature for this case.

[kagalenko-m-b]

You're dispatching on the type of ydata[], but what if it is Real, while the model returns a complex result?

[mzaffalon]

Then it will fall back to the original curve_fit and fail later on. My PR is only for complex ydata.
But you are right, it will fail when the model returns real numbers.

[kagalenko-m-b]

Unfortunately, Julia is not Haskell and can not dispatch on the function argument's signature, which is what you really need here.

[mzaffalon]

So there is nothing left to do except for asking the user to separate manually the real from the imaginary part as it was suggested in your #163?

[kagalenko-m-b]

There're two questions here, really - complex optimization domain and complex-valued model. Your PR assumes that both model input and output are either real or complex (and have the same numerical precision), but that's too restrictive. For example, what if I need to fit a complex exponent of an unknown, but real frequency to a set of complex measurements?

[mzaffalon]

My PR assumes that model and ydata have the same complex type while the xdata and free parameters are real: this covers the case you describe. Sure, it can be relaxed to have different precision for the types.

[kagalenko-m-b]

Sorry, read the source and your initial comment rather carelessly. Indeed, this PR is about complex-valued model and ydata. My remark in #163

• disallow complex variables, recommending instead to treat them as pairs of real and imaginary parts

is about complex model parameters. There is no other way, other then requesting a user to indicate somehow that he wants optimization over the complex domain, in my opinion. Once we have this indication, splitting into real and imaginary part may be done programmatically, for instance, by the reinterpret() trick you did in your PR. The indication may be implicit, by supplying a complex starting value, or explicit, by adding optional named input, something like complex_domain=false.

As for complex model and/or ydata, that is handled completely by #163. The dispatch on complex/real is done by Julia's std library functions like abs2.