On 15 November 2016 at 16:51, Waldek Hebisch <[email protected]> wrote:
> Bill Page wrote:
>>
>> On 14 November 2016 at 23:59, oldk1331 <[email protected]> wrote:
>> >> How about using List of EXPR as Rep?
>> >
>> > Second thought, it will not work, polynomial will still be expanded.
>> >
>> >> On the other hand, probably carrying it too far, one might use OutputForm
>> >> which
>> >> is very expressive and greatest possible "symbolic", if only there were a
>> >> way
>> >> back ;)
>> >
>> > Yes, something between OutputForm and Expression: it will keep the
>> > similarity
>> > of its input form and have semantic to perform various operations.
>> >
>>
>> InputForm is rather poorly named but logically I think it does fall
>> somewhere between OutputForm and Expression. Both InputForm and
>> OutputForm are represented as Lisp SExpressions
>
> No. Both InputForm and OutputForm are represented by SExpression.
> Now, compound SExpression is a list of SExpressions, but at the end
> you will get atoms.
>
Yes, the Rep of InputForm and OutputForm is actually SExpression.
However the Rep for SExpression is not given explicitly in the code.
Is your claim that "compound SExpression is a list of SExpressions"
based on this operator:
convert(l : List %) == l pretend %
but then what is the Rep of List? I think the distinction is "just
splitting hairs" so long as both InputForm and OutputForm require
built-in support from boot and Lisp coding.
>> and functionally
>> assisted by built-in boot and Lisp coding. In fact the current
>> version of 'Symbolic' takes advantage of the fact that for the most
>> part InputForm can just be interpreted as a particular sort of
>> OutputForm via 'pretend'.
>
> That is bad. There are good reasons to change representation
> of OutputForm, but we can not currently do it because code
> making unwarranted assumptions like this would get broken.
>
Yes it is bad. The current version of coerce@OutputForm is only a
quick hack that exploits this similarity. It can and should be
replaced with something smarter.
>> This is adequate in a large majority of
>> cases but it is awkward for example in representing arbitrary
>> precision Float numbers. Conversion of Float to InputForm relegates
>> this to the syntax of a function call to 'float'. As I understand it
>> the formatting of Float values is currently handled directly by coerce
>> in Float while DoubleFloat is handled by OutputForm. In principle
>> OutputForm could be improved to do both.
>
> Actually, DoubleFloat formatting is handled by coerce in
> DoubleFloat. Doubles as elements of OutputForm are probably
> still tolerated, but eventually all such uses should be
> eliminated.
OK. Of course a "smarted" version of coerce@OutputForm could handle
this properly.
>
> More generally, this is question of what is allowed set of
> atoms in SExpression and in OutputForm. Currently doubles
> are allowed as atoms (because they are available in Lisp
> and we can reuse Lisp support). However, domain semantics
> affects desired output, so all data should go trough
> "coerce(x : %) : OutputForm". OutputForm can do something,
> but that should be limited to some general formatting
> decisions. For this we may need new atoms or nodes
> (to carry extra formatting information).
>
Yes you are right. The representation of Float is a dotted pair of
integers. Give just this value it is not immediately clear whether
OutputForm can always treat such a dotted pair as a Float value.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
