> 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
>> (This possibly affects also speed of operations like draw, that use
>> InputForm for creating compiled functions from expressions. If things
>> go badly, it may even affect speed of the created functions.)
>>
>
On Sun, Nov 22, 2009 at 8:18 PM, Waldek Hebisch
<hebi...@math.uni.wroc.pl> wrote:
> Let me say that I am not sure if InputForm is best solution for
> problems where it is used now, in particular it looks that there
> are better ways of converting expressions to functions. But
> if we keep using InputForm for such purposes, then fully typed
> InputForm is the correct way.
>
> Current use of InputForm for plotting is a hack, I think it
> does not work for really general input form. As long as we keep
> the simplest forms untyped there should be no negative impact
> on plotting.
>
If every domain had a constructor function I think there would be no
negative impact - perhaps in some special cases even an improvement.
No?
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=.
