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

Compact printing and more legible output #21

Closed
jcrist opened this issue Feb 24, 2014 · 3 comments
Closed

Compact printing and more legible output #21

jcrist opened this issue Feb 24, 2014 · 3 comments

Comments

@jcrist
Copy link
Contributor

jcrist commented Feb 24, 2014

Julia's show functions appear to be in the process of an overhaul (see this issue), but at this point it doesn't appear there is any way to set the global printing precision in the REPL. With floating point coefficients (i.e. 1/3 = 0.3333333333....) the default printing precision can make the output difficult to read. At least that's my opinion. However, showing the full output is also desirable.

The ideal way is to define a show function that provides the full output, and a showcompact function that limits the output. However, my use case requires using the polynomials in a composite data type, where printing "poly(...)" would be not ideal. At the same time, show and showcompact by convention provide type information like this. And print and string by convention output the default precision as well.

What I'm looking for is a clean way to provide both full and compact output with & without type info (i.e. "Poly(x^2 + 1)" and "x^2 + 1"). Possible solutions:

  • Define show and showcompact as normal. I then sprint(showcompact, p) and strip the "Poly( )" from the string when I need the compact format. This keeps the library itself cleaner, but puts a larger burden on anyone who wants a compact Poly representation without the type information.
  • Add an optional parameter to the print or string method to output the compact form. This would look something like this:
function print(io::IO, p::Poly, compact::Bool=false)
    ...
end
  • Some unknown method to me that makes this far simpler and more julia like. I'm rather new at this language, so there's probably a better way.

Regardless of which method above is chosen, here's my vision for the prettier output:

  • Real:
julia > Poly([1.12345678, 0.00001, -2.12345678, 3.12345678])
Poly(1.1234 x^3 - 2.1234 x + 3.1234)
  • Complex:
julia > Poly([1.12345678 + 1.12345678im, 2.12345678 + im, 3.12345678])
Poly([1.1234 + 1.1234im] x^2 + [2.1234 + im] x + 3.1234)

These changes would:

  1. Truncate decimal output to some precision (I arbitrarily chose 4, could be whatever)
  2. If coefficient is smaller than precision, display it in scientific notation. (i.e. 0.00001 -> 1.0e-5)
  3. If decimals are all zero, remove them (cleaner IMO)
  4. If coefficient has no im term, don't display # + 0im, just show that it's real
  5. If coefficient is 1, don't display it
  6. If coefficient is negative, print # - # instead of # + -#
  7. Add a space between the coefficient and the variable (easier to read IMO)
  8. If power is 1, print x instead of x^1

These last 4 (or at least 3) could also be added to the regular show command, as they deal more with formatting than full output.

Thoughts?

@vtjnash
Copy link
Owner

vtjnash commented Feb 26, 2014

I've addressed 2, 3, 4, 5, 8

1 -- I'm waiting to see how showcompact changes shake out. In general, you should be able to reconstruct the object from the output.
6 -- I'm not sure how to test for less than zero in a general manner. Perhaps this would just apply for Real coefficients?
7 -- 1x is valid Julia input format 1 x is not and would need to be written as 1*x. I don't feel this helps much in readability

@jcrist
Copy link
Contributor Author

jcrist commented Feb 26, 2014

1 -- Sounds good. That's probably the best plan.
6 -- Fixed it. Implemented in the recent pull request.
7 -- Makes sense to me. I was mainly bugged by 1x instead of x. The spacing is irrelevant, and your argument seems to make more sense for no space

I fetched your update to play around with, and found some bugs, mainly in how complex numbers were handled, and if the first coefficient was -1. I reworked the logic, and ended up splitting the functions into two methods - one for Real, and one for ComplexPair. Manually tested it for everything I could conceive of, and it seems to handle nicely.

No tests have been added to the test.jl file, as I'm not sure the best way to automate printing tests. Perhaps sprint, and compare to a string?

@vtjnash vtjnash closed this as completed Mar 10, 2014
@vtjnash
Copy link
Owner

vtjnash commented Mar 10, 2014

i think all of the major points have been addressed. open a new issue for anything else

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

No branches or pull requests

2 participants