On Mon, Mar 7, 2011 at 11:46 AM, Martin Baker <[email protected]> wrote: > Hi Bill and Waldek, > > Thanks for both your replies, I take your point that you are trying to > simplify the code rather than make it more complex. I just thought > that, if I'm going to mention it, better to do it while people are > working on the code. > >> (3) -> ("α"::Symbol)::Polynomial(Integer) > > I didn't realise this until you both mentioned it, definitely a hack > and far from ideal, but its useful to know about this.
Actually I did not recommend this although I knew that it was possible. What I was suggesting was adding some new (internal) representations in the Symbol domain and some association function names, e.g. _&alpha: () -> Symbol that return these symbols. These new Symbols would have to be rendered as appropriate depending on )set output. > >> 1) It seems that you really ask for "complete" support for Unicode >> (or at least mathematical subset of Unicode). Namely, for >> something better than hack above we really need a worked out >> design. > > Exactly! Of course one could also have a function such as unicode: Integer -> Symbol that does this in a more general manner. > >> For processing Unicode is done and really I see >> no reason to design something different. > > I don't quite understand this. Just so that I am completely clear > about this, are you saying that SPAD and Lisp can handle Unicode but > command line I/O is the only thing preventing this? If you are talking about unicode character support in a console session (as opposed to MathML or LaTeX) then current the command )set output algebra on does not (and I think is not intended) to handle this. "algebra" mode might be better named "ASCII" mode. The intention is to "draw" symbols, subscripts, superscripts etc. as "ASCII art". For unicode support in a console session that supports unicode one would need yet another output format, say )set output unicode on Then the internal representation of a Symbol could be rendered as appropriate for that presentation form, i.e. as a specific unicode character encoded for example in the UTF-16 character set. In this case there would be some serious decisions that might need to be made for unicode support of symbols for certain operations such as integral signs and sums etc. This might be quite non-trivial. > > Although this is non-ideal, I can certainly live with this issue (by > using the hacks that you mentioned and if required I can hack my own > local copy of html formatter) however I would be quite surprised if I > am the only one who has wanted to uses non-ascii characters with > FriCAS. Is there a list of known issues for new users where all these > workarounds could be put in one place? > > Come to think of it, is there a wish-list for FriCAS? I could think of > a long list, but perhaps I should keep quiet, I suspect you won't > agree with most of them? > I think you should not be discouraged by Waldek's response. I would like to see what you have on your mind. If you feel inclined to elaborate you are welcome to post such ideas on http://axiom-wiki.newsynthesis.org in addition to this list. 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.
