Open albinahlback opened 2 years ago
I agree. We need to check what all the other printing methods do though. Probably one of these methods is inconsistent with all the others.
Wrong documentation for fmpq_poly_fprint_pretty
(also note FILT
instead of FILE
): https://flintlib.org/doc/fmpq_poly.html?highlight=print#c.fmpq_poly_fprint_pretty
I think the "ugly" versions are important and should be there to ease parsing. With that being said, I think fmpz_[mat/vec]_print
does the correct thing, and thus think that fmpq_mat_print
should print something very similar.
Thus, I think it remains to discuss the formatting of the output for the pretty printing. For matrix/vector-type objects, I am in favor of using one pair of brackets for each row (vectors can be interpretted as rows in order to not output so many newline-characters). I also think that commas are nice.
I thought the issue was consistency. The only way to achieve that is to check what all the other functions are doing.
Yeah, we could either investigate how everything is printed and then do something about it. Or we could try to come up with a standardized format for everything based, and change it from there.
Printing
fmpz_mat
andfmpq_mat
gives the followingSome questions:
fmpq_mat
.fmpq_mat_print
is quite nicely printed. Should we call thisfmpq_mat_print_pretty
and remove<n x n matrix over Q>
?fmpq_mat
be implemented, like the one forfmpz_mat
?fmpz_mat_print_pretty
?fmpz_mat_print_pretty
print the last two brackets with a newline character in between?Perhaps it goes for other types, I have not checked them out yet.
I suppose these are kind of breaking changes, but they need to be coherent at least (in my opinion).