Supports SIMD / Vector API

[stevenylai]

In our use cases, we generally need to apply the same formula multiple times to a list of values and one way to efficiently perform such calculation is through SIMD. In Java, there is Vector API.

There are several challenges though:

1. Vector API started to appear in a more recent Java version (Java 19)
2. API is still in incubation for Java 21 LTS

One way to implement this on top of what we currently have is perhaps to override all operators / functions so that if the operands are lists, we convert them using Vector APIs, perform the computation and return the result as a list.

Any other ideas how this could possible be done? Perhaps the library can automatically detect the availability of the Vector API and switch between different implementation? Or perhaps it's not a good idea to do things like that in Java at all?

[uklimaschewski]

Interesting idea, supporting the new Vector API.
I think this could be done similar to the EvalEx-big-math extension.
It would be a separate project, using any Java version, that is needed to work with the Vector API.

The extension would provide new functions and operators, that override the standard functions and operators and support vectors.
It would also provide new Converter implementations and a new converter configuration, that would allow to pass a Vector as parameter to EvalEx.

The only thing needed to change in EvalEx hopefully would be a new data type, e.g. VECTOR in EvaluationValue, along with a check functions like isVectorValue(). The getter and setter methods could not be implemented now in EvaluationValue , because the Vector class is not known in Java 11.
But it could be stored in the EvaluationValues object nonetheless, with that new data type. Casting would be done outside of EvaluationValue and EvalEx, in the new operator and function implementations.

The new methods and operators should also check the data type and delegate to the original implementations for the 'scalar' types, e.g.:

@InfixOperator(precedence = OPERATOR_PRECEDENCE_ADDITIVE)
public class VectorInfixPlusOperator extends AbstractOperator {

  private static InfixPlusOperator delegate = new InfixPlusOperator();

  @Override
  public EvaluationValue evaluate(
      Expression expression, Token operatorToken, EvaluationValue... operands) {
    EvaluationValue leftOperand = operands[0];
    EvaluationValue rightOperand = operands[1];

    if (leftOperand.isVectorValue() && rightOperand.isVectorValue()) {
        // cast the values to the Vector class, using leftOperand.getValue() and rightOperand.getValue()
        // do some Vector calculations and return a new Vector
    } else {
        return delegate.evaluate(expression, operatorToken, operands);
    }
  }
}

this would allow to move the extension to the main implementation, once EvalEx is using the required Java version.
And also avoid code duplication and duplicated code maintenance.

There is also be a clear separation of the already supported arrays and the new vector support.
I was thinking to add support for operations on arrays, like adding two arrays, or multiply an array with a number.
Both resulting in a new array. But I think this is a different pair of shoes.
There is now such thing like a BigDecimal vector, and array operations in the above example are operations of BigDecimals under the hood.

[stevenylai]

Sounds good. I will look into this.