On Sat, Dec 5, 2009 at 8:12 AM, Waldek Hebisch wrote:
> Bill Page wrote:
>> > Martin Rubey wrote:
>> >>
>> >> I would also like to see the rudimentary test file I sent to go with
>> >> this patch. ?One remark: as you probably know, I'm strongly in favour of
>> >> having InputForm keep all type information. ?I tried to prepare such a
>> >> patch, but there is a small problem in the way the InputForm of certain
>> >> elements of EXPR is created. ?I know how to fix it (and it shouldn't be
>> >> too much work), but I won't do it without being completely sure that
>> >> there is consensus that INFORM should keep type information.
>>
>> Yes, we have discussed this before. I am not in favor of adding
>> explicit domain/package calls or inserting coercions. I think that
>> every domain for which we need to create an InputForm should have it's
>> own construction function. These function names should be unique and
>> related to the domain name in an obvious manner. Eg.
>>
>> (1) -> unparse(3.141592::InputForm)
>>
>> (1) "float(231808574432053350722,-66,2)"
>> Type: String
>>
>
> AFAICS explicit constructors really do not work for parametric
> domains: currently result type can not depend on values of argument
> so you have only overloading to choose correct type. But
> interpreter currently only allows 'Type' as category of type-valued
> arguments, so it can not resolve interesting cases. Let me add
> that overloading on types arguments would significantly complicate
> typchecking, so I am not sure if we ever will support it.
>
> So explicit constructors are really only for 'special cases' and
> general case needs type annotations.
>
> As an example consider:
>
> (14) -> MP := SparseMultivariatePolynomial(Float, Integer)
>
> (14) SparseMultivariatePolynomial(Float,Integer)
> Type: Type
> (15) -> monomial(3.14, 1, 1)$MP
>
> (15) 3.14 1
> Type: SparseMultivariatePolynomial(Float,Integer)
> (16) -> (monomial(3.14, 1, 3)$MP)::InputForm
>
> (16) (float 231691105565791968297 - 66 2)
> Type: InputForm
>
> As you see currently coercion to InputForm gives bogus result. How
> you want to introduce explicit constructors for polynomials with
> variables from an arbitrary set?
>
> BTW: You may think of polynomials having integers as variables as
> a perversion, but in fact such choice is natural if you want to
> do arithmetic on variables.
>
I do not have any problem with polynomials with integer "variables".
This is certainly ok for certain "technical" applications although for
users the notation generated by OutputForm might be a bit confusing.
I agree the result in (16) is wrong but isn't this just a result of
the poor method by which the Polynomial domains produce their
InputForm? As I recall it just maps the polynomial into the InputForm
domain, so the confusion is similar to the odd visual result in
OutputForm. No?
Before we can agree whether a result is bogus or not I still think we
need to agree on the specifications for coercion to InputForm. I
proposed in another thread that this should involve
interpret$InputFormFunctions1(T)
where T is a known type such as MP above. However even in this case I
agree the result in (16) is wrong but I am not convinced that this
means we should add explicit type information to InputForm. I think we
just need a better way of representing polynomials. E.g.
(17) -> ['monomial, ['float, 231691105565791968297, -66,
2]$List(SExpression),1,3]$List(SExpression)::SExpression::InputForm
(17) (monomial (float 231691105565791968297 - 66 2) 1 3)
Type: InputForm
(18) -> interpret(%)$InputFormFunctions1(MP)
3
(18) 3.14 1
Type: SparseMultivariatePolynomial(Float,Integer)
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 fricas-de...@googlegroups.com.
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
