On Mon, Oct 27, 2008 at 4:41 AM, Ralf Hemmecke wrote:
>
>>> (12) -> vl : List Symbol := [x,y]
>>>
>>> (12) [x,y]
>>> Type: List(Symbol)
>>> (13) -> p:DMP(vl,Integer):=1
>>>
>>> (13) 1
>>> Type: DistributedMultivariatePolynomial([x,y],Integer)
>
>> But what is the type of the right hand side of (13)?
>
> That is easy: DMP(vl,INT). Note that the 1 does appear in some context.
Are you sure that is what is happening here? What is the type of the rhs below?
(13') -> p:DMP(vl,Integer):=2
> If the interpreter would work similar to the compiler or as Aldor, then
> the type of the left and right hand side of := should match. So from the
> many types for 1 that are in scope here, only DMP(vl,INT) matches.
>
Although in the first case the interpreter *could* produce a call to
one()$DMP(vl,Integer), it seems more likely to me that in both (13)
and (13') the interpreter treats the rhs first as a PositiveInteger
and then looks for the coercions PI->INT and INT-> DMP(vl,INT). No?
> ...
>> Note: There is a bug here however. I should be able to write this:
>
>> (16) -> test( p=interpret(convert(p)@INFORM)$INFORM1(typeOf(p)) )
>
> You are calling test$InputFormFunctions(DMP(vl,INT)). That package does
> not have that function.
>
I don't think that's the problem. Check the parenthesis. Or look at this:
(4) -> interpret(convert(p)@INFORM)$INFORM1(typeOf(p))
Function Selection for convert
Arguments: DMP([x,y],INT)
Target type: INFORM
[1] signature: DMP([x,y],INT) -> INFORM
implemented: slot (InputForm)$ from DMP([x,y],INT)
Function Selection for interpret
Arguments: INFORM
Target type: DMP([x,y],INT)
From: INFORM1 DMP([x,y],INT)
[1] signature: INFORM -> DMP([x,y],INT)
implemented: slot (DistributedMultivariatePolynomial (x y)
(Integer))(InputForm) from INFORM1
DMP([x,y],INT)
Function Selection for x
Arguments: VARIABLE y
Target type: LIST SYMBOL
-> no function x found for arguments VARIABLE y
There are no library operations named x
Use HyperDoc Browse or issue
)what op x
to learn if there is any operation containing " x " in its name.
Cannot find a definition or applicable library operation named x
with argument type(s)
Variable y
Perhaps you should use "@" to indicate the required return type,
or "$" to specify which version of the function you need.
>> ----
>>
>> The error message above does not make sense.
>
> Well, I agree, the error message is quite misleading.
>
???
>>> I agree that both domains might be useful for "symbolic computation",
>>> but "symbolically" I can also use the big M's.
>
>> I am uncertain about the status of calculus (and some other parts of
>> mathematics) as a purely *algebraic* concept. But surely you are not
>> arguing that Axiom should not attempt to handle these sort of
>> computations? It makes sense to me to have some domain in Axiom
>> where "symbolic computation" is possible.
>
> Of course, FriCAS should also be able to cover things that the big
> M's do. I argue only that FriCAS should work "as typed as possible".
> I cannot prevent a user from giving imprecise input. There is probably
> always some guessing involved. But if finally types have been
> guessed and the user is satisfied with them, FriCAS should not use
> any conversion to an "untyped" (which InputForm is for me) object
> and later try to interpret manipulations of that. I would put the last
> thing basically on the same level as user input.
>
At some level InputForm *is* a type so what do you mean by "untyped"?
Regards,
Bill Page.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
