<@U5F0TT0UX> Have you thought about using F-bounde...

# mathematics

[breandan]

@altavir Have you thought about using F-bounded quantification in your algebra? It’s a nice way to get concrete types out of an abstract structure while only defining behavior once on the most generic type. For example, try to define an extension function buffer.min() over an arbitrary buffer whose elements are subtypes of Comparable where min() returns a specific type (i.e. not a Comparable)? Can you implement it using a single function?

[altavir]

I do not know what F-quantification is (not a CS guy, remember?), but it works exactly like this now. In order to get some new function you just define an extension on the Algebra of the type.

[altavir]

For comaparable you can just write fun <T> Buffer<out Comparable<T>>.min() or something like that and it will work for all buffers (thanks to static dispatch). For algebra you can define things like folding. I am working on stream processing of those now.

[altavir]

You can see an example here: https://github.com/altavir/kmath/blob/dev/kmath-core/src/commonMain/kotlin/scientifik/kmath/operations/Algebra.kt#L37. I would move to extensions, but I need KEEP-176 for that.

[altavir]

Probably should move it anyway and convert to Space<T>.sum(iterable : Iterable<T>)

[breandan]

But you get an out Comparable<T> back, right? Suppose I have a new numeric type Float16 that implements Comparable and I want Float16 back

[altavir]

It requires a bit more complicated generic. A moment please

[altavir]

fun<T: Comparable<T>> Buffer<T>.max(): T? = asSequence().max()

[altavir]

It does not require Kmath. You need it when you actually want some operations

[breandan]

Right, <T: Comparable<T>> simplifies a lot of boilerplate for specializing to subtypes

[altavir]

It does not solve self-type problem. Element types are complicated because of recursive generics

[altavir]

I mean in Kmath.

[breandan]

I’m not sure about the performance issues of checking recursive types when you have a long chain of subtypes

[breandan]

But it helps to avoid some boilerplate

[altavir]

It is completely free. Those generics exist only in compile-time

[breandan]

Type checking is not free, but the cost is incurred at compile time

[altavir]

It is almost free. Compared to things like annotation processing it is almost zero. Of course if you are not talking about Scala

[breandan]

Even Java’s type system is Turing Complete, you can send the checker into an infinite loop https://bugs.eclipse.org/bugs/show_bug.cgi?id=543480

[breandan]

https://arxiv.org/pdf/1605.05274.pdf

[breandan]

Anyhow, this is the issue we run into with shape checking tensor algebra for long chains

[breandan]

I don’t think it would be expensive for type checking a small set of types, but if you have type-level integer literals, it can get expensive

[altavir]

No, it is not the same. Generics do not generate new classes. What you want is a full-fledged higher order type system, which in turn requires new classes for each singleton-type.