You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Function _get_parameter_type in line 117 of instantiation.py throws error No AE parameter type corresponding to <class 'numpy.float64'>. if the bounds of a range variable are calculated outside Ax using some Numpy function, which will return numpy.float64 as opposed to a Python float.
If possible, given how ubiquitous Numpy is, either (1) allowing Numpy primitives or (2) suggesting casting in the error message will make it easier for users to debug their application. It may be just me (I was not a CS major), but I couldn't figure out that a simple casting would solve the problem until digging into Ax's code with the debugger.
The text was updated successfully, but these errors were encountered:
Thank you for bringing this to our attention, and I'm happy you were able to unblock yourself!
What you're suggesting does not sound unreasonable to me; numpy (and torch) floats can almost always be safely casted here. I will raise it with the team here and hear what they have to say :)
Also will chime in and say this is important for my workflow as well. Manually casting to a python native float adds a lot of obfuscation to my call to ax.optimize
I'm going to put this onto the wishlist, as property handling the numpy types is not actually entirely trivial to add in Ax, as there are a lot of places this will need to be handled. For now, please ensure you coerce your numpy values to Python primitives before passing them to Ax.
Function
_get_parameter_type
in line 117 ofinstantiation.py
throws errorNo AE parameter type corresponding to <class 'numpy.float64'>.
if the bounds of a range variable are calculated outside Ax using some Numpy function, which will return numpy.float64 as opposed to a Python float.If possible, given how ubiquitous Numpy is, either (1) allowing Numpy primitives or (2) suggesting casting in the error message will make it easier for users to debug their application. It may be just me (I was not a CS major), but I couldn't figure out that a simple casting would solve the problem until digging into Ax's code with the debugger.
The text was updated successfully, but these errors were encountered: