8 ms·
Julia 0.5 release
- tomrod 10y agoExcellent news! I look forward to reading over the release notes. Edit: this is a game changer for me: > Support for multi-threading. Loops with independent iterations can be easily parallelized with the Threads.@threads macro.
- 3JPLW 10y agoA better link is: https://github.com/JuliaLang/julia/blob/release-0.5/NEWS.md https://github.com/JuliaLang/julia/blob/release-0.5/NEWS.md Better yet, wait for the official announcement once binaries are compiled and posted for download. I believe there will be a blog post to go along with it, too.
- KenoFischer 10y agoYes, there'll be an official announcement in a little bit. Tagging is just the first step (we haven't even added the release metadata to the tag on GitHub yet).
- jmde 10y agoThis could either be brilliant or a total nightmare: "Support for arrays with indexing starting at values different from 1. The array types are expected to be defined in packages, but now Julia provides an API for writing generic algorithms for arbitrary indexing schemes (#16260)." Originally I thought total nightmare but now I'm not sure.
- KenoFischer 10y agoMany people think this was added for support of 0 offset arrays, but that's only a side effect really. This feature was requested by people who work with rather odd arrays (e.g. diagonal slices through high dimensional data). I have mentioned in previous threads on the subject that julia's 1-indexed arrays don't matter much in practice because the generic APIs hide that fact most of the time. This just adds the last bit of code to make that completely true and adds documentation/cleanup. For those seeking more information, I'd recommend Tim Holy's JuliaCon keynote on the subject: https://www.youtube.com/watch?v=fl0g9tHeghA https://www.youtube.com/watch?v=fl0g9tHeghA
- zerofan 10y ago> I have mentioned in previous threads on the subject that julia's 1-indexed arrays don't matter much in practice because the generic APIs hide that fact most of the time. My guess is that most people who prefer zero-based feel strongly about it, and most people that like one-based don't care that much. If it really doesn't matter that much, I think Julia should've gone with zero. FFTs, Vandermonde matrices (least squares), polynomials, and pretty much anything where the array subscript relates to the mathematics is cleaner with zero-based arrays.
- sundarurfriend 10y ago> My guess is that most people who prefer zero-based feel strongly about it, and most people that like one-based don't care that much. FWIW, as someone in the latter category (liking one-based indexing), I'd say you're partially correct: I'm not emotional attached to 1-based indexing the way some 0-based folks seem to be, but it's a practical nicety and one of the things I'm really glad Julia chose to do. Making 0-based the default would definitely reduce its appeal to me.
- zerofan 10y agoCall it emotional if you like, but I won't use a language that has an off by one error built into its specfication :-)
- deleted 10y ago[deleted]
- Avshalom 10y agoPascal and Ada have had arbitrary indexing for decades. It's been fine.
- StefanKarpinski 10y agoAnd Fortran, where it works fine. Perl lets you change the array index offset but everyone warns you that your computer will reach out and slap you in the face if you do. As is often the case, the devil is in the details.
- ch_123 10y agoEiffel too IIRC (same family I suppose)
- nimrody 10y agoPascal and Ada don't usually use their arrays as matrices in mathematical expressions. Julia is targeted at people using Matlab. How do you multiply two matrices that use different indexing? Ignore the indexing differences? It's also problematic when different libraries use different conventions (0-based vs 1-based). Can you use the output of one such library to feed another?
- yaantc 10y agoAda has the notion of attributes applying to types and variables, to access related properties. Among those, there are attributes to get the starting and ending indexes of an array. So it's possible to program completely generic array processing, independent of the underlying choice or range for the array. All this from memory, and it's been a long time...
- data_hope 10y agoDoesn't Fortran feature variable indices for quite a while now? I think the varying indices are a great feature for porting old code over from other programming languages.
- ceyhunkazel 10y agoA feature request, Anaconda partners with Intel and includes MKL default. Could you do same for Julia and add MKL default at least in version 1.0 so no manual work needed?
- tavert 10y agoSee https://github.com/JuliaLang/julia/issues/18374#issuecomment-245108175 https://github.com/JuliaLang/julia/issues/18374#issuecomment.... Open-source Julia builds also need to support non-Intel processors and architectures, and operating systems where MKL isn't available. If you have a specific operation where MKL is noticeably faster than OpenBLAS, report it. OpenBLAS can always be improved if they have specific workloads to target.
- ceyhunkazel 10y agoThanks for the comment, I understand why it is not option.By the way I do not understand why I received downvotes.
- tavert 10y agoProbably because a hacker news comment isn't the best place for a feature request about using a proprietary library and comparing to a commercial distribution of a different language. By the way, Julia partners with Intel as well, but on things like adding multithreading support to the language, and developing auto-parallelizing compilers (https://github.com/IntelLabs/ParallelAccelerator.jl https://github.com/IntelLabs/ParallelAccelerator.jl). Improved support for building Julia with MKL and Intel's C and Fortran compilers is something that Intel would probably like to collaborate with us on as well, but not much has happened there officially yet (these are different groups within Intel).
- ceyhunkazel 10y agoKeep up the good work Julia team.
- qwertyuiop924 10y agoI haven't thus far been interested in Julia. Unless you're into high-level math, it didn't seem to provide much value, and it did weird stuff with arrays, and wasn't Lua, which gets a free pass for being amazingly well designed in all other respects (arguably, it was well designed in that one as well, but it makes all the array math a pain). I don't know, maybe it's great. Maybe I should reconsider. But then again, it's strongly typed, which isn't usually my sort of thing (I'm not working with a team, and my programs haven't devolved into chaos yet, so with no empirical data either way, I'll take my favorite)
- jhbadger 10y agoI'm not sure what you mean by "high-level math". It isn't a symbolic language like Mathematica for mathematics research but something along the lines of R for data analysis. The strong typing isn't just there for discipline, but efficiency in execution.
- qwertyuiop924 10y agoYeah. But it's definitely optimized for mathematical usage.
- Recurecur 10y agoSince programming is fundamentally mathematics (grin) that means it's a "general purpose language". There's nothing whatsoever preventing it from being a first-class string manipulation language for instance. Granted, the emphasis has been on applied mathematics. I think in the longer run it will branch in several directions, one being realtime simulation - and then on to games. It is close to C++ efficiency (plus or minus) already, and it will only get better. I haven't looked into Julia's GC implementation in detail, but I'm hopeful that with a little effort it's easy to avoid "stop the world" GC collections.
- JoeAltmaier 10y agoThat old saw is getting dull. Because something can be described by mathematics, does not make it mathematics. Else the whole universe would be mathematics. Programming is the art of getting a particular machine to do something you want. You may use math to get there (like in accounting or swimming) but its fundamentally a task that's performed by skilled people.
- dschiptsov 10y agoArguably, it is better numpy based on multimethods, but it is far from being polished as Python 3.5+ On the contrary it suffers from the kitchen sink syndrome, with process of continuous adding of stuff instead of continuous clarification and refinement, which characterizes a good Python 3 language.)) But there is a lot of enthusiasm.
- papaf 10y agoI think that you are missing the big picture. To you it is a better numpy/python, to me it is a faster/cleaner/more parallelizable version of R, to some people it is a cleaner/faster version of Matlab. This could be seen as a "kitchen sink" approach but it also is very useful when you want to get things done. My gripes about Julia are really minor considering how young and ambitious the project is.
- dschiptsov 10y agoYes, you are right. It is a better R. I haven't thought of R because I consider it as being nothing special in terms of design of programming languages.
- sndean 10y agoIs Julia 1.0 still scheduled for approximately Summer/Fall 2017? I really like/liked Julia, but some things breaking between 0.2 and 0.4 made me use it a bit less.
- rspeer 10y agoI used Julia a bit in the same time span, and I was frustrated with the breakage, but I also saw a lot of things that clearly needed breaking changes. I'm glad they're happening. Until now, [a, b] meant "concatenate a and b if they're arrays, make a 2-element array otherwise". This struck me as both annoyingly inconsistent and as a failure to think recursively. Now it's always a 2-element array, possibly an array of arrays. And that's a huge change in syntax, and it's for the better. I look at many things in the 0.5 release notes and they're fixes to specific pain points I had. This has me paying attention to the language again.
- mathieutd 10y agoAre there large speed improvements from the previous version?
- 3JPLW 10y agoYes, in many areas: * Higher order functions now specialize on (and possibly even inline!) passed functions * Anonymous functions are now fast, too * Fused broadcasting can avoid intermediate allocations and only make one pass through the array * User-extensible bounds checks allow custom array types to opt-in to skipping bounds checking, enabling SIMD-ification of some for loops That said, compilation times may take a bit longer due to the LLVM upgrade… but this resulted in an even stronger push towards better performance in many other areas.