51–60 of 70 posts
Earlier quoted context omitted.
Julia is FOrtran-indexed, and thus anathema to my religion.
In Fortran you can choose the starting index for each array separately. Even negative integers work. (But it's true that idiomatic Fortran starts indexing from 1.)
Earlier quoted context omitted.
Such as?
The iterative linear solvers from IterativeSolvers.jl along with the preconditioner ecosystem is more expansive and uses genericness to have a lot more functionality (it's all able to be used with matrix-free operators, GPUs and Xeon Phis, arbitrary precision number choices along with complex, quaternions, etc.). The differential equations solvers from DifferentialEquations.jl covers a lot more domains than the stuff…
Earlier quoted context omitted.
The iterative linear solvers from IterativeSolvers.jl along with the preconditioner ecosystem is more expansive and uses genericness to have a lot more functionality (it's all able to be used with matrix-free operators, GPUs and Xeon Phis, arbitrary precision number choices along with complex, quaternions, etc.). The differential equations solvers from DifferentialEquations.jl covers a lot more domains than the stuff…
Cool! To be clear, I realize that could have come across as an accusatory "prove it!", it wasn't meant that way. I've just never really needed anything not available in the scipy ecosystem, except for some obscure statistical methods (or not that obscure, but with a non-terrible api) that I don't think are available in julia either.
Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh
In research programming, you often spend as much or more time in data acquisition and munging than implementing core algorithms. Plus, more than in production code, the requirements change as you explore different applications and approach. And, because it's not production code, you have more opportunity to explore outputs at different stages to review function. It's effectively continual prototyping. All of these th…
For 2 Type agnosticism, this can be emulated with a "fused type" in Cython. See this example: http://cython.readthedocs.io/en/latest/src/userguide/numpy_t...
But I think the major inconvenience with Cython vectorization is really not about `float32` and `float64`. You get `float64` NumPy array by default from floating-point calculations. The actual inconvenience is that the vectorized function cannot take a scalar input like the NumPy ones. To remain polymorphic, I usually have to perform an `is_scalar` check on the input in a Python wrapper before sending the input data to the Cython function.
Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh
And yet, for my particular area (audio signal processing), Julia is just objectively worse than Python in expressivity, library support, and even speed.
But I'll keep trying. Maybe next year.
Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh
just as soon as someone who knows C/C++ ports numpy and scipy and pandas. and gensim and nltk and sounddevice. and tensorflow and scikit-learn and keras....
Earlier quoted context omitted.
Could you elaborate more on the advantages of a functional language?
Scientific work should strive to be functional by definition (identical input == identical output), so I could see why a programing language should reflect that.