41–50 of 70 posts
Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh
Python has good support for a lot of functional concepts
Off topic, but this seems like as good a place as any to ask: It's my impression that numpy is really good. Is it as good as Fortran? That is, if I have a large, sparse, complex matrix, Fortran will have an efficient solver for it that will also be numerically stable, and will have four decades of use to find any weaknesses. Is numpy equivalent (except for the four decades part)? Is it close? Or does it just cover th…
Earlier quoted context omitted.
> "Pythran is an ahead of time compiler for a subset of the Python language, with a focus on scientific computing." and > a claimless python to c++ converter
(main dev writting) Don't focus too much on the claimless :-) There still are far more wide spread tools that solve the same kind of issues (numba, cython, julia)... The idea of the change was that it's more important to convey the problem it solves rather than how it's done ;-)
Simple and Effective Type Check Removal through Lazy Basic Block Versioning[0] could be adapted to make it unnecessary to compile more than one version of the function at a (probably) minor cost of performance. It's geared more towards jitted code but something like it where it compiles different blocks where the types matter and falls back to interpreted code if users pass in some random types not expected just might work -- or the python interpreter throws an exception if the types don't make sense.
[0]http://drops.dagstuhl.de/opus/volltexte/2015/5219/pdf/9.pdf
Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh
Julia is FOrtran-indexed, and thus anathema to my religion.
(But it's true that idiomatic Fortran starts indexing from 1.)
Earlier quoted context omitted.
(shameful author here) One should read def rosen_explicit_loop(x): s = 0. n = x.shape[0] for i in range(0, n - 1): s += 100. * (x[i + 1] - x[i] ** 2.) ** 2. + (1 - x[i]) ** 2 return s (edited)
... n = x.shape[0]
Earlier quoted context omitted.
Maybe. It's currently just a safer bet to learn and use Python. Easier to get a job after you fail getting your next grant. I have so far seen zero Julia job ads. Hell, I see more e.g. Haskell and Fortran job ads than Julia.
or learn both and have the convenience+speed of Julia for scientific work? Speaking from my experience here as a bioengineering PhD student. The Julia learning curve is low enough for an experienced Python/scipy user to switch over fairly swiftly. edit: also, I would be very surprised if you had seen any Julia job ads, v1.0 hasn't been released yet. Doesn't mean it can't make my scientific life easier in the meanwhil…
Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh
All of these things play to python's main strengths: huge community with connectors to every API and format, plus ability to conveniently integrate code at several levels of complexity & maturity as you prototype.
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…
Earlier quoted context omitted.
That's a pretty broad statement. And it's a goal that a lot of scientific work simply doesn't allow for. Any stochastic process will have variability for a given set of inputs. I think there are more fields within the umbrella of Science where purely functional programming isn't an achievable ideal--let alone a desirable one--than there are where this is a good fit. You can make the argument that all programming shou…
Any stochastic process will have variability for a given set of inputs If you're modelling stochastic processes it's important to be able to set the random seed you can reproduce your simulations. So for a given set of inputs you should get the same output, given that one of the inputs is your seed.
Earlier quoted context omitted.
That was done quite awhile ago? Julia now has a bunch of unique stuff Python doesn't have because the basics are already done.
Such as?
I agree that Python has a library advantage in data science + ML. R has a library advantage in the area of statistics. But Julia has quite a few advantages in the core math areas of scientific computing and algorithm development. There is headway being made into DS+ML as well. Julia's pandas/dataframe equivalent is JuliaDB which adds out-of-core and online stats functionality, so it's more at the level of pandas+dask. Flux.jl is still in its early stages but it's quite a unique ML framework which can directly incorporate any Julia function at any level, and then has some working experiments with compiling to things like JS and XLA.
But in the broad view of things, every language has SciPy+NumPy pretty satisfactory (ex: Julia's Base library has most of it, the top 20 packages cover the rest), but from there all have tradeoffs in what areas the community is specializing in.