41–50 of 257 posts
The main issue I encountered as a Julia user is that multiple dispatch doesn't scale very well. When you start building out a project, it's easy to keep track and debug if multiple dispatch starts failing (i.e. type starts spreading everywhere and Julia slows to Python like speeds). In medium-to-large projects, it becomes extremely cumbersome to manage this. It's doable, but adds a layer of complexity management to p…
Of course 1 based indexing makes the move harder, but it's worth the effort anyways.
I'm trying to embrace 1 line functions as much as I can, and Julia helps me with it's special notion for short function definition.
I like Julia a lot, and thought I understood some of it, but this article puzzles me: > This output is saying that a floating point multiplication operation is performed and the answer is returned. But "this output" is: %2 = mul i64 %1, %0 ret i64 %2 which looks very much like an int64 operation and return. Similarly: > Here we get an error. In order to guarantee to the compiler that ^ will give an Int64 back, it has…
> In [6]: 2^-5
> Out[6]: 0.03125
> (ie, no error, but the correct (floating point) result.)
julia> 16^17
0I like Julia a lot, and thought I understood some of it, but this article puzzles me: > This output is saying that a floating point multiplication operation is performed and the answer is returned. But "this output" is: %2 = mul i64 %1, %0 ret i64 %2 which looks very much like an int64 operation and return. Similarly: > Here we get an error. In order to guarantee to the compiler that ^ will give an Int64 back, it has…
> In [6]: 2^-5 > Out[6]: 0.03125 > (ie, no error, but the correct (floating point) result.) On the other hand: julia> 16^17 0
Earlier quoted context omitted.
I haven't dipped into Julia's macro side, but I wonder how much work it would be to just create macros to create syntactic sugar that maps infix Kronecker products to the Kronecker function. There are so many Julia packages that do similar stuff that I imagine it can't be all that hard for people who have become fluent with the macro system.
Why metaprogram? Just define an operator using the built in kron function. Example: const ⊗ = kron A = rand(5,5) B = rand(3,3) A ⊗ B Tada! I'm not sure how MATLAB/Octave's kron(A,B) looks more like math than A⊗B, but everyone can have their own opinion.
This is the second time I've learned about time-saving functionality related to infix that I didn't know about. (The previous was the symbol for integer division, which had been left out of the documentation until version 0.7). In this second case, interpretation of Unicode symbols as infix operators should be better surfaced in Julia documentation and tutorials - it's a really useful feature.
Earlier quoted context omitted.
> In [6]: 2^-5 > Out[6]: 0.03125 > (ie, no error, but the correct (floating point) result.) On the other hand: julia> 16^17 0
That's just integer overflow.
julia> 2^62
4611686018427387904
julia> 2^63
-9223372036854775808
julia> 2^64
0Developing anything multithreaded was a major pain.
Earlier quoted context omitted.
I do not recall the exact issue anymore unfortunately, I abandoned the project because of it, but the general sentiment on the Julia discourse seemed to be just avoid them. This blog post seems to sum up my issues with modules and namespaces pretty well though: http://luthaf.fr/julia-some-criticism.html I think that these issues are generally acknowledged although I don't know if they will be addressed. Seems like ma…
A lot of this blog post is addressed by just using `import` instead of `using`... so it was actually just an issue of not reading the manual. It's like using `from package import *` and then complaining Python doesn't namespace properly.
It really is not:
* `from package import ` is more work than `import package`, `using` is shorter than `import`
* the official documentation Python documentation starts with qualified imports, then introduces local bindings, and finally unqualified imports, opening a few doc pages imports are either fully qualified or explicitly bound; the first occurrence of using a non-prelude package in Julia's tutorial is `using`[0] and the modules documentation explains `using` first
The official Julia documentation very specifically steers the reader towards unqualified imports as the default & proper way to do things, Python's does the opposite.
[0] https://docs.julialang.org/en/v1/manual/functions/#Optional-...
edit: oh for fuck's sake I hate hn's shitty brain-dead pseudo-markup.
I did a 5000 line dissertation project in Octave after rejecting Julia. Reason : I had derived the math in linear algebra including Kronecker products; the math mapped to Octave pretty directly, but Julia requred me to translate all the Kronecker products to loops —yuck! kron(A, B) would become 12 lines of weird indices and for loops. On the listserv I was told that Julia was great because it didn't require vectoriza…
Surprises me. Julia can usually stay much closer to mathematical notation than, say, Python or C++. You can even use nice Unicode notation such as A ⊗ B ⊗ C. So, `kron` is actually provided by the standard library [1], are you saying that this kronecker product didn't do the job? [1] search in this file: https://github.com/JuliaLang/julia/blob/master/stdlib/Linear...
I wasn't comparing Julia to python or c+, but to Matlab octave.
As someone who has never run into performance problems with R, and also knows how to use Python - is there a good reason to learn Julia?
Ideally, Julia should give you the best of R (good, integrated data-types, -structures and functionality for statistics etc) and python (a sane, real programming language) - with the benefit of speed - and no/hardly any need to drop to/link to C libraries - "everything" is in Julia, and you can inspect the code "all the way down" (well, to a point - there's of course llvm at the bottom). Whether Julia is that for you…
So... R is an unreal language then?