Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Matrix backend #33

Closed
DhruvaSambrani opened this issue Jan 29, 2020 · 10 comments
Closed

Add Matrix backend #33

DhruvaSambrani opened this issue Jan 29, 2020 · 10 comments

Comments

@DhruvaSambrani
Copy link
Contributor

Used to output the table as a mathematical matrix.

REPL -

The borders of unicode, but without the horizontal lines. Center align by default if possible.

┌                                   ┐
│      1    false      1.0        1 │
│      2     true      2.0        2 │
│      3    false      3.0        3 │
└                                   ┘

LaTeX -

$$ \left[
  \begin{array}{ c c }
     1 & 2 \\
     3 & 4
  \end{array} \right]
$$

source
HTML - Here

@ronisbr
Copy link
Owner

ronisbr commented Jan 31, 2020

Hi @DhruvaSambrani ,

As I pointed out in the PR, I did something very wrong and had to hard reset everything. However, I think we can discuss a little how can we implement this feature. I really like the idea to print matrices as you showed. However, adding right and left borders does not really fix everything.

I always wanted to change how the text table format is handle. I think the best was is to define a line as a string like this:

line = "├─┼┤"

with the characters to build the line. Then, we can add formats for the top line, header separation line, row line, and bottom line. With this, we will have a very good flexibility to create text formats as you proposed.

@DhruvaSambrani
Copy link
Contributor Author

But internally, don't you need to again split it into the chars? And if we are going to do that anyway, might as well store them as a dictionary as we are doing it now. We could add another TextFormat constructor which splits it like how you said. We will still need different "border" elements though, as a column separator may not be the same as the border.

@ronisbr
Copy link
Owner

ronisbr commented Jan 31, 2020

But internally, don't you need to again split it into the chars?

Yes, we have two approaches here. First, we can use string[1], string[2], and so on. Or we can create a struct with a convert definition to change the string to characters as we are using today.

I will try to implement something this weekend and then we can discuss :) If you have any better idea, please, let me know!

@DhruvaSambrani
Copy link
Contributor Author

I don't personally like string[k] as it gets really difficult to extend it if necessary. Like rn, I just had to add another entry to the Dict and call accordingly. If we choose to add a char in-between, you'll need to re-index it all over again in all the locations. Instead, a convert function would help better.

@DhruvaSambrani
Copy link
Contributor Author

Should I PR again? You can merge to a new branch and make your changes there, so that you can edit it to add the syntactic sugars

@ronisbr
Copy link
Owner

ronisbr commented Mar 24, 2020

Hi @DhruvaSambrani

I recently commit a breaking change to PrettyTables.jl. We now have a way to suppress drawing of vertical lines and this can be set in each format. Thus, the option left_border and right_border were no long necessary. Can you please test to see if I broke something in your workflow?

@waldyrious
Copy link

@ronisbr It would be nice if we could use actual bracket characters for the matrix backend. Unicode has dedicated characters for precisely this use case (I suggested using them for Julia's log messages in JuliaLang/julia#33898).

In PrettyTables.jl it would look like this:

Before:

┌                     ┐
│ 1   false   1.0   1 │
│ 2    true   2.0   2 │
│ 3   false   3.0   3 │
└                     ┘

After:

⎡ 1   false   1.0   1 ⎤
⎜ 2    true   2.0   2 ⎥
⎣ 3   false   3.0   3 ⎦

I would propose this change as a PR myself, but I'm not sure how to implement it, since with the extended bracket characters the corners are not placed in a separate "row", as is the case with the current format, but rather inline with the first and last lines of actual content. Would this be possible with the current implementation?

@ronisbr
Copy link
Owner

ronisbr commented Mar 24, 2020

I would propose this change as a PR myself, but I'm not sure how to implement it, since with the extended bracket characters the corners are not placed in a separate "row", as is the case with the current format, but rather inline with the first and last lines of actual content. Would this be possible with the current implementation?

This is nice! However, it will be a "huge" change in the API. We need to check if it is the first line to be printed (of the last line) and change the printed chars. IMHO, the best way here is to create a new back-end dedicated to print matrix.

@waldyrious
Copy link

Yeah, I suspected it wouldn't fit well with the current system. 😅

Do you want me to open a new issue to track that change?

@ronisbr
Copy link
Owner

ronisbr commented Mar 24, 2020

Yes, please!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants