#18742: interactive_simplex_method: Support several styles corresponding to
major
textbooks
-------------------------------------+-------------------------------------
Reporter: mkoeppe | Owner:
Type: task | Status: needs_work
Priority: minor | Milestone: sage-6.8
Component: numerical | Resolution:
Keywords: beginner, lp, | Merged in:
teaching | Reviewers: Andrey Novoseltsev
Authors: Peijun Xiao, | Work issues: clean up default
Matthias Koeppe | names logic
Report Upstream: N/A | Commit:
Branch: | 8f5c7a43f2109a30f7e0dd95df1218a66c96e836
u/novoselt/interactive_simplex_method__support_several_styles_corresponding_to_major_textbooks|
Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by mkoeppe):
Replying to [comment:22 novoselt]:
> Nitpicks:
>
> - Every function has to have input/output blocks if there is any
input/output.
Do you want us to work on this, or do you plan to make more changes?
>
> - Copy-pasting is bad in general and lead to some mistakes in
dictionary code and documentation.
>
> More substantial:
>
> - The point of `style` is to affect output and automatic choice of
names which also really matter only when displayed. Therefore
`LPAbstractDictionary` has nothing to do with the style and since there
was no customization for `LPRevisedDictionary` let's not through in extra
arguments there.
>
> - I still feel like overall logic will be cleaner if there was a
single style rather than separate for each problem - no need to drug style
arguments around and pass it along to every newly constructed instance, or
engage in aforementioned copy-pasting. I just don't see under what
circumstances someone will want to actively work with different styles at
once. Can I rewrite things without `style` argument to
problems/dictionaries?
Since the style affects default names of primal and dual, I would be a bit
concerned about what happens when a user creates a problem P, then changes
the global style, then dualizes the problem. However, if this can be done
consistently, I have no strong objections to having just a global style
variable.
> - As I have not heard about others using this module before, perhaps
we can be somewhat relaxed about backward compatibility. In fact, I'd like
to break it even more since with your changes `prefix` argument has
unclear meaning and gets in the way. (This change is done in my commit.)
>
> - I am thinking about collecting all name choices into a dictionary
which is then referred to in appropriate places, otherwise things are
difficult to keep in sync. With dictionaries adding another style would
mean: add a new dictionary with desired default names and tweak output
methods as appropriate. No need to go through all functions that can
construct a problem or dictionary. (So far the only output differences
were presence of frame and position of the objective. In general things
can be more different, but just in the latex method.) The use for the
dictionary would be something like
> {{{
> if slack_variable is None:
> slack_variable = _default_name[style]["slack variable"]
> }}}
I think this is a great idea.
> - Is there any default auxiliary variable name in Vanderbei?
What do you mean by auxiliary variable? The one in a primal phase I?
That's x0.
--
Ticket URL: <http://trac.sagemath.org/ticket/18742#comment:23>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
