Knowing what package a function is from?

Both Calculus.jl and SystmUtils.jl have a simplify funtction. If I have code like.

using Calculus
using SystemUtils



how do in know which simplify it would use?

I am not an expert on this stuff, but I imagine it would depend on the argument type. The Calculus package make define simplify(::T1) while SystemUtils may define the method simplify(::T2) where T1 and T2 are types. So when you call simplify(ans) it depends on what the type is of ans.

Now if both packages define a method for the same type, that is type piracy and you’ll get ambiguity warnings (error?). To resolve the ambiguity, you can qualify the method by its module name, i.e.

# or 

Prefix the function name with the module name: Calculus.simplify.


Perfect! then I can compare outputs! I didn’t like the results of Calculus.jl simplifications, and hope that SymbolicUtils will do a better job. I’m also interested in comparing Reduce.jl (but I can’t find how to simplify it the documentation), and Maxima.jl(Maxima simplifies nice, but I need a .bar file with Windows).

SymPy.jl is also worth trying

1 Like

Calculus.jl is ancient and should not be used


@Wikunia is actually working on a project that should help with this called Seahawk.jl (link: He could probably explain more about it than I could. :slight_smile:

Going back to the question in the title, you could have used the which macro, which tells you where the method being called comes from:

julia> @which sum(rand(10))
sum(a::AbstractArray; dims) in Base at reducedim.jl:722

Seahawk can be used if you don’t know the name of the function. In this case you want to use @which

1 Like

Also worth considering.

Thank’s I’ll try to remember that.

It’ seems to work fine for me, but what would you recomend? I like Reduce.jl, but it won’t work in Markdown, and there’s some drama with the creator. Maxima.jl is probably good, but has .bar files to set up. So, I’m thinking of looking into SymPy, although I’m a bit worried that it will be slow, if it’s a frontend for python code.

Can symengine.jl do simplification? It’s a C library, that is supposedly faster.

I can make a new post on this, but here I suggested an alternate syntax for differentiation, if Calculus.jl could be rebuilt, to focus on differentiation, limits and integrals, without simplification, it would be a handy tool.

SymEngine.jl can do simplification.
I have used it for that before. it works.

I haven’t used it but I feel like ModellingToolkit is the future of practical symbolic calculus in julia
Here is its docs on deriviatives

It does simplication also, apparently via using SymbolicUtils.j

if Calculus.jl could be rebuilt, to focus on differentiation, limits and integrals, without simplification, it would be a handy tool.

When Calculus.jl says derivative at mostly means finite differencing.
which has 2 problems:

  1. Finite differencing is bad. We have excelling forward mode and reverse mode ADs so many of them. That are perfectly accurate. At least one could use ForwardDiff.jl
  2. If one really wants finite differencing, then FiniteDiff.jl and FiniteDifferences.jl are state of the art finite differencing libraries that are much more accurate.

For 1 case it means symbolic differentiation. and ModelingToolkit does that has done for ages, and is much more actively worked on.

Calculus.jl doesn’t do limits or integrals.


Thanks, I think Reduce does the same finite differencing. I was going to say that SymEngine diff() works good and gives a simplified result:


using SymEngine


instead of 24x^2+40x+6

If I foil, it works fine though, so I can do a lot with that, until I have more time to learn up on ModellingToolkit.

I seem to be able to get SymEngine to work, the only thing, and it’s not important, but is there a way to plot the symbolic output without rewriting it? I know Maxima and Reduce both plot with Gnuplot, which would also work, but Plots.jl would be best.

Yes: ModelingToolkit is built with SymbolicUtils as its utility backend. But ModelingToolkit is a full complete CAS.

That’s already been done. FiniteDiff.jl, FiniteDifferences.jl, Quadratue.jl, and ModelingToolkit.jl. And this set greatly expands the functionality, makes it an order of magnitude faster, and makes it more robust/stable. Honestly, delete Calculus.jl: it’s been done for years now. I am still surprised it ever comes up in a conversation.


It might be nice to restructure to docs positioning it as a CAS first and foremost,
with a particular set of nice things for working with differential equations.
right now the docs are very DiffEq application centric.


Also, for a specific symbol, see parentmodule.

1 Like