[fricas-devel] InputForm again

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

Dear all!

I would like to make another effort to promote and implement clear
semantics for InputForm. As you may know, my motivation and use case for
this is the interoperability with sage.

As an aside, I am very happy to report that these efforts finally bear
fruit:

* FriCAS was recently promoted "optional package", which means that changes
to other parts of sage must make sure that they do not break functionality
imported from FriCAS
* there is improved interest in the integration routines from FriCAS,
resulting in bug reports and feature requests

I am working on exposing more functionality (in particular, the solver for
differential equations, the manipulation of power series and the guessing
package).

The main workhorse for this is FriCAS InputForm and dom$Any. They proved
to be very efficient for performing the translation between FriCAS and sage
types.

However, I am now at the point where I am badly in need of clearer

Well, apparently InputForm was done for specific purpose
(creating functions for plotting) and most other parts
were unimplemented. So no deep reason for absence
of convertion for PositiveInteger. OTOH there is related
issue: should convertion make effort to preserve types?
If no than very simple fix should work. If we want to
preserve types, than several existing convertions would
need changes. The issue of types came, because
preserving types is needed for equality 'x = interpret(x::INFORM)'.
Currently I think that we should weaken this requirement
and instead of 'x::INFORM' have 'atType(x::INFORM)' in
the equality (otherwise all (or most) convertions need
to perform equivalent of 'atType').

As it turns out, it would be much better to separate the type information
from the rest in InputForm. Consider the following:

(5) -> l := [i for i in 1..20]@List PF 5

(5) [1,2,3,4,0,1,2,3,4,0,1,2,3,4,0,1,2,3,4,0]
Type:
List(PrimeField(5))
(6) -> l::INFORM

(6)
(construct (($elt (PrimeField 5) index) 1)
(($elt (PrimeField 5) index) 2) (($elt (PrimeField 5) index) 3)
(($elt (PrimeField 5) index) 4) (($elt (PrimeField 5) index) 5)
(($elt (PrimeField 5) index) 1) (($elt (PrimeField 5) index) 2)
(($elt (PrimeField 5) index) 3) (($elt (PrimeField 5) index) 4)
(($elt (PrimeField 5) index) 5) (($elt (PrimeField 5) index) 1)
(($elt (PrimeField 5) index) 2) (($elt (PrimeField 5) index) 3)
(($elt (PrimeField 5) index) 4) (($elt (PrimeField 5) index) 5)
(($elt (PrimeField 5) index) 1) (($elt (PrimeField 5) index) 2)
(($elt (PrimeField 5) index) 3) (($elt (PrimeField 5) index) 4)
(($elt (PrimeField 5) index) 5))
Type:
InputForm

It would be much more efficient to have (WARNING: mockup)

-> l::INFORM

(construct 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
Type:
InputForm
-> dom(l::Any)

(List (PrimeField(5)))
Type:
SExpression

So I propose the following:

***@InputForm should return an object, such that, together with the
type, the original object can be reconstructed unambiguously and
automatically

Can you agree with this?

(Note that interpret(x)$INFORM1(type) does currently not quite (but almost)
perform what I would like...)

Martin

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

I should add: I am well aware that I asked this question before, for
example in

https://groups.google.com/forum/#!topicsearchin/fricas-devel/inputform/fricas-devel/EDdvs1MaJNA

but the answers back then were not really helpful.

Thus, given the renewed interest on the sage side, I am simply hoping that
opinions changed. Of course, I would do the work. I only want to avoid to
do the work and then get a "no" afterwards.

I guess, an alternative might be a friendly (!) "fork".

Martin

[Bill Page]

On Mon, Jul 9, 2018 at 7:57 AM, 'Martin R' via FriCAS - computer

Post by 'Martin R' via FriCAS - computer algebra system
I should add: I am well aware that I asked this question before,
for example in
https://groups.google.com/forum/#!topicsearchin/fricas-devel/inputform/fricas-devel/EDdvs1MaJNA
but the answers back then were not really helpful.

After reviewing that thread I find that I did and still do agree with
your approach.

Post by 'Martin R' via FriCAS - computer algebra system
Thus, given the renewed interest on the sage side, I am simply hoping
that opinions changed. Of course, I would do the work. I only want to
avoid to do the work and then get a "no" afterwards.

I am willing to help, although as usual time is limited. The
difficulty of course is that this is not just a simple addition of
some independent domain/package to FriCAS. It actually affects nearly
all domains is the system. Still it might be more desired by some
other developers to avoid changes to InputForm as such and create such
an independent domain specifically for exchange with external systems,
say: ExternalForm. But still this would affect all other domains to
provide a coercion to ExternalForm.

It would be nice if there were some way to add a default
implementation of some conversion to ExternalForm to a category such
as SetCategory or BasicType that would automatically filter down to
all the underlying domains but right now I cannot think of anyway to
do this. Of course all values in FriCAS are Lisp values. Maybe
something is possible at this level? How well would it work to export
raw Lisp values for every domain? Just thinking out loud ...

Post by 'Martin R' via FriCAS - computer algebra system
I guess, an alternative might be a friendly (!) "fork".

Anyone can declare a fork. For example this happens by design every
time someone clones a repository in github. But the real issue is
maintenance and commitment. Usually both of these are insufficient for
real collaboration to grow. If the purpose is a fork specifically for
some flavor of FriCAS/Axiom in Sage maybe this is possible since Sage
has potentially a much larger user/developer base. But frankly, I have
not seen any evidence of that much interest in FriCAS among Sage
users. Perhaps you are aware of other working going on behind the
scenes.