71–80 of 114 posts
Let's not forget to give at least some credit to Perl Data Langauge (PDL). It pioneered a lot of these ideas 10 years before NumPy existed, and is still a pretty great tool today: http://pdl.perl.org/index.php?page=FirstSteps
Earlier quoted context omitted.
Theoretically Julia is better for scientific computing, the only issue is its package ecosystem isn't as mature as Python's. But it's growing incredibly fast and there have already been libraries available for a few years that would be really impractical to write and maintain at such a level in C++ for Python. I assume that for science at least Julia will catch on a lot.
Julia interop with Python is insanely easy. using PyCall np = pyimport("numpy") res = np.fft.fft(rand(ComplexF64, 10)) You just called numpy fft from Julia.
julia> data = rand(ComplexF64, 1024^2);
# python fft from julia:
julia> res = @btime np.fft.fft(data);
78.613 ms (39 allocations: 16.00 MiB)
In [11]: %timeit res = np.fft.fft(data)
89.3 ms ± 1.65 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
As expected, julia has its own fft package (based on FFTW):
julia> res = @btime fft(data);
61.540 ms (33 allocations: 16.00 MiB)As someone who cut his teeth on bioinformatics before eventually just completing a full computer science degree, I was a bit worried that this article wouldn’t address the applied scientific audience well. Pleasantly surprised, though, at how well this article evangelizes NumPy to that exact community. Many labs are gaining access to or creating physical tools that create data analysis over experimental design proble…
The coolest thing I read last year was about single cell rna-seq trajectory analysis of the differentiation for different blood cells.
[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3273988/figure/...
Earlier quoted context omitted.
I started using python and numpy/scipy back then because it was vastly easier to deploy on a server or supercomputer. The matlab compiler meanwhile is clunky and adds new bugs and additional steps. Julia doesn't really match python in this regard either. For more pure research and prototyping things both can do, I still think matlab is better though I rarely use it. I just like the idea of being able to easily deploy…
In Julia, there is one package manager and it gets things right. https://docs.julialang.org/en/v1/stdlib/Pkg/ It's super nice to have no fragmentation when it comes to packaging. In Pkg, package states are immutable, always reproducible, and quick. Julia packages that have binary dependencies usually build them all for every platform using the binary builder infrastructure ( https://github.com/JuliaPackaging/Yggdrasi…
Don't underestimate the impact this has on getting funding or even just tenure/etc recognition for working on numpy. I'm in industry these days, but coming from the academic side, it's _really_ hard to get recognized for building the underlying infrastructure that tons of people use. I've built and maintained libraries that are used in a ton of publications, but was always told my work was "utterly and completely use…
props to your work and similar to numpy, i assume it has been immensely useful for loads of people. but 'building the underlying infrastructure that tons of people use' is not science. in my department we had to fail a phd student because 90% of his work was just implementing bunch of existing methods as a python library. useful, yes; science, no. wasn't his fault, had a shitty supervisor, but making useful tools is…
What could be useful is openness in used tools and software and a way of getting citation counts for software used. It's nothing more than a table. That way the hotness of publication could start to flow for the underlying tools.
Let's not forget to give at least some credit to Perl Data Langauge (PDL). It pioneered a lot of these ideas 10 years before NumPy existed, and is still a pretty great tool today: http://pdl.perl.org/index.php?page=FirstSteps
NumPy’s direct predecessor Numeric was released in 1995.
Then Travis started Numpy which somehow magically was backward compatible with both numeric and numarray - and managed to get the community united again.
Now if you want to use array comprehensions, the first case looks similar: [A[k] for k in range(3,0,-1)] but the second now has to be [A[k] for k in range(2,-1,-1)].
Further, for some reason, array and matrix are different types and one has to convert back and forth between them.
Earlier quoted context omitted.
Theoretically Julia is better for scientific computing, the only issue is its package ecosystem isn't as mature as Python's. But it's growing incredibly fast and there have already been libraries available for a few years that would be really impractical to write and maintain at such a level in C++ for Python. I assume that for science at least Julia will catch on a lot.
> Theoretically Julia is better for scientific computing, the only issue is its package ecosystem isn't as mature as Python's. That's not a small issue. The ecosystem is probably the reason people choose NumPy over MATLAB, for example. NumPy is not inherently superior to MATLAB, and most academicians that adopted NumPy in the 2000's already had a MATLAB license, so cost was not a concern either.
In fact, it's not an issue at all since Julias ecosystem is a superset of that of Python: with PyCall you can use Python libraries and Julia libraries in one program without issues.
Don't underestimate the impact this has on getting funding or even just tenure/etc recognition for working on numpy. I'm in industry these days, but coming from the academic side, it's _really_ hard to get recognized for building the underlying infrastructure that tons of people use. I've built and maintained libraries that are used in a ton of publications, but was always told my work was "utterly and completely use…
Don't underestimate the impact this has on getting funding or even just tenure/etc recognition for working on numpy. I'm in industry these days, but coming from the academic side, it's _really_ hard to get recognized for building the underlying infrastructure that tons of people use. I've built and maintained libraries that are used in a ton of publications, but was always told my work was "utterly and completely use…
props to your work and similar to numpy, i assume it has been immensely useful for loads of people. but 'building the underlying infrastructure that tons of people use' is not science. in my department we had to fail a phd student because 90% of his work was just implementing bunch of existing methods as a python library. useful, yes; science, no. wasn't his fault, had a shitty supervisor, but making useful tools is…