Martin Baker wrote: > > Ralf, Waldek, Andrey, > > Thank you for the useful information, I have added it to the document: > http://www.euclideanspace.com/maths/standards/program/mycode/output/ > > So here is the $64000 question ... take your time ... dramatic pause ... > > Is this a worthwhile project and would you like me to work on it? > > You probably think that, since this is an open source project, as I am > interested in it I should just start coding, see what happens and stop > wasting my time with documentation and requirements. > > However the thing about this project is that it is a big chunk of work > requiring a re-write of ALL the formatters, OutputForm and > i-output.boot. I don't think it is possible to change some formatters > and not others, so the whole thing would have to be changed in one > single release. Therefore I would be discouraged if I did a lot of work > on it and then you chose not to use it. Of course I don't expect a > guarantee that you would use any of my code, but it would be nice to > have a strong commitment, even if there were some dangers in the first > release and some interfaces might get broken.
I am commited to moving code from Boot to Spad. However, I am worried by "big bang, fresh start" approach you seem to prefer. There are dependencies, some are non-obvious. Once dependencies are resolved we will be able to make modifications to _representation_ of OutputForm without risk of significant breakup. However, currently OutputForm is used by HyperDoc code and fortran output (split between Boot and Spad). Fortran output is crappy and should be restructured. I hope that no other subsystem depends on fortran output, but as long as it stays in Boot it is hard to be sure. In the past 'unparse' (and consequently HyperDoc) used fortran routines, but this was cleaned up few years ago. HyperDoc use of OutputForm needs to be cleaned up: currently HyperDoc uses a set of "universal" routines to convert s-expressions to text form. Those routines try to handle types (as obtained from Spad compiler), OutputForm-s and some other strange stuff. Unfortunatly, this is buggy and and can not work: the same s-expression may mean different things depending on source where is came from and accordingly should give different text forms. So we need different routines depending on intended meaning. In particular, we need routine to do 1D text output of OutputForm. Coming back to 'i-output.boot', I would like to have Spad version. I believe that this is possible to do _keeping_ existing representation, after all, other formatters cope with current representation, so why should it cause extra trouble for 2D text output. It is desirable that text formatter should be able to do both 1D and 2D output. Assuming representation is unchanged, other users of OutputForm should be inaffected. Converting 'i-output.boot' to Spad is an important cleanup. As I wrote we need also to clean up fortran part and use in HypeDoc. Cleaning HypeDoc would be easier if we had decent 1D formatter. Once cleanups are done it should be possible to do significant changes to representation of OutputForm in incrementatl way. More precisely, Spad ensures that types are accessed only via well-defined interface. Living purely in Spad world we can make large change to representation without breaking users. Once we have better representation we can incrementally take advantage of it. Doing cleanup instead of writing entirely new code may look boring. However, this is safe way and IME quite efficient. Doing "freash start" rewrite may look more attractive, but in this case, due to dependencies looks more risky. In particular, as long as cleanups are not done we need to keep old OutputForm. Of course, we could have to subsystems "old" and "new". But this creates new mess. Basically everywhere w currently use OutputForm w would have to decide if we want the new or old form -- this looks unfeasible. We could create some Frankstein form combining inside new and old, but that is also quite messy. > I don't think I have the skills to work on fortran, teXmacs and efricas, > I would not even know how to test such interfaces, so someone else would > have to work on these. efricas uses either 2D text form or TeX. If both work OK and hooks are called when needed efricas should not care. Concerning tests: in the src/input subdirectory there is 'of.input' test file. If you add new construct it should get added to this file. To thes formatter just run the thest file and look if formatted output looks correct. Of course to see output would need to install Texmacs. Alternatively, capture texmacs format output to file and compare for differences -- as long as as you are not adding new constructs this should avoid major breakup. Concerning fortran: main issue is output of expression (various advanced stuff can not be represented in fortran anyway). Just compare output of several expressions -- if it stays the same that means OK. > What I could do for fortran and teXmacs is to provide skeleton > formatters which output plain unformatted text and well documented hooks > for someone else to add the formatting details. Hmm, I am affraid that means me doing the rewrite... > There are some things that would help me. I always have problems doing a > full make of FriCAS as you can see here: > http://www.euclideanspace.com/maths/standards/program/fricas/compiling/ > I did once manage to build it using CLisp but it was problematic. 1) AFAICS you succesfully compiled FriCAS 2) Apparenty you do not understand 'DESTDIR'. 'DESTDIR' is mainly for people building binary packages. The effect is that binaries are installed in different place than the place where they are intended to run. If you want to have FriCAS installed in different place than the default '/usr/local' use '--prefix' argument to configure. 3) IIRC your '100%' load is incorrect, you meant that clisp compiled FriCAS was visibly slower than binary you have. '100%' doing nothing would be a bug, '100%' load during computations is normal. On my machine in light use clisp compiled FriCAS is fast enough (I can not notice any difference in speed compared to sbcl compiled version). But on heavier computations difference is visible (in extreme cases clisp version beeing 4000 slower then sbcl version, on average sbcl gives 7 times better speed). > So if > you are planning to do a new release of FriCAS anytime soon it would > really help if you could add a new SPAD package with a function > output(domain:Type) then change everything that calls output in > 'i-output.boot' to call the SPAD code instead, which would then call the > output$Lisp. This extra indirection, via SPAD, would mean that I could > work purely by modifying the SPAD code. Re-routing call to 'output' via Spad is easy, I can do this. > I am happy to write SPAD code and to reverse engineer to SPAD by tracing > through the existing Lisp and boot code (perhaps 'happy' is not quite > the right word, concerning boot code, but you probably know what I mean). > > It would be helpful, although not essential, if there is anything you > could do to provide some sort of System command, directly in SPAD, to > get the system level data set by such things as digits(n), > outputFloating(), outputFixed(), outputGeneral(), ')set output', ')set > expose',')set fortran' and so on. If not, I can still use the Lisp calls > for now. It would just be nice to get rid of all lisp and associated > pretends. digits(n), outputFloating(), outputFixed(), outputGeneral() are defined in 'float.spad' and have nothing to do with Boot. Concerning ')set ...', associated data is accessed both from Spad and Boot. Accessing Boot (Lisp) data from Spad is quite easy, the oposite requires more work. Note that on Spad side you may have single macro which is used in all needed places. Once the macro ensures correct typing (via pretend or declartion) other use in Spad is type-checked. > On 17/03/14 22:31, Waldek Hebisch wrote: > > Use of OutputForm in SExpression can be easily removed: > > related functions are only used in genufact.spad and > > fortran.spad. Deeper problem is that fortran.spad > > apparently assumes that OutputForm = SExpression and > > passes values to Boot code with little regard to types. > > Note that defining something like OutputForm2 will help > > only a little, because code in fortran.spad is supposed > > to work on OutputForm, so you would need to keep > > all current mess supporting OutputForm. > > I really would NOT be willing to do this. The whole point is to get rid > of the mess, not replace one mess with another mess. I think we can only > move forward when we are building on solid, concise, well-typed, > well-documented code. > > I realise that Fortran is still used for industrial scale number > crunching but I don't get the impression that numerical computing is a > strong area for FriCAS? Are the people doing this sort of computing (and > the companies that support them like The Numerical ALgorithms Group Ltd) > really using FriCAS? Although there is a theoretical possibility that > people are using the fortran interface are you sure there are any real > users? Would you really be willing to put the massive amount of work in, > at the cost of future development, just to support fortran? I wouldn't. There we two fixes to fortran output following bug reports. So it is used and users care enough to report problems. As I wrote, current fortran formatter is crappy, and I would prefer to have better formatter capable of generating output in a few languages beside fortran. But combining symbolic computation with number crunching is very important. Purely symbolic computation is freqently too slow or there are no symbolic answer. Purely numeric computation may have its own inefficiencies and frequently needs long code. Generating code via symbolic computation means that real source code is much simpler than in purely numeric approach. And CAS freqently may do optimizations that are hard in traditional compilers. -- Waldek Hebisch [email protected] -- 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 http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
