InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises. Learn more →
SciPy Alternatives
Similar projects and alternatives to SciPy
-
-
-
Sonar
Write Clean Python Code. Always.. Sonar helps you commit clean code every time. With over 225 unique rules to find Python bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work.
-
-
Pandas
Flexible and powerful data analysis / manipulation library for Python, providing labeled data structures similar to R data.frame objects, statistical functions, and much more
-
-
-
-
InfluxDB
Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.
-
PyMC
Probabilistic Programming in Python: Bayesian Modeling and Probabilistic Machine Learning with PyTensor
-
-
ModelingToolkit.jl
An acausal modeling framework for automatically parallelized scientific machine learning (SciML) in Julia. A computer algebra system for integrated symbolics for physics-informed machine learning and automated transformations of differential equations
-
-
-
Home Assistant
:house_with_garden: Open source home automation that puts local control and privacy first.
-
-
-
-
OptaPlanner
Java Constraint Solver to solve vehicle routing, employee rostering, task assignment, maintenance scheduling, conference scheduling and other planning problems.
-
-
-
r-source
Read-only mirror of R source code from https://svn.r-project.org/R/, updated hourly. See the build instructions on the wiki page.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
SciPy reviews and mentions
- Python
-
What's Great about Julia?
Software has bugs. That's the way it is. You may think that Julia (but I suppose this is mostly about the ecosystem of packages around Julia) has too many bugs. Then you can use something else. Like Python. If you move from Julia to Python, you may want to use Numpy? Pretty cool project. It currently has 1,9k issues on Github and if you filter by bugs, it has 599 such labeled issues. How many of those are issues like in the post? I don't know. The same applies to Scipy. For example, the gaussian hypergeometric function returns wrong results for some input values https://github.com/scipy/scipy/issues/3479. This issue was filed in 2014. You can find similar old issues in Julia packages. That's how these things go. Luckily, many of the issues listed in the blog post are fixed.
If you think that picking any language and any library combination with a semi-high requirement for the number of features you want to be already implemented will be able to fulfill the "this has to be completely correct or I won't use it for my research"-requirement you will have a hard time.
The last part of the post seems to be about OffSetArrays.jl. Many people who have implemented libraries and who care about composability and generic input also agree that the Base AbstractArray interface is not perfect or complete and sometimes the issue is that the interface that does exist is not followed well enough for composability to work. A more complete, agreed upon, and generally adhered to interface for an "AbstractArray" would be nice and has been+is being worked on and discussed by many people in the community.
-
scipy?
git clone https://github.com/scipy/scipy
If you want to build on device: (assuming gfortran, openblas, numpy and pybind11 already installed) git clone https://github.com/scipy/scipy cd scipy python setup.py install -> SciPy 1.10.0.dev0+xxxx.xxxxxxx
- were can i find advance ( hardest ) python projects with source code ?
- Choosing Julia, Matlab, Python or R in economics?
-
“Why I still recommend Julia”
I don't see how it addresses the original complaint. Vishnevsky basically stated that if you are trying to run a scientific experiment on a supercomputer, maybe it's a risky idea to use a new programming language with a new stdlib and a bunch of OSS libraries vs using an old language like C with very stable set of existing code because new things tend to have unknown bugs? Vishnevsky has a point, but unless you are running some critical computations on supercomputers, maybe it doesn't apply to you?
To be clear, in supercomputing environments people still use old versions of CentOS just to make sure that library version updates do not change their computation results. I don't think many people here would say "I am sticking to Ubuntu 16.04 because I am afraid that the updates to some library like gmplib will slightly change my computation results in a way that is hard for me to detect".
Also, just staying with the old doesn't mean it's correct. You can also introduce bugs to your libs. I think NASA thought this through long time ago and solved it by making sure critical parts of the code are implemented twice using different stacks with different programmers.
If you are NASA, CERN, LLNL, or a bank, maybe it's a good idea to implement your computations once in Python and once in Julia (by at least two different programmers) and compare the outputs. And I don't think in this situation Julia is any different from other languages (other than you may put too much trust into it and skip this dual implementation). Case in point: https://github.com/scipy/scipy/issues?q=is%3Aissue+is%3Aclos...
-
Being 500x faster than python still means it's 10x slower than C
This is not that uncommon for performant python packages. Another example: scipy is 19% Fortran and 17% C.
-
Open source library unavoidably prints advertisement upon initialisation. My program runs parallel processes each using this library.
*********************************************************************************** This program is written in Python, an easy programming language for a first time programmer. Python is open software released under the PSF license (https://docs.python.org/3/license.html#psf-license-agreement-for-python-release). *********************************************************************************** +-----------------------------------------------------------------+ | This program uses NumPy, an open source library for numerical | | computing with Python. NumPy is released under the modified BSD | | license (https://github.com/numpy/numpy/blob/main/LICENSE.txt) | +-----------------------------------------------------------------+ +-----------------------------------------------------------------+ | This program uses SciPy, an open source library for scientific | | computing with Python. SciPy is released under the modified BSD | | license (https://github.com/scipy/scipy/blob/main/LICENSE.txt) | +-----------------------------------------------------------------+ \|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||/ = This program contains Baba Saitaandas, an aghori for programmatic decapitation of = = header files and head files. Saitaandas is unleashed by the Max Plank Institute = = for the Science of Decapitation (https://mpi-sod.github.io) = /|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||\
-
Discrete Algebraic Ricatti Equation Solver
I am the author who touched the DARE solver in SciPy introduced here and modified over the years. The iterative solvers are not more stable in fact it is the other way around but when arrays are too big for dense computations, decompositions become intractable and we resort back to iterative solvers.
-
A note from our sponsor - InfluxDB
www.influxdata.com | 3 Feb 2023
Stats
scipy/scipy is an open source project licensed under BSD 3-clause "New" or "Revised" License which is an OSI approved license.