On Saturday 25 Jun 2011 12:27:10 Ralf Hemmecke wrote: > Hi Martin, > > on > https://github.com/martinbaker/multivector/blob/master/computation.spad.pam > phlet#L424 > > I see > > Rep := Record(nme:String) > > I cannot see a good reason for this extra Record wrapper. Why don't you > simply say > > Rep := String
Hi Ralf, I can't quite remember, I vaguely recall that I couldn't get the constructor to return an unwrapped value, but it may have been some other issue. I'm sure, whatever the reason, it would be my lack of expertise rather than a limitation in FriCAS. Also, while I'm still developing this, its quite useful that the Untyped domain has a similar sort of structure as the Typed domain and it could be that future changes might require extra extra information be held in an Untyped variable. I agree that, if the structure of this domain stays the same, then this needs to be changed. I guess the question is: when is the best time to optimise these things? There is the possibility of big architectural changes (for instance Waldeks idea to use Kernel or SEexpression) so I did not want to spend to much time on the details, which might have to be changed anyway, without giving time for the overall design to evolve. > Furthermore, I don't really like that the output looks like a string. > What was your reason for choosing this print format? Again lazyness on my part. I find it quite useful to have a toString function, in all domains for debug if nothing else, so its just easy to generate output like this: coerce(n: %):OutputForm == toString(n)::OutputForm Again, I was thinking of optimising this at a later stage, especially if more formatting is needed. Would you be happy for me to put these things on the to-do list (along with Waldeks comments about using symbols instead of literal strings or integers) or do you see them as urgent? (does github have a to-do list feature that could be used for this?) I would be very interested to hear any thoughts you might have about the top level architectural design of the computation framework. 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.
