Future plans are to integrate the package with Unitful.jl, be able to render the algebraic expressions within a function, and many other things. This package is an extension of Latexify.jl.

This is fantastic! Great work @co1emi11er! I’ll give it a whirl one of these days for some of my literate documents I write with Weave.jl and Quarto!

A macro that will generate LaTeX for a function that was called. The generated
LaTeX would be the algebraic equations within the function.

My ultimate wish for this type of functionality is to be able to pull simple equation sets from different sources and use them together showing my work at the destination:

using Handcalcs, Smith1993, Jefferson2020
a=3
b=4
@handcalcs y = Smith1993.y(a) # show LaTeX for y equation defined in package
@handcalcs z = Jefferson2020.z(b) # show LaTeX for z equation defined in package
@handcalcs c = y + z # just show simple LaTeX addition

I structure my code like this now because:

I can keep a master copy of my reference equations separately from all the reports that will use them. This avoids a lot of boilerplate and copy-paste errors.

I can easily update or swap reference equations for all future reports with a dependency change.

It makes clear in the report where I am coming up with my equations.

I use @latexrun when defining the equations in my dependency packages and then compare a weaved PDF in the dependency package to the reference text for verification that I transcribed them correctly. However, it would be wonderful if I could show the reference equation substitutions in the report itself!

Yes this is exactly the goal of the function functionality! I do believe it is possible. The CodeTracking.jl package allows me to pull the function head and body info from a function.

The code is there to do the latex substitution. I just need to figure out how I will parse the args and kwargs of the function!

Incredible! It looks like handcalcs.py integrates nicely with SymPy. Does Handcalcs.jl have plans to similarly integrate with Symbolics.jl in the future? And what might that look like if so?

Cool! Yeah that one exponent issue is the only thing I know of currently for unitful stuff. The back end is Latexify.jl so you can provide kwargs at the end of the handcalc macro to pass those through to latexify.

You can type for example:

a = 0.25u"ft"
b = 4u"inch"
@handcalcs c = sqrt(a^2+b^2) post = u"inch"

with Pluto you want to use begin and end statements though to get rid of the assignment callout in the top left of the output cell. Like so:

@handcalcs begin
c = sqrt(a^2+b^2)
end post = u"inch"

You can see the exponent not rendering properly in the numeric substitution part. This is probably at the top of my list to get fixed. It actually breaks when you have a unit that has an exponent that is then under an exponent. But it should hopefully work smoothly after this fix. I want to get it fixed on the latexify side though, since it is broken on that end too.

Correct. This is what I want to get fixed in Latexify. See my pull request here. This pull request fixes the issue on the latexify side. I haven’t received any responses though.

I just wanted to provide an update on the progress here, because I will be unable to work on this for a couple weeks. I have a rough working macro that does this in my handfunc branch! See example below!

Some function defined in another package

function calc_Ix(b, h)
d = if b > 4
b * 5
else
b + 5
end; "test if statement";
c = h + 6; "test equation";
Ix = b*h^3/12
end

using @handfunc (you don’t need to use begin end here but can)

And yes Ix is evaluated!! Ix being the variable assigned in the @handfunc part (variables within function are not defined in the global name space). If you assign it to a different variable then that will be the variable defined (although you will still see it as Ix in the latex portion)

The current limitations are:

You can’t have return statements in the function (I plan to filter these out before passing to be latexified.)

The names of the variables you pass to the function as parameters can not be the same name as the parameters in the actual function or any variable names defined in the function. (There is some macro hygiene I need to do).

you must pass numbers or symbols (not fields of objects). This is also a current limitation of the @handcalcs macro.

For whatever reason things work in jupyter and the repl but not pluto (I am unsure what to do here).

I believe the function needs to be defined in another package. The @code_expr macro from CodeTracking.jl does not see functions in Main for some reason.

There is also an issue with negative exponents in units:

julia> using Unitful, Handcalcs
julia> v = 10u"m/s"
10 m s^-1
julia> A = 2u"m^2"
2 m^2
julia> ρ = 1.2u"kg/m^3"
1.2 kg m^-3
julia> @handcalc mdot = ρ * v * A
L"$\begin{align}
mdot &= \rho \cdot v \cdot A = 1.2 kg m^-3 \cdot 10 m s^-1 \cdot 2 m^2 = 24.0 kg s^-1
\end{align}$

I assume that need a fix on the handcalcs side since the whole negative exponent would need to go into {}