Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin Rubey wrote:
> >
> > I'm not completely sure about the following (well, to be honest, I am, but
> > I think I shouldn't be). In any case, I think we should take a decision.
> > I see two possibilities:
> >
> > A) InputForm should be precise. I.e., a given InputForm completely
> > determines which functions are called, independent on what is exposed etc.
> >
> > B) InputForm should be vague. I.e., calling "interpret" on a given
> > InputForm mimicks behaviour at the prompt.
> >
> > Currently, at least seriesSolve$EXPRODE depends on behaviour B: the
> > InputForm corresponding to an element of EXPR INT is *not* decorated with
> > package calls, and can easily be re-interpreted as function from UTS ->
> > UTS.
>
> I believe that we should not depend on such behaviour. "interpret" on
> InputForm should exactly recreate given object.
Wonderful, we agree.
> How to make sure that "interpret" is exact is a different matter. One
> possibility is to qualify everything, but than InputForm would be quite
> bulky.
I think that this is acceptable. One way to make it more efficient is to get
the symbols from a global table. But I think that currently this would be
premature.
> Another possibility is to make sure that "interpret" sees some standard
> environment, independent on what user exposed.
I don't think that this is a good idea. I think this makes creating
InputForm's more work than necessary. I'd like to be able to create an
InputForm as follows:
convert(x:%):INFORM ==
packageCall(someFunctionToConstructElement, [args])$INFORM1(%)
> Or we can change representation of InputForm, for example annotating
> InputForm with type information (that should be less bulky that explicit
> coercions).
I do not think that this is necessary right now, but if we run into trouble,
yes.
> > I think that this is not a very robust and clean solution, as demonstrated
> > also by #301. I see two possibilities:
> >
> > a) provide a function that takes an InputForm, and converts calls to EXPR
> > INT to calls to UTS or whatever needed.
> >
> > b) take a completely different approach.
> >
> > Ideas?
> >
>
> ATM I do not know why EXPRODE works via InputForm, at first glance
> this looks like useless complication -- one possible reason is
> that EXPRODE wants to re-use existing tree walkers (one producing
> InputForm, the other in the interpreter). However, limit machinery
> contains tree walker which expands expressions into power series,
> so it would be natural to use the same tool in EXPRODE.
I have no idea how much work this could be, but yes, I agree. And, as I said
before, seriesSolve$EXPRODE should allow more general expressions than
currently, i.e., be merged with a package that covers my seriesSolve hack.
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
-~----------~----~----~----~------~----~------~--~---
