oldk1331 wrote:
>
> This bug originates from this:
> There are something got printed out before real answer:
>
> (1) -> integrate(x*tan(x),x)
> dilog
> 2
> 2cos(x) 2cos(x)sin(x)
> [----------------- + ----------------- %i]
> 2 2 2 2
> sin(x) + cos(x) sin(x) + cos(x)
>
> (1)
> +---+ +---+
> 2\|- 1 2\|- 1
> - 2x log(---------------) - 2x log(- ---------------)
> +---+ +---+
> tan(x) + \|- 1 tan(x) - \|- 1
> +
> +---+ +---+
> +---+ 2\|- 1 +---+ 2\|- 1
> \|- 1 dilog(---------------) - \|- 1 dilog(- ---------------)
> +---+ +---+
> tan(x) + \|- 1 tan(x) - \|- 1
> /
> 4
> Type:
> Union(Expression(Integer),...)
>
> After some tracing, I found these extra lines are printed by
> ker2trigs_error in efstruc.spad , which called by 'try_real'
> in integrat.spad:
>
> try_real(f : F) : F ==
> pu : Union(F, "failed") := trappedSpadEval(real(f))$Lisp
> pu case F => p
> f
>
> ker2trigs_error(op : OP, arg : List GF) : GF ==
> print(op::OutputForm)$OutputForm
> print(arg::OutputForm)$OutputForm
> error "ker2trigs: cannot convert kernel to gaussian function"
>
> A simpler "real dilog %i" triggers this bug:
>
> (6) -> real dilog %i
> dilog
> [%i]
>
> >> Error detected within library code:
> ker2trigs: cannot convert kernel to gaussian function
>
> Here are my questions:
>
> (1) Should ker2trigs handle dilog?
No. 'ker2trigs' tries to write expression in "rectangular form",
that is give real expressions for real and imaginary part in
terms of real and imaginary parts of arguments. AFAIK there
are no such expression for 'dilog'. So it is not possible
for 'ker2trigs' to do what is requested, so only remaining
possibility is to signal error.
> (2) Whether ker2trigs handles dilog or not, 'integrate' should not
> print these debug message, I think the 'print' expression in
> ker2trigs_error should be commented out.
Well, from point of view of 'real' this is error that should
be reported. So removing 'print' from 'ker2trigs' is out
of question. We could try to make the printout conditional,
so that 'real' alone will signal error, but when called
via 'trappedSpadEval' the printout will be supressed.
Let me add that call from 'integrate' to 'real' is a bug,
it causes various problems. But currently just omiting
call to 'real' causes worse problems. Namely, integrator
sometimes produces results which look complex (contain %i
or roots of negative number) but are in fact real. So we
need to implement a new routine, which finds real form
of integration result if possible.
My efforts mostly went into eliminating need to call real
from integrator -- there is still significant work to do
but now integrator produces real results in many cases
that previously gave complex expressions.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
