> > Waldek Hebisch writes: >> Martin Rubey wrote: >> > 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.
On Sun, Oct 26, 2008 at 3:09 PM, Martin Rubey wrote: > > Wonderful, we agree. > I am not convinced. If InputForm values are fully type-decorated then I am sure that there may be times - especially in calculus where typically manipulations are essentially *symbolic* in nature - where one would want to largely ignore such "exta" information. >> 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. > I do not think that efficiency is an issue. If anything, a fully typed InputForm value should be easier for the interpreter to handle than without this information. >> Another possibility is to make sure that "interpret" sees some >> standard environment, independent on what user exposed. > I rather like this idea. > I don't think that this is a good idea. I think this makes creating > InputForm's more work than necessary. How is it more work? > I'd like to be able to create an InputForm as follows: > > convert(x:%):INFORM == > packageCall(someFunctionToConstructElement, [args])$INFORM1(%) > Why do you mention "packageCall" here? >> 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. > As I mentioned in my previous reply, this is very similar to something that Gaby is already doing in OpenAxiom. >> >> 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. I also agree that in general this is a good idea, on the other hand it makes sense that symbolic manipulations be abstracted in some convenient domain. Perhaps that suggests some specific additions to the functions already exported by InputForm, but it also makes sense to me that this symbolic domain should have a close connection to the interpreter since part of the job of the interpreter is to translate from the users "symbolic notation" to algebraic computations. > ... 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 -~----------~----~----~----~------~----~------~--~---
