Ralf Hemmecke wrote:
>
> On 10/13/2014 03:46 AM, Waldek Hebisch wrote:
> >> Unfortunately, that would mean some more deep change to Algebra,
> >> since FriCAS, for example uses differentiate: (%, Symbol) -> % in
> >> Expression(R) which is basically used in DERHAM (and, of course,
> >> it's somehow convenient).
> >
> > It make sense to omit variable names in some cases, for example
> > SparseUnivariatePolynomial gets a lot of use. But in general names
> > are important for readability and FriCAS tries to follow traditional
> > notation. So we should support names.
>
> I've nothing against names. Only if they are meant to be important for
> the domain. I'd rather consider them as an optional parameter of a
> domain so that the printing of the objects looks nice.
>
> I.e. if no variables are given, something like x1, x2, etc is used. Or
> maybe a new (default) symbol for each domain, so that there will be no
> conflicts.
ATM we do not have optional parameters. If we had them, they could
be useful. But for example passing polynomial with wrong variables
is a type error now. I am not sure how optional parameters would
interact with typechecking.
>
> And I rather think we should have two levels of such domains. The lower
> level should basically work without variables and implement all the
> features. Then there could be a small wrapper domain that would serve as
> an interface to the end user. Programming should still be done with the
> low-level domain.
>
> > Well, SAE contains no names but may cause problems.
>
> Where?
Sorry, do not have example now. But some seemingly easy uses
of parameters caused trouble for Spad compiler. I think
that currently algbera contains no such problematic usese
(they would fail during compile or tests). But the way forward
is to fix Spad compiler.
>
> > Assuming that this is fixed F1 and F2 should be equal: types produced
> > by named constructors are equal when the the constructor names are
> > equal and values of arguments are equal.
>
> Are you saying that DirectProduct(5,Integer) and
> DirectProduct(2+3,Integer) are identical types in FriCAS?
>
> OK, I would understand if they are identical in the interpreter.
> But in SPAD? Does the compiler evaluate?
Types are identical, you can use 'is' to check that. Another
matter is that Spad compiler _during compilation_ can not
see that expression you gave produce the same type. But in
Spad types are first class and runtime testing shows that
they are equal.
--
Waldek Hebisch
[email protected]
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
