def __init__(self):
AbstractProblemWriter.__init__(self, ProblemFormat.cpxlp)
# The LP writer tracks which variables are
# referenced in constraints, so that a user does not end up with a
# zillion "unreferenced variables" warning messages.
# This dictionary maps id(_VarData) -> _VarData.
self._referenced_variable_ids = {}
# Per ticket #4319, we are using %.17g, which mocks the
# behavior of using %r (i.e., float('%r'%<number>) == <number>) with
# the added benefit of outputting (+/-). The only case where this
# fails to mock the behavior of %r is for large (long) integers (L),
# which is a rare case to run into and is probably indicative of
# other issues with the model.
# *** NOTE ***: If you use 'r' or 's' here, it will break code that
# relies on using '%+' before the formatting character
# and you will need to go add extra logic to output
# the number's sign.
self._precision_string = '.17g'
self.linear_coef_string_template = '%+' + self._precision_string + ' %s\n'
self.quad_coef_string_template = '%+' + self._precision_string + ' '
self.obj_string_template = '%+' + self._precision_string + ' %s\n'
self.sos_template_string = "%s:%" + self._precision_string + "\n"
self.eq_string_template = "= %" + self._precision_string + '\n'
self.geq_string_template = ">= %" + self._precision_string + '\n\n'
self.leq_string_template = "<= %" + self._precision_string + '\n\n'
self.lb_string_template = "%" + self._precision_string + " <= "
self.ub_string_template = " <= %" + self._precision_string + "\n"
def __init__(self):
AbstractProblemWriter.__init__(self, ProblemFormat.cpxlp)
# The LP writer tracks which variables are
# referenced in constraints, so that a user does not end up with a
# zillion "unreferenced variables" warning messages.
# This dictionary maps id(_VarData) -> _VarData.
self._referenced_variable_ids = {}
# Per ticket #4319, we are using %.17g, which mocks the
# behavior of using %r (i.e., float('%r'%<number>) == <number>) with
# the added benefit of outputting (+/-). The only case where this
# fails to mock the behavior of %r is for large (long) integers (L),
# which is a rare case to run into and is probably indicative of
# other issues with the model.
# *** NOTE ***: If you use 'r' or 's' here, it will break code that
# relies on using '%+' before the formatting character
# and you will need to go add extra logic to output
# the number's sign.
self._precision_string = '.17g'
self.linear_coef_string_template = '%+'+self._precision_string+' %s\n'
self.quad_coef_string_template = '%+'+self._precision_string+' '
self.obj_string_template = '%+'+self._precision_string+' %s\n'
self.sos_template_string = "%s:%"+self._precision_string+"\n"
self.eq_string_template = "= %"+self._precision_string+'\n'
self.geq_string_template = ">= %"+self._precision_string+'\n\n'
self.leq_string_template = "<= %"+self._precision_string+'\n\n'
self.lb_string_template = "%"+self._precision_string+" <= "
self.ub_string_template = " <= %"+self._precision_string+"\n"
def __init__(self):
AbstractProblemWriter.__init__(self, ProblemFormat.bar)
#Copied from cpxlp.py:
# Keven Hunter made a nice point about using %.16g in his attachment
# to ticket #4319. I am adjusting this to %.17g as this mocks the
# behavior of using %r (i.e., float('%r'%<number>) == <number>) with
# the added benefit of outputting (+/-). The only case where this
# fails to mock the behavior of %r is for large (long) integers (L),
# which is a rare case to run into and is probably indicative of
# other issues with the model.
# *** NOTE ***: If you use 'r' or 's' here, it will break code that
# relies on using '%+' before the formatting character
# and you will need to go add extra logic to output
# the number's sign.
self._precision_string = '.17g'
def __init__(self):
AbstractProblemWriter.__init__(self, ProblemFormat.bar)
#Copied from cpxlp.py:
# Keven Hunter made a nice point about using %.16g in his attachment
# to ticket #4319. I am adjusting this to %.17g as this mocks the
# behavior of using %r (i.e., float('%r'%<number>) == <number>) with
# the added benefit of outputting (+/-). The only case where this
# fails to mock the behavior of %r is for large (long) integers (L),
# which is a rare case to run into and is probably indicative of
# other issues with the model.
# *** NOTE ***: If you use 'r' or 's' here, it will break code that
# relies on using '%+' before the formatting character
# and you will need to go add extra logic to output
# the number's sign.
self._precision_string = '.17g'
def __init__(self):
AbstractProblemWriter.__init__(self, ProblemFormat.cpxlp)
# the LP writer is responsible for tracking which variables are
# referenced in constraints, so that one doesn't end up with a
# zillion "unreferenced variables" warning messages. stored at
# the object level to avoid additional method arguments.
# dictionary of id(_VarData)->_VarData.
self._referenced_variable_ids = {}
# Keven Hunter made a nice point about using %.16g in his attachment
# to ticket #4319. I am adjusting this to %.17g as this mocks the
# behavior of using %r (i.e., float('%r'%<number>) == <number>) with
# the added benefit of outputting (+/-). The only case where this
# fails to mock the behavior of %r is for large (long) integers (L),
# which is a rare case to run into and is probably indicative of
# other issues with the model.
# *** NOTE ***: If you use 'r' or 's' here, it will break code that
# relies on using '%+' before the formatting character
# and you will need to go add extra logic to output
# the number's sign.
self._precision_string = '.17g'
def __init__(self):
AbstractProblemWriter.__init__(self, ProblemFormat.mps)
# the MPS writer is responsible for tracking which variables are
# referenced in constraints, so that one doesn't end up with a
# zillion "unreferenced variables" warning messages. stored at
# the object level to avoid additional method arguments.
# dictionary of id(_VarData)->_VarData.
self._referenced_variable_ids = {}
# Keven Hunter made a nice point about using %.16g in his attachment
# to ticket #4319. I am adjusting this to %.17g as this mocks the
# behavior of using %r (i.e., float('%r'%<number>) == <number>) with
# the added benefit of outputting (+/-). The only case where this
# fails to mock the behavior of %r is for large (long) integers (L),
# which is a rare case to run into and is probably indicative of
# other issues with the model.
# *** NOTE ***: If you use 'r' or 's' here, it will break code that
# relies on using '%+' before the formatting character
# and you will need to go add extra logic to output
# the number's sign.
self._precision_string = '.17g'
def __init__(self):
AbstractProblemWriter.__init__(self, ProblemFormat.bar)
def __init__(self):
AbstractProblemWriter.__init__(self, ProblemFormat.gams)
