Комплексные числа в scala

https://github.com/non/spire

Любая джавашная реализация. Сверху можешь нагородить оберток для удобства, чтобы не а.плюс(б), а а + б было.

К слову, какая, к примеру? Хотя уже не уверен, что лучше, своё написать, или тянуть что-то из java...

Фига се, даже кватернионы есть (вряд ли они мне нужны, но раз есть, значит, кто-то действительно потел над той библиотекой).

Благодарю, будет круто, если ещё и через sbt подрубится.

Фига се, даже кватернионы есть

Кватернионы как раз на практике гораздо чаще используются в алгоритмах.

гораздо чаще

это слишком сильное утверждение. чуть менее, чем всей пользы кватернионов для алгоритмов - накрытие SU(2) -> SO(3)

Есть ли годная библиотека?

А разве в Scala на JVM можно получить эффективные и удобные комплексные числа? Все же будет аллоцироваться в heap с лишней косвенностью как вот здесь.

Сейчас производительность играет не первую роль. Более того, скорее всего она не будет играть никакой роли в моей задаче.

https://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/co...

spire ближе к scala, а это всё-таки java. ну как вариант, если по какой-то причине нельзя использовать scala, но нужно для java, да...

Я вообще не вижу разницы. В конце-концов, получаешь один и тот же результат. Особенно на фоне твоего «самому писать, чтоб не тянуть из джавы». Тоже мне, выбираешь из сортов гогна)

Ну продвинутая система типов же. Я пока не разобрался, как мне сделать Complex, для действительной и мнимой части чтобы было что-то отличное от Float или Double, но сутя по тому, что тип параметризованный, это таки возможно...

А какой тебе там нужен тип?

Да пока уже никакой не нужен... я «заморозил» эту задачу. Думал, вместо чисел с плавающей точкой сделать что-то вроде точного представления, но для ограниченного подмножества вещественных чисел (не всех).

Потом подумал получше и понял, что мне эти числа (в том числе и комплексные) вообще не впились, и всё можно сделать проще. Но комплексные числа в будущем таки могут пригодиться... потому библиотеки в «закладки». И одну и вторую.

Подробнее про задачу распинаться не хочется... надолго затянется.

А вот, кстати, и минус того, что в скале нет четко фиксированных операций. Если делаешь параметризованный тип, то остается лишь надеяться на то, что тот, кто захочет зафигачить в него что-то, подгонит контракт этого чего-то под внутреннюю реализацию => поломанная инкапсуляция и вообще.

Я имею в виду вот что:

final case class Complex[@spec(Float, Double) T](real: T, imag: T)(implicit f: Fractional[T], t: Trig[T], r: IsReal[T])
    extends ScalaNumber with ScalaNumericConversions with Serializable {
    def +(b: T): Complex[T] = new Complex(real + b, imag)

То есть, если захочешь Complex[MyRational], то у нас одна надежда - что MyRational реализует, например, + так, как ожидалось. Поэтому BigInteger сюда уже не прецепишь, а придется цеплять BigInt-обертку. Ну и т. д.