I am converting some symbolic integrals to see if I can evaluate them in Julia symbolic. Some of these have things like exp(1) but Julia automatically convert this to number 2.718281828459045

What do I need to keep it as exp(1)? Here is an example

using Symbolics
@syms x
julia> x*exp(1)
2.718281828459045x

Are you saying I should make 1 as @syms 1 ? I do not understand.
Could you please show in code how your suggestion will work for the example I’ve given so that the result will come out as x*exp(1)

Thanks, This helps a little. But for what I am doing, I see two problems.

I am trying to use the symbolic integrator at Home · SymbolicNumericIntegration.jl and when called with x*exp(1) it changes it back to floating point. Here is the code

using Symbolics
using SymbolicNumericIntegration
using SymbolicUtils
@syms x
expr=x*Symbolics.Term(exp,[1])

Second issue. I am reading hundreds of integrals. with exp(1) and exp(25) and any other such expressions.

Is there a way to automate this, so that it automatically replaces exp( a_numeric_value) to Symbolics.Term(exp,[ a_numeric_value ]) so I do not have to manually edit hundreds of expressions and do this by hand for each case?

btw, thanks for the link you gave. I tried to replace the numbers with SymbolicValue(1) but it said it could not find SymbolicValue

julia> exp(SymbolicValue(1))
ERROR: UndefVarError: SymbolicValue not defined
Stacktrace:
[1] top-level scope
@ REPL[33]:1
julia> exp(Symbolics.SymbolicValue(1))
ERROR: UndefVarError: SymbolicValue not defined
Stacktrace:
[1] getproperty(x::Module, f::Symbol)
@ Base ./Base.jl:31
[2] top-level scope
@ REPL[34]:1
julia> exp(SymbolicUtils.SymbolicValue(1))
ERROR: UndefVarError: SymbolicValue not defined
Stacktrace:
[1] getproperty(x::Module, f::Symbol)
@ Base ./Base.jl:31
[2] top-level scope
@ REPL[35]:1
julia>

That was proposed pseudocode, not actual code. That issue in DataDrivenDiffEq.jl is probably solvable if the element type is allowed to be set directly. The issue is that it’s exp(1) * x so exp(1) is the coefficient which is assumed to be numeric, and that is then used to set the numeric type in the STLSQ sparse regression, but since it’s symbolic it does not have numeric operations.

Yes, and it’s symbolic-numeric, as in, it uses numerical methods to solve for the symbolic equation. So it needs to numerically evaluate, and it cannot keep a closed representation of transcendentals (nor algebraic variables, I think it can do rationals in some sense though?)

It will, it just hasn’t been done because they are generally slower and less robust than this new thing.

It’s neither here nor there: it has some upsides over other methods, and downsides over others. It’s just that given the SciML ecosystem, algorithms like this are extremely easy to write so it came first. There are some in Risch and rule-based methods in development, but of course those then have major trade-offs in speed and types of integrals they tend to fail on.