-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GAMS eps
isn't the same as Numpy EPS
#39
Comments
Actually, in GAMS |
The documentation for the embedded code feature shows they map EPS to |
@jebob - I think it makes sense to follow what GAMS does and either map to ~1E-300 or 0. I lean toward the former (or explicitly providing the option), because in my experience part of the point of preserving eps values in GDX is to indicate that something is there/something has been calculated rather than is missing. That is, if the default maps eps to 0, that information (an actual rather than a missing value in the GDX file) may get lost. |
Makes sense to me, I lean towards 1e-300 as well. |
GAMS
eps
is a special value for an arbitrarily a small number [sic] and has all the logic of an infintesimal,eps * 100 == eps
eps + 1e-100 == 1e-100
An
eps
in a GDX is currently converted to np.finfo(float).eps, defined as "The smallest representable positive number such that 1.0 + eps != 1.0." which is about 2.220446049250313e-16 on my machine. This is in line with the python definition but doesn't have the infitesimal properties.np.finfo(float).eps + 1e-100 == np.finfo(float).eps
returnsTrue
due to floating point errorI propose changing all references to
np.finfo(float).eps
tonp.finfo(float).tiny
, which is about 2.2250738585072014e-308 on my machine.The text was updated successfully, but these errors were encountered: