Interest in full complex matrix support?

[light-matters]

I'm curious what the future plans are regarding full complex matrix support? Looking at your doc and tests, complex matrices seem mostly to be considered for the results of certain operations but are there plans for full feature parity with real matrices?

I'm looking at interfacing with a java matrix library from Clojure and currently ejml's complex matrix support is tipping me that way.

Many thanks for what looks like a great project, regardless.

[apete]

Don't understand your question. ComplexNumber matrices are supported, same as RationalNumber, Quadruple and others. That includes a (full) set of matrix decompositions.

[light-matters]

Ah, I may have made a boo boo. I did try to find complex matrix multiplication in the docs and tests but I was prejudiced by my initial questioning of ChatGPT:

does ojalgo work for complex matrices?

Excellent question — and the short answer is:
👉 Not really, at least not natively.
Let’s unpack that precisely, because there’s a bit of nuance in how ojAlgo (a very high-quality JVM linear algebra library) treats complex numbers.

ojAlgo does include a ComplexNumber class, and even a ComplexArray structure internally, but:

These are scalar-level utilities, not first-class matrix types.

There’s no “ComplexMatrix” equivalent (no ComplexMatrix class, no multiply() for matrices of ComplexNumbers).

Operations like eigen decomposition, SVD, etc., are implemented for real data and return complex eigenvalues where appropriate — but as arrays of ComplexNumber, not as a complex-valued matrix object.
...

I should have been more careful, apologies! I look forward to exploring this library more.

[light-matters]

So I've been playing around with the library, but I can't seem to find any factory method of constructor for creating complex matrices from rows or columns or by wrapping, which the deprecation warning seems to be suggesting.

Is the only way of making complex matrices, by making a store/receiver (e.g. GenericStore.C128.make(dim, dim)) and then populating the elements one-by-one?

[apete]

Do you mean like these?

public static <N extends Scalar<N>> GenericStore<N> wrap(final GenericStore.Factory<N> factory, final N... data) {
    return new GenericStore<>(factory, data.length, 1, data);
}

public static <N extends Scalar<N>> GenericStore<N> wrap(final GenericStore.Factory<N> factory, final N[] data, final int structure) {
    return new GenericStore<>(factory, structure, data.length / structure, data);
}

You do not have to set elements one-by-one on your store/receiver instances. There're mutable in many ways. Perhaps use some of the fillXXX methods.

You should try to avoid creating ComplexNumber[]. Use the array/matrix classes instead.

[light-matters]

I'm not sure I follow what you mean about not using the ComplexNumber class as you seem to have convenient complex matrix classes laid out for this? Is this a performance concern?

Could you give an example of your canonical way to move from a 2D array of pairs, i.e.
[
[[11] [1 1]]
[[11] [1 1]]
],
to a matrixclass?

I'm sorry for pestering you, but I think this would be useful to others - to know how to get started with your complex matrix operations, given a plane of complex numbers.

[apete]

Of course you should use ComplexNumber, but don't create (intermediate) ComplexNumber[] or ComplexNumber[][] arrays. Use the ojAlgo types directly.

I assume you need to write a little utility yourself.

[light-matters]

The fastest way I'm able to do this at the moment (haven't tried the fill methods yet) is to go from a ComplexNumber array to a GenericStore using one of the wrap methods you suggested, but there seems to be accessibility problems. To get it to work I have to manually make it accessible, which seems weird.

Should this work in java? My Clojure equivalents don't seem to.

import org.ojalgo.matrix.store.GenericStore;
import org.ojalgo.matrix.store.GenericStore.Factory; 

GenericStore.Factory<ComplexNumber> factory = GenericStore.C128; 

ComplexNumber[] data = ...;
GenericStore<ComplexNumber> store = GenericStore.wrap(factory, data, 2);

Here's the Clojure that works (for posterity), if that means anything to you.

(defn ^GenericStore wrap-array-reflection
  "Use reflection to call GenericStore.wrap, bypassing access restrictions."
  [rows cols data]
  (let [arr (into-array ComplexNumber data)
        factory (GenericStore/C128)
        wrap-method (->> (.getMethods GenericStore)
                         (filter #(= "wrap" (.getName ^java.lang.reflect.Method %)))
                         (filter #(= 3 (alength (.getParameterTypes ^java.lang.reflect.Method %))))
                         first)]
    (when wrap-method
      (.setAccessible ^java.lang.reflect.Method wrap-method true)
      (.invoke ^java.lang.reflect.Method wrap-method nil (into-array Object [factory arr (int cols)])))))

[apete]

That's a problem you found. The wrap methods take a GenericStore.Factory<N>, but that class is package private, and the factory constants are typed as the more general PhysicalStore.Factory<ComplexNumber, GenericStore<ComplexNumber>>. So code outside the org.ojalgo.matrix.store package will have the problem you encountered.

I'll have to change something to fix this.

[apete]

I fixed that and released v56.1.1

https://central.sonatype.com/artifact/org.ojalgo/ojalgo/56.1.1

[light-matters]

Great, thanks. Fast work :). I'll try it out in the coming week.