Ce qui pourrait causer cette erreur pyomo: "ERREUR: évaluation de l'objet comme valeur numérique"?

Question

Très rarement j'obtiens cette erreur lors de l'exécution de pyomo: "ERREUR: évaluation de l'objet comme valeur numérique: 0.0". Cela ressemble un peu à l'erreur qui se produit lorsque certains solveurs retournent, par exemple, 0.0 au lieu de 0, ce qui conduit à une erreur lors de la réutilisation des résultats avec, par exemple, within = argument binaire de la fonction Var. Je ne crois pas que ce soit le cas ici. Quelqu'un peut-il me donner quelques idées sur ce qui peut causer cette erreur? J'utilisais glpk à l'époque.

Voici quelques informations supplémentaires. Je résous un problème d'optimisation de manière séquentielle, un jour à la fois. Donc, la solution d'hier devient une contribution au problème d'aujourd'hui. Voici quelques spinets de code simplifié:

results = manager.solve(instance, kwargs...) 
instance.solutions.load_from(results) 
states_dict = get_next_states(instance, time, args...) 

def get_next_states(instance, time, args...): 
    states_dict = {} 
    for state in states: 
     var = getattr(instance, state) 
     for a in a_list: 
      value = var[a, time].value 
      states_dict[state, a] = force_domain(value, integer, tolerance) 
    return states_dict 

force_domain valeur forces à entier et/ou non négatif, en fonction des arguments entiers et tolérance. Le code échoue lors de l'évaluation de force_domain; parfois avec l'erreur ci-dessus, et parfois avec une exception TypeError: TypeError: types non modifiables: NoneType() < int(). Voici force_domain:

def force_domain(x, integer, nonnegative): 
    y = x 
    if x < 0 and nonnegative: 
     y = chop_tiny(y, nonnegative) 
    if integer: 
     y = round_if_int(y) 
    return y 

def chop_tiny(x, tol): 
    if abs(x) > tol or isinstance(x, int): 
     return x 
    else: 
     return 0.0 

def round_if_int(x): 
    if isinstance(x, float) and (x).is_integer(): 
     return int(x) 
    else: 
     return x 

Ces erreurs se produisent dans moins de 1 dans 2000 exécutions.

Est-ce que cette information supplémentaire vous aide à répondre à ma question?

Answer 1

J'ai réussi à isoler et à reproduire l'erreur. Il s'avère être dû à l'instabilité numérique dans GLPK v4.57 qui a abouti à un accident. Cette instabilité numérique semble avoir été corrigée dans GLPK v4.60. Voir https://lists.gnu.org/archive/html/info-gnu/2016-04/msg00000.html.