On Thu, Feb 04, 2021 at 10:08:53AM -0800, Tobias Neumann wrote:
> Dear FriCAS group,
>
> thinking about writing in Aldor instead of SPAD (to have better error
> messages and maybe less quirks) I came across a few issues. As an example I
> want to (again) write a wrapper over Taylor series with a subsequent
> 'approximate' (see code below).
>
> There seems to be an issue finding 'approximate' from
> UnivariateTaylorSeries (available through UnivariatePowerSeriesCategory):
> [L32 C62] #1 (Error) There are no suitable meanings for the operator
> `approximate$UnivariateTaylorSeries(Expression(Integer), sym, x...'.
>
> I was thinking that this might likely be the same issue as with SPAD, that
> is I have to check whether Expression(Integer) has the approriate 'coerce'
> and '^' operations. Unfortunately this does not seem solve the problem, and
> with the additional conditions as below 'taytest' is also no longer exposed.
This may be the same issue: when calling FriCAS functions Aldor
uses type information extracted from FriCAS. In principle
single reasom may lead to failure in FriCAS and to wrong info
(hence failure) in Aldor. However, Aldor seem to be smart
enough to notice that there are no free parameters and
consequently that runtime test "can not" give different
value than compile time test.
>
> Is there a way to completely erase a package from the interpreter
> environment? For example, even after a ")clear completely", ")show
> TaylorPackage" still shows that this domain is "available". Sometimes it
> seems that I have to recompile/load packages twice or restart FriCAS,
> especially after a type signature has changed (that is even after ")clear
> completely").
ATM there is no way. You can partially hide a package (or
domain) using ')unexpose'. In principle implementing erase
for packages is easy, but careless use of erase could lead to
strange results because there is a lot of dependencies
between constructors and current code assumes checks were
done at compiler time. To give you a taste of possible
problems look at:
(2) -> )unexpose Equation
Equation is now explicitly hidden in frame frame1
(2) -> 1 = 2
There are 2 exposed and 1 unexposed library operations named
equation having 2 argument(s) but none was determined to be
applicable. Use HyperDoc Browse, or issue
)display op equation
to learn more about the available operations. Perhaps
package-calling the operation or using coercions on the arguments
will allow you to apply the operation.
Cannot find a definition or applicable library operation named
equation with argument type(s)
PositiveInteger
PositiveInteger
Perhaps you should use "@" to indicate the required return type,
or "$" to specify which version of the function you need.
At first glance 'equation' above makes no sense, but interpreter
has hardcoded info about 'Equation' and converts '=' to 'equation'
without checking if 'Equation' is exposed.
Basically, when there are dependencies between domains erasing
one should erase all domains depending on it. But FriCAS does
not track dependencies, so it would need to erase all, that is
perform a restart. Alternatively, instead of really erasing
domains one could try to partially hide them, so that explicit
references would fail but dependencies would still work.
As you can see from 'equation' above hiding domains without
bad effects also is not that easy.
> Is there a noticeable performance difference between SPAD and Aldor
> compiled programs? I'm surprised that for the small test code I have
> written the generated Lisp code is several times smaller with SPAD. Maybe
> there is a lot of "auxiliary" code generated with Aldor that isn't involved
> or used, but if there is a real factor of ~5-10 overhead, it's something to
> think about.
Pure Aldor code should be faster than FriCAS code (assuming
you crank up Aldor optimization settings). However, when calling
FriCAS code from Aldor expect worse performance than Spad: FriCAS
code is a black box to Aldor while Spad compiler sees the code
and can perform some optimizations. Size of generated Lisp may
be misleading, better look as size of .fasl file (which contains
actual machine code).
--
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/20210205005154.GA16835%40math.uni.wroc.pl.
