I was not asking whether you removed all bugs from FriCAS, but rather
whether you intended to fix the "%iint in output" issue with this commit
and believe that you succeeded or whether you are *sure* that you left
some cases.
It is about conveying some information with the commit message.
On Wed, Jan 27, 2021 at 04:09:04PM -0800, Ralf Hemmecke wrote:
> Waldek,
> your commit
>
> commit 240e2641928fab6f3bd2d638c5d5c437a8f68d7a
> Author: Waldek Hebisch
> Date: Thu Jan 21 21:09:35 2021 +0100
>
> Better handle '%iint'
>
> cures the initial issue, but does it also prevent %iint
Waldek,
your commit
commit 240e2641928fab6f3bd2d638c5d5c437a8f68d7a
Author: Waldek Hebisch
Date: Thu Jan 21 21:09:35 2021 +0100
Better handle '%iint'
cures the initial issue, but does it also prevent %iint from ever appearing
in user output?
Ralf
--
You received this message because
On Sun, Jan 10, 2021 at 08:22:25PM +0800, oldk1331 wrote:
> The patch is as following or see the attachment.
>
> This code only solves the case like
>
> %iint(x,c1*%iint(c2*%iint(c3*%iint(...)/f3(x))/f2(x))/f1(x))
>
> Which is the case we encountered.
>
> I'm not aware about other integrals it
On Sun, Jan 10, 2021 at 12:57:55PM +0100, Ralf Hemmecke wrote:
> >> It would be good to know (and best specified in the code) even if
> >> it is not intended to be visible to an enduser.
>
> > BTW2: Such details as internal representation of Liouvillian
> > functions are normally left
The patch is as following or see the attachment.
This code only solves the case like
%iint(x,c1*%iint(c2*%iint(c3*%iint(...)/f3(x))/f2(x))/f1(x))
Which is the case we encountered.
I'm not aware about other integrals it can't handle, yet.
- Qian
diff --git a/src/algebra/integrat.spad
>> It would be good to know (and best specified in the code) even if
>> it is not intended to be visible to an enduser.
> BTW2: Such details as internal representation of Liouvillian
> functions are normally left undocumented, because documentation
> encourages users to depend on such details
On Sat, Jan 09, 2021 at 01:24:36PM +0100, Ralf Hemmecke wrote:
> Hi Waldek,
>
> On 09.01.21 13:01, Waldek Hebisch wrote:
> > On Sat, Jan 09, 2021 at 12:24:47PM +0100, Ralf Hemmecke wrote:
> >>> 2. As Waldek said, '%iint" should be used only internally. But the
> >>> following workaround prints
On 1/9/21 8:24 PM, Ralf Hemmecke wrote:
> But what is the meaning of
>
> log(- e x + 1) log(- e x + 1)
> %iint(e,x,- --,- --)
> ex
>
> ? It would be good to know (and best specified in the code) even if it
Hi Waldek,
On 09.01.21 13:01, Waldek Hebisch wrote:
> On Sat, Jan 09, 2021 at 12:24:47PM +0100, Ralf Hemmecke wrote:
>>> 2. As Waldek said, '%iint" should be used only internally. But the
>>> following workaround prints '%iint' as 'iint':
>>
>> What would that help? Whether it prints as %iint or
On Sat, Jan 09, 2021 at 12:24:47PM +0100, Ralf Hemmecke wrote:
> > 2. As Waldek said, '%iint" should be used only internally. But the
> > following workaround prints '%iint' as 'iint':
>
> What would that help? Whether it prints as %iint or iint, I still would
> not know how to interpret that
On Sat, Jan 9, 2021, 7:24 PM Ralf Hemmecke wrote:
> Hi Qian,
>
> > 1. Maybe Sage should be able to automatically escape '%' in its 'latex'
> > command.
>
> I don't think that is an option if %iint was not meant to be visible to
> an enduser.
I mean it's a Sage bug that it can't translate for
we can fix Sage interface only if we know what %iint stands for. Is it
a kind of polylogarithm?
On Sat, Jan 9, 2021 at 10:22 AM oldk1331 wrote:
>
> Hi, my thoughts are:
>
> 1. Maybe Sage should be able to automatically escape '%' in its 'latex'
> command.
>
> When using FriCAS to generate latex,
Hi Qian,
> 1. Maybe Sage should be able to automatically escape '%' in its 'latex'
> command.
I don't think that is an option if %iint was not meant to be visible to
an enduser.
> 2. As Waldek said, '%iint" should be used only internally. But the
> following workaround prints '%iint' as
Hi, my thoughts are:
1. Maybe Sage should be able to automatically escape '%' in its 'latex'
command.
When using FriCAS to generate latex, it returns '\%' directly.
2. As Waldek said, '%iint" should be used only internally. But the
following workaround prints '%iint' as 'iint':
diff --git
On Fri, Jan 08, 2021 at 01:11:41PM -0800, 'Nasser M. Abbasi' via FriCAS -
computer algebra system wrote:
>
> There are antiderivatives generated by Fricas which uses %iint.
>
>
> Is it possible that fricas not use %iint as that causes problem converting
> to Latex.
>
> Here is an example
>
Waldek,
you have introduced %iint here:
https://github.com/fricas/fricas/commit/3b129a3ba619d8a8825cce132170d75a236b3e57
but probably never meant it to be visible as an output form.
Ralf
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra
Hello. I use sagemath to call fricas integrate as part of build the
independent CAS integration tests.
I am not running the tests using sagemath 9.2 against Fricas 1.3.6
There are antiderivatives generated by Fricas which uses %iint.
This cause a problem when converted to Latex for the report.
18 matches
Mail list logo
