Edit detail for DesignIssues revision 3 of 3

This should become a page where we document design issues.

variables$UP

Currently, FriCAS says

(1) -> variables((x^2+2*x)::UP(x, INT))

(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.

I tried to put this on my wiki home page, but I have no idea if it was successful or not.

Why do the following have Expression Integer type when they aren't integers:

sin(x)

(4)

asin(1)

(5)

sqrt(%pi)

(6)

Type 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 constant-valued 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 .