A nice feature would be a nice way to build define...
# mathematics
s
A nice feature would be a nice way to build defined matrices. Like in python ([[1,2,3],[4,5,6],[7,8,9]]) or better like matlab by omitting the comma and using line returns. There is nice syntax for HTML and SVG... I don't understand why we wouldn't have something nice and clean also...
z
Copy code
fun vec(vararg elems: Int) = elems
Copy code
fun mat(vararg elems: IntArray) = elems
Or maybe
Copy code
typealias Vec = IntArray
operator fun IntArray.Companion.get(vararg elems: Int) = elems

val a = Vec[2, 3, 4]
s
@Zhelenskiy Seems good enough... I think I still have to pratice my kotlin.
🙂 1
a
There is a matrix builder in KMath, but I can not say I like it very much. The idea itself.
z
There is an issue in YouTrack about collection literals. I wrote my view there.
s
@altavir What does it look like?
s
Not that bad. But I like @Zhelenskiy implementation. Splitting the vector and the array seems more instinctive than defining the pitch (number of element by row, yeah, you don't need the number of row and it can be deducted)
The problem with @Zhelenskiy method is for tensor. Were I would use your method instead.
a
For linear structures we work with fake constructors as well like Point(1,2,3). The problems begin when you have non-linear structures.
s
I read the issue @Zhelenskiy. I think I understand the problem. I see no issue using naming the collection.
Collection Type*
The little trick to get the square brackets is neat!
Can something like html be done. Like html{ object object } Mat{ Mat Mat }
z
@Spationaute I can do the same for Matrices too, not just to Vectors.
The problem with {} is that Vec { 2, 3, 4 } cannot work as
2
is not a function call
or a property
s
Ho! Thanks @Zhelenskiy. I learn about kotlin alot with you.
That means that by the nature of kotlin we can't have something as clean as the other languages for this application. Can having a specific symbol for numerical collection solve this issue (like the " for strings)? I mean after strings the most used collection is tensors (vectors, matrices, etc...).
I start thinking simply parsing a string would do the trick. Such genetator wouldn't be used much any ways Mat("1 2 3;4 5 6;7 8 9")
Since its constant, the string would only parsed at compile time after all.
Ah, no it won't... We cannot use functions... I think your solution is the best for now...
a
It is not question of what we can do. We can do the same things as in python. It is a question of what we should do to keep things concise and safe. Using the square brackets is a bad idea since it creates unexpected syntax. It is possible to create a row builder using lambda function, but I am not sure it makes things better. As Roman keeps saying, you should start with describing what you want to do, not how you want to do them. So first you can create an issue listing the structures you want to create and their dimensions.
z
@altavir is absolutely right. However, we can just make a function
matrixOf(vararg elems: IntArray)
instead of operator syntax. Then, it is both kotlin style and safe.
a
This is what MatrixBuilder was done for. It is designed so you can add extensions for it. Meaning you can write
matrix(2,2)(row1,row2)
. The explicit size in my opinion is important because it allows to do a visual size check and avoid a number of problems.
z
Maybe, we can make a plugin that would check number of parameters in compile-time. It may also give some recommendations to formatter (not sure if it is possible and necessary)
a
It is possible, but it seems like an overkill right now. You also need to keep in minde, that nobody will really use that outside of test cases. In reality all those matrices are built dynamically from data. Also it is not possible to work with matrices of size about 5 this way. Too many numbers otherwise. Anyway, It would be greate if anyone would open a discussion issue with use-cases to keep that in mind in a future design (and extend communication with potential contributors).
z
As for now, I find it to be an overkill too (as I noticed), so that was more a random idea than a proper suggestion
a
I am thinking about a plugin for mathematics in a distant future. Maybe we should add a
for compiler plugin
tag in issues. Right now some things could be experimented with in Jupyter pre-processor.
z
Maybe, we can make an issue with list of things that may be done with plugin somewhen.
a
Indeed. I've been talking with kotlin compiler developers just this week and we were discussing what we would like to have from the point of view of language and compiler. But we need to think a lot about what we want and how to do that. So please leave issues with ideas.
z
Ok, however, there are lots of more urgent things to do imho.
s
Yeah, I understand @altavir. I think the choice made for kotlin is good and that the square bracket might create problems. I just want to find an easy for the eyes which is not necessarily a good thing. I think @Zhelenskiy option is the best. For Tensor or larger dimension, making the matrices by writing them shouldn't be possible anyway (to much chance of an error). So stinking with Vector (1D) and Matrix (2D) or Row (1D) Matrix (2D) Seems the best course of action.
Mat<Int>( Vec(1, 2, 3), Vec(4, 5, 6), Vec(7, 8, 9) ) OR Mat<Double>( Row(1.0, 2.0, 3.0), Row(4.0, 5.0, 6.0), Row(7.0, 8.0, 9.0) ) is not that bad!
And @Zhelenskiy is right, there is more useful thing to focus on! 😛
a
I will add a row-based builder later If I do not forget (you can open an issue so I don't).
s
It can even become super powerful. Boundaries condition for a finite diffence could look like this Mat<Double>( LinSpace(0,9), Zeros(10), Zeros(10), Zeros(10) )
a
z
@Spationaute As it is written in the issue I mentioned the problem with [] is that it would have an overhead when converting to other collection, but the idea of literals is not bad.
👍 1
s
message has been deleted
❤️
My implementation up until now
Probably have full of defects, but it's simple 😛
(It's also incomplet, I still have to put operation between the tensor, I just hesitate for the nomenclature.)
(And I want to implement broadcasting, which make me a bit scared.)
a
I really do not like broadcasting as a concept, but @Ролан’s team implemented broadcating for
TensorAlgebra
.: https://github.com/mipt-npm/kmath/tree/master/kmath-tensors I believe that something like this also is available in Multik. As always, contributions are welcome. I know I promised to add row-based matrix builders, but I a little bit stuck with other work. I will be back to it ASAP.
z
I just looked there. Am I right when say that broadcasting is extending dimensions. Something like from shape changing (a, b, c) to (d, e, a, b, c)?
Also, some of dimensions of the extendable one can be 1
р
@Spationaute that's a really bad idea to back a tensor by a mutable list
1
s
Yeah... I will change that... Are statics arrays good enough?
р
performance was not our target, but our implementation could be a good start to look for further optimisations: