121–130 of 146 posts
Are there any mature visualization libraries for Julia yet? I'm pretty excited about this language, but I couldn't find any visualization tools that had good documentation.
I believe there are bindings to plot.ly
Earlier quoted context omitted.
wbhart This sounds like a really interesting project! Is it already on Gitub? I suspect there are others in the Julia community who would love to join the effort too when you have something ready.
It is, essentially. https://github.com/wbhart/Nemo.jl See the wiki for a few bits of our planning that have actually made it online. Our current focus is twofold: 1) interface to Singular ( http://www.singular.uni-kl.de/ ) from Julia 2) write a Singular interpreter in Julia (as an independent implementation of the Singular language). (Of course Julia will always be the main language of Nemo. The Singular interpreter…
What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn'…
In R computing an outer product while passing a custom function is easy. Something like outer(x,y, some function of (x,y)) is pretty straight forward. Not sure how to achieve this in Julia.
Nevertheless, as the language grows and as more idioms are documented and widely used, lif will be simpler I guess.
Earlier quoted context omitted.
Dictionary performance is still slow from what I can't tell. Like 2x slower than Python last time I checked. https://groups.google.com/forum/#!topic/julia-users/hxfR70Ro... I also find the dataframe library to be much harder to use/not much faster than pandas. Great community though.
Right now, DataFrames is handicapped by problems with how DataArrays was designed. With some revisions coming in Julia 0.4, it should be possible to fix a lot of the worst problems (esp. performance) with DataFrames.
I think that being not faster than Pandas is pretty good, since it is written in C and heavily optimized.
Earlier quoted context omitted.
This very much depends on what you want to do with it and what your background is. Here are some things that might bother you. * Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm. * Julia's garbage collector is not generational/incremental and in some corner cases, GC can…
Arrays are indexed starting at 1. I asked about this and Jeff said it just depends which types of problems end up having to use +1 or -1. I said anything mod n is now going to have the +1 and he actually paused for quite a while. I know it's an unsolvable debate, but I thought indexing from 1 went out with Fortran. I also would have thought the math folks would prefer to start at zero.
I'd much rather have +1 scattered throughout my code (though I tend not to) than have to do -1 in my head at the repl, personally.
I am a little weary of the hype around a language whose unique selling point is speed. Where else in Julia is there significant innovation versus Python? The latter seriously has it all when it comes to scientific computing, and if anybody is not already running vectorized numpy code, or trivially compiling critical for loops to c-like speed using Numba/Cython, then they're missing out on performance which has nothin…
Then there's the really powerful metaprogramming capabilities, which are absent from the languages you've mentioned. I can't emphasise it enough: the paper this comment thread is about does a great job of explaining why these things are compelling.
Also, you may be interested in [1], an argument that language performance is valuable even if you don't need it yourself.
[1]: https://medium.com/the-julia-language/performance-matters-mo...
Earlier quoted context omitted.
Arrays are indexed starting at 1. I asked about this and Jeff said it just depends which types of problems end up having to use +1 or -1. I said anything mod n is now going to have the +1 and he actually paused for quite a while. I know it's an unsolvable debate, but I thought indexing from 1 went out with Fortran. I also would have thought the math folks would prefer to start at zero.
Don't forget matlab starts at 1. R starts at 1. Mathematica starts at 1 by default, though you can override that for any given array. 1-based indexing is very common in mathematical software.
Earlier quoted context omitted.
Still working my way through them myself. Useful examples working through docs would be useful. Most seem to presume a lot of knowledge of the libraries.
You are right - package documentation has some ways to go. Currently we don't yet have a mechanism to do `help()` on a package function, but we expect that to change in 0.4.
The one based indexing pretty much kills the entire thing for me.
Earlier quoted context omitted.
Julia is homoiconic, so it can do things non-homoiconic languages can't do. E.g. symbolic differentiation of Julia expressions. Of course Lisp and Scheme can do this too, but it's virtually non-existent in any common language today. SICM makes heavy use of this. Now, is there any other language with Lisp-like macros and static typing?
When do you call a language "homoiconic" exactly? When it exposes its own AST (abstract syntax tree) structure? In that case, you can call any language homoiconic, whenever somebody builds a library that can transform a given AST back into executable code. I'm not sure if it is a very distinctive feature.
Note that I mean to symbolically calculate derivatives and integrals, not numerically. A homoiconic language can deconstruct any object representing code and can construct another object based on the underlying structure of the original, not based on any particular value of the original. The original doesn't even need to be invoked at all.
In mathematical parlance, a homoiconic language allows implementing functionals, as opposed to mere higher-oder functions (which is nothing more than function composition).
Please note that all this works with higher-order functions. You don't have to have a textual representation of the function. A.i. you don't parse your own source code.
LISP was actually invented to be able to implement functionals and symbolic calculations like this. The original paper demoed implementing function differentiation (among other things).