[fricas-devel] interoperability with sage again

['Martin R' via FriCAS - computer algebra system]

Dear all,

as you may know, I am trying to improve the accessibility of FriCAS from
sage, since some people (including myself) value FriCAS strengths.

I wanted to add functionality to translate FriCAS' sums and products into
sage's, but ran into a stupid problem.

Basically, I use the unparsed InputForm to obtain an expression tree from
FriCAS EXPR. Consider now:

(52) -> f := guess([reduce(*, [reduce(+, [1/k for k in 1..m], 0) for m in
1..n], 1) for n in 0..10]).1

p - 1
n - 1 11
++-++ --+ 1
(52) | | > ------- + 1
| | --+ s + 2
p = 0 s = 0 10
11 10
Type:
Expression(Integer)
(53) -> f::INFORM

(53)
(%defprod (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX - 1)) 1)
%LX (*01000p 11) 0 (+ n - 1))
Type:
InputForm

As you can see, the summation variables have subscripts. However, the
string representation of the InputForm of scripted symbols does not allow
to reproduce the symbol. In fact, the code in symbol.spad is simply:

convert(s : %) : InputForm == convert(s pretend Symbol)$InputForm

Would it be possible to change that to something like the following
(WARNING: only lightly tested!). Two comments:

1) The scripts are of type OutputForm, but there is no way to get an
InputForm from an OutputForm. So the below will not work always, but only
when the input is reasonable. In fact
interpret convert subscript('s, [z^2]) works...

2) There seems to be a problem when the subscript has a value. For
example, x := subscript('s, ['x^2]) produces an error about cons'ing
InputForm with InputForm. Not sure what's happening there.

Best wishes,

Martin

Code:

convert(s: Symbol): InputForm ==
not scripted? s => convert(name s)$InputForm

ls := scripts s
A: List InputForm := [e pretend InputForm for e in ls.sub]
B: List InputForm := [e pretend InputForm for e in ls.sup]
C: List InputForm := [e pretend InputForm for e in ls.presup]
D: List InputForm := [e pretend InputForm for e in ls.presub]
E: List InputForm := [e pretend InputForm for e in ls.args]
a: InputForm := convert('script)
b: InputForm := convert name s
c: InputForm := cons(convert('construct), [cons(convert('construct), e)
for e in [A, B, C, D, E]])
convert([a, b, c])

[Ralf Hemmecke]

Hi Martin,

Post by 'Martin R' via FriCAS - computer algebra system
(52) -> f := guess([reduce(*, [reduce(+, [1/k for k in 1..m], 0) for m in
1..n], 1) for n in 0..10]).1
p - 1
n - 1 11
++-++ --+ 1
(52) | | > ------- + 1
| | --+ s + 2
p = 0 s = 0 10
11 10
Expression(Integer)
(53) -> f::INFORM
(53)
(%defprod (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX - 1)) 1)
%LX (*01000p 11) 0 (+ n - 1))
InputForm

I think that going via InputForm is not the right way to do such a
conversion from FriCAS Expression(INT) into a Sage expression.

Wouldn't it be wiser to add functions to Expression in order to
decompose an element. There are already some such functions.

http://fricas.github.io/api/FunctionSpace.html#l-function-space-is-expt

You probably also have to look at how sum and prod is represented in FriCAS.

Ralf

[Bill Page]

Post by Ralf Hemmecke
I think that going via InputForm is not the right way to do such a
conversion from FriCAS Expression(INT) into a Sage expression.

I disagree.

Post by Ralf Hemmecke
Wouldn't it be wiser to add functions to Expression in order to
decompose an element.

No, not in the case of the Sage interface to FriCAS.

[Ralf Hemmecke]

Post by Bill Page

Post by Ralf Hemmecke
Wouldn't it be wiser to add functions to Expression in order to
decompose an element.

No, not in the case of the Sage interface to FriCAS.

Can you give a reason why?

A function that would enable to go step by step through an expression
tree in FriCAS wouln't be such a bad idea even though the representation
of Expression(INT) is a rational function, but still the idea is
"expression tree".

Ralf

['Martin R' via FriCAS - computer algebra system]

Sorry, emails crossed...

Post by Ralf Hemmecke

Post by Bill Page

Post by Ralf Hemmecke
Wouldn't it be wiser to add functions to Expression in order to
decompose an element.

No, not in the case of the Sage interface to FriCAS.

Can you give a reason why?
A function that would enable to go step by step through an expression
tree in FriCAS wouln't be such a bad idea even though the representation
of Expression(INT) is a rational function, but still the idea is
"expression tree".

As far as I understand, InputForm is achieving precisely this, except that
it is not restricted to EXPR:

(2) -> integrate(sin(x^2), x)::INFORM

(2) (/ (fresnelS (* x (^ (/ 2 (pi)) (/ 1 2)))) (^ (/ 2 (pi)) (/ 1 2)))
Type:
InputForm

is an expression tree.

(3) -> 1.23::INFORM

(3) (float 181515961685301987901 - 67 2)
Type:
InputForm

Of course, some (type) information may be lost - not by design, but rather
because of implementation details. But in general, things work well:

(12) -> (matrix [[(i+j)::PF(2) for i in 1..3] for j in 1..3])::INFORM

(12)
(matrix

(construct

(construct (($elt (PrimeField 2) index) 2)
(($elt (PrimeField 2) index) 1) (($elt (PrimeField 2) index) 2))


(construct (($elt (PrimeField 2) index) 1)
(($elt (PrimeField 2) index) 2) (($elt (PrimeField 2) index) 1))


(construct (($elt (PrimeField 2) index) 2)
(($elt (PrimeField 2) index) 1) (($elt (PrimeField 2) index) 2))
)
)
Type:
InputForm
The sage interface uses this information:

sage: fricas("(matrix [[(i+j)::IntegerMod(2) for i in 1..3] for j in
1..3])").sage().parent()
Full MatrixSpace of 3 by 3 dense matrices over Ring of integers modulo 2

just noticed a bug that PrimeField is not translated :-)

sage: fricas("(matrix [[(i+j)::PF(2) for i in 1..3] for j in 1..3])").sage()
...
NotImplementedError: The translation of FriCAS type (PrimeField 2) to sage
is not yet implemented.

All the best,

Martin

['Martin R' via FriCAS - computer algebra system]

Post by Ralf Hemmecke
I think that going via InputForm is not the right way to do such a
conversion from FriCAS Expression(INT) into a Sage expression.
Wouldn't it be wiser to add functions to Expression in order to
decompose an element. There are already some such functions.

At least for the moment, no. The problem is that, currently and in the
near future, there is no (sensible) way to access FriCAS data structures
from sage directly. While I know that this would be possible in principle,
I do not have the expertise to do that, and so far, nobody indicated that
(s)he would be able and have the time to do it.

But even then, I think that InputForm would be the correct way to talk to
other systems, because it is a very general way to transport typed
information.

In any case, currently all I can get from FriCAS is a string. There is a
reasonably efficient and well-maintained, parser in sage, all I have to do
is to provide a lookup table which tells it how to interpret a particular
function, which is completely straightforward most of the time, and
extremely easy to maintain. For example:

def safe_subs(f, v, n):
if n in f.variables():
return f, v
return f.subs({v:n}), n

register_symbol(lambda f,v,n,a,b: symbolic_sum(*(safe_subs(f, v, n)
+ (a, b))), {'fricas':'_defsum'})
register_symbol(lambda f,v,n,a,b: symbolic_prod(*(safe_subs(f, v,
n) + (a, b))), {'fricas':'_defprod'})

is all I have to do to make the translation for sums and products. (FriCAS
has the
concept of dummy variables, which sage has not, that's the reason for
"safe_subs".)

Note that for other FriCAS types, I use a slightly different approach, but
still mostly
the InputForm. For those FriCAS domains that lack InputForm, I have to use
ugly
hacks, but that's OK...

Anyway, it would be great to have a polished version of my proposal in the
next release...

Martin

[Bill Page]

On Thu, Jul 5, 2018 at 11:17 AM, 'Martin R' via FriCAS - computer

Post by 'Martin R' via FriCAS - computer algebra system
Would it be possible to change that to something like the following
(WARNING: only lightly tested!).

+1

Post by 'Martin R' via FriCAS - computer algebra system
1) The scripts are of type OutputForm, but there is no way to get an
InputForm from an OutputForm. So the below will not work always, but only
when the input is reasonable. In fact
interpret convert subscript('s, [z^2]) works...
2) There seems to be a problem when the subscript has a value. For example,
x := subscript('s, ['x^2]) produces an error about cons'ing InputForm with
InputForm. Not sure what's happening there.
Best wishes,
Martin
convert(s: Symbol): InputForm ==
not scripted? s => convert(name s)$InputForm
ls := scripts s
A: List InputForm := [e pretend InputForm for e in ls.sub]
B: List InputForm := [e pretend InputForm for e in ls.sup]
C: List InputForm := [e pretend InputForm for e in ls.presup]
D: List InputForm := [e pretend InputForm for e in ls.presub]
E: List InputForm := [e pretend InputForm for e in ls.args]
a: InputForm := convert('script)
b: InputForm := convert name s
c: InputForm := cons(convert('construct), [cons(convert('construct), e)
for e in [A, B, C, D, E]])
convert([a, b, c])
--

I think this is a very good idea.

['Martin R' via FriCAS - computer algebra system]

Can I do anything to facilitate inclusion in FriCAS?

It would be relatively urgent, because it holds up other stuff and I cannot
see how to work around this. So I'd be extremely grateful if it would make
it into the next release.

Martin

[Bill Page]

On Sat, Jul 7, 2018 at 6:00 AM, 'Martin R' via FriCAS - computer

Post by 'Martin R' via FriCAS - computer algebra system
Can I do anything to facilitate inclusion in FriCAS?

Of course just submit a patch. Such as what you attached to your
original message. :)

Post by 'Martin R' via FriCAS - computer algebra system
It would be relatively urgent, because it holds up other stuff and I cannot
see how to work around this. So I'd be extremely grateful if it would make
it into the next release.

In your first message you wrote:

...

Post by 'Martin R' via FriCAS - computer algebra system
(53) -> f::INFORM
(53)
(%defprod (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX - 1)) 1)
%LX (*01000p 11) 0 (+ n - 1))
InputForm
As you can see, the summation variables have subscripts. However,
the string representation of the InputForm of scripted symbols does
not allow to reproduce the symbol.

Although I am very much in favor of improving the coding for
InputForm, I note what you wrote above is strictly speaking not true.

(*01000s 10) and (*01000p 11)

do contain all the information you need to reconstruct the s_{10} and
p_{11} subscripts. Could process *01000s as a function that takes one
argument 10 and produces a subscripted symbol s, etc. In the past I
have done this in FriCAS internally when wanting to interpret
InputForm expressions.

['Martin R' via FriCAS - computer algebra system]

Post by Bill Page
Of course just submit a patch. Such as what you attached to your
original message. :)

Help very much appreciated!

Post by Bill Page
...

Post by 'Martin R' via FriCAS - computer algebra system
(53) -> f::INFORM
(53)
(%defprod (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX -

1)) 1)

Post by 'Martin R' via FriCAS - computer algebra system
%LX (*01000p 11) 0 (+ n - 1))
InputForm
As you can see, the summation variables have subscripts. However,
the string representation of the InputForm of scripted symbols does
not allow to reproduce the symbol.

Although I am very much in favor of improving the coding for
InputForm, I note what you wrote above is strictly speaking not true.
(*01000s 10) and (*01000p 11)
do contain all the information you need to reconstruct the s_{10} and
p_{11} subscripts. Could process *01000s as a function that takes one
argument 10 and produces a subscripted symbol s, etc. In the past I
have done this in FriCAS internally when wanting to interpret
InputForm expressions.

Oh dear, that's very "clever". Many thanks. What information does the
01000
contain?

In any case, this raises the question:

* does the FriCAS team prefer if I do this mangling on the sage side, or
* does the FriCAS team prefer if I wait for the patch (or something
similar) above?

Martin

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
Dear all,
as you may know, I am trying to improve the accessibility of FriCAS from
sage, since some people (including myself) value FriCAS strengths.
I wanted to add functionality to translate FriCAS' sums and products into
sage's, but ran into a stupid problem.
Basically, I use the unparsed InputForm to obtain an expression tree from
(52) -> f := guess([reduce(*, [reduce(+, [1/k for k in 1..m], 0) for m in
1..n], 1) for n in 0..10]).1
p - 1
n - 1 11
++-++ --+ 1
(52) | | > ------- + 1
| | --+ s + 2
p = 0 s = 0 10
11 10
Expression(Integer)
(53) -> f::INFORM
(53)
(%defprod (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX - 1)) 1)
%LX (*01000p 11) 0 (+ n - 1))
InputForm
As you can see, the summation variables have subscripts. However, the
string representation of the InputForm of scripted symbols does not allow
convert(s : %) : InputForm == convert(s pretend Symbol)$InputForm
Would it be possible to change that to something like the following
1) The scripts are of type OutputForm, but there is no way to get an
InputForm from an OutputForm. So the below will not work always, but only
when the input is reasonable. In fact
interpret convert subscript('s, [z^2]) works...
2) There seems to be a problem when the subscript has a value. For
example, x := subscript('s, ['x^2]) produces an error about cons'ing
InputForm with InputForm. Not sure what's happening there.
Best wishes,
Martin
convert(s: Symbol): InputForm ==
not scripted? s => convert(name s)$InputForm
ls := scripts s
A: List InputForm := [e pretend InputForm for e in ls.sub]
B: List InputForm := [e pretend InputForm for e in ls.sup]
C: List InputForm := [e pretend InputForm for e in ls.presup]
D: List InputForm := [e pretend InputForm for e in ls.presub]
E: List InputForm := [e pretend InputForm for e in ls.args]
a: InputForm := convert('script)
b: InputForm := convert name s
c: InputForm := cons(convert('construct), [cons(convert('construct), e)
for e in [A, B, C, D, E]])
convert([a, b, c])

Well, you need coercion from OutputForm to InputForm. Above
you try 'pretend' but it is very poor coercion. The problem is
that InputForm is evaluated, at least you would need something
like Lisp quote. Since we do not have quote, the correct way
is to walk aroud InputForm and recursively convert them. So
correct InputForm for OutputForm of 'x^2' is something like
parsed version of the following

prefix(outputForm('^), [outputForm('x), outputForm(2)])$OutputForm

['Martin R' via FriCAS - computer algebra system]

Thanks Waldek!

I am currently preparing a proper patch. I decided to try a few
approaches, so it won't be before tonight...

Martin

Post by 'Martin R' via FriCAS - computer algebra system

Post by 'Martin R' via FriCAS - computer algebra system
Dear all,
as you may know, I am trying to improve the accessibility of FriCAS from
sage, since some people (including myself) value FriCAS strengths.
I wanted to add functionality to translate FriCAS' sums and products

into

Post by 'Martin R' via FriCAS - computer algebra system
sage's, but ran into a stupid problem.
Basically, I use the unparsed InputForm to obtain an expression tree

from

Post by 'Martin R' via FriCAS - computer algebra system
(52) -> f := guess([reduce(*, [reduce(+, [1/k for k in 1..m], 0) for m

in

Post by 'Martin R' via FriCAS - computer algebra system
1..n], 1) for n in 0..10]).1
p - 1
n - 1 11
++-++ --+ 1
(52) | | > ------- + 1
| | --+ s + 2
p = 0 s = 0 10
11 10
Expression(Integer)
(53) -> f::INFORM
(53)
(%defprod (+ (%defsum (/ 1 (+ %LW 2)) %LW (*01000s 10) 0 (+ %LX -

1)) 1)

Post by 'Martin R' via FriCAS - computer algebra system
%LX (*01000p 11) 0 (+ n - 1))
InputForm
As you can see, the summation variables have subscripts. However, the
string representation of the InputForm of scripted symbols does not

allow

Post by 'Martin R' via FriCAS - computer algebra system
convert(s : %) : InputForm == convert(s pretend Symbol)$InputForm
Would it be possible to change that to something like the following
1) The scripts are of type OutputForm, but there is no way to get an
InputForm from an OutputForm. So the below will not work always, but

only

Post by 'Martin R' via FriCAS - computer algebra system
when the input is reasonable. In fact
interpret convert subscript('s, [z^2]) works...
2) There seems to be a problem when the subscript has a value. For
example, x := subscript('s, ['x^2]) produces an error about cons'ing
InputForm with InputForm. Not sure what's happening there.
Best wishes,
Martin
convert(s: Symbol): InputForm ==
not scripted? s => convert(name s)$InputForm
ls := scripts s
A: List InputForm := [e pretend InputForm for e in ls.sub]
B: List InputForm := [e pretend InputForm for e in ls.sup]
C: List InputForm := [e pretend InputForm for e in ls.presup]
D: List InputForm := [e pretend InputForm for e in ls.presub]
E: List InputForm := [e pretend InputForm for e in ls.args]
a: InputForm := convert('script)
b: InputForm := convert name s
c: InputForm := cons(convert('construct), [cons(convert('construct),

e)

Post by 'Martin R' via FriCAS - computer algebra system
for e in [A, B, C, D, E]])
convert([a, b, c])

Well, you need coercion from OutputForm to InputForm. Above
you try 'pretend' but it is very poor coercion. The problem is
that InputForm is evaluated, at least you would need something
like Lisp quote. Since we do not have quote, the correct way
is to walk aroud InputForm and recursively convert them. So
correct InputForm for OutputForm of 'x^2' is something like
parsed version of the following
prefix(outputForm('^), [outputForm('x), outputForm(2)])$OutputForm
--
Waldek Hebisch

['Martin R' via FriCAS - computer algebra system]

I am sorry it took so long. Attached there is a patch which appears to
work well:

(1) -> (3^2)$OUTFORM

2
(1) 3
Type:
OutputForm
(2) -> (3^2)$OUTFORM::INFORM

(2) '(^ 3 2)
Type:
InputForm
(3) -> interpret((3^2)$OUTFORM::INFORM)

2
(3) 3
Type:
OutputForm
(4) -> subscript('abc, [(3^2)$OUTFORM, x])

(4) abc
2
3 , x
Type:
Symbol
(5) -> subscript('abc, [(3^2)$OUTFORM, x])::INFORM

(5)
(script abc

(construct (construct '(^ 3 2) 'x) (construct) (construct)
(construct) (construct))
)
Type:
InputForm
(6) -> interpret(subscript('abc, [(3^2)$OUTFORM, x])::INFORM)

(6) abc
2
3 , x
Type:
Symbol

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
I am sorry it took so long. Attached there is a patch which appears to
(1) -> (3^2)$OUTFORM
2
(1) 3
OutputForm
(2) -> (3^2)$OUTFORM::INFORM
(2) '(^ 3 2)
InputForm
(3) -> interpret((3^2)$OUTFORM::INFORM)
2
(3) 3
OutputForm

That is OK. But AFAICS with your code we depend on quote giving
us the right type. But it seems that this is not always so:

(11) -> interpret((1::OUTFORM)::INFORM)

(11) 1
Type: PositiveInteger
(16) -> atType((1::OUTFORM)::INFORM)$InputFormFunctions1(OUTFORM)

(16) (@ '1 (OutputForm))
Type: InputForm
(17) -> interpret(atType((1::OUTFORM)::INFORM)$InputFormFunctions1(OUTFORM))

An expression involving @ OutputForm actually evaluated to one of
type PositiveInteger . Perhaps you should use :: OutputForm .

Worse, for strings we get wrong value:

(22) -> interpret(("x"::OUTFORM)::INFORM)

(22) ""x""
Type: String

This is because coercion from strings to OutputForm adds quotes.

So minimally, one must special case coercion of OutputForm
consisting from single string.

['Martin R' via FriCAS - computer algebra system]

Cool, thank you for the hints!

I'll check whether special casing atoms makes sense. Should I prepare a
pull request or a simple patch, and should I add testcases to a new file or
to an existing file.

Finally, do you prefer the current InputForm for sum and product (%defsum,
%defprod), which "interpret" does not handle, or should I prepare a patch
for this one, too?

Best wishese,

Martin

Post by Waldek Hebisch

Post by 'Martin R' via FriCAS - computer algebra system
I am sorry it took so long. Attached there is a patch which appears to
(1) -> (3^2)$OUTFORM
2
(1) 3
OutputForm
(2) -> (3^2)$OUTFORM::INFORM
(2) '(^ 3 2)
Type: InputForm
(3) -> interpret((3^2)$OUTFORM::INFORM)
2
(3) 3
OutputForm

That is OK. But AFAICS with your code we depend on quote giving
(11) -> interpret((1::OUTFORM)::INFORM)
(11) 1
PositiveInteger
(16) -> atType((1::OUTFORM)::INFORM)$InputFormFunctions1(OUTFORM)
Type: InputForm
(17) ->
interpret(atType((1::OUTFORM)::INFORM)$InputFormFunctions1(OUTFORM))
type PositiveInteger . Perhaps you should use :: OutputForm .
(22) -> interpret(("x"::OUTFORM)::INFORM)
(22) ""x""
Type: String
This is because coercion from strings to OutputForm adds quotes.
So minimally, one must special case coercion of OutputForm
consisting from single string.
--
Waldek Hebisch

[Ralf Hemmecke]

This post might be inappropriate. Click to display it.

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
Finally, do you prefer the current InputForm for sum and product (%defsum,
%defprod), which "interpret" does not handle, or should I prepare a patch
for this one, too?

Well, InputForm should be consistent with "interpret" so please
prepare a patch.

['Martin R' via FriCAS - computer algebra system]

Dear all,

attached a patch. Curiously, the InputForm of products and sums gets rid
of subscripted symbols automagically...

all the best,

Martin

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
attached a patch. Curiously, the InputForm of products and sums gets rid
of subscripted symbols automagically...

Well, you use dummy variables in input form. Scripted symbols
only appear in names corresponding to dummies. So in effect
you drop original names of variables, replacing them by
dummies. ATM I am not sure if this matters.

Post by 'Martin R' via FriCAS - computer algebra system
@@ -470,6 +470,19 @@ OutputForm() : SetCategory with
outputForm s ==
sform concat(quote()$Character, concat(s, quote()$Character))
+ convert(a: %): InputForm ==
+ b: SExpression := a pretend SExpression
+ if atom?(b)$SExpression then
+ if string?(b)$SExpression then
+ c: String := string(b)$SExpression
+ l: Integer := maxIndex(c)
+ if l >= 2 and c.1 = c.l and c.1 = quote()$Character then
+ d: String := c.(2..(maxIndex c)-1)
+ b: SExpression := convert(d)$SExpression
+ return convert(b)$InputForm

^^^^^^^^^^^^^^^^^^^^^^^^^^^
AFAICS this has undesirable effect on symbols. Namely, symbols
are supposed to be evaluated:

(1) -> if1 := (x::Symbol)::InputForm

(1) x
Type: InputForm
(2) -> x := 5

(2) 5
Type: PositiveInteger
(3) -> interpret(if1)

(3) 5
Type: PositiveInteger

However, it seem desirable to preserve names of symbols, and with
the code above name (more precisely subscripts) can change:

(31) -> z[y]

(31) z
y
Type: Symbol
(32) -> if2 := (z[y])::InputForm

(32)
(script z
(construct (construct y) (construct) (construct) (construct) (construct)))
Type: InputForm
(33) -> y := 5

(33) 5
Type: PositiveInteger
(34) -> interpret(if2)

(34) z
5
Type: Symbol

Also for consistency with other cases we should prevent 'y' from
evaluation above.

BTW: This ilustrates that InputForm (or rather 'convert') is not
well defined. Namely, for expressions it is natural to expect
that InputForm can be evaluated and value will depend on
variables. For domains which represent values (most of
FriCAS domains) it is natural that InputForm reconstructs
the value. But there are borderline cases. In fact, it
would make sense to have two different 'convert'-s: one
which is intended to pick values from environment and
the other which should reconstruct value exactly. But
this is separate topic...

['Martin R' via FriCAS - computer algebra system]

Dear Waldek,

Post by Waldek Hebisch

Post by 'Martin R' via FriCAS - computer algebra system
Curiously, the InputForm of products and sums gets rid
of subscripted symbols automagically...

Well, you use dummy variables in input form. Scripted symbols
only appear in names corresponding to dummies. So in effect
you drop original names of variables, replacing them by
dummies.

Yes. What I found curious is that the name is preserved in FriCAS:

(10) -> p := product(1/k, k=1..n)

n
++-++ 1
(10) | | -
| | k
k = 1
Type:
Expression(Integer)
(12) -> p::INFORM

(12) (%defprod (/ 1 %B) %B k 1 n)
Type:
InputForm
(16) -> product(1/%B, %B=1..n)

n
++-++ 1
(16) | | -
| | k
k = 1
Type:
Expression(Integer)

At least for the sage interface it doesn't matter. Python is slightly
crippled what concerns identifiers, so I would have to replace the scripted
symbol with something else anyway...

Attached a new patch, treating symbols in OutputForm special.

Best wishes,

Martin

[Waldek Hebisch]

------=_Part_5621_1147149640.1532098688227
Content-Type: multipart/alternative;
boundary="----=_Part_5622_1923490781.1532098688228"
------=_Part_5622_1923490781.1532098688228
Content-Type: text/plain; charset="UTF-8"
Dear Waldek,

Post by Waldek Hebisch

Post by 'Martin R' via FriCAS - computer algebra system
Curiously, the InputForm of products and sums gets rid
of subscripted symbols automagically...

Well, you use dummy variables in input form. Scripted symbols
only appear in names corresponding to dummies. So in effect
you drop original names of variables, replacing them by
dummies.

Names of variables do not matter for kernels equality, so you
get names used in first kernel that you create.

Attached a new patch, treating symbols in OutputForm special.

OK, please commit.

['Martin R' via FriCAS - computer algebra system]

Wonderful, thank you!

If possible, could you please commit for me?

Otherwise I'll try tomorrow...

Martin

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
If possible, could you please commit for me?

OK, commited.

['Martin R' via FriCAS - computer algebra system]

Thank you!

unfortunately, I just discovered a problem:

(18) -> unparse(sum(1/factorial(k), k=1..n+m)::INFORM)
strsym: form is neither a string or symbol

I am trying to fix it...

Martin

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
(18) -> unparse(sum(1/factorial(k), k=1..n+m)::INFORM)
strsym: form is neither a string or symbol
I am trying to fix it...

There is a bug in unparse of SEGMENT:

PRETTYPRINT(unparseInputForm(sum(1/factorial(k), k=1..n+m)::INFORM)$Lisp)$Lisp
(|sum| |(| "1" "/" "factorial" "(" #1="%C" ")" |,| "equation" "(" #1#
"," "1" ".." ("n" "+" "m") ")" |)|)

Fix for this is easy, but I would like to check if there are no
related problems.

['Martin R' via FriCAS - computer algebra system]

Perhaps as follows? Besides, it seems that this was dead code before my
patch...

Martin

diff --git a/src/interp/format.boot b/src/interp/format.boot
index fc2de70..4748d9e 100644
--- a/src/interp/format.boot
+++ b/src/interp/format.boot
@@ -394,7 +394,7 @@ form2String1 u ==
lo := form2String1 first argl
argl := rest argl
(null argl) or null (first argl) => [lo, '".."]
- [lo, '"..", form2String1 first argl]
+ concat(lo, '"..", form2String1 first argl)
op = "MATRIX" => matrix2String argl
u1 is ["ROOT", arg1] =>
concat("sqrt(", appOrParen(arg1),")")

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
Perhaps as follows? Besides, it seems that this was dead code before my
patch...
Martin
diff --git a/src/interp/format.boot b/src/interp/format.boot
index fc2de70..4748d9e 100644
--- a/src/interp/format.boot
+++ b/src/interp/format.boot
@@ -394,7 +394,7 @@ form2String1 u ==
lo := form2String1 first argl
argl := rest argl
(null argl) or null (first argl) => [lo, '".."]
- [lo, '"..", form2String1 first argl]
+ concat(lo, '"..", form2String1 first argl)
op = "MATRIX" => matrix2String argl
u1 is ["ROOT", arg1] =>
concat("sqrt(", appOrParen(arg1),")")

Well, above there is also one argument case. But it seems that
simplest fix is to delete the special case for SEGMENT.
SEGMENT is also handled in 'application2String' and this
should be enough.

['Martin R' via FriCAS - computer algebra system]

Indeed, this also works. The only difference seems to be the additional
parentheses:

(3) -> unparse(sum(1/k, k=1..n)::INFORM)

(3) "sum(1/%H,equation(%H,(1..n)))"

Although inconvenient (are they necessary?), I think I can handle them.

Thanks for everything,

Martin

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
Indeed, this also works. The only difference seems to be the additional
(3) -> unparse(sum(1/k, k=1..n)::INFORM)
(3) "sum(1/%H,equation(%H,(1..n)))"
Although inconvenient (are they necessary?), I think I can handle them.

AFAICS parentheses are necessary in some cases. Deciding when to
add them would require extra code in 'unparse'. IME handling
extra parentheses in parser is trivial compared to avoiding
unnecessary ones in 'unparse'.

['Martin R' via FriCAS - computer algebra system]

Fine with me!

['Martin R' via FriCAS - computer algebra system]

unfortunately, I was mistaken. It turns out that the extra parens are
quite problematic.

The problem is that the parser for symbolic expressions provided by sage
only allows function calls of the form f(a,b,c), with very few exceptions.

In particular, expressions of the form f(a, (b, c)) are not parsed.

What I did originally (in the context of expressions only!), is to replace
".." with ",". Thus

"equation(k, (a+b)*c..n)" was replaced with "equation(k, (a+b)*c, n)",
which the parser could handle.

Thus, unless the extra parentheses can be dropped, I'm afraid I have to use
the InputForm itself (in parsed form).

The downside is that the strings which have to be processed become much
longer, usually. But I admit that I never seriously tried.

Martin

[Waldek Hebisch]

BTW Martin, have you looked at times at


https://www.12000.org/my_notes/CAS_integration_tests/index.htm

FriCAS timings are done via Sage and I see much longer times
than when I run FriCAS directly (of order 25 times longer).
Why Sage slows down things so much?

['Martin R' via FriCAS - computer algebra system]

If you post a concrete example, I can have a look. One thing is that sage
uses ecl, not sbcl. The other thing is that the size of the output might
affect the timing significantly.

Martin

Post by Waldek Hebisch
BTW Martin, have you looked at times at
https://www.12000.org/my_notes/CAS_integration_tests/index.htm
FriCAS timings are done via Sage and I see much longer times
than when I run FriCAS directly (of order 25 times longer).
Why Sage slows down things so much?
--
Waldek Hebisch

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system
If you post a concrete example, I can have a look. One thing is that sage
uses ecl, not sbcl. The other thing is that the size of the output might
affect the timing significantly.
Martin

Post by Waldek Hebisch
BTW Martin, have you looked at times at
https://www.12000.org/my_notes/CAS_integration_tests/index.htm
FriCAS timings are done via Sage and I see much longer times
than when I run FriCAS directly (of order 25 times longer).
Why Sage slows down things so much?

The 3 very first examples:

https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu1.htm#1
https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu2.htm#2
https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu3.htm#3

all give times 0.208579s, 0.218311s, 0.237783s.

In FriCAS I get:

(1) -> )set messages time on
(1) -> integrate(sqrt(2*x + 1),x)

+-------+
(2 x + 1)\|2 x + 1
(1) -------------------
3
Type: Union(Expression(Integer),...)
Time: 0.01 (IN) + 0.02 (EV) + 0.28 (OT) = 0.32 sec
(2) -> integrate(sqrt(3*x + 1)*x,x)

2 +-------+
(54 x + 6 x - 4)\|3 x + 1
(2) ---------------------------
135
Type: Union(Expression(Integer),...)
Time: 0.00 (IN) + 0.00 (EV) + 0.01 (OT) = 0.02 sec
(3) -> integrate(sqrt(x + 1)*x^2,x)

3 2 +-----+
(30 x + 6 x - 8 x + 16)\|x + 1
(3) ---------------------------------
105
Type: Union(Expression(Integer),...)
Time: 0.01 (IN) + 0.01 (OT) = 0.02 sec


The first time is longer because it includes initialization, the
other are much shorter than times reported by Nasser.

['Martin R' via FriCAS - computer algebra system]

Post by Waldek Hebisch

Post by 'Martin R' via FriCAS - computer algebra system
If you post a concrete example, I can have a look. One thing is that

sage

Post by 'Martin R' via FriCAS - computer algebra system
uses ecl, not sbcl. The other thing is that the size of the output

might

Post by 'Martin R' via FriCAS - computer algebra system
affect the timing significantly.
Martin

Post by Waldek Hebisch
BTW Martin, have you looked at times at
https://www.12000.org/my_notes/CAS_integration_tests/index.htm
FriCAS timings are done via Sage and I see much longer times
than when I run FriCAS directly (of order 25 times longer).
Why Sage slows down things so much?

https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu1.htm#1
https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu2.htm#2
https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu3.htm#3
all give times 0.208579s, 0.218311s, 0.237783s.
What timings are you comparing against? In any case, I get roughly the

same time in sage through the interface and fricas itself on my laptop.

Martin

[Waldek Hebisch]

Post by 'Martin R' via FriCAS - computer algebra system

Post by Waldek Hebisch

Post by 'Martin R' via FriCAS - computer algebra system
If you post a concrete example, I can have a look. One thing is that

sage

Post by 'Martin R' via FriCAS - computer algebra system
uses ecl, not sbcl. The other thing is that the size of the output

might

Post by 'Martin R' via FriCAS - computer algebra system
affect the timing significantly.
Martin

Post by Waldek Hebisch
BTW Martin, have you looked at times at
https://www.12000.org/my_notes/CAS_integration_tests/index.htm
FriCAS timings are done via Sage and I see much longer times
than when I run FriCAS directly (of order 25 times longer).
Why Sage slows down things so much?

https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu1.htm#1
https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu2.htm#2
https://www.12000.org/my_notes/CAS_integration_tests/reports/rubi_4_15_2/test_cases/0_Independent_test_suites/Apostol_Problems/resu3.htm#3
all give times 0.208579s, 0.218311s, 0.237783s.
What timings are you comparing against? In any case, I get roughly the

same time in sage through the interface and fricas itself on my laptop.

I gave you times on my machine in the post. The timings above are given
by Nasser. What timing do you get?

['Martin R' via FriCAS - computer algebra system]

Post by Waldek Hebisch
I gave you times on my machine in the post. The timings above are given
by Nasser. What timing do you get?

(I replaced lines of output which are not interesting with "...". This is
on a Intel(R) Celeron(R) CPU N2940 @ 1.83GHz)

...
│ SageMath version 8.3.rc1, Release Date: 2018-07-14 │
...
sage: fricas.console()
;;; Loading #P"/home/martin/sage-develop/local/lib/ecl/cmp.fas"
...
Version: FriCAS 1.3.2
...
(1) -> )set messages time on
(1) -> integrate(sqrt(2*x + 1),x)

+-------+
(2 x + 1)\|2 x + 1
(1) -------------------
3
Type:
Union(Expression(Integer),...)
Time: 0.03 (IN) + 0.08 (EV) + 0.67 (OT) = 0.78
sec
(2) -> integrate(sqrt(2*x + 1),x)

+-------+
(2 x + 1)\|2 x + 1
(2) -------------------
3
Type:
Union(Expression(Integer),...)
Time: 0.00 (IN) + 0.01 (EV) + 0.01 (OT) = 0.03
sec
(3) -> integrate(sqrt(2*x + 1),x)

+-------+
(2 x + 1)\|2 x + 1
(3) -------------------
3
Type:
Union(Expression(Integer),...)
Time: 0.00 (IN) + 0.01 (EV) + 0.01 (OT) = 0.03
sec
(4) -> integrate(sqrt(3*x + 1)*x,x)

2 +-------+
(54 x + 6 x - 4)\|3 x + 1
(4) ---------------------------
135
Type:
Union(Expression(Integer),...)
Time: 0.01 (IN) + 0.01 (EV) + 0.02 (OT) = 0.04
sec
(5) -> integrate(sqrt(3*x + 1)*x,x)

2 +-------+
(54 x + 6 x - 4)\|3 x + 1
(5) ---------------------------
135
Type:
Union(Expression(Integer),...)
Time: 0.00 (IN) + 0.01 (EV) + 0.02 (OT) = 0.03
sec
(6) -> integrate(sqrt(3*x + 1)*x,x)

2 +-------+
(54 x + 6 x - 4)\|3 x + 1
(6) ---------------------------
135
Type:
Union(Expression(Integer),...)
Time: 0.00 (IN) + 0.01 (EV) + 0.01 (OT) = 0.02
sec
(7) -> integrate(sqrt(3*x + 1)*x,x)

2 +-------+
(54 x + 6 x - 4)\|3 x + 1
(7) ---------------------------
135
Type:
Union(Expression(Integer),...)
Time: 0.00 (IN) + 0.01 (EV) + 0.01 (OT) = 0.02
sec
(8) -> integrate(sqrt(x + 1)*x^2,x)

3 2 +-----+
(30 x + 6 x - 8 x + 16)\|x + 1
(8) ---------------------------------
105
Type:
Union(Expression(Integer),...)
Time: 0.01 (IN) + 0.01 (EV) + 0.03 (OT) = 0.05
sec
(9) -> integrate(sqrt(x + 1)*x^2,x)

3 2 +-----+
(30 x + 6 x - 8 x + 16)\|x + 1
(9) ---------------------------------
105
Type:
Union(Expression(Integer),...)
Time: 0.00 (IN) + 0.01 (EV) + 0.01 (OT) = 0.02
sec
(10) -> integrate(sqrt(x + 1)*x^2,x)

3 2 +-----+
(30 x + 6 x - 8 x + 16)\|x + 1
(10) ---------------------------------
105
Type:
Union(Expression(Integer),...)
Time: 0.00 (IN) + 0.01 (EV) + 0.01 (OT) = 0.02
sec
(11) -> )qu


sage: %timeit integrate(sqrt(2*x + 1),x,algorithm="fricas")
10 loops, best of 3: 21.3 ms per loop
sage: %timeit integrate(sqrt(3*x + 1)*x,x,algorithm="fricas")
10 loops, best of 3: 24.1 ms per loop
sage: %timeit integrate(sqrt(x + 1)*x^2,x,algorithm="fricas")
10 loops, best of 3: 24.7 ms per loop