ENH: biteopt algorithm for global optimization

Is your feature request related to a problem? Please describe.
biteopt is a differential evolution like global optimizer which scored first in Scipy's benchmark suite in an extensive recent benchmark .
Besides great accuracy it is also very fast as it is completely implemented in C++: https://scipybiteopt.readthedocs.io/en/latest/Benchmark.html
A scipy.like API for biteopt is available at scipybiteopt based on this wrapper. The python wrapper is implemented based on Python's C API. Currently, the wrapper does not properly handle Python exceptions or errors. Maybe a ctypes or Cython wrapper would be a more robust alternative?
Describe the solution you'd like.
A function scipy.optimize.biteopt .
Describe alternatives you've considered.
No response
Additional context (e.g. screenshots, GIFs)
Using the same benchmarking code in the DIRECT PR, I get the following performance plots for biteopt: 180 solved problems. This is 13 more than for dual_annealing and direct which seem to perform best currently.

A first thought is that it'd be preferable (if it's decided to add the algorithm) to have the entire minimiser code base ported to Pythran/Cython/Python.

It seems to be a stochastic method, using a large amount of random numbers. We'd want to be using the numpy Generators for all RNG, and I don't know how easy it would be to plumb that in.
It seems to use Constraints (Nonlinear/Linear/Bounds), the port would have to be able to use the equivalent Python objects from scipy.optimize to specify the problem.
Whilst the CPP can lead to speed, it also leads to a significantly higher maintenance burden because it's harder to look after C++ code compared to Cython/Python. For example, it's very difficult to track down bugs in the minimize Fortran codebase.

biteopt implements its own LCG based random number generator. Inserting numpy's RNG will be quite a lot of work. Would non numpy RNGs be a blocker?
biteopt does not support linear or nonlinear constraints but only box constraints. The github readme lists a penalty method to add to the objective function . Making biteopt work with the Bounds class will be simple.
Also a complete rewrite of the algorithm will require an enthusiast with a big time budget

Sounds like this might be difficult in the short term. Let's leave this open for dicussion though.

For the RNG: if there is nothing special done, it should use the QMC generators we have in SciPy. Halton is flexible enough in terms of number of points and there is not anymore questions about convergence superiority over plain MC.

biteopt implements its own LCG based random number generator. Inserting numpy's RNG will be quite a lot of work. Would non numpy RNGs be a blocker?

QMC is a fine option to have, but I think users would expect the ability to use NumPy RNG. We did this sort of thing in gh-13330: biasedurn had its own RNG, and we made it possible to use either the old RandomState or new Generator RNGs. @mckib2, could you describe how (at a high level)?

Just to make sure we are talking about the same thing. I am only advising to use QMC if internally the optimizer needs to generate random numbers to generate a population (like in differential_évolution where we added QMC basically).

@mckib2, could you describe how (at a high level)?

We were lucky with biasedurn because it was written with swappable random backends in mind (for integration with R).  At a high level, what we did was implement a basic dependency injection scheme where we allowed assignment of rng functions (see base class function data members).  The integrator is responsible for setting these data member functions to numpy rng generators before use.
It looks like you could provide a new implementation for the CBiteRnd class that uses numpy and/or QMC under-the-hood.  The same dependency injection scheme would probably work here -- that doesn't seem too difficult to me, but you can't really say until you try :)

BiteOpt author here, stumbled upon this thread via websearch. "Better" PRNG won't make solver perform better. Just a waste of CPU cycles. Beside that, I've developed an astonishing PRNG myself (unlimited period), it also makes no sense to use it in BiteOpt. https://github.com/avaneev/prvhash
As for the C++ code maintenance, I do not think this is an issue as I do all C++ development myself. So far no bugs were reported while according to PyPI analyzer, some 300 biteopt installations (of another precompiled Python wrapper) are done per month.

BiteOpt author here, stumbled upon this thread via websearch. "Better" PRNG won't make solver perform better. Just a waste of CPU cycles. Beside that, I've developed an astonishing PRNG myself (unlimited period), it also makes no sense to use it in BiteOpt. https://github.com/avaneev/prvhash
As for the C++ code maintenance, I do not think this is an issue as I do all C++ development myself. So far no bugs were reported while according to PyPI analyzer, some 300 biteopt installations (of another precompiled Python wrapper) are done per month.

Also important to note (so that no misunderstanding happens) is that BiteOpt is in a broader "stochastic global optimizer" category, it's not Differential Evolution. DE-alike population generator is used, but it's a non-standard DE, no crossover and no usual popindex randomization is used. I do have DE-alike optimizer in BiteOpt project called deopt.h - maybe also worth a look, it's not bad.

Also important to note (so that no misunderstanding happens) is that BiteOpt is in a broader "stochastic global optimizer" category, it's not Differential Evolution. DE-alike population generator is used, but it's a non-standard DE, no crossover and no usual popindex randomization is used. I do have DE-alike optimizer in BiteOpt project called deopt.h - maybe also worth a look, it's not bad.

Why a better PRNG does not make a difference? The LCG used in BiteOpt passes 8MB window in PractRand. This is a lot more than necessary in a single optimization run.

Why a better PRNG does not make a difference? The LCG used in BiteOpt passes 8MB window in PractRand. This is a lot more than necessary in a single optimization run.

The discussion about replacing the PRNG is not about quality. It's about being able to use the same pseudorandom stream in all of one's code. In all of the other places scipy uses pseudorandomness, we use numpy's PRNG facilities. If we can at all avoid it, we do not want to introduce other PRNG facilities that the user will have to manage in other ways.

The discussion about replacing the PRNG is not about quality. It's about being able to use the same pseudorandom stream in all of one's code. In all of the other places scipy uses pseudorandomness, we use numpy's PRNG facilities. If we can at all avoid it, we do not want to introduce other PRNG facilities that the user will have to manage in other ways.

I would say that PRNG in BiteOpt is "self-contained". In biteopt_minimize() the same PRNG object is used over all attempts, so each attempt starts at some individual PRNG stream point yielding the same performance as reseeding individual PRNGs. Even if BiteOpt is ever implemented in multi-threaded manner, it is practically enough to init CBiteRnd with attempt/rerun index, nothing fancy is needed. But well, porting is not in my hands, so you can just "upgrade" the CBiteRnd class, its state variables and the advance function.

I would say that PRNG in BiteOpt is "self-contained". In biteopt_minimize() the same PRNG object is used over all attempts, so each attempt starts at some individual PRNG stream point yielding the same performance as reseeding individual PRNGs. Even if BiteOpt is ever implemented in multi-threaded manner, it is practically enough to init CBiteRnd with attempt/rerun index, nothing fancy is needed. But well, porting is not in my hands, so you can just "upgrade" the CBiteRnd class, its state variables and the advance function.

Hi @avaneev, thanks for dropping by.
The question to me for the PRNG is purely about space coverage properties. If the spread of points matter (like when you sample a new population for DE), then QMC would help. I am not talking about speed or memory footprint or anything else.

Hi @avaneev, thanks for dropping by.
The question to me for the PRNG is purely about space coverage properties. If the spread of points matter (like when you sample a new population for DE), then QMC would help. I am not talking about speed or memory footprint or anything else.

I do not think QMC will improve the method. E.g. if we are talking about 20-dimensional problem and a population size between 60 and 200, population sampling is so sparse relative to the problem's possible surface there's no difference in sampling method.

I do not think QMC will improve the method. E.g. if we are talking about 20-dimensional problem and a population size between 60 and 200, population sampling is so sparse relative to the problem's possible surface there's no difference in sampling method.

I do not think QMC will improve the method. E.g. if we are talking about 20-dimensional problem and a population size between 60 and 200, population sampling is so sparse relative to the problem's possible surface there's no difference in sampling method.

On the contrary 200 points in 20 dimensions is well enough to show QMC's benefits. If you try to construct a response surface (with RBF, PC or GP for instance) you will see that it makes a huge difference.

I do not think QMC will improve the method. E.g. if we are talking about 20-dimensional problem and a population size between 60 and 200, population sampling is so sparse relative to the problem's possible surface there's no difference in sampling method.

On the contrary 200 points in 20 dimensions is well enough to show QMC's benefits. If you try to construct a response surface (with RBF, PC or GP for instance) you will see that it makes a huge difference.

Maybe, if it's DE with 20*Dims, or in the thousands (there are some DE variants that converge extremely slowly and sample thousands of points, in an attempt to do "exhaustive" search). BiteOpt's popsize formula is 13+3*Dims. It really is not worth it, even the distribution of sampling does not play a role - I've extensively experimented with uniform, box, Gaussian. Just no measurable difference on big testsets. BiteOpt is not a pure DE - it has "random moves", not just "mutations". Sampling in DE may be important as it derives solutions from the sampled population. As I've replied earlier, there should be no misunderstanding that BiteOpt is not DE.

Maybe, if it's DE with 20*Dims, or in the thousands (there are some DE variants that converge extremely slowly and sample thousands of points, in an attempt to do "exhaustive" search). BiteOpt's popsize formula is 13+3*Dims. It really is not worth it, even the distribution of sampling does not play a role - I've extensively experimented with uniform, box, Gaussian. Just no measurable difference on big testsets. BiteOpt is not a pure DE - it has "random moves", not just "mutations". Sampling in DE may be important as it derives solutions from the sampled population. As I've replied earlier, there should be no misunderstanding that BiteOpt is not DE.

I will wait to see a PR and try to experiment then 😃 Thanks for the discussion.
I could understand that you did not see much difference with different distributions if the samples were from some kind of MC. MC is just extremely bad as the dimensionality grows and sampling a Gaussian or a uniform could lead to the same samples with a low number of points. It's similar to an integration problem in nD, exactly what QMC was made for and is known to have at worst the same convergence rate. (p.s. I am only talking about DE because we enabled use of QMC in SciPy's implementation. My comments are more general about sampling a small population in nD).

I will wait to see a PR and try to experiment then 😃 Thanks for the discussion.
I could understand that you did not see much difference with different distributions if the samples were from some kind of MC. MC is just extremely bad as the dimensionality grows and sampling a Gaussian or a uniform could lead to the same samples with a low number of points. It's similar to an integration problem in nD, exactly what QMC was made for and is known to have at worst the same convergence rate. (p.s. I am only talking about DE because we enabled use of QMC in SciPy's implementation. My comments are more general about sampling a small population in nD).

I think QMC as a solution to sampling depends on the optimization method. DE or Nelder-Mead, whose solution generation depends on the diversity of initial population it may be useful, but even if so, it should be some "special" quasi-randomness, tuned to subsequent "derivations" via mutation operations like x0+(x1-x2)*0.5. Other methods like CMA-ES (and my SMA-ES) that continuously generate diverse populations, a usual PRNG is sufficient. The problem of DE is that with a small population it quickly runs out of candidate solutions.

I think QMC as a solution to sampling depends on the optimization method. DE or Nelder-Mead, whose solution generation depends on the diversity of initial population it may be useful, but even if so, it should be some "special" quasi-randomness, tuned to subsequent "derivations" via mutation operations like x0+(x1-x2)*0.5. Other methods like CMA-ES (and my SMA-ES) that continuously generate diverse populations, a usual PRNG is sufficient. The problem of DE is that with a small population it quickly runs out of candidate solutions.

@avaneev It looks like you've written that integrality constraints can be added simply by rounding the decision variables. I know it might not be efficient, but currently, we don't have any global optimizers that claim to handle integrality constraints. It would be helpful to have something.
Does it sound good to add integrality (boolean array same shape as decision variables x) as a parameter of the SciPy wrapper? The intent is for the wrapper to do the rounding before passing the decision variables into the objective function, e.g. x[integrality] = np.round(x[integrality]). It is easy enough for the user to round, but users familiar with gradient-based optimizers, for instance, would hesitate to do so.
Would a simple approach like this be reasonable with any of our other global optimizers?

@avaneev It looks like you've written that integrality constraints can be added simply by rounding the decision variables. I know it might not be efficient, but currently, we don't have any global optimizers that claim to handle integrality constraints. It would be helpful to have something.
Does it sound good to add integrality (boolean array same shape as decision variables x) as a parameter of the SciPy wrapper? The intent is for the wrapper to do the rounding before passing the decision variables into the objective function, e.g. x[integrality] = np.round(x[integrality]). It is easy enough for the user to round, but users familiar with gradient-based optimizers, for instance, would hesitate to do so.
Would a simple approach like this be reasonable with any of our other global optimizers?

Yes, BiteOpt handles discontinuous variables acceptably. And a little number of boolean variables at the same time. But such variables, if they were discretized to only a few possible states, transform the problem into a combinatorial problem which BiteOpt and likely any other continuous method can't solve well. So, I would say BiteOpt can handle "discretized" continuous variables.

Yes, BiteOpt handles discontinuous variables acceptably. And a little number of boolean variables at the same time. But such variables, if they were discretized to only a few possible states, transform the problem into a combinatorial problem which BiteOpt and likely any other continuous method can't solve well. So, I would say BiteOpt can handle "discretized" continuous variables.

scipy would have the advantage to use code which is actively being developed. If a PRNG backend agnostic version of biteopt is required, it would be harder to benefit from upstream updates. Still, if numpy RNGs are a strategic decision for scipy as users and depending libraries are very much used to them, that should have higher priority after all. While we are it: Maybe the importance of numpy PRNG should then also be prominent in the developer docs (might have missed it too).

scipy would have the advantage to use code which is actively being developed. If a PRNG backend agnostic version of biteopt is required, it would be harder to benefit from upstream updates. Still, if numpy RNGs are a strategic decision for scipy as users and depending libraries are very much used to them, that should have higher priority after all. While we are it: Maybe the importance of numpy PRNG should then also be prominent in the developer docs (might have missed it too).

Here's an example of BiteOpt use in mixed-integer optimization, by Dietmar Wolz, an active participant of space trajectory optimization competitions. BiteOpt is fast at finding "good" solutions, and only slightly worse with an unlimited time budget (not the case in fast-paced competitions). Scipy's DE is basically unusable for this sort of applications.
https://github.com/dietmarwo/fast-cma-es/blob/master/tutorials/Scheduling.adoc

Biteopt clearly performs well enough (on our benchmarks and in other places) that it'd be great to have in SciPy.
The two key issues for integration are:

Random number generation, can numpy.random be used or not (the QMC discussion is less relevant, the critical point is the one @rkern made in https://github.com/scipy/scipy/issues/15298#issuecomment-1003504621)
Maintenance burden of including a significant amount of vendored C++ code.

(1) is discussed enough above (someone should try this as @mckib2 said), so I'll focus on (2). As @andyfaff said, maintenance issues can be quite painful when we integrate external C/C++/Fortran code bases. We are currently a month behind releasing 1.8.0 because we're having issues with exactly that. The recent additions of HiGHS, UNU.RAN and PROPACK have been a strain on build times as well, in addition to the segfaults and other issues. Those things are also draining to deal with for maintainers. So we should we careful here.
The code is in okay-ish but not great state, it's ~3500 lines of C++ code (based on the setup.py file in the repo) which doesn't look overly complicated, however it has no CI and one of the header files included in setup.py is missing from the repo. Maybe the setup.py is wrong though, since only biteopt.h is used in https://github.com/leonidk/biteopt/blob/master/biteopt_py_ext.cpp?
That the code is actively maintained and improved is a significant plus, as is the fact that @avaneev shows up here to participate. The former means it does not make sense to translate the code to Cython/Pythran - and C/C++ with a thin wrapping layer is actually preferable anyway once code gets over a certain level of complexity.
@dschmitz89 you've been fairly active recently, working on multiple optimizers - if you'd want to help maintain the added code, that would certainly be helpful here too.
Given that biteopt seems to outperform all other optimizers in our benchmarks, I'd be +1 on including it. It looks like this requires:

Integrating it with the SciPy build system and ensuring it builds without warnings (the existing C++ Python bindings seem fine to me, those could be replaced with Cython if desired)
Adding the Bounds constraints
Making the random number generation use numpy.random functionality
Tests & benchmarks (and checking test coverage)

What would also be helpful is to modernize the upstream code a bit. Just running it through clang-format would be great, the style is currently slightly jarring. I just tried on biteopt.h - it gets 200 lines shorter, and much easier to read.

Sorry for off-topic, but the style clang-format creates is a "common denominator" style. First, it does not look good without a syntax highlight, and secondly, it turns constructs like after const int SelMethod =... into uncomprehensible layers of ifs(). But who am I to oppose community?
Just for perspective, I have 20 years of full-time C++ experience. Also, generalizing problems with C++ code with some packages to other instances of C++ code is not a great idea.

@avaneev styles and tastes about styles vary, and there's probably not much point arguing about them. It's just that if we incorporate this code, it'd be preferable if it didn't look very foreign and therefore much harder to read to people who are used to "regular" or "common denominator" style.

Also, generalizing problems with C++ code with some packages to other instances of C++ code is not a great idea.
...
As for the C++ code maintenance, I do not think this is an issue as I do all C++ development myself. So far no bugs were reported while according to PyPI analyzer, some 300 biteopt installations (of another precompiled Python wrapper) are done per month.

You do have to realize that when we incorporate this code, it's going to go from 300 installs/month to 30,000,000 installs/month. So you're going to get the weirdest bug reports, on hardware platforms you don't have access to, and on corner cases you may or may not personally care about. The level of support we have to offer is unfortunately painfully high.

Well, 300 installs/month without issues is a good indicator 30mln installs/month won't cause a trouble if supplied in binary form. If supplied in source code form it's another story as some systems may have an outdated C++ compiler. My other open-source C++ projects range from 1000 to 6000 installs/month, and even in source code form they generate no issues. In commercial field I have 100000 binary installs per month, across Windows and Mac OS.
Not that this matters much, but I think you can rely on my experience at least. If there are bugs discovered, they will be fixed.

If supplied in source code form it's another story as some systems may have an outdated C++ compiler.

Yes, unfortunately we have to support both packagers and end users with the most niche configs. xlC on AIX, mingw on Windows, custom compilers for HPC systems and cross-compiling, etc.

Not that this matters much, but I think you can rely on my experience at least. If there are bugs discovered, they will be fixed.

Thank you, much appreciated.
Okay, I think the point on maintenance is clear. We do want to integrate biteopt, however there's a bit of work to be done for points 1-4 above and someone will have to do that.

While we are it: Maybe the importance of numpy PRNG should then also be prominent in the developer docs (might have missed it too).

This is a separate thing to do, would indeed be nice to add a section on this at http://scipy.github.io/devdocs/dev/api-dev/api-dev-toc.html.

Yes, unfortunately we have to support both packagers and end users with the most niche configs. xlC on AIX, mingw on Windows, custom compilers for HPC systems and cross-compiling, etc.
I have this covered in my practice as well: I simply do not use C++ features beyond C++98 in my code; yes, not even STL, which increases compile times considerably (e.g. Eigen is a bad practice C++ IMO). As you can imagine, several thousands of C++ source code installs end up in very diverse developer workflows. Not to mention the compiled code ends up in millions of binary installs.

Sorry to continue a talk about the "coding style". (maybe I just want to better understand this aspect myself; not expecting a reply or trying to change community standards). In C/C++ world the coding style is usually unimportant since fixing upstream or even co-worker's bugs is hard or fruitless, if we are talking about systemic or algorithmic bugs, not just memory-sanitizer-reachable bugs. A community-driven C++ project may require a specific coding style, and that's understandable. Previously, I've come across PHP community that required a specific coding style, but I wasn't impressed since if one ever dealt with including many third-party C/C++ libraries one would immediately understand that "coding style uniformity" is unreachable.
To be more specific, while it's likely a memory-bound bug in Biteopt can be fixed by most community members, a systemic issue like inability to solve some objective function just because bounds used were "a bit off" would require author's involvement. So, from this perspective, coding style is just a "feel good" aspect, not a guarantee of maintainability.

@dschmitz89 , if you need assistance integrating Numpy into BiteOpt PRNG, please post an issue at the BiteOpt page, or contact me directly via<EMAIL_ADDRESS>. I do use Python myself, but only sparingly (e.g. for SAT solvers available for it), thus I myself would need assistance to integrate Numpy RNGs, and I'm just unaware of SciPy users' specific needs, so maintaining a Python-BiteOpt wrapper myself is out of the question to me.

@avaneev thanks for the offer. I do not think I will have time to look into this deeply anytime soon though. Would like to focus my spare time on a bit easier SciPy stuff like the DIRECT PR and documentation overhaul. My C skills are very much lacking unfortunately: my extension of the biteopt wrapper already produced a memory leak which was fixed by another contributor some days ago.
Regarding the PRNGs: if numpy PRNGS are included, would SciPy still be able to easily update the biteopt source?
Random thought: could this be an GSoC project?

@dschmitz89 , as for the numpy PRNGs I basically need to know the way it is interfaced from C/C++ code. Currently, the CBiteRnd class is non-virtual, and this information will help me to virtualize some parts of it. Then on your side it will be just a matter of writing a simple C++ class derived from CBiteRnd, and updating other parts of the wrapper to make PRNG type switchable; BiteOpt source update will not be required afterwards. However, just a virtualization of CBiteRnd class increases algorithm's overhead by 5-10% at least; as I've mentioned above, it's a bit of a waste if numpy PRNGs are not often needed.
In overall, I'm not in a hurry nor in a thirst. However, as it seems to me (from unexpectedly getting method's mention in Nature Cancer paper), there is a very thin line between not-so-good to great results if a model to be solved is a bit more complex than usual. So, it's a honor to offer a method that allows teams to have things going forward, in modern competitive science. But I'm not a "science guy" myself, so even citations are of no much use to me.

I'm willing to bet that the overhead of calling the Python objective function (safely handling exceptions, etc.) overwhelms any overhead involving the PRNG.
The relevant documentation on calling the numpy PRNG from C/C++ is here. Basically, you can boil it down to getting a void * state pointer and a uint32_t (*next_uint32)(void *st) function pointer that you can use to implement CBiteRnd::advance(), more or less.
Ultimately, I won't care too much if the biteopt implementation uses its current PRNG internally as long as the Python wrapper derives the seed for CBiteRnd by drawing from the numpy Generator that the user passes in. That lets the user control all of their pseudorandomness consistently if it's too difficult to make CBiteRnd draw from the numpy PRNG directly.
def biteopt(fun, bounds, args=(), ..., seed=None):
    ...
    rng = np.random.default_rng(seed)
    cbite_rnd_seed = rng.integers(1<<31)  # pull out a C signed int to seed CBiteRnd
    ...

But it will simplify user's mental model of how things work if CBiteRnd is actually drawing numbers from the numpy PRNG directly, so I will suggest to whoever is implementing this to try that first.

@rkern I'll study the docs on numpy PRNG calls. At first glance, it's not obvious if numpy uses approximations of distributions on top of some "core" uniform PRNG, and if other distributions are obtainable from the same numpy RNG object. BiteOpt makes use of both uniform and normal/Gaussian distributed random numbers, using the fastest approximation I could find. I guess I'll need to virtualize gaussian function as well, just in case.
On "expensive" functions, my understanding is that it's an important, but small class of problems; e.g. most problems from MINLPLib, PrincetonLib and the like "de facto standard" benchmark testsets are not expensive. Even GTOP space trajectory problems (also "de facto" by now) are not expensive to calculate, but being in the class of N-body problems, they are extremely complex, and the overhead shifts to optimizer's side considerably.

(I've rechecked the gaussian PRNG function, I've missed mentioning the source of adopted code: "Leva, J. L. 1992. "A Fast Normal Random Number Generator", ACM Transactions on Mathematical Software, vol. 18, no. 4, pp. 449-453". Will update BiteOpt; all other code is original, except in parts it may have similarities to e.g. DE or Nelder-Mead, or some genetic code, but I guess it's too broad match to reference any specific source, also DE to me is practically a simplified, non-state-automata, Nelder-Mead)

(BiteOpt as a whole is something like "probabilistic state-automata", to call it in a freeform way, but it may not be science-worthy, "not well understood", may not be generalizable as much as plain DE, for example, as I needed to solve my own complex "black-box" problems, without being limited by scientific "tree of knowledge" or "state of the art")

(Also worth mentioning SpherOpt that I've implemented as a parallel optimizer for BiteOpt: SpherOpt samples points on a hyper-sphere which converges to a point eventually, much like a circle in the online game called Fortnite; no idea why it actually works as "feature exploration" aspect in this method is very limited; maybe other venues in derivative-free methods still exist which may allow derivative-free methods to surpass analytic solvers like BARON, CPLEX and others, at least in medium dimensions)

It's not important to me for biteopt to use our implementations of Gaussian distributions, etc., though they are available as functions to call. The main thing is the state manipulation.

I've updated BiteOpt: instead of virtualizing CBiteOpt I've went "C" way so that a function pointer can be passed via the biteopt_minimize() function, so it should be fairly easy to integrate uniform numpy RNG. This approach also did not increase overhead too much compared to virtualization.

Perfect!

(sorry for a bit of off-topic again, but I have to tell this. even though, there's no way for me to know if BiteOpt will make it to Scipy or not, if you decide to include BiteOpt, you may need to evaluate a bit of my personal view about science. I'm a huge fan of research, especially in the field of computing, but I'm not happy about science as a whole, its "pyramidal" and "sponsored" structure (sorry, but it's a church's organizational model), and on the outside it's commercialized for outsiders-I can't download most research papers freely; "garbage", but well-marketed journals, from time to time send me invitations to publish research for $1000. Also, "sponsoring" means granting resources to one project and rejecting "not sound" another: how anyone knows in advance what would it reap? what if sponsor is interested in a particular beneficial world-model? I'm mostly happy I did not take a route to attain PhD that was offered by my alma mater. And I'm not particularly a nice guy in some situations. It's not about people, it's about science, which is now called "scientism" at times. Possibly, this is all irrelevant as I have no "voice" anyway. On the other hand, GitHub is much better and psychologically rewarding, be the participants officially scientists or not)

This note is not exactly an off-topic as I want to make some justice to Nelder-Mead since I think it's under-researched.
I've come across optimiazation methods in 2005, at the time I had a choice between NM, some DE implementation and some genetic method if I'm not mistaken (Deb, K , Anand, A., and Joshi, D (April, 2002). A Computationally Efficient Evolutionary Algorithm for Real-Parameter Optimization. KanGAL Report No. 2002003). At that time I was only a "user", without any clue of how they worked. It was much later, and it was a much more complex problem (choosing parameters of image resizing system which is a complete black-box and very expensive to evaluate) when I started my research in the optimization.
NM implementations I've later studied in-depth use a term "simplex", this applies to Scipy as well:
"initial_simplex:array_like of shape (N + 1, N)" (https://docs.scipy.org/doc/scipy/reference/optimize.minimize-neldermead.html)
A probable issue it was specified and tested that way by the origin. Maybe even my reference to NM as "state-automata" (there was no "automaton" at the time, why not "automatum"?) are not exactly understandable. If in doubt, you can check my "state-automatized" NM implementation in "nmsopt.h". It's the same NM, just a considerably rearranged code.
The core of the issue is that "simplex" is not actually something special, it's just a population, and it can be resized to any size. In "nmsopt.h" it's (N+1)*4 by default.
When initialized with a Gaussian sampling and larger population, Nelder-Mead is a very potent global optimizer with a very fast convergence - calling it "local optimizer" does not make it justice. If several retries are made, and a better population formula is used, it's as good as an average DE and CMA-ES, at least in up 20 dimensions. If I'm not mistaken on how science works, both DE and CMA-ES would not have gained tracktion and would have not got resources being unable to compete with the "state of the art". (I'm wondering, who would pay me 1.5 years worth of scientist wage for something perceptively "silly" like prvhash)

I would add that it's extremely lame for a scientist not to specify algorithm without version, and not providing a call in wrapper to get the version. I thought science seeks precision and fights false claims.

I've added the BITEOPT_VERSION macro to further reduce chances of false claims. In case "plaglobal" balance of forces changes, whatever that means. I do not know what D.Wolz does, maybe tries to prolong relevancy of DE and CMA-ES. There was no generally-agreeable "standard" method was set. Since 1965 I think? At least scientists would argue between each other. BBOB/COCO designed by CMA-ES author, are you kidding?

@avaneev I appreciate your frustrations, but they do not appear to be related to @dschmitz89's efforts here. Certainly, if you have some specific requests about how to integrate your code into scipy (like exposing the precise version number of the algorithm used), those are perfectly reasonable requests to make here if made explicitly. I had to read between the lines to guess at what you actually wanted us to do about it. If you have complaints about how your code has been integrated into dietmarwo/fast-cma-es, venting about it here in this manner will not achieve anything to your benefit.

Well, I'm not seeking for a "benefit", I've already benefitted from BiteOpt and just do not have any other practical problems to solve. And I'm venting about a lot more important things, if anyone understands or cares.
Like if outsiders experimented enough to know Earth is flat, and the official science tells its a globe, a second Einstein would not be able to raise to prominence in scientific world to build a space curvature model that unites both perceptions. Even if it's not hard at all.

As for the version number, you may decide yourself, if my point was reasonable enough. I've just added a C macro. I'm here to do what you will tell me, not the other way around. I venting, because I have nowhere else to vent.

Specifically, I meant that venting here about how BiteOpt has been evaluated in the documentation of dietmarwo/fast-cma-es will do nothing to change how it has been evaluated. You can open an issue there, or talk about it in your own documentation, or start a blog. You do have a lot of options to communicate things that are off-topic here.

I've only made a remark how fast-cma-es might be presented. Cherry-picked problems, why not?
I think it would be actually beneficial to community to include fast-cma-es into scipy, if what is claimed is true - multi-threaded parallel retry out of the box, and if it's not yet implemented, a cloud-computing based parallel retry that can utilize 1000 nodes simultaneously, on the same problem, out of the box. I do not care if it will be "biteopt in fast-cma-es in scipy" or "biteopt in scipy". Also it would be better if version of each algorithm was obtainable.
Just giving ideas to community.

Biteopt is now at version 2022.5, and according to my tests e.g. 2022.1 is measurably "not the state-of-the art" anymore. Biteopt version is not specified. Hence, personally I just do not know what to think, maybe it's 2018 version which is considerably "not the state-of-the art".

You seem to be addressing people who are not here in response to statements never made here. This is not an appropriate forum for the discussion you seem to want to have on this subject.

I'm sorry for seeming spamming, but points I'm making are hardly discussable anywhere. I'm in a mode like I'm writing a paper to include in some basically "garbage bin worthy" journal for $1000. Not discussing and not expecting a reply. Let it be archived later. It's cheaper by $1000, with the same outcome.
As for fast-cma-es, I've pointed the author to a stopping criteria feature in BiteOpt to my disadvantage. He made it fixed, unswitchable. I've created https://github.com/dietmarwo/fast-cma-es/issues/10 if anyone cares.

This is not an appropriate forum. I am asking you to stop. You may write about whatever you want on your own repo or blog. If it's "hardly discussable" in those forums, it is not at all discussable here. Thank you.

Okay, I'll stop. But I've noticed an interesting logic: if it's not discussible there, then it's not discussible here.

Overly elliptical phrasing on my part. "If your issues about how BiteOpt is integrated into fast-cma-es is "hardly discussable" on the fast-cma-es repo or the biteopt repo or any other communication platform that you might have editorial control over like a blog, then it is not discussable here, an unrelated repo".

Hm. I think I've posted much more than "biteopt in fast-cma-es-related issues". Seems like you are somehow not wanting to refer to posts other than "biteopt in fast-cma-es-related issues"? But anyway, I won't continue. Don't want to hear "stop posting bullshit".

Thank you. I can clarify more if you like in private email (address in my Github profile), but we can leave that off of here as the meta-discussion is also off-topic.

I just want to mention that I'm not a novice in writing "garbage journal-quality papers", so I'm not just telling that figuratively. A bit of self-promotion: https://vixra.org/author/aleksey_vaneev
It's worth to note a recent geomagnetic storm that floored Starlink satellites. That's plasma from Sun if I'm not mistaken. Unpredictable sattelite fall-off: unknown gravity perturbations. That's what one of my papers assumes-plasma can create gravity.
A paper about "energy", if experiment can be replicated at all, would just destroy all energy business worldwide.
Junk science, of course.

This is a constructive idea to the community.
When someone tells you CMA-ES is "fast", check the complexity analysis of "Symmetric tridiagonal QL algorithm", or something 100% equivalent that has less complexity. It's what makes CMA-ES uncompetitive on higher-dimensional non-expensive problems. SMA-ES is a result of my deconstruction of CMA-ES and then reconstruction using my own ideas. Source of creative inspiration, if scientists talk that way at all.

You are continuing to be off-topic after promising to stop. This is not your personal blog.

Or saying softer, you may simply unsubscribe. When a topic turns into a wrong direction, I usually just unsubscribe from updates.

Just that you know, I'm officially diagnosed with "paranoid schizophrenia" in Syktyvkar's (my native city) psychiatric system.  Legally in Russia, what I do or say can be interpreted as behavioral disorder, unless, of course, I do some unlawful things.
So, unfortunately, what I do or say may cause schizophrenia symtpoms in others, because I overcame the "disease" without anyone's help, and neuroleptics just made things worse (not taking them for quite a while already). The root case of schizophrenia is "cognitive dissonance", it can be so great that psychosis is imminent (it's a relief actually, resetting all cognitive stress). Any professional can induce it (so that you now) depending on his level and the level of "bullshit" barriers of a victim. Some psychiatrists want to know one's life completely, which is not exactly logical.
This is not exactly a nice "bullshit" I know, but you can close a topic, really. If you thought that I want 'scipy' intergration, you are not exactly right. I want to talk to people, like any schizophrenic wants, but can't - the disorder can be so great the speech becomes completely unintelligible gibberish. And I think some psychiatrists can "educate" a victim to shift to such "style".

This issue does not belong to you. Yes, I certainly have the authority to close it, but the issue that @dschmitz89 opened is perfectly on-topic and appropriate; you have hijacked it with your off-topic comments. Blocking you and you alone would be the next step if you persist. You have shown that you are perfectly capable of identifying when your comments are off-topic (you labeled them so) and you have been told that the off-topic comments are unwelcome and promised to stop.

(I myself speak intelligible Russian, of course, but I witnessed an psychiatrical attempt, can't prove it, so treat it as an information)

It's called don't give a microphone to a guy you do not know exactly well. Sorry, that's life, we all want to survive.

Just took a photo on my iPhone 12, it's a relief to show it to people that are least know my work.

I do not have a problem with psychiatry myself, the laws are just in Russia in this matter. But you are going to be classified a schizophrenic to the end of your life, which is not exactly right. It's a worldwide problem.

I think "schizophrenics" that talk "unintelligible gibberish" can be healed - I witnessed they can say an intelligible phrase that does not dissonate with my perception of reality. To me it feels like medical science wants to silence such people (check the life expectancy adjustments of schizophrenics' population). The VERY first dose of mouth-dissolvable Olanzapine (Zyprexa), AFAIR, completely disorganized contact of my thought with my vocal tract. But I recovered after some time: not all brains are created equal, it's a basis of evolutionary theory. But I think I'm not the only one, of course, some are untrained or turned into complete human bullshit: populations evolve in cycles, that's why civilizations fall and any prior form of control falls apart.

Talend

Whatever that means. "Dietmar Wolz/Woltz" mentioned it.

Complete, full loss of sight, a cancer of eyes, is the real, experienced lifetime fear, mainly for complete control freaks that rose to power. No need to wonder what a "black hole" is: Project-ion of fear to everyone in a hope somebody solves the problem and shares with everyone. It is an inbuilt populational protection mechanism. Some turned blind already during our lifetimes and were easily removed from the scene by forces noone knows about.

I witnessed that local psychiatrists, somewhere around after 2011, told me a lie that I told them that I have a "black hole" in my stomach. Do not wonder why.

Companies like Gogel may hope that a programmer's "work of art" they have bought hiring them has an unlimited timespan of copyright. While in a sane law system author's rights last for a specified timespan after his death, and then author's rights become "public domain" that, of course, cannot be copyrighted (otherwise it's schizo). It's usually too long in the current situation (70 years in some countries). Even if GGL hopes to have a copyright indefinitely, he can be duped to believe so by "deaths". CORPO-RATS. Even companies turn into shitty living organisms emanating decay from unknown reality.

QoS, you know. ... a feeling something goes wrong, and may probably kill you in real life

Like a nurturing and helping REAL mother... it's cognitive dissonance, a schizo.

This issue has been brought to the attention of the Code of Conduct Committee. We want to acknowledge this is a difficult issue. The discussion here clearly has gone off-topic, and despite that being pointed out and being asked to stop, @avaneev hasn't stoppped posting. That said, we believe @avaneev isn't intentionally trying to harm anyone else here, and may have legitimate medical problems - we are not qualified to address those, but nevertheless will reach out privately to @avaneev for dialogue.
Regarding this issue, our opinion is that the initial feature request and part of the discussion that followed it has value, however the issue now is too polluted to be useful. We will therefore close this issue and lock discussion, and we will summarize the useful parts in a new issue. We ask @avaneev and all other participants to please keep discussion on that and other issues on-topic, and respect our code of conduct.


I can not remove an extension

I have problems with brackets, when I do a live, it falls and when I remove an extention I can not delete it on reboot qeda there.

What operation system do you use? Windows, OSX, Linux?

in windows, but it discovered that the virus does not let the application run well so you uninstall it is, adaware

In windows, goto explorer > %appdata% and then delet the brackets folder. This would reset brackets to original state.


Framer-motion 5 support

Update peer dependency to support Framer 5
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>|| 3.x || 4.x" from<EMAIL_ADDRESS>

Fixed in v1.4.2


How to set xhr.withCredentials?

Hi guys, first of all, amazing work with this project!
What do I need to do to inject xhr.withCredentials? Any idea? I looked at the source code but I can't seem to find the connection between the request builder and the xhr object. Please help :)

Currently there is no way to set this. Would make sense to have it. Would you like to take a shot at it?

Hi @basti1302 had a crack at it, hope all is fine, added tests and build is passing.

This has landed in release 3.1.0


Counter+ soft locking in fpfc

When getting into Counter+ menu with the fpfc (steamVR) vers, nothing is clickable and you cannot go back, resulting in soft locking you on the Counter+ menu (actually I wanted to access it without my headset so I could esaly change my set up for replays)
The Counter+ Log :
_latest.log
The BeatSaber Log :
_latest.log
if any other details needed I may be able to add up.

Hi, according to the logs that you provided, this is not a Counters+ error. Rather, this appears to be errors resulting from one (or more) mods that cascade down to the Counters+ menu, which softlocks the game.
[ERROR @ 20:51:19 | BS_Utils] Caught Exception when executing event: Exception has been thrown by the target of an invocation.
[ERROR @ 20:51:19 | BS_Utils]  In Assembly: BeatSaverVoting, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[DEBUG @ 20:51:19 | BS_Utils] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
[DEBUG @ 20:51:19 | BS_Utils]   at BeatSaverVoting.Plugin.BSEvents_gameSceneLoaded () [0x00010] in <ab2b8cc00c774f4689036030820aecc0>:0
[DEBUG @ 20:51:19 | BS_Utils]   at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]    --- End of inner exception stack trace ---
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00048] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x000e7] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x00008] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at BS_Utils.Utilities.BSEvents.InvokeAll (System.Action action, System.Object[] args) [0x00042] in <e63997fdc82e4dadb4f96d64c805074a>:0
[ERROR @ 20:51:19 | BS_Utils] Caught Exception when executing event: Exception has been thrown by the target of an invocation.
[ERROR @ 20:51:19 | BS_Utils]  In Assembly: BeatFollower, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[DEBUG @ 20:51:19 | BS_Utils] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
[DEBUG @ 20:51:19 | BS_Utils]   at BeatFollower.Services.EventService.BSEvents_gameSceneLoaded () [0x0000a] in <d1dbf90946ba414da68e8acb8166a495>:0
[DEBUG @ 20:51:19 | BS_Utils]   at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]    --- End of inner exception stack trace ---
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00048] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x000e7] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x00008] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at BS_Utils.Utilities.BSEvents.InvokeAll (System.Action action, System.Object[] args) [0x00042] in <e63997fdc82e4dadb4f96d64c805074a>:0
[ERROR @ 20:51:19 | DataPuller] System.NullReferenceException: Object reference not set to an instance of an object
[ERROR @ 20:51:19 | DataPuller]   at DataPuller.MapEvents.BSEvents_gameSceneLoaded () [0x00047] in <6bab6d00ea9947f082625a105d0f287f>:0

I would personally contact the authors of the DataPuller mod, the BeatFollower mod, and the BeatSaverVoting mod, preferably in that order.
Counters+ uses the Tutorial environment as the background, and when mods do not properly take this into account, they break, which cascades into the Counters+ menu.

Hi, according to the logs that you provided, this is not a Counters+ error. Rather, this appears to be errors resulting from one (or more) mods that cascade down to the Counters+ menu, which softlocks the game.
[ERROR @ 20:51:19 | BS_Utils] Caught Exception when executing event: Exception has been thrown by the target of an invocation.
[ERROR @ 20:51:19 | BS_Utils]  In Assembly: BeatSaverVoting, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[DEBUG @ 20:51:19 | BS_Utils] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
[DEBUG @ 20:51:19 | BS_Utils]   at BeatSaverVoting.Plugin.BSEvents_gameSceneLoaded () [0x00010] in <ab2b8cc00c774f4689036030820aecc0>:0
[DEBUG @ 20:51:19 | BS_Utils]   at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]    --- End of inner exception stack trace ---
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00048] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x000e7] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x00008] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at BS_Utils.Utilities.BSEvents.InvokeAll (System.Action action, System.Object[] args) [0x00042] in <e63997fdc82e4dadb4f96d64c805074a>:0
[ERROR @ 20:51:19 | BS_Utils] Caught Exception when executing event: Exception has been thrown by the target of an invocation.
[ERROR @ 20:51:19 | BS_Utils]  In Assembly: BeatFollower, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[DEBUG @ 20:51:19 | BS_Utils] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
[DEBUG @ 20:51:19 | BS_Utils]   at BeatFollower.Services.EventService.BSEvents_gameSceneLoaded () [0x0000a] in <d1dbf90946ba414da68e8acb8166a495>:0
[DEBUG @ 20:51:19 | BS_Utils]   at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]    --- End of inner exception stack trace ---
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00048] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x000e7] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x00008] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0
[DEBUG @ 20:51:19 | BS_Utils]   at BS_Utils.Utilities.BSEvents.InvokeAll (System.Action action, System.Object[] args) [0x00042] in <e63997fdc82e4dadb4f96d64c805074a>:0
[ERROR @ 20:51:19 | DataPuller] System.NullReferenceException: Object reference not set to an instance of an object
[ERROR @ 20:51:19 | DataPuller]   at DataPuller.MapEvents.BSEvents_gameSceneLoaded () [0x00047] in <6bab6d00ea9947f082625a105d0f287f>:0

I would personally contact the authors of the DataPuller mod, the BeatFollower mod, and the BeatSaverVoting mod, preferably in that order.
Counters+ uses the Tutorial environment as the background, and when mods do not properly take this into account, they break, which cascades into the Counters+ menu.


Forking guncoin

hey Dev, if I want to fork guncoin, what parameters and variables etc must be changed to be on a new blockchian and file names please?

There's a pretty clear commit history converting Bitcoin to Guncoin, follow that to see exactly what needed to be changed do a similar process.


Inventory and host entity not updated when account/license_key is changed

We've seen some issue where inventory information is outdated or host is not visible in the Entity Explorer UI.
We suspect that changing the license_key is affecting both behaviours.
Steps to Reproduce

Have an agent running using license: AAA, ensure host is visible in UI, host inventory is collected, etc.
Stop the agent and change license to BBB
Restart the agent and verify inventory and entity explorer UI
Current behaviour: it seems only inventory deltas as submitted and host is not visible in UI

Your Environment
Reproduced on linux (Ubuntu 20 and RHEL 8)
Alternative
In order to fix this scenario, removing the data folder (var/db/newrelic-infra/data on linux) and restarting the agent should solve the issue.

This behavior also occurs on Windows (tested on Windows Server 2019) and requires deleting C:\ProgramData\New Relic\newrelic-infra\data.


Submission 1 Review

Bases.py works as expected. If you can avoid using the ** operator or the pow function it can make it slightly more efficient.
You can incrementally increase what you multiply the base by setting a value to multiply each number by, starting at 1, then multiplying the current multiplier by the base after each digit. So the first iteration is base^0, then base^1, then base^2, and so on, without repeated calculation.
Recursive binary search is not working, as there is no base case for when the item is not found. One possibility is considering what happens when the range of items is 0 or 1, and what to do then.

its fixed...


Write/WriteLine and Read die if they are called at the beginning of a script.

In and Out do not seem to be properly initialized at the beginning, therefore the methods Write/WriteLine and Read die. This does not happen in STRICT mode (see Devel::StrictMode).

$self-In() or $self->Out() initialize correctly.
The code is processed in STRICT mode when assert is called, i.e. see
https://github.com/brickpool/Win32-Console-DotNet/blob/366c2b053789f984cb8b619b074360984635cf6f/lib/Win32/Console/DotNet.pm#L2510


Dry-run policy execution 'savepoints' - restart policy dry-run from the list of 'saved' places

Problem description
In practice when developing a policy it is often rerun (in dry-run mode) to test latest changes. For realistic policies it can be time consuming as they tend to be quite lengthy and complex and thus require to remember and then re-execute all operations just to reach the point which is tested. It can be inconvenient and time consuming.
Note: this is different from #2559 which targets Guardian DR, i.e. its subject is published artefacts while this ticket aims to simplify dry-run (i.e. policy authoring) mode.
Requirements

Introduce a new functionality for users to 'save' dry-run execution status at arbitrary points by clicking 'save state' button.
The system should support the creation of multiple savepoints for the same execution workflow
Next time the (draft) policy is executed in the dry-run mode users should be given a choice whether to restart from the beginning, or continue execution from any of the 'savepoints'.
Starting execution from a 'savepoint' invalidates and removes all the other savepoints that logically followed it
It should be possible to delete some or all savepoints manually

Definition of done

Dry-run savepoint functionality is implemented as above
Documentation is updated accordingly

Acceptance criteria
UX of policy authoring is improved by giving users ability to restart dry-run policy execution from the last savepoint.

@prernaadev01 Request from Bram to move this up to discuss in refinement for timing.


couchstore: launch couch container from couchstore test

I have also improved the create database with a retry to avoid instability in integration testing.
Resolves #244

This change is

Great feature, it should be great to have the same behavior for postgresql & rethinkdb

Reviewed 4 of 4 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

couchstore/api.go, line 31 at r1 (raw file):

var (
	dbName string

It should be an CouchStore attribute to make api stateless

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

couchstore/api.go, line 31 at r1 (raw file):
Previously, alexppxela (Alexandre Thibault) wrote…
It should be an CouchStore attribute to make api stateless

I am just using this global variable to make it available to the retry function (defined in utils) as I can't pass additional parameters. So on create database this var is updated. Otherwise I can rewrite the retry function if you think this is not the best way to it.

Comments from Reviewable

Review status: 3 of 4 files reviewed at latest revision, 1 unresolved discussion.

couchstore/api.go, line 31 at r1 (raw file):
Previously, piedup wrote…
I am just using this global variable to make it available to the retry function (defined in utils) as I can't pass additional parameters. So on create database this var is updated. Otherwise I can rewrite the retry function if you think this is not the best way to it.

As discussed I have used a closure to solve this issue.

Comments from Reviewable

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Had to rebase on top of master to integrate Simon Couchstore/TMPop tests. Otherwise code unchanged.

Review status: 3 of 4 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable