I'm trying to adjust a random forest as a Hyperopt, but this error is occurring and I can't solve it
Here, rstate parameter of fmin() function needs random number generator which can be provided by np.random.RandomState(seed). However, you have passed an integer value (i.e., rstate=42) and that is why it is showing
AttributeError: 'int' object has no attribute 'randint'
Therefore, simply replacing that value (i.e., 42) by np.random.RandomState(42) will resolve the problem.
Not sure if you have resolved this yet but I think you can't set 'rstate' as an integer in this method, I had the same issue and it's resolve since I stopped setting 'rstate'
Related
I have a "QTY" field (simple property) on a page whose value is used in a Function Import. The Function Import expects a Number type.
The error I get in BAS is:
Incorrect type. Expected "number".
How do I set this as a number? There is nothing in the simple property to says it's a number type, other than the "Keyboard Type".
Adding $(N,...) still shows as an error, but deploys fine.
For the query "PROJECT[1]/PROPOSAL[1]/SOLUTION[1]/UNIT[1]/distinct-values(LANDING_DOOR_FRAME_FINISH_FRONT/LANDING_DOOR_FRAME_FINISH_FRONT_VALUE)" this appears to work if distinct-values() returns exactly one value, but throw an exception otherwise. (And by the way, this query is not my idea).
Is it a bad idea to have an atomic value as a node name in a query? Or is it ok? And if ok, is it ok only if it returns exactly one value?
Calling Saxon from Java for this.
It's a perfectly valid query, whether or not distinct-values() returns exactly one value.
(If it fails, show us a repro: all the data we need to reproduce the problem, plus the error message).
But your question, about using atomic values as node names, suggest that you don't understand what the expression means. The values returned by distinct-values() don't have to be node names, and they are not used as node names.
These days I prefer to use the "!" operator when the RHS expression returns atomic values rather than nodes. It's equivalent, but clearer.
This problem is about some fields that are declared double and often is null in the database.
Using findAllBy to receive a list then fails if some of the fields are null.
I tried with changing the type to Double but then I get problems when I do arithmetics on them. If the value is null the Double can't decide which converter it should use.
I don't know if there is any way to convert nulls in the domain before they are set.
Example of error:
Caused by: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of com.buffer.ProdBuffer.makeInquiry
You should always use Double in your entities/domains; unless you have a nullable: false constraint at work, even then it's a good practice, nonetheless.
However, you need to handle null by yourself in your calculations, probably by making that 0 or 1, you know it better. For more suggestions, post the code snippet.
Type inference in F# doesn't seem to work very well with parameters that are supposed to take values of a class type.
Is there a way to avoid explicit type annotation on such parameters?
It looks like a problem because when there are some 5 of such parameters each of which requires its pair of parentheses and a colon and the name of a type it looks much messier than the same declaration in C# which is known for being more syntactically noisy.
So that instead of
let writeXmlAttribute (writer: XmlWriter) name value = ()
I wish I could write something like
let writeXmlAttribute writer name value = () // <-- a problem when in comes to writer.WriteStartAttribute name
Is there a way I can get away with it?
UPDATE:
There is no such problem with records, only on classes.
If your primary reason for wanting to avoid this is a cleaner signature, you could move the explicit typing into the function with an upcast (which will infer the parameter type due to it being a compile-time determination). You're not avoiding it, however, you're just moving it.
let writeXmlAttribute writer name value =
(writer :> XmlWriter).WriteStartAttribute(name, value)
F# has difficulty with the kind of inference you're asking for in relation to members (including members on records), so you will have to do at least a minimal amount of explicit typing in any case.
I am having a brain freeze on f#'s option types. I have 3 books and read all I can but I am not getting them.
Does someone have a clear and concise explanation and maybe a real world example?
TIA
Gary
Brian's answer has been rated as the best explanation of option types, so you should probably read it :-). I'll try to write a more concise explanation using a simple F# example...
Let's say you have a database of products and you want a function that searches the database and returns product with a specified name. What should the function do when there is no such product? When using null, the code could look like this:
Product p = GetProduct(name);
if (p != null)
Console.WriteLine(p.Description);
A problem with this approach is that you are not forced to perform the check, so you can easily write code that will throw an unexpected exception when product is not found:
Product p = GetProduct(name);
Console.WriteLine(p.Description);
When using option type, you're making the possibility of missing value explicit. Types defined in F# cannot have a null value and when you want to write a function that may or may not return value, you cannot return Product - instead you need to return option<Product>, so the above code would look like this (I added type annotations, so that you can see types):
let (p:option<Product>) = GetProduct(name)
match p with
| Some prod -> Console.WriteLine(prod.Description)
| None -> () // No product found
You cannot directly access the Description property, because the reuslt of the search is not Product. To get the actual Product value, you need to use pattern matching, which forces you to handle the case when a value is missing.
Summary. To summarize, the purpose of option type is to make the aspect of "missing value" explicit in the type and to force you to check whether a value is available each time you work with values that may possibly be missing.
See,
http://msdn.microsoft.com/en-us/library/dd233245.aspx
The intuition behind the option type is that it "implements" a null-value. But in contrast to null, you have to explicitly require that a value can be null, whereas in most other languages, references can be null by default. There is a similarity to SQLs NULL/NOT NULL if you are familiar with those.
Why is this clever? It is clever because the language can assume that no output of any expression can ever be null. Hence, it can eliminate all null-pointer checks from the code, yielding a lot of extra speed. Furthermore, it unties the programmer from having to check for the null-case all the same, should he or she want to produce safe code.
For the few cases where a program does require a null value, the option type exist. As an example, consider a function which asks for a key inside an .ini file. The key returned is an integer, but the .ini file might not contain the key. In this case, it does make sense to return 'null' if the key is not to be found. None of the integer values are useful - the user might have entered exactly this integer value in the file. Hence, we need to 'lift' the domain of integers and give it a new value representing "no information", i.e., the null. So we wrap the 'int' to an 'int option'. Now, if there is no integer value we will get 'None' and if there is an integer value, we will get 'Some(N)' where N is the integer value in question.
There are two beautiful consequences of the choice. One, we can use the general pattern match features of F# to discriminate the values in e.g., a case expression. Two, the framework of algebraic datatypes used to define the option type is exposed to the programmer. That is, if there were no option type in F# we could have created it ourselves!