Thanks for the response!
I can't speak for others, but I'm fine with receiving it in the [0, 1]
range and then scaling it myself, to avoid the need for the stock functions to take that slight overhead hit. But whatever your preference is works for me.
On further reflection it makes sense to supply the population in the [ bounds.lb, bounds.ub range]. It would be a copy of the population, so the original array wasn't overwritten by the user.
Makes sense.
TBH using very expensive objective functions doesn't sound great for
differential_evolution though, there's always a lot of function evaluations.
Do you have an alternative solution for a task that is prone to local minima, benefits greatly from crossing with other population members, and would benefit from custom mutation function capabilities? The sort of tasks I'm doing are pretty close to the constraints of literal physical evolution, e.g. the evolution of physical forms optimized to physical tasks. The fact that CFD is slow (esp. on certain tasks like combustion modeling :Þ ) can't be helped, except by throwing lots of compute resources at it and not overcomplicating the simulation. The upside is that perfection is not needed - there's no need to refine to fine tolerances.
w.r.t implementation, it just needs someone to do the programming and write tests. We always welcome new contributors for PRs.
On that note I tried setting up the dev environment, on a new branch. After two hours of work I got it built. But now I can neither rebuild it nor run tests: scipy]$ python dev.py test -v 💻 ninja -C /path/to/scipy/build -j6 ninja: Entering directory `/path/to/scipy/build' [4/4] Generating scipy/generate-version with a custom command Build OK Task Error - build => PythonAction Error ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────── build ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ Traceback (most recent call last): │ │ File "/path/to/.local/lib/python3.10/site-packages/doit/action.py", line 461, in execute │ │ returned_value = self.py_callable(*self.args, **kwargs) │ │ File "/path/to/scipy/dev.py", line 668, in run │ │ cls.install_project(dirs, args) │ │ File "/path/to/scipy/dev.py", line 533, in install_project │ │ raise RuntimeError("Can't install in non-empty directory: " │ │ RuntimeError: Can't install in non-empty directory: '/path/to/scipy/build-install' │ │ │ ╰─────────────────────────────────────────────────────────────────────────────────────────────────────────── PythonAction Error ────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ Does it expect me to manually delete the build directory every time, or what? If so, that may raise a problem, because I had to build with "*python dev.py build -C-Dblas=blas -C-Dlapack=lapack"*, but it refuses to take those -C options with "python dev.py test -v". Honestly, it's strange that "test" would insist on the build directory being nonexistent in the first place. Perhaps I'm misunderstanding something. - kv, Karen _______________________________________________
SciPy-Dev mailing list -- scipy-dev@python.org To unsubscribe send an email to scipy-dev-leave@python.org https://mail.python.org/mailman3/lists/scipy-dev.python.org/ Member address: karen.robertsdottir@gmail.com