Integration with Jafama

[CommanderTvis]

To external contributors:

Notify us if you are going to try to implement this feature to receive our contacts (and maybe guest access to our Space) and extensive explanations of what does this problem means.

[altavir]

Is it better than commons-math FastMath?

[CommanderTvis]

I don't know, but I think there are no blockers for this integration. We have to compare, of course.

[altavir]

Because we already have integration with CM. And FastMath is not that fast anymore when compared to JRE own methods.

[CommanderTvis]

OK, then I should benchmark CM vs Jafama vs j.u.Math first.

[CommanderTvis]

benchmarks: kscience.kmath.benchmarks.AFastMathBenchmark.cm

Warm-up 1: 6.453 ops/s
Warm-up 2: 6.703 ops/s
Warm-up 3: 6.824 ops/s
Warm-up 4: 6.613 ops/s
Warm-up 5: 6.617 ops/s
Iteration 1: 6.604 ops/s
Iteration 2: 6.594 ops/s
Iteration 3: 6.686 ops/s
Iteration 4: 6.574 ops/s
Iteration 5: 6.549 ops/s

6.601 ±(99.9%) 0.200 ops/s [Average]
  (min, avg, max) = (6.549, 6.601, 6.686), stdev = 0.052
  CI (99.9%): [6.401, 6.801] (assumes normal distribution)

benchmarks: kscience.kmath.benchmarks.AFastMathBenchmark.jafama

Warm-up 1: 16.947 ops/s
Warm-up 2: 17.707 ops/s
Warm-up 3: 17.749 ops/s
Warm-up 4: 17.821 ops/s
Warm-up 5: 17.620 ops/s
Iteration 1: 17.733 ops/s
Iteration 2: 17.610 ops/s
Iteration 3: 17.714 ops/s
Iteration 4: 17.651 ops/s
Iteration 5: 17.658 ops/s

17.673 ±(99.9%) 0.192 ops/s [Average]
  (min, avg, max) = (17.610, 17.673, 17.733), stdev = 0.050
  CI (99.9%): [17.482, 17.865] (assumes normal distribution)

benchmarks: kscience.kmath.benchmarks.AFastMathBenchmark.jafamaStrict

Warm-up 1: 17.387 ops/s
Warm-up 2: 18.083 ops/s
Warm-up 3: 17.579 ops/s
Warm-up 4: 17.387 ops/s
Warm-up 5: 17.433 ops/s
Iteration 1: 17.929 ops/s
Iteration 2: 17.888 ops/s
Iteration 3: 17.574 ops/s
Iteration 4: 17.259 ops/s
Iteration 5: 17.454 ops/s

17.621 ±(99.9%) 1.102 ops/s [Average]
  (min, avg, max) = (17.259, 17.621, 17.929), stdev = 0.286
  CI (99.9%): [16.519, 18.722] (assumes normal distribution)

benchmarks: kscience.kmath.benchmarks.AFastMathBenchmark.jdk

Warm-up 1: 4.427 ops/s
Warm-up 2: 4.430 ops/s
Warm-up 3: 4.374 ops/s
Warm-up 4: 4.412 ops/s
Warm-up 5: 4.420 ops/s
Iteration 1: 4.364 ops/s
Iteration 2: 4.444 ops/s
Iteration 3: 4.430 ops/s
Iteration 4: 4.393 ops/s
Iteration 5: 4.474 ops/s

4.421 ±(99.9%) 0.166 ops/s [Average]
  (min, avg, max) = (4.364, 4.421, 4.474), stdev = 0.043
  CI (99.9%): [4.255, 4.587] (assumes normal distribution)

benchmarks: kscience.kmath.benchmarks.AFastMathBenchmark.jdkStrict

Warm-up 1: 4.261 ops/s
Warm-up 2: 4.253 ops/s
Warm-up 3: 4.227 ops/s
Warm-up 4: 4.300 ops/s
Warm-up 5: 4.197 ops/s
Iteration 1: 4.240 ops/s
Iteration 2: 4.346 ops/s
Iteration 3: 4.462 ops/s
Iteration 4: 4.398 ops/s
Iteration 5: 4.348 ops/s

4.359 ±(99.9%) 0.314 ops/s [Average]
  (min, avg, max) = (4.240, 4.359, 4.462), stdev = 0.082
  CI (99.9%): [4.045, 4.673] (assumes normal distribution)

[CommanderTvis]

Jafama is significantly faster both than JDK math and CM FastMath (and has worse accuracy, probably), so it may be useful

[CommanderTvis]

I think it's a simple, harmless change to add a module with something like JafamaRealField

[altavir]

OK. Marking it as awaiting its hero. It is simple enough, so I would like to leave it for new contributors to try.

[therealansh]

Hey @CommanderTvis @altavir , its an interesting project to work on can i try this one? and also i am new here so i might have to ask alot of questions?

[altavir]

@therealansh of course. Feel free to try. The discussion is mostly in the mathematics channel in kotlin slack.

[therealansh]

Thanks @altavir i would be needing the "extensive explaination" for first few issues and to get along with the codebase so where are we trying to integrate Jafama? and why do we need it?

[CommanderTvis]

@therealansh
Hello!

1. Look up these files:

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/Algebra.kt

This one is responsible for the main concept of KMath—separation of algebraic elements and operations.

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/NumericAlgebra.kt

This one provides some extensions related to number-based structures.

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/numbers.kt

And this one implements the Algebra interfaces for builtin Kotlin numbers (Int, Double, etc.)

2. The task is to implement ExtendedField<Double> with two singleton objects, but mathematical operations must go not from kotlin.math but from FastMath and StrictFastMath. The class you should pay attention to as reference one is DoubleField.
3. Also it will be nice to add a couple of KDoc comments for the classes you are to create.

[CommanderTvis]

and why do we need it

As stated by benchmarks above Jafama is a bit faster both than Java Math and Apache Commons FastMath.

[therealansh]

Thanks @CommanderTvis will try to get back with a PR soon and will ask for guidance if needed

[therealansh]

Hey Commander,

So i have a couple of questions?

1. Look up these files:

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/Algebra.kt

This one is responsible for the main concept of KMath—separation of algebraic elements and operations.

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/NumericAlgebra.kt
This one provides some extensions related to number-based structures.

Does these files need to be refactored into using FastMath and StrictFastMath or should i create new interfaces?

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/numbers.kt

And this one implements the Algebra interfaces for builtin Kotlin numbers (Int, Double, etc.)

1. The task is to implement ExtendedField<Double> with two singleton objects, but mathematical operations must go not from kotlin.math but from FastMath and StrictFastMath. The class you should pay attention to as reference one is DoubleField.

And which two objects in particular are you talking about here? And also should i implement ExtendedField<Double> in a new file?

[CommanderTvis]

Hey Commander,

So i have a couple of questions?

1. Look up these files:

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/Algebra.kt

This one is responsible for the main concept of KMath—separation of algebraic elements and operations.

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/NumericAlgebra.kt
This one provides some extensions related to number-based structures.

Does these files need to be refactored into using FastMath and StrictFastMath or should i create new interfaces?

https://github.com/mipt-npm/kmath/blob/master/kmath-core/src/commonMain/kotlin/space/kscience/kmath/operations/numbers.kt

And this one implements the Algebra interfaces for builtin Kotlin numbers (Int, Double, etc.)

1. The task is to implement ExtendedField<Double> with two singleton objects, but mathematical operations must go not from kotlin.math but from FastMath and StrictFastMath. The class you should pay attention to as reference one is DoubleField.

And which two objects in particular are you talking about here? And also should i implement ExtendedField<Double> in a new file?

Create a separate module called kmath-jafama and place the implementations there.

[altavir]

Basically, you need to re-implement DoubleField using library functions. And as @CommanderTvis said, place it in a separate module to avoid unnecessary dependencies in the core.

[therealansh]

Hey @altavir @CommanderTvis do we need to implement with StrictFastMath as well in a different file?

[CommanderTvis]

Hey @altavir @CommanderTvis do we need to implement with StrictFastMath as well in a different file?

It doesn't matter

[altavir]

@CommanderTvis the benchmarks in the merged module seem to show that there is no difference between Jafama and kotlin core math. I am closing this issue now, but feel free to check benchmarks.