Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin and linear programming

tomstechnicalblog.blogspot.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Kotlin and linear programming

#31

Post by aninhumer »

lmm wrote: post #30
SmirkingRevenge wrote: post #8

Earlier quoted context omitted.

Python is often a second class citizen in these areas, even if much is made about its widespread support in the data science realm. I don't want to say it's hype is overblown... but a lot of the pain points and cracks in the seams are glossed over. Take spark, for instance. You run into extreme performance issues the second your data has to be serialized to cross the py4j gap. An many essential parts of its API requi…

Scala is a lot simpler than Kotlin once you get into the details - it uses a few simple but very general features rather than a lot of ad-hoc language-level functionality. A lot of the time what looks like some complex construct in Scala is actually two or three separate features combining in a way that makes perfect sense once you look at the pieces, and you can click through to see how the thing is implemented in p…

I think saying something it's simple because it's based on simple rules can be slightly misleading. This is why I like to distinguish the ideas of "complication" and "complexity".

To me "complicated" means that the rules of a system require a lot of information to describe, i.e. it has a lot of special cases and caveats to learn. Whereas "complex" is more about the variety of emergent patterns in a system which are necessary to understand it and interact with it effectively.

As an example, rules of Go are very simple, but we probably wouldn't call it a simple game. In contrast, the rules of Chess are rather more involved, with quite a few special cases. Both games can be called "complex", but I'd also say that Chess is more complicated.

So using these terms, it sounds like you're saying Scala is less complicated than Kotlin, whereas the parent is perhaps saying that Kotlin is less complex?

Re: Kotlin and linear programming

#32

Post by pjmlp »

agibsonccc wrote: post #28
pjmlp wrote: post #24

Earlier quoted context omitted.

IBM and NVidia do have CUDA JVM support. There are .NET CUDA implementations as well.

Cuda4j is only implemented in the ibm jvm and last I saw was slow to add newer cuda versions.

Still, it is a possibility.

Re: Kotlin and linear programming

#33

Post by MaxBarraclough »

deepsun wrote: post #13
sevensor wrote: post #4

Adding to my other comment, my biggest dissatisfaction with this article is that all it did was show the quite excessively verbose problem setup, without actually showing an algorithm for integer linear programming. An interesting post would have explained how to implement branch and bound in Kotlin, not how to call somebody else's library. Needless to say, I'm not sold on Kotlin from reading this.

Also, I believe no one is doing linear programming without vectorized operations (SIMD) nowadays. I know JVM optimizes small methods, so maybe their JIT optimizer does that automatically, but I'm not sure that optimizer is better that manually optimized code like in numpy.

I suspect you're right. Java doesn't have the best track-record when it comes to SIMD.

Unlike .Net with System.Numerics.Vectors, they're not even interested in making a platform-independent SIMD library for manual optimisation. The JVM holds contempt for such real-world optimisations. I see that Intel have made one though - https://software.intel.com/en-us/articles/vector-api-develop...

At a glance, it looks like Oracle have dabbled with AVX in HotSpot, but aren't taking it very seriously. https://www.google.com/search?q="-XX%3AUseAVX"

Re: Kotlin and linear programming

#34

Post by twic »

frankc wrote: post #7
sevensor wrote: post #4

Adding to my other comment, my biggest dissatisfaction with this article is that all it did was show the quite excessively verbose problem setup, without actually showing an algorithm for integer linear programming. An interesting post would have explained how to implement branch and bound in Kotlin, not how to call somebody else's library. Needless to say, I'm not sold on Kotlin from reading this.

I would disagree with this. In general, the algorithms are well known and only need to be implemented once. Doing problem modeling to solve real problems is where the action is for optimization.

> the algorithms are well known and only need to be implemented once

To an extent. The basic algorithms are well known (simplex, interior point), but there is a lot of scope for improvements - this is why the big commercial solvers can be orders of magnitude faster than the best open source ones. Still, even if the algorithms are not well-known, they do only need to be implemented once.

For integer programming, though, there can definitely be value in problem-specific heuristics for branch selection and rounding.

Re: Kotlin and linear programming

#35

Post by sevensor »

deepsun wrote: post #13
sevensor wrote: post #4

Adding to my other comment, my biggest dissatisfaction with this article is that all it did was show the quite excessively verbose problem setup, without actually showing an algorithm for integer linear programming. An interesting post would have explained how to implement branch and bound in Kotlin, not how to call somebody else's library. Needless to say, I'm not sold on Kotlin from reading this.

Also, I believe no one is doing linear programming without vectorized operations (SIMD) nowadays. I know JVM optimizes small methods, so maybe their JIT optimizer does that automatically, but I'm not sure that optimizer is better that manually optimized code like in numpy.

Also note that integer linear programming like in the article is very different in practice from continuous linear programming. Relaxing to a continuous problem often doesn't help much.

Re: Kotlin and linear programming

#36

Post by bitL »

pjmlp wrote: post #24
bitL wrote: post #5

Not sure why Kotlin would be picking this fight - Python and to some extent R already dominate in data science with a little bit of Scala added in Spark - where does author see an opening for Kotlin? For high performance libraries nobody would pick Python or any JVM-based language either, and that's what most of the wrappers end up calling anyway (C++, CUDA, Fortran, OpenCL).

IBM and NVidia do have CUDA JVM support. There are .NET CUDA implementations as well.

It's always like that; JVM is just way behind the cutting edge and people have to wait years to get access to latest stuff. I quit that a few years ago, now I go straight to the source, unhindered by whatever *VM is out there, even if it means learning new things every single day.

Re: Kotlin and linear programming

#38

Post by pjmlp »

bitL wrote: post #36
pjmlp wrote: post #24

Earlier quoted context omitted.

IBM and NVidia do have CUDA JVM support. There are .NET CUDA implementations as well.

It's always like that; JVM is just way behind the cutting edge and people have to wait years to get access to latest stuff. I quit that a few years ago, now I go straight to the source, unhindered by whatever *VM is out there, even if it means learning new things every single day.

That is common to any language that isn't part of the OS vendors stack, not only Java.

For example, on Android, Java is the name of the game, beyond 3D rendering and audio codecs, the NDK is quite useless as everything else is exposed behind JNI calls.

Re: Kotlin and linear programming

#39

Post by riku_iki »

icebraining wrote: post #25
XorNot wrote: post #14

Earlier quoted context omitted.

Python 3.6's optional types are pretty great. Block out your solution first then start constraining it where you need to.

+1, I recently wrote some data extraction and processing code using pandas and mypy, and it was pretty great. And progress is happening to add types to numpy and pandas themselves.

You still have many not type annotated libraries in ecosystem, and poor support of refactoring/navigation in IDEs.

Re: Kotlin and linear programming

#40

Post by SmirkingRevenge »

fulafel wrote: post #20
SmirkingRevenge wrote: post #8

Earlier quoted context omitted.

Python is often a second class citizen in these areas, even if much is made about its widespread support in the data science realm. I don't want to say it's hype is overblown... but a lot of the pain points and cracks in the seams are glossed over. Take spark, for instance. You run into extreme performance issues the second your data has to be serialized to cross the py4j gap. An many essential parts of its API requi…

> In any case, a "not-java" language that can talk java is freakin amazing, in my book (Scala doesn't scratch my itch there - it's far too clever - had enough of that with perl back in the day). Clojure is a bunch simpler than Scala, many Python programmers are quick to pick it up. The dynamic nature and interactive prompt is all there. If you look at Norvig's Python-Lisp comparison table at http://norvig.com/python-…

I agree. I really like clojure a lot (though have only toyed with it.. and years ago at that). I think I would like to see it gain more adoption.
Post reply on HN