On Sat, Aug 07, 2021 at 04:41:01PM +0000, Neven Sajko wrote:
> The title basically says it all. I am referring to the lack of
> appropriate coerce or convert operations that make it impossible to
> convert the simpler type to the more complex type with only :: in Spad
> code.
>
> On the other hand, if I do this in the interpreter:
> 0::Polynomial(Integer)::Polynomial(Fraction(Integer))
> I get the result as expected.
>
> Also, the situation is the same with, e.g., UnivariatePolynomial (as
> with Polynomial).
>
> I guess that it's possible to convert between polynomials with such
> differing coefficient types by disassembling into coefficients,
> converting coefficients, and then reassembling into a polynomial. But
> why isn't this built into the library as a coerce or convert
> operation?
>
> Also, how come that the interpreter has this functionality
> automatically? How is it achieved in the interpreter?
>
> Lastly, what is the recommended way to achieve a conversion like this
> in Spad code?
Ralf already mentioned PolynomialFunctions2. Interpreter has
several buitin rules for coercion, one of them is: "if there
is map between T(C) and T(D) and coerce from C to D, then
map(c -> coerce(c)@D, t) gives coercion". Currently, in Spad
one has to provide explicit code for such coercions.
What could be done: easy thing would be to add 'coerce' to
PolynomialFunctions2. In fact, there are several xxFunctions2
packages, so probably several coercions to add. OTOH,
actual code to implement coercion is smaller than package
specification, so there would be little gain from such 'coerce'.
More general problem is that currently Spad compiler sees
what is explicitly or implicitly imported, but ignores
everthing else. In particular, Spad compiler will not
"invent" a package name containing some needed function,
when needed package must be explicitely imported. Spad
compiler will not "invent" a parameter, even if for
human specific parameter looks like obvious choice.
As an example, if you need list of integers and list of
symbols you need import both List(Integer) and List(Symbol).
In principle, there shuld be possible to write something like
import List(?)
to import all possible lists and let compiler choose appropriate
parameter. However, currently this is not implemented, and
if implemented it is not clear how well it would work. There
is question of syntax, '?' could mean uspecified parameter, but
what to do when there are two parameters, or one parameter that
appears in two places? And which rules should govern choice
of parameter values. Currently interpreter uses bunch of ad-hoc
rules for parameters, and sometimes it gives rather surprising
results, in other cases interpreter is unable to find parameters
that are "obvious" to people. In interpreter normally there
is user who knows what is intended and can react to wrong
choices. In compiler we want robust rules, code that compiles
and works today, should compile and work in future, even if
compiler is enhanced and there are new domains.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20210807200244.GB12798%40math.uni.wroc.pl.
