I am writing a custom search strategy with builds() (this doesn't matter w.r.t. this question) which shall use hypothesis.strategies.integers(min_value=None, max_value=None) to generate integer data with an explicit step size other than, let's say delta 10. I do not need a list of values like [10, 20, 30, 40, etc.]. Instead I need subsequent calls of the test function to be called with integer values with step size of 10, e.g. with 10 for the first call, 20 for the second call, etc. How can I achieve this easiest?
You can easily adapt existing strategies, for example generating even numbers via:
integers().map(lambda x: x * 2)
And just to check - are you using a recent version of Hypothesis? You linked to the documentation for v1.8, which is unsupported and significantly less powerful than the current version 3.48.
Finally, consider a composite strategy if you need to have a particular relationship between the parts of whatever you're constructing - builds() is simpler but doesn't support dependencies between arguments.
I need subsequent calls of the test function to be called with integer values with step size of 10, e.g. with 10 for the first call, 20 for the second call, etc.
Hypothesis only supports stateful testing via the hypothesis.stateful module.
By design, each example provided by #given is independent of any other - if this doesn't work for your use case Hypothesis is probably the wrong tool for the job.
Related
I have been trying to update a spreadsheet we currently using to show the most efficient way of ordering items. Items can be ordered in packs of 1, 5, 10 or 20. Can if statements be used to produce a table to show the best way of ordering these?
E.G: 18 - made of 1 x pack of 10; 1 x pack of 5; 3 x pack of 1
Been trying to use IF statements, but as the numbers get larger: more errors seems to creep in. I'm certain there is a simple solution i am missing at the moment.
Packaging
You can handle this easily with INT and MOD.
=INT($A3/B$2)
=INT(MOD($A3,B$2)/C$2)
It was easy when the packaging was convenient. If it isn't, instead of MOD, you could use SUMPRODUCT.
=INT($A3/B$2)
=INT(($A3-SUMPRODUCT($B$2:B$2,$B3:B3))/C$2)
A quick go at this, but I added some prices:
But you may want to consider how you could get the result of ordering 20 and having 2 spare etc...
So, set that up like this, but you nay want to fine tune to control your situation more precisely:
I would like to generate two set of variables, h_min and h_max,
h_max = [h_max_1, h_max_2, …h_max_2000]
h_min = [h_min_1, h_min_2,… h_min_2000]
Each element of h_max is generated based on uniform distribution, i.e.,
h_max = np.random.uniform(0, 20, 2000).
For each element, h_min_i, it should be generated based on the uniform distribution with range of 0, and corresponding h_max_i In other words, h_min_i = np.random.uniform(0, h_max_i)
In stead of using iteration, how to efficiently generate h_min
The numpy.random.uniform function allows the first and/or second parameters to be an array, not just a number. They work exactly as you were expecting:
h_max=np.random.uniform(0,20,2000)
h_min=np.random.uniform(0,h_max,2000)
However, numpy.random.* functions, such as numpy.random.uniform, have become legacy functions as of NumPy 1.17, and their algorithms are expected to remain as they are for backward compatibility reasons. That version didn't deprecate any numpy.random.* functions, however, so they are still available for the time being. See also this question.
In newer applications you should make use of the new system introduced in version 1.17, including numpy.random.Generator, if you have that version or later. One advantage of the new system is that the application relies less on global state. Generator also has a uniform method that works in much the same way as the legacy function numpy.random.uniform. The following example uses Generator and works in your case:
gen=np.random.default_rng() # Creates a default Generator
h_max=gen.uniform(0,20,2000)
h_min=gen.uniform(0,h_max,2000)
This is a follow-up to a suggestion by #DCTLib in the post below.
Cudd_PrintMinterm, accessing the individual minterms in the sum of products
I've been pursuing part (b) of the suggestion and will share some pseudo-code in a separate post.
Meanwhile, in his part (b) suggestion, #DCTLib posted a link to https://github.com/VerifiableRobotics/slugs/blob/master/src/BFAbstractionLibrary/BFCudd.cpp. I've been trying to read this program. There is a recursive function in the classic Somenzi paper, Binary Decision Diagrams, which describes an algo to compute the number of satisfying assignments (below, Fig. 7). I've been trying to compare the two, slugs and Fig. 7. But having a hard time seeing any similarities. But then C is mostly inscrutable to me. Do you know if slugs BFCudd is based on Somenze fig 7, #DCTLib?
Thanks,
Gui
It's not exactly the same algorithm.
There are two main differences:
First, the "SatHowMany" function does not take a cube of variables to consider for counting. Rather, that function considers all variables. The fact that "recurse_getNofSatisfyingAssignments" supports cubes manifest in the function potentially returning NaN (not a number) if a variable is found in the BDD that does not appear in the cube. The rest of the differences seem to stem from this support.
Second, SatHowMany returns the number of satisfying assignments to all n variables for a node. This leads, for instance, to the division by 2 in line -4. "recurse_getNofSatisfyingAssignments" only returns the number of assignments for the remaining variables to be considered.
Both algorithms cache information - in "SatHowMany", it's called a table, in "recurse_getNofSatisfyingAssignments" it's called a buffer. Note that in line 24 of "recurse_getNofSatisfyingAssignments", there is a constant string thrown. This means that either the function does not work, or the code is never reached. Most likely it's the latter.
Function "SatHowMany" seems to assume that it gets a BDD node - it cannot be a pointer to a complemented BDD node. Function "recurse_getNofSatisfyingAssignments" works correctly with complemented nodes, as a DdNode* may store a pointer to a complemented node.
Due to the support for cubes, "recurse_getNofSatisfyingAssignments" supports flexible variable ordering (hence the lookup of "cuddI" which denotes for a variable where it is in the current BDD variable ordering). For function SatHowMany, the variable ordering does not make a difference.
I am trying to fit a custom function to some data points using curve_fit. I have tried 1 or two free parameters. I have used it other times. Now I am struggling to make a fit, because the algorithm returns always the initial input values, with infinite sigma, no matter what the initial values are. I have also tried to print the internal parameters with which my custom function is called, and I don't understand, my custom function is called just 4 times, the first three with always the same parameters and the last with a relative change of the parameter of 10^-8. this doesn't look right
It is normal for the objective function to be called initially with very small (roughly 1e-8) changes in parameter values in order to calculate the partial derivatives to decide which way to go in parameter space. If the result of the objective function does not change at all (not even at 1e-8 level) the fit will give up: changing the parameter values did not change the result.
I would first look into whether the result of your objective function is really sensitive to the parameters. If the changes to your result really are not sensitive to a 1e-8 change, but would be sensitive to a larger change, you may want to increase the value of epsfcn passed to scipy.optimize.leastsq.
I have a random number generator that outputs values from (0, 1], but I need to give the output to a function that returns infinity at 0 or 1. How can I post-process the generated number to be in (0, 1) without any branches, as this is intended to execute on a GPU?
I suppose one way is to add a tiny constant and then take the value mod 1. In other words, generate from (ɛ, 1 + ɛ], which gets turned into [ɛ, 1). Is there a better way? What should the ɛ be?
Update 1
In Haskell, you can find ɛ by using floatRange. The C++ portion below applies otherwise.
Note: The answer below was written before the OP expressed the answer should be for Haskell
You don't state the implementation language in the question, so I'm going to assume C++ here.
Take a look at std::nextafter.
This will allow you to get the next possible value which you can add to the upper limit, which will result in your code acting as if it was inclusive.
As for the branching, you could overload the function to avoid the branch. However, this leads to code duplication.
I'd recommend allowing the branch and letting the compiler make such micro-optimizations unless you really need the performance and can provide a more specialised implementation than the standard one (see Pascal Cuoq's comment).