Renaming %A variable in FriCAS sandbox output

[h-x h.-x]

I'm playing with FriCAS in sandbox and the problem is, When asked to find indefinite integral (as well as in many other cases), FriCAS outputs auto-generated variables in a rather unsightly manner, for example,

integrate(x^x, x) 

produces

which is quite unsightly. The question is, is there a way to prettify the output? How can I substitute %A with t, for example?

By the way, what is the motivation behind writing superscript x? Can I somehow change the output format? I'm fine with having

some preprocessing function eating integrate call result and emitting some prettified latex -- but I couldn't force the sandbox to

output arbitrary latex anyway...

So, can I change %A into something else?

PS. Sorry to trouble you guys with what probably is some very basic stuff -- I first asked at mathoverflow, but had no answer there unfortunately :(

[Waldek Hebisch]

On Sun, Jul 05, 2020 at 07:18:35AM -0700, h-x h.-x wrote:
> I'm playing with FriCAS in sandbox

> <http://fricas-wiki.math.uni.wroc.pl/FriCASIntegration#bottom> and the

> problem is, When asked to find indefinite integral (as well as in many
> other cases), FriCAS outputs auto-generated variables in a rather unsightly
> manner, for example,
>
> integrate(x^x, x)
>
> produces
>
>

> which is quite unsightly. The question is, is there a way to prettify the
> output? How can I substitute %A with t, for example?
> By the way, what is the motivation behind writing superscript x? Can I
> somehow change the output format? I'm fine with having
> some preprocessing function eating integrate call result and emitting some
> prettified latex -- but I couldn't force the sandbox to
> output arbitrary latex anyway...
>
> So, can I change %A into something else?

Short answer is: do not do this. Longer explanation is as follows.
In idefinite integral logicaly you have two different variables:
variable in integrand and variable representing the upper limit
of integration. Variable in integrand is really dummy variable,
its name does not matter and you can not change it by substitution.
OTOH you can substitute for upper limit. Consider:

(7) -> ii := integral(sin(x), x)

x
++
(7) | sin(%A)d%A
++
Type: Expression(Integer)
(8) -> subst(ii, x = exp(y) + z)

y
%e + z
++
(8) | sin(%A)d%A
++
Type: Expression(Integer)

This shows that without dummy variable naive substitution could
produce nonsensical result. Why FriCAS uses '%A' as dummy?
This is to minimize risk of "variable capture". Namely if
you have something containing 't' as parameter you can not use
't' as a dummy, because this would change meaning of the integral.
Since users can substitute expressions into parameters dummy
variable should be different from "normal" variables. FriCAS
convention is that when it needs a new variable it uses names
starting with '%'. Of course, if user decides to of '%A' as
normal variable we will have problem. Somewhat ugly '%A'
should minimize temptation to use it as a "normal" variable...

Concerning superscript 'x': indefinite integral is really
a definite integral with missing lower bound. Maybe the
following internal representation makes it clearer:

(9) -> (ii::OutputForm) pretend SEX

(9) (INTSIGN (NOTHING) x (* (sin %A) (CONCAT d %A)))
Type: SExpression

Concerning prettifying result, FriCAS gives you access to
internal representation. If you insist you can implement
version of 'subst' that changes names of dummy variables
(normal 'subst' knows which variables are dummy and
skips them performing substitutions). Or you can work
with OutputForm and change names of variables there.

--
Waldek Hebisch

[h-x h.-x]

Thanks a lot! The whole reason for doing that to me is, sometimes I want to show

axiom's output to someone (and that form appears whenever axiom proves that the integral

is not an elementary function), and %A everywhere makes things harder to read.

So I thought, if I conjure a post-processing subroutine and save it, I will always be able

to get the prettified output from fricas sandbox and share it. I never intended to rename

dummy variables for any reason besides having the output look cleaner.

...hmm it seems fricas sandbox is currently broken -- or at least for me:

I go here: http://fricas-wiki.math.uni.wroc.pl/SandBoxIntegration#bottom

type a single command in an axiom block:

\begin{axiom}
ii := integral(sin(x), x)
\end{axiom}

and get this:

I'll try writing my own substitution routine when I get the chance...

When the sandbox will be back online, that is :)

вс, 5 июл. 2020 г. в 19:44, Waldek Hebisch <heb...@math.uni.wroc.pl>:

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/OcAocpXmC-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200705164411.GA5445%40math.uni.wroc.pl.

[Ralf Hemmecke]

On 7/6/20 12:19 AM, h-x h.-x wrote:
> Thanks a lot! The whole reason for doing that to me is, sometimes I
> want to show axiom's output to someone (and that form appears
> whenever axiom proves that the integral is not an elementary
> function), and %A everywhere makes things harder to read.

If you want AXIOM's output, then use AXIOM. Here you write to the FriCAS
mailing list and this is all about FriCAS (which is a fork of the AXIOM
code base, but otherwise a project on its own).

> So I thought, if I conjure a post-processing subroutine and save it,
> I will always be able to get the prettified output from fricas
> sandbox and share it. I never intended to rename dummy variables for
> any reason besides having the output look cleaner.

Well, there is a new Formatting framework (not yet in FriCAS).
https://groups.google.com/forum/#!topic/fricas-devel/VTZf_lrVXyM

With that framework it should be easy to redefine the output for the
integral sign. Just write an appropriate routine that replaces the dummy
variable by something that you like more.

Currently, since the code is not yet in FriCAS you would first have to
compile the respective FriCAS from my repository.

> ...hmm it seems fricas sandbox is currently broken -- or at least for
> me: I go here:
> http://fricas-wiki.math.uni.wroc.pl/SandBoxIntegration#bottom type a
> single command in an axiom block: \begin{axiom} ii :=
> integral(sin(x), x) \end{axiom} and get this: [image: image.png] I'll
> try writing my own substitution routine when I get the chance... When
> the sandbox will be back online, that is :)

Oh, I still see the site without errors, but I believe you that you run
into such troubles. The reason is that the code that is behind
transforming output of TexFormat into that what you see on the webpage
is not perfect.

Even if it is a little work, you should install fricas yourself or
compile my "formatted" branch.

https://github.com/hemmecke/fricas/commits/formatted

BTW, together with Kurt Pagani I work on a Jupyther frontend for FriCAS.
It's nearly finished. That should give better results wrt TeX output,
but still, it remains to write a little routine to display the dummy
variable in a nicer form.

I guess it's not satisfying what I wrote, but it still takes a while
until I am satisfied and can release the jfricas code.

Ralf

[Waldek Hebisch]

On Mon, Jul 06, 2020 at 01:19:34AM +0300, h-x h.-x wrote:
> Thanks a lot! The whole reason for doing that to me is, sometimes I want to
> show
> axiom's output to someone (and that form appears whenever axiom proves that
> the integral
> is not an elementary function), and %A everywhere makes things harder to
> read.
>
> So I thought, if I conjure a post-processing subroutine and save it, I will
> always be able
> to get the prettified output from fricas sandbox and share it. I never
> intended to rename
> dummy variables for any reason besides having the output look cleaner.

Well, the following routine substitutes for variables in OutputForm:

--------------<cut here>--------------------------------------------

)expose OutputFormTools

subst_of(f, ls, lf) ==
symbol?(f) =>
s := symbol(f)
k := position(s, ls)
k > 0 => lf(k)
f
atom?(f) => f
la := arguments(f)
nla := [subst_of(fi, ls, lf) for fi in la]
construct(operator(f), nla)$OutputFormTools

----------<cut here>----------------------------------

One can use it as follows:

(11) -> iif := integral(sin(x), x)::OutputForm

x
++
(11) | sin(%A)d%A
++
Type: OutputForm
(12) -> subst_of(iif, [%A], [t])

x
++
(12) | sin(t)dt
++
Type: OutputForm

Note: this does not perform substitution in operator position. Such
version looked more reasonable for current problem. If desired
one could also substitute for operator (just add recursive call
on operator).

> ...hmm it seems fricas sandbox is currently broken -- or at least for me:
> I go here: http://fricas-wiki.math.uni.wroc.pl/SandBoxIntegration#bottom
> type a single command in an axiom block:
> \begin{axiom}
> ii := integral(sin(x), x)
> \end{axiom}
> and get this:
> [image: image.png]
> I'll try writing my own substitution routine when I get the chance...
> When the sandbox will be back online, that is :)

For me sandbox simply works...

--
Waldek Hebisch

[h-x h.-x]

Sorry for asking what most probably was a very basic thing.

I somehow suspected that when I write

\begin{axiom}

integrate(x^x, x)

\end{axiom},

 I invoke the Risch algorithm from fricas.

Studying math is just a hobby to me, and I ended up being really curious as to how Risch's algorithm works.

So, I started reading stuff on it, albeit having extremely hard time understanding even the simplest transcendental part,

and already wondering if I would ever make it to the algebraic parts. Sometimes specific examples occur that are not

yet handled properly by any of the existing CASes -- sometimes even really simple ones like sqrt(x+sin(x)).

Thus, I often check up different CASes as to how they handle certain integrals. I don't really know how different fricas's

Risch algorithm implementation are from axiom's one, so I don't really differentiate between fricas and axiom -- and this

is why I wrote "I wanted axiom output". Sorry for confusion.

As for the sandbox, the site magically fixed itself and I can't replicate that bug anymore, even when sending the exact same thing.

I will try compiling your fork, as I happened to have a linux virtual machine available -- not sure if I'll manage tho as I never really

worked in a nix environment, being a .net developer :)

Thanks a lot!

пн, 6 июл. 2020 г. в 01:42, Ralf Hemmecke <ra...@hemmecke.org>:

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/OcAocpXmC-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/41993f21-ef31-b707-e054-597a7854f98a%40hemmecke.org.

[h-x h.-x]

Excellent! Thank you very much!

I really feel somewhat stupid because I never really touched axiom (or any other CAS, or lisp),

other than for a few trivial tasks -- and had you doing something seemingly trivial for my sake.

It would have probably taken a good couple of hours for me to get the basics of

handling expressions, if we count time spent on googling each necessary operation/call name...

The site seems to be suffering from a ddos -- or is just struggling under load, because now it sometimes

responds when I hit the preview button, but sometimes crashes in a way I print-screened before.

It's the first time I ever saw it crash like that, usually it worked great. I wonder if it is a recent regression?

By the way, this may be an even dumber (and definitely more offtopic) question, but still:

Is there a way for me to contact someone who knows what is happening inside Risch's algorithm,

who would be able to explain what exactly is wrong about a particular function (for example (x+sin(x))^(1/3) ),

so that no CAS is able to prove its integral non-elementary -- or give any decisive answer on the problem?

For certain simpler examples that drove certain CASes into troubles (and some even into freezes), I was able

to get an answer from Aaron Meurer who implemented the simplest case of the Risch's algorithm in sympy,

but certain others remained mysterious to me...

Sorry for troubling you, and thank you very much!

пн, 6 июл. 2020 г. в 02:00, Waldek Hebisch <heb...@math.uni.wroc.pl>:

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/OcAocpXmC-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200705230003.GA24181%40math.uni.wroc.pl.

[h-x h.-x]

And yet another little silly thing for me, this time about output formatting:

Is there a way to change the width limit for the expression renderer?

Here, I most certainly would appreciate the output to be rendered much wider...

(and by the way, can we tell the CAS to simplify that expression? Perhaps there is a way

to force it to assume that the denominator is never zero?)

пн, 6 июл. 2020 г. в 02:22, h-x h.-x <theh...@gmail.com>:

[Waldek Hebisch]

On Mon, Jul 06, 2020 at 02:22:04AM +0300, h-x h.-x wrote:
>
> The site seems to be suffering from a ddos -- or is just struggling under
> load, because now it sometimes
> responds when I hit the preview button, but sometimes crashes in a way I
> print-screened before.
> It's the first time I ever saw it crash like that, usually it worked great.
> I wonder if it is a recent regression?

Some operations may take long time. To avoid troubles there is a
timeout. Unfortunatly, formatting of page is also slow, so once
page is big enough timeouts are more likely.

You may try separate page. But some integration problems ATM
are impossible to show on wiki, they need more time than allowed
by timeout.

>
> By the way, this may be an even dumber (and definitely more offtopic)
> question, but still:
> Is there a way for me to contact someone who knows what is happening inside
> Risch's algorithm,
> who would be able to explain what exactly is wrong about a particular
> function (for example (x+sin(x))^(1/3) ),
> so that no CAS is able to prove its integral non-elementary -- or give any
> decisive answer on the problem?

I work on integration in FriCAS, and there are a lot of changes
compared to what Axiom did (about 40% of integration code is new
compared to Axiom era). Concerning (x+sin(x))^(1/3), this is
an easy special case and it is somewhat embarassing to say
that it is still not implemented. One explanation is that
in FriCAS I very much prefer to have general solution instead
of adding special cases which do not contribute to general
solution. Theoreticaly general problem of integrating elementary
functions containing algebraic operations is solved. However,
the first "solution" given by Risch is considered too slow even
on modern machines. Trager and Bronstein gave much better
method (core idea is the same as in Risch approach so this
is frequently called "Risch algorithm"), but there are rather
small examples where it could take unacceptably long time.

Now, in principle FriCAS contains all building blocks needed
for Trager-Bronstein method. However, currently FriCAS
uses this only in algebraic case. In mixed transcendental-
algebraic case FriCAS tries a few ad-hoc tricks, it they
do not work then FriCAS gives up.

Anyway, if you ask why algebraic part is difficult, one
short answer is that polynomials are unique factorization
domain. Once you add algebraic extentions that is
usualy no longer true. Lack of unique factorization
leads to theortical problems (which are now mostly
solved) and practical problems, because instead of using
GCD-s we need much more complicated replacements,
in particular need to calculate with divisors on
algebraic curves.

--
Waldek Hebisch

[h-x h.-x]

So, for that example, the obvious hypothesis (non-elementary) is true, I take it?

I totally agree that adding sets of heuristics does not help implementing the algorithm,

and I also think that the general methods matter the most. While helpful for the practical

uses, it does not bring us closer to a complete implementation. Even barring the constant

problem -- I suppose that the fact that currently most CASes fail at sqrt(sin(x)+x) has nothing

to do with the constant problem, right?

Btw, this exact example was how I initially found out that mathcad never checks the integration

result by differentiating it and comparing to the original integrand, because when asked to work

on that, it produces an answer that is utter nonsense, and proceeds like nothing happened.

So, currently, there is a method that would prove the above example to be non-elementary,

but its direct implementation would be so slow that there is no reason to actually implement it,

and there are currently no optimized versions of it known, so the cases are left unimplemented

until someone finds a quicker way to do it without loss of generality?

пн, 6 июл. 2020 г. в 03:23, Waldek Hebisch <heb...@math.uni.wroc.pl>:

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/OcAocpXmC-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200706002343.GA28113%40math.uni.wroc.pl.

[Waldek Hebisch]

On Mon, Jul 06, 2020 at 11:18:26AM +0300, h-x h.-x wrote:
> So, for that example, the obvious hypothesis (non-elementary) is true, I
> take it?

Yes, assuming I made no silly mistake in calculations.

> I totally agree that adding sets of heuristics does not help implementing
> the algorithm,
> and I also think that the general methods matter the most. While helpful
> for the practical

> uses, it does not bring us closer to a *complete *implementation. Even

> barring the constant
> problem -- I suppose that the fact that currently most CASes fail at
> sqrt(sin(x)+x) has nothing
> to do with the constant problem, right?

Constant problem usualy means problem of deciding if constants
are transcendental (and finding algebraic dependencies if not).
This is not a problem with 'sqrt(sin(x)+x)'.

> Btw, this exact example was how I initially found out that mathcad never
> checks the integration
> result by differentiating it and comparing to the original integrand,
> because when asked to work
> on that, it produces an answer that is utter nonsense, and proceeds like
> nothing happened.
>
> So, currently, there is a method that would prove the above example to be
> non-elementary,
> but its direct implementation would be so slow that there is no reason to
> actually implement it,
> and there are currently no optimized versions of it known, so the cases are
> left unimplemented
> until someone finds a quicker way to do it without loss of generality?

Well, for 'sqrt(sin(x)+x)' general method should run quite fast.
First step is to rewrite 'sin(x)' in terms of exponentials:

sin(x) = (exp(ix) - exp(ix)^(-1))/(2i)

In later steps we need to take square root of 'exp(ix)' so it
is convenient to write exp(ix) = t^2. Using this one can
rewrite:

sqrt(sin(x) + x) = ct^(-1)sqrt(1 - t^4 - 2it^2x)

From this form it is clear that we have pole when t = 0. General
theory says that if function is integrable, then we can integrate
by parts to eliminate the pole. We have trial form

ct^(-1)sqrt(1 - t^4 - 2it^2x) = (Bt^(-1)sqrt(1 - t^4 - 2it^2x))' + w'

where w' has no pole at t=0. Above B is a polynomial in t with
coefficients being rational functions of x. This leads to equation

c = b' - ib/2

where c is constant (from equation above) and b is coeffient of t^0
in B. This equation has no solution in rational functions, so
function is not integrable.

Now, concerning difficulties. Above I was able to factor out
c, and it plays minor role. But in general c may play important
role and it may appear in coefficient of various functions.
So pretty quickly we may be forced to deal with complicated
constant field. This is different kind of "constant problem",
theorticaly easily solvable, but in practice computations
with algebraic constans are significantly slower than in
transcendental case. The case above is easy, because we
quickly reach nonintegrability. But if untegration by
parts is succesful we go to the next step, that is to
determining logarithmic part. This needs computations
with divisors. Again, the above is easy case and FriCAS
should have no trouble with needed computations.

As I wrote, it is shame that FriCAS can not do this example.
There is class of functions were computations of general
method are doable without much trouble. So I hope to
extend class of functions which FriCAS can integrate.
OTOH it is easy to produce cases where general method
would take too much time. So, it make sense to implement
general method, however it is important to look for
improvements. FriCAS already contains several improvements
for algebraic functions, which would otherwise take too
much time. And even after that I expect some small
examples to take too long time.

If that does not sound clear let me put it in few points:
- in the past I was sceptical about utility of general
method for cases beyond algebraic functions
- I was looking for improvements and I did found a few
- recently I realised that in fact there is large class
of functions for which general method should work well


--
Waldek Hebisch

[h-x h.-x]

Thank you for your explanation!

I followed your steps somewhat, and I'm sorry in advance for putting here this blob of mathcad worksheet, but

there was no way I could handle all that manually, and I feel taking screenshots from a live sheet is the simplest way

to show how I worked my way through...

...at least not yet... BUT, at this point, B, which is a poly in t with coefficients in ℚ(x), will have to be a multiple of BSR² in order to "bring BSR up";

then we could collect further "around" BSR...

-- and, finally, B and B' have the same degree as polynomials in exp(ix), and the multiple of (t²-1)(t²+1) in the second summand

will never vanish, and we need it to vanish in order to obtain the constant expression you denoted as c (which I estimated to be 1/sqrt(2))?

Do I understand you correctly?

So, for this example, the only part that remains a mystery is the structure theorem that dictates that we shall look for the antiderivative in form (B/t)*BSR + W,

both B and W from ℚ(x)[t], and we search for them by differentiating said form and checking if such polys are even possible...

No possibilities for new logarithms in the answer?

I feel like this is getting very off-topic, considering the initial question, and am not sure as to where I could ask a question or two if you don't mind my further questions?

I'm really, really sorry to bug you with this, it is just that I have nobody who understands differential algebra enough to even talk about formal integration, let alone

trace Risch in its non-trivial cases -- and I too understand very little of it...

Thanks again for answering!

чт, 9 июл. 2020 г. в 02:52, Waldek Hebisch <heb...@math.uni.wroc.pl>:

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/OcAocpXmC-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200708235217.GA8653%40math.uni.wroc.pl.

[h-x h.-x]

(Above I mistakenly wrote (t²-1)(t²+1) instead of (t²-1)², but that does not affect the arguments that follow)

-- also, at which point the ring stops being a unique factorization domain?

сб, 11 июл. 2020 г. в 05:28, h-x h.-x <theh...@gmail.com>:

[Waldek Hebisch]

On Sat, Jul 11, 2020 at 05:28:55AM +0300, h-x h.-x wrote:
> Thank you for your explanation!
> I followed your steps somewhat, and I'm sorry in advance for putting here
> this blob of mathcad worksheet, but
> there was no way I could handle all that manually, and I feel taking
> screenshots from a live sheet is the simplest way
> to show how I worked my way through...
> [image: image.png]
> ...at least not yet... BUT, at this point, B, which is a poly in t with

> coefficients in ???(x), will have to be a multiple of BSR?? in order to "bring

> BSR up";
> then we could collect further "around" BSR...
>
> -- and, finally, B and B' have the same degree as polynomials in exp(ix),

> and the multiple of (t??-1)(t??+1) in the second summand
> will never vanish, and we need it to vanish in order to obtain the*
> constant expression* you denoted as c (which I estimated to be 1/sqrt(2))?

>
> Do I understand you correctly?
>
> So, for this example, the only part that remains a mystery is the structure
> theorem that dictates that we shall look for the antiderivative in form
> (B/t)*BSR + W,

> both B and W from ???(x)[t], and we search for them by differentiating said

> form and checking if such polys are even possible...
>
> No possibilities for new logarithms in the answer?

Well, W contains all logarithms. Let me state basic principle
first: function that have no finite poles is of form

A + B*BSR

where BSR is as you wrote and A and B are in Q(x)[t]. Without
root this is well known, at least when you write K=Q(x) and
consider elements of K(t). Now, usual proof of this in case
of K(t) uses unique factorization in K[t]. It is known that
after extending K(t) by our square root we no longer have
unique factorization in K[t] extended by the root (which
is natural ring if one wants to ape transcendental theory).
Fortunately, for looking at poles it is enough to work
using K[t] as a base ring and consider modules over it.
To fix notation I will use L to denote K(t) extended by
square root and f to dentote integrand.

One can check that derivative of logarithm can not
have pole at t=0. Since our f have poles there,
those poles must come from derivative of element of L,
call it g. So f - g' has no pole at 0. Also, f has
no finte poles outside 0. Outside 0 logarithm give
only poles of multiplicity 1. OTOH if g has finite
pole outside 0, then g' has multiple pole. Multiple pole
can not cancel with pole of multiplicity 1. So,
g has no finite poles outside 0. Any element of L
can be written as

C + D*BSR

where BSR is the root and A, B are in K(t). In particular

g = C + D*BSR

with appropriate C and D. As we argued, g has no finite
poles outside 0. At 0 g has pole of multiplicity 1. It
is easy to see that replacing BSR by -BSR in all formulas
we will get valid equality (this replacement can be vieved
as using Galois theory, but is an easy special case).
Using such replacement one can see that C = 0. Our
argument about poles means that D has pole of multiplicity 1
at 0 and no other finite poles. Consequently,

D = t^(-1)*B

where B is in K[t]. Now, B = b + t*E where E is in K[t], so

g = b*t^(-1) + E

Differentiating E*BSR we see that it has no pole at 0, so
in order for

f - g'

to have no pole at 0, we need

f - (b*t^(-1)*BSR)'

to have no pole at 0. Now we expand both terms into powers of t.
To have on pole at 0 coefficients of t^(-1) must cancel which
leads to equation that I gave previously:

c = b' - ib/2

Solution to this equation is exponential, so not in K = Q(x).

Comparing to your argument, we do not look at higher terms in B.
In fact, in cases where we can integrate by parts (solve equation
similar to the above), we stop once we arrive at t^0 in power
series expansion. We need to do similar thing at infinity
(in practice we replace t by t^(-1) and change root to match).
This ends one stage if integration procedure. After this
stage we have reduced problem to integrand which has no poles
at 0 and at infinity and ony poles of multiplicity 1 at
other places. Now we need to determine logarithmic part.
Here, lack of unique factorization is more serious.
Explaining what to do with logarithmic would make this
message much longer, so today I stop here.

--
Waldek Hebisch