#18270: Print matrices using unicode large delimiters (on demand)
-------------------------------------+-------------------------------------
Reporter: gagern | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.7
Component: user interface | Resolution:
Keywords: unicode matrix | Merged in:
Authors: Martin von Gagern | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/MatrixUnicodeDelimiters | e174830facfed57934dec14cf107ffd6952955b5
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gagern):
Replying to [comment:8 vdelecroix]:
> review comment:
> - I would very much prefer that you avoid `replace` as well as the final
step which deals with the top and bottom line. You should rather define
'''all''' the characters needed as variables at the begining (as you did
for `left_bracket`, `right_bracket`, etc). That would help for readability
and if at some point we decide that all these characters are arguments of
the function.
Indeed when I started this patch, I had a line like
top_left_bracket, mid_left_bracket, … = u"⎡⎢⎣⎤⎥⎦"
but the long names made things very hard to read. And shorter
alternatives, like `tlb`, make things a bit hard to understand and
therefore harder to maintain. Quite the opposite of “help for
readability”, in my opinion. But if you insist, I can go with this
approach, using the short names.
Keep in mind that the `left_bracket` and `right_bracket` strings, which
have been there before, are not only representing the brackets, but also
collecting the vertical lines at the ends.
Plugging the delimiting brackets in the right rows is a non-trivial
affair, and would therefore in my opinion be far harder to maintain. The
possibility of an arbitrary number of horizontal lines at either end
complicates things considerably. I haven't been able to come up with a
reasonably simple code snippet to achieve correct symbols automatically
while building these strings. So unless you ''absolutely'' insist on this
point, or can give a good reason on why my approach has very undesirable
reprecussions, or can suggest some formulation, I'd rather stick with my
approach. Or adjust it in such a way that it assembles the matrix body
without any brackets, and then adds all the bracket parts in a single loop
instead of replacing existing incorrect parts.
> - why not curly bracket?
Because I don't encounter them in my day-to-day work. Can you give me a
hint as to where these might occur? For an even number of rows (except
two), big curly brackets would look slightly unsymmetric, but I doubt that
should be a concern.
--
Ticket URL: <http://trac.sagemath.org/ticket/18270#comment:9>
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.
