This should become a page where we document design issues.

(1) 
The reason for this is, that UP
is a UPOLYC
, which in turn is a
PolynomialCategory(R:Ring, E:OrderedAbelianMonoidSup, VarSet:OrderedSet)
with VarSet
being SingletonAsOrderedSet
. Hence it is currently not possible to instantiate variables
in UP
with a modeline other than
% > List SingletonAsOrderedSet
, and since the latter domain only contains "?"
, we are out of luck.
This issue might be related to the following:
Where do variables belong?
Currently, FriCAS allows
(1/x)::UP(x,FRAC POLY INT)
(2) 
and
(1/x)::UP(x,EXPR INT)
(3) 
Similarly also for MPOLY
, UTS
and the like. The issue is that it currently not clear to which domain in the tower a variable belongs to. Mathematically related is the item UEXPR
on the OldWishList.
Interface of RINTERP
I'm quite unsure what the interface of RINTERP
should look like. Originally, I just wanted to mimick the interface of PINTERP
. However, I'm not sure whether this is ideal. I'd rather fix both at once.
More to come, if there is interest.
Why do the following have Expression Integer type when they aren't integers:
sin(x)
(4) 
asin(1)
(5) 
sqrt(%pi)
(6) 
Expression Integer
refers to any expression involving
functions (or operators) and integers. If you don't tell FriCAS otherwise, then FriCAS
"thinks" of sin(x)
as sin(1*x)
i.e. an Expression
involving the function sin()
, a polynomial function x
with coefficient 1
. For example, what would you expect the
result of the expression sin(1.0*x)
to be?
sin(1.0*x)
(7) 
The type of the result of some calculation in FriCAS is often
expressed as an object of the same type as the operands that
created it. So in your example asin(1)
is an Expression Integer
for the same reason as sin(x) is an Expression Integer
and the
result is still an Expression Integer
even though FriCAS decides
to display the value of asin(1)
in a more convenient form.
Ditto sqrt(%pi)
.
In princple it should be possible to ask FriCAS to represent the result of a calculation in a different form. E.g.
asin(1)::Expression Float
(8) 
sqrt(%pi)::Expression Float
(9) 
But in some cases the result is unexpected. For example:
asin(1)::Pi
Pi is not a valid type.
Pi
is a type for certain constantvalued expressions in .
However in this case it seems that the domain Expression Integer
is not sufficiently complete to perform this conversion, though
it works in the other direction
%pi/2
(10) 
%::Expression Integer
(11) 
Comments from wyscc:
This is a quite common problem whenever a result can be expressed in a subdomain. In this case, the subdomain is Pi
. The correct way to perform conversion of types in this situation is to retract
, not coerce
since coerce
is supposedly always possible, whereas retract
is not. The Interpreter will use retract
if it is available even when ::
is used. However, Expression Integer
does not have RetractableTo(Pi)
(we can add this if we like). An example where this works is:
4/3 * 6/2
(12) 
(4/3 * 6/2)::Integer
(13) 
retract(4/3 * 6/2)@Integer
(14) 
whereas this fails.
coerce(4/3*6/2)@Integer
An expression involving @ Integer actually evaluated to one of type PartialFraction(Integer) . Perhaps you should use :: Integer .