(Nicolas, I'm cc'ing you because of the last two paragraphs...)

Ralf Hemmecke <[email protected]> writes:

> On 06/14/2010 03:32 PM, [email protected] wrote:
>> While we are at it, here is another example of the interpreter
>> being to ambitious:
>> ************************************************************
>> (1) -> A:Matrix IntegerMod 5 := [[2,3],[3,2]]
>> 
>>         +2  3+
>>    (1)  |    |
>>         +3  2+
>>                                                   Type: Matrix(IntegerMod(5))
>> (2) -> inverse A
>> 
>>         +  2   3 +
>>         |- -   - |
>>         |  5   5 |
>>    (2)  |        |
>>         | 3     2|
>>         | -   - -|
>>         + 5     5+
>>                                    Type: Union(Matrix(Fraction(Integer)),...)
>
> Oh, that should not happen. I only see a function
>
> convert: IntegerMod(p) -> Integer
>
> But wasn't it an agreement that only "coerce" (and perhaps "retract")
> functions are to be applied in the interpreter?

I'm afraid that i-coerce.boot does several things it shouldn't.

> I also would like the "inverse" above to fail. Better would be to offer
> PrimeField 5, but that might involve checking for primeness of 5.

no no no: IntegerMod does not have Field, and thus no inverse.

> Maybe it would be a nice exercise to create a testing branch where
> src/interp/i-coerce.boot does actually no coercion.
>
> I guess, "no coercion" is too drastic a change, but is there some nice
> way to restrict the types that are in scope and bring them in scope as
> they are needed? I'd rather like to type "import from Something" than
> having the interpreter apply a coercion I don't want.

There was an idea to write up approaches to coercion together with the
sage community and especially with Nicolas Thiery.  I think that would
be really good.

Actually, I don't know whether they face similar difficulties.

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en.

Reply via email to