Hi, I would preferably use /1
Something like *1/1 ord use 2/1 for example. Awful but usable. Greg Le sam. 7 août 2021 à 20:02, Waldek Hebisch <[email protected]> a écrit : > > 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. -- 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/CAHnU2dbsgTK6n8RGNRF41S9CBXs_y09GfJtFq7Gxew715LyiHw%40mail.gmail.com.
