GAMS `eps` isn't the same as Numpy EPS
jebob opened this issue · 5 comments
GAMS eps is a special value for an arbitrarily a small number [sic] and has all the logic of an infintesimal,
eps * 100 == epseps + 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).epsreturnsTruedue to floating point error
I propose changing all references to np.finfo(float).eps to np.finfo(float).tiny, which is about 2.2250738585072014e-308 on my machine.
Actually, in GAMS eps eq 0, so maybe it should map to zero?
The documentation for the embedded code feature shows they map EPS to 0 (default) or 4.94066E-324.
@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.