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

Julia 1.0

julialang.org

Post reply on HN
Print view View original

351–360 of 446 posts

Re: Julia 1.0

#351

Post by ivirshup »

staticfloat wrote: post #318
ivirshup wrote: post #86

Earlier quoted context omitted.

I do love Julia, but start up and import time can make scripting a little rough. Hopefully PackageCompiler.jl will solve that soon.

If you haven't yet, you should check out a build of 1.0. The start-up time is _greatly_ improved. Basic startup time is twice as fast as ipython for me now: $ time ipython -c '1+1' Out[1]: 2 real 0m0.493s user 0m0.401s sys 0m0.063s $ time julia -e '1+1' real 0m0.222s user 0m0.115s sys 0m0.101s Yes, python itself is still much faster. I compare against ipython just because that used to be my go-to interactive shell fo…

That's pretty cool! I never had to much of an issue with the startup time for interactive computing though. It mainly has come up as an issue when I was writing short scripts that could be run a couple dozen times in serial.

The real question is how long does `using Plots` take in v1.0?

Re: Julia 1.0

#352

Post by ChrisFoster »

dnbgfher wrote: post #343

I'm sure this is too late to get much visibility, but I recently looked into using Julia (for my MS thesis) and found it sorely lacking in one major way that I found unforgivable. Their type system is pretty interesting, and allows for some really cool abilities to parameterize things using types. I'd like to have seen more work done on, effectively, strong typedefs (or whatever $lang wants to call them). However tha…

It's not that people are uninterested; it's more that inventing a system for specifying and enforcing these kind of generic interfaces is a really hard design problem.

As a comparison, consider that the C++ standards body has been working on, debating and serially rejecting the various "C++ concepts" proposals for years now.

Re: Julia 1.0

#353

Post by pjmlp »

kazinator wrote: post #345
stellalo wrote: post #307

Earlier quoted context omitted.

I haven’t, so far, encountered a single occasion in which I would need to manually flatten-deflatten indices: Julia has multidimensional arrays of any dimension N, and you can access their content in a linear fashion without any effort (simply provide one index instead of N)

Still, the implementation has to internally do ABC(z - 1) + AB(y - 1) + A(x - 1), compensating for the pointless bias at every dimension. It's just a wanton complication, like insisting on Roman numerals instead of a radix enumeration.

The implementation already has to do lots of internal stuff to map high level language abstractions to actual real hardware capabilities, index calculations is just another one.

Re: Julia 1.0

#354

Post by timholy »

pravus wrote: post #316
peatmoss wrote: post #62

Earlier quoted context omitted.

> 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success. I’m curious as to why this is a problem outside numerical computing. From my perspective, this is consistent with a long history of mathematics dealing with matrices that predates electronic computers. 0-based arrays are pop…

0-based indexing has the advantage of easily mapping to memory addresses since the index is an offset from a base address (perhaps multiplied by a unitary per-item length). I personally prefer this since I tend to think about and work with data as an offset from a starting point. 1-based indexing has the advantage of always knowing the length of the array since the index of the last element is this value. You also ge…

As noted above, Julia does too. Heck, if you wanted to, in Julia with probably <100 lines of code you could create an array type that only allows prime numbers as indices. And subject to the constraints of the raw calculations needed, it would be as fast as it can be---there is no "extra" performance overhead associated with doing basically whatever you want.

Re: Julia 1.0

#355

Post by timholy »

renox wrote: post #297
jebej wrote: post #148

Earlier quoted context omitted.

You can use whatever start index you like: https://docs.julialang.org/en/stable/devdocs/offset-arrays/#... For a pre-baked solution: https://github.com/JuliaArrays/OffsetArrays.jl

The problem is the default behaviour: in Ada you can use whatever you want, in Julia the default is 1-based which is quite controversial.

Picking whatever you want is one line of code, and similar to the line you'd need to allocate any array. And your choice propagates to the downstream operations.

Instead of complaining in the abstract, check it out, you'll be impressed. https://julialang.org/blog/2017/04/offset-arrays

Re: Julia 1.0

#356

Post by marmaduke »

ChrisFoster wrote: post #288
marmaduke wrote: post #228

Earlier quoted context omitted.

What happens for that scientist when they have to dive into Julia’a stack to debug something weird? In Python and C, you have established debuggers, semantics etc, which means that, yes, there are two languages instead of one, but neither is a moving target compared to a language which just had a 1.0 release. I get the issue with scientists writing poor code, but Numba has largely solved this problem, by packing an L…

Sometimes low level debugging is a surprisingly pleasant experience as the julia JIT generates proper DWARF debug info. So for instance, you can break in gdb and see the julia source code for any julia generated stack frames, neatly intertwined with the frames of the C runtime. To be clear, I don't remember needing to do this as a regular user. As an occasional compiler hacker it's been quite nice though.

That’s cool, I wasn’t aware. I think that’s most useful when working with external libs.

Re: Julia 1.0

#357

Post by timholy »

typon wrote: post #42

Reading through the docs, looks like they have 1-indexed arrays..?

For all those worried about whether Julia's indexing is good enough, let's broaden the conversation a bit. How good is your favorite language at, say, iterating along dimension m of an n-dimensional array, where m and n are not known by the programmer, and where you can't count on the array being strided? Trivial and extremely efficient in Julia: https://julialang.org/blog/2016/02/iteration.

Re: Julia 1.0

#358

Post by petre »

simonbyrne wrote: post #314
tavert wrote: post #232

Earlier quoted context omitted.

Things are decent on average, but there's a persistent carelessness and rush to do things without paying attention to the consequences. More in packages than base nowadays, but there's a lot of merging and releasing things immediately without waiting for code review that could have caught mistakes before breaking users.

Out of curiosity: what language has a package ecosystem that in your opinion does do this right?

Dlang. But it's a compiled language and you have the option of statically compiling all your dependencies. The package manager is also quite simple and just works.

https://github.com/dlang/dub

Re: Julia 1.0

#359

Post by Athas »

taliesinb wrote: post #49

I have high hopes for Julia becoming the defacto open-source scientific language. Despite Python and R both having a massive head start, I'm willing to bet that talented engineers and scientists will be drawn to Julia to implement their next-generation frameworks owing to the powerful features that it offers. For example, the fact that an array of unions such as Array{Union{Missing,T}} is represented in memory as a m…

> For example, the fact that an array of unions such as Array{Union{Missing,T}} is represented in memory as a much more efficient union of arrays is a perfect example of where a clever compiler can make the logical thing to do also the efficient thing to do!

Can you elaborate on how Julia represents arrays of unions, or point to some documentation? I'm working on something where an automatic efficient representation would be useful, and I'd like to learn from other's experience.

Re: Julia 1.0

#360

Post by ChrisRackauckas »

marmaduke wrote: post #338
ChrisRackauckas wrote: post #299

Earlier quoted context omitted.

SciPy's ODE solver doesn't have a stable contributor who contributes more than than about once a year even though it has many long standing issues, and PyDSTool hasn't had a commit in 2 years and doesn't work on Python 3 (and most of pycont is incomplete...). R's deSolve isn't even in a repository you can track and still hasn't fixed their DDE solver issues even though they directly mention in the docs how it's incor…

SciPy solvers are mostly interfaces to existing established solvers, and I’ve not had any problems with them. We’ve also used PyDSTool without problem, and it appears to support Python 3, https://github.com/robclewley/pydstool/blob/master/README.rs... If you think these are poorly maintained you should see XPPAUT, a tool still quite widely used.

SciPy's solvers cannot handle events which are nearby, most return codes aren't documented, you cannot run the wrapped solvers in stepping control mode, you cannot give it a linear solver routine, etc. So it wraps established solvers but still only gives the very basic solving feature of it, and most of the details that made the methods famous are not actually available from SciPy's interface.

And it wasn't Python 3 for pydstool. It's SciPy 1.0.0. Some of the recent maintenance for this stuff has actually come from the Julia devs though:

https://github.com/robclewley/pydstool/pull/132

Post reply on HN