https://kotlinlang.org logo
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
benchmarks
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
confetti
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
lincheck
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by
Title
a

altavir

12/27/2018, 4:05 PM
- We want at least one package to follow Python conventions so it will be easy for Python guys to switch to Kotlin. It probably should still follow common API somewhere on lower level.
👍 3
k

kyonifer

12/28/2018, 7:08 PM
From this bullet and the various conversations in other channels, it seems that most people are interested in having a numpy/matlab-like API available which wraps a lower level kotlin numerical library (yet to be written). Upon some consideration, I'm thinking that koma could fill the role of this bullet point. Koma's stated goal is to expose a numpy/matlab API which delegates the work to lower level libs like BLAS or the new one that we write. If koma fails to meet this goal cleanly (and I'm sure it does, since it is still early days) we're interested in PRs/issues that would help it to succeed. Would everyone agree with that approach? @bjonnh @thomasnield @altavir @Percha
If the answer to the above is yes, then in the short term Koma could simply add a backend for the lower level kotlin numerical library that is being built. As our homegrown lib becomes feature complete, koma could start to deprecate support for other backends as they become less relevant, or even eventually stop supporting other backends if our pure kotlin lib has competitive performance/capability/platform support versus using platform libs.
a

altavir

12/28/2018, 7:17 PM
I think that this is the place Koma is suited best. We need something python-like and koma already does that. Though I do not really like how it looks like on the inside. So I think that we keep designing a set of APIs to suite everyone needs (with your input of course) and when it is ready, make koma implement it so we could exchange basic mathematics objects between different libraries (not thinking about performance).
b

bjonnh

12/28/2018, 7:19 PM
What do you mean by "not thinking about performance"? ç
a

altavir

12/28/2018, 7:19 PM
I do not know how it will work in the end, but in my opinion modules focused on specific features + common API is better than universal monolithic library.
I mean that you need to think about performance when you are doing some things inside the library, but when you are moving an object form one implementation to another one, performance is not important since it is quite rare.
b

bjonnh

12/28/2018, 7:23 PM
I agree with the Python-like conventions (numpy-like more exactly). It would be nice to get these to work with more statistical/modelling packages (similar to scipy) and dataframes (similar to pandas)
k

kyonifer

12/28/2018, 7:29 PM
@bjonnh so far we have krangl for dataframes and kotlin-statistics. Both authors are on slack @thomasnield @holgerbrandl
b

bjonnh

12/28/2018, 7:29 PM
I am aware of that, but that would be nice if all those things were handling the same low-level representations (the same as pandas and scipy that use numpy in the back)
k

kyonifer

12/28/2018, 7:30 PM
yep, i meant i could ping them here to weigh in
a

altavir

12/28/2018, 7:30 PM
Yep. Now we need common app to make them talk to each other and focus on their own features instead of duplicating them.
👍 1
z

Zelenyi

12/28/2018, 7:34 PM
Koma is similar to numpy, but no enough, I think,, we need in more usefull and more python-like scientifik DSL.
b

bjonnh

12/28/2018, 7:37 PM
We may also want to find out what numpy's design defects are (that they can't get rid of because of backward compatibility) and avoid having the same problems
p

Percha

12/28/2018, 7:37 PM
@kyonifer I agree with koma's goal, it can provide a familiar API for newcomers from python and matlab. It's important to start discussing about how we want the lower level API, I'll start working on a KEEP like proposal based on numeriko to have on @altavir KEEP-math repository.
a

altavir

12/28/2018, 7:39 PM
Here comes pythonic guy. @Zelenyi please start with writing a proposal for Keep-math about what you really need and why do you think that Python approach is good. We can discuss it later in our slack.
k

kyonifer

12/28/2018, 7:42 PM
@Mikhail the numpy-like API can still be extended and fleshed out for those that prefer it (I'll admit I'm one of those!). Supporting offloading the work to a low level kotlin lib doesn't get in the way of koma growing. I'd be interested in you opening issues for koma if you have ideas on how it could be better
wrong user tag apparently: @Zelenyi
a

altavir

12/28/2018, 7:44 PM
@bjonnh numpy limitation come mostly not from backward compatibility, but from limitations if underlying Fortran libs and performance issues. For example you can't use functions, they would be super slow.
b

bjonnh

12/28/2018, 7:58 PM
is there a way to avoid that for us?
k

kyonifer

12/28/2018, 8:00 PM
openjdk's jit is much better than cpython in terms of performance. Where the python guys have to drop to cython, numba, numexpr etc. to get more performance, we could theoretically drop to kotlin/native to yield even better performance (once optimization passes have been done on k/native, its not ready yet). So I think kotlin is already better poised to not have the same issues, as long as we design carefully for performance along the way.
👌 3
my biggest beef with numpy is really python. Among other things, its lack of static typing. it makes it really hard to use for larger projects in technical computing with everything being dynamic and failing at runtime. I would like anything we come up with to be statically typed and avoid runtime casting as much as possible, as this is one strong advantage of using kotlin.
👍 2
💯 3
a

altavir

12/28/2018, 8:04 PM
I do not think that native performance will be ever better, but functions in kotlin are very cheap compared to pyhon. Also we do not need to think about passing arrays to Fortran. I've currently implemented lazy operations which are not possible in Python.
k

kyonifer

12/28/2018, 8:08 PM
the advantage of k/native is that you can call directly into vectorized (SSE optimized) assembly when you need to. the JNI/JNA add a good deal of overhead so one has to be careful how often they go through the JNI barrier (do loops in C), and the jvm currently has issues with generating SSE jit output, and compiled code will never beat hand-rolled assembly like Intel MKL anyway. I don't think code written in k/native will ever be faster than k/jvm (in fact probably slower without the awesome optimizer that is hotspot), but easy and low-latency access to C ABI is useful
t

thomasnield

12/28/2018, 8:08 PM
I am not an expert by any means in developing a computational library at the lowest level. However I do think keeping the core Library as minimalist and
Unopinionated as possible should be the goal. We are probably never going to agree on the different levels of abstractions that will be built. And those abstractions should contain the risks of design mistakes, not the low level BLAS.
👍 2
a

altavir

12/28/2018, 8:11 PM
Indeed, I think everyone will agree with that. Those are the details of implementation and should be hidden.
By low level I usually mean abstract which is probably high level by general conventions.
t

thomasnield

12/28/2018, 8:16 PM
I do think we should keep the core statically typed as much as possible. Developers building the abstractions will hate having to cast things. I think ojalgo maximizes the use of static types pretty effectively on the java platform. I have also seen terrible Java libraries that look like they were written by a python developer who spent more time fighting static typing than leveraging it.
:yes: 1
👍 1
a

altavir

12/28/2018, 8:21 PM
You need to remember that kotlin sometimes allows to use generics much more effectively than Java. For example to avoid boxing. So static typing it is, but probably a little bit more generic. I have to go to sleep right now, but I am looking forward to continue discussion tomorrow. Also remember that pragmatic development starts with use-cases. So feel free to contribute them.
p

Percha

12/28/2018, 8:21 PM
We all agree on building the core taking advantage of the static typing as much as possible, it is the main reason I want to use Kotlin instead of Python. For this reason, I believe we shouldn't try to copy numpy's API, it is thought for a dynamically typed language and breaks with Kotlin principles and idioms.
t

thomasnield

12/28/2018, 8:24 PM
@altavir haha I wonder if this initiative will create KEEP proposals finding new and creative ways to inline primitives and functions...
z

Zelenyi

12/28/2018, 8:24 PM
@thomasnield Nobody don't request to fight with statically typed, but it muste be hidden. If in code contains heap of <Int>, this is ugly. I cann't says about java-library which was created by python-developer, but scientifik java library from java-developers also it not sugar.
p

Percha

12/28/2018, 8:26 PM
And for the performance issues, I'm not sure if you are familiar with this repository: https://github.com/JetBrains-Research/viktor it uses JNI to call SIMD instructions when available. It is from Jetbrains Research, I don't know if any of you have been in touch with them and if they are interested in the discussion.
a

altavir

12/28/2018, 8:26 PM
They are.