-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
Performance/style improvement with buffer printing? #110
Comments
I'm not opposed to this in principle but my initial guess is that changing this would be a bit more complicated than you seem to think. We'd still need to actually return a LaTeXString, not just invoke Also, some operations work directly on the strings by When I started making this package, my fingers were itching to optimise it to perfection but I refrained since I did not think it worthwhile. Have you found latexify to affect performance in any way? Even if the string manipulation is slow, I've never used latexify on anything large enough for execution time to be noticeable. But if you think that doing this would provide value to you or anyone else, and if it does not make the code harder to maintain, then feel free to tinker! |
Now is a good time to revisit this since I'm refactoring anyways. I just spent 15 minutes formulating all the ways in which this would be hard only to find myself able to poke holes in all my arguments. Maybe this would be good. If it could improve compile time then I'd be very happy. I'm pretty sure that it could improve runtime but I don't think that's an issue since latexify already has pretty much no notable runtime. |
hmmm, if every step in the recursion writes to io rather than returns a string then stuff like
would work but not when you also wanted to descend into
would not work since |
nevermind. Something like
should just work as a drop-in replacement for join where I also want to descend the arguments. |
I have no idea how this would affect compile time, and your argument about runtime is a strong one. But I still think this is principally a good idea. Perhaps working with One really nice thing about replacing (or supplementing) |
huh, that's a good point. It's a very different approach to what I'm working with now where I'm using an array (that can be Doing it with I really like the idea that extending packages would then not even need to import latexify.jl though. |
Sorry to throw extra stuff in the mix.
Could you give an example of what kind of formatting needs this / what type of conditional? I'm sure many things can be solved by passing things through IOContext: function show(io, mime::MIME"text/latexify", x::Multiplication)
surround = compare_precedence(get(io, :precedence, :+), :*)
io = IOContext(io, :precedence=>:*)
surround ? write(io, "\\left(") : nothing
show(io, mime, x.a)
write(io, get(io, :multsign, "\\cdot"))
show(io, mime, x.b)
surround ? write(io, "\\right)") : nothing
end That said, like I said, I don't know if there are any big benefits to this way over the array of functions. If you want I could formulate a mockup in the next couple of days. |
This is interesting. Untimely but interesting. I need a solution for the compile time before Thursday when there's a feature freeze on Pumas.jl. I have been working that in to the refactor that I'm working on. That refactor is fairly mature so I should be able to get that done in time. Switching to this approach might mess that up. That said. I do find the approach interesting and worth exploring. |
The following works. Any suggestions for improvements?
|
When working on the complex and rational numbers, I got thinking about how this package is passing strings around. From what I've learned in other languages, building strings by concatenating other strings has a lot more overhead than making a buffer and printing to it. One way to refactor this package would be to introduce
etc. Is there a strong reason to not do this? It should be pretty straightforward to switch from building a string inside every function to printing to the same buffer each time. I could give it a try, just want to check that it hasn't been tried and discarded.
The text was updated successfully, but these errors were encountered: