Clifford Algebra
Martin Baker
http://github.com/martinbaker/multivector/
Would you consider putting this into FriCAS?
This works with a non-orthogonal basis unlike the existing code which
gives incorrect results.
I have compared it with test cases from Bertfried here:
http://www.euclideanspace.com/maths/standards/program/clifford/test/
Further info about the code here:
http://www.euclideanspace.com/maths/standards/program/clifford/
Martin
Waldek Hebisch
> I have put a rewritten version of CliffordAlgebra here:
>
> http://github.com/martinbaker/multivector/
>
> Would you consider putting this into FriCAS?
>
> This works with a non-orthogonal basis unlike the existing code which
> gives incorrect results.
>
Yes, we certainly want handle non-orthogonal basis. I had no time
to look deeper, but AFAICS there are at least small problems to fix:
1) Description: the formula e[i]*e[j] = -e[j]*e[i] is valid only
for orthogonal basis. General rule for symmetric forms is
u^2 = Q(u). I am not sure about non-symmetric case.
2) Comment 'eFromBinaryMap(n) sets the appropriate unit elements' is
misleading. From code it is clear that it produces corresponding
element of basis, but 'unit element' in a ring typically means
something quite different. And formulas in the comment look
wrong in non-orthogonal case.
Also, it would be good to compare speed of current code and your
version. Orthogonal case is doing much simpler computation, so
it may be faster. If that is the case then it makes sense to
keep current code (renamed) and implement a switch so that
non-orthogonal case is done by your code but orthognal one
by old. Of course, if there is no significant difference in
speed (or your is faster) then we will just replace old version.
BTW: At the URL you gave I can view code, but it inside HTML
markup. How I can fetch the source? Given that it is github
I guess 'git....' but what I should put in place of dots?
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> Martin Baker wrote:
> > I have put a rewritten version of CliffordAlgebra here:
> >
> > http://github.com/martinbaker/multivector/
> >
> > Would you consider putting this into FriCAS?
> >
> > This works with a non-orthogonal basis unlike the existing code which
> > gives incorrect results.
>
> Yes, we certainly want handle non-orthogonal basis. I had no time
> to look deeper, but AFAICS there are at least small problems to fix:
>
> 1) Description: the formula e[i]*e[j] = -e[j]*e[i] is valid only
> for orthogonal basis. General rule for symmetric forms is
> u^2 = Q(u). I am not sure about non-symmetric case.
Yes this is a comment remaining from the old version, I will change this.
> 2) Comment 'eFromBinaryMap(n) sets the appropriate unit elements' is
> misleading. From code it is clear that it produces corresponding
> element of basis, but 'unit element' in a ring typically means
> something quite different. And formulas in the comment look
> wrong in non-orthogonal case.
Perhaps I should say it produces corresponding element of _Grassmann_ basis.
You can see that the /\ multiplication has been added for the exterior product
(along with the various inner products). So both Grassmann and Clifford
multiplication are supported. The 'multivectors' are stored using the
Grassmann basis as before.
> Also, it would be good to compare speed of current code and your
> version. Orthogonal case is doing much simpler computation, so
> it may be faster. If that is the case then it makes sense to
> keep current code (renamed) and implement a switch so that
> non-orthogonal case is done by your code but orthognal one
> by old. Of course, if there is no significant difference in
> speed (or your is faster) then we will just replace old version.
the variable 'orthogonal' is set when the domain is created:
orthogonal:Boolean := diagonal?(bLin)
The Clifford multiplication tests this and if true it uses a version that is
similar to the previous code. So there should not be a big performance drop.
It may be slightly slower because the old code returned the results to a
global variable 'z'. I had to change this in the non-orthogonal case to return
the result at the end of the function, in the usual way, to allow it to be
recursive and I changed it in the orthogonal case also for compatibility and
because using global variables in this way seems a bit messy. Do you prefer
things to be optimised for speed or more maintainable code? I guess this is
something to keep in mind for anyone who want to use this to build a realtime
raytracing program.
> BTW: At the URL you gave I can view code, but it inside HTML
> markup. How I can fetch the source? Given that it is github
> I guess 'git....' but what I should put in place of dots?
I am new to github (I used it because Ralf suggested it) so I don't really
know how to use it but it seems to work for me. I go to
http://github.com/martinbaker/multivector/
then click on:
clifford.spad.pamphlet
under multivector / section of the page. This shows the text of the pamphlet
file. Can anyone else see it? I would welcome any advise if there is a better
way to use github?
Martin
Ralf Hemmecke
> know how to use it but it seems to work for me. I go to
> http://github.com/martinbaker/multivector/
> then click on:
> clifford.spad.pamphlet
> under multivector / section of the page. This shows the text of the pamphlet
> file. Can anyone else see it? I would welcome any advise if there is a better
> way to use github?
There is a "Download Source" button on
http://github.com/martinbaker/multivector
But using
git clone git://github.com/martinbaker/multivector.git
is the way to obtain the (read-only) sources. Actually 'read-only' is
nonsense for git, since when you clone a repository, you have everything
local and even can commit (locally). By read-only, I just meant that you
cannot push your changes back to Martin's github account.
Even better (for other people than Martin Baker) to create an account on
github and than click the "Fork" button on
http://github.com/martinbaker/multivector
This gives a read/write repository which you can publicly write to and
leaves Martin with the option to fetch your changes.
I've just done this
http://github.com/hemmecke/multivector
Now I could say
git clone g...@github.com:hemmecke/multivector.git
(Note that the difference to the 'git clone' above!)
That gives me a local directory "multivector" on my laptop. I can then
modify Martin's file(s), commit and push the changes back to my
repository at github via
... edit inside multivector
git add FILE-THAT-WAS-CHANGED
git commit # commit locally
git push origin master # push back to github
Now Martin has the option to pull my changes into his repository. Just
by adding my repository as a "remote". On his local computer (inside
multivector) he would say
git remote add ralf git://github.com/hemmecke/multivector.git
(needs to be done only once)
and finally
git fetch ralf
(that only fetches my changes but doesn't merge them to
the current branch)
or
git pull ralf master
(that will fetch and merge to the master branch)
I haven't yet done this myself, but if there is interest I try to figure
it out and put a note on the Axiom-Wiki. I'll do that anyway in the next
few days, but "interest of others" might increase my motivation to start.
Anyway, with git there is no danger in losing data. One can easily go
back and clean up a mangled repository. However, it's maybe even easier
to test all the commands first on a clone of your original repository.
If there are any more questions left (wrt. git), I'd be happy to answer
them.
Best,
Ralf
Martin Baker
I have updated the comments in the pamphlet file as you suggested on git hub:
http://github.com/martinbaker/multivector/
Or if you prefer I have also put a copy here:
http://www.euclideanspace.com/maths/standards/program/clifford/clifford.spad.pamphlet
Martin Baker
Ralf Hemmecke
The diff is here:
http://github.com/martinbaker/multivector/commit/832899ad7bf680d23558970d241d42942903a3be
Ralf
Waldek Hebisch
>
> I have updated the comments in the pamphlet file as you suggested on git hub:
> http://github.com/martinbaker/multivector/
>
Pf := PrimeField(17)
bL := matrix([[1, 1, 0], [1, 1, 1], [0, 1, 1]])$SquareMatrix(3, PrimeField(17))
Ca := CliffordAlgebra(3, Pf, bL)
randc() == reduce('+, [random()$Pf*eFromBinaryMap(i)$Ca for i in 0..7])
(23) -> a := randc()
(23) 2 + 4e + 2e + 15e e + 6e + 3e e + 7e e + 16e e e
1 2 1 2 3 1 3 2 3 1 2 3
Type: CliffordAlgebra(3,PrimeField(17),[[1,1,0],[1,1,1],[0,1,1]])
(24) -> b := randc()
(24) 7 + 4e + 14e + 11e e + 2e + 10e e + 8e e + 8e e e
1 2 1 2 3 1 3 2 3 1 2 3
Type: CliffordAlgebra(3,PrimeField(17),[[1,1,0],[1,1,1],[0,1,1]])
(25) -> c := randc()
(25) 10 + 9e + 14e + 7e e + 10e e + 5e e + 9e e e
1 2 1 2 1 3 2 3 1 2 3
Type: CliffordAlgebra(3,PrimeField(17),[[1,1,0],[1,1,1],[0,1,1]])
(26) -> (a*b)*c - a*(b*c)
(26) 10e + 7e + 8e e + 4e + 5e e + 4e e + 15e e e
1 2 1 2 3 1 3 2 3 1 2 3
Type: CliffordAlgebra(3,PrimeField(17),[[1,1,0],[1,1,1],[0,1,1]])
so the multiplication is nonassociative. I am not sure about
nonsymmetric case, but in symmetric case Clifford algebra is
a ring and multiplication is associative. In fact, for normal
Clifford algebra (that is when we forget about extra things like
wedge product or contractions) the only things you need to test
is defining property: v*v = Q(v) for v beeing a vector and associativity
(linearty is assured by code structure, and rest is mathematical
consequence).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> I have now tried your code. There is a problem in non-diagonal case:
OK, thanks, I'll look into this.
It works for Clifford multiplication based on 2D vectors so it looks like
there is a problem with the way that it is called recursively for higher
dimensional cases.
Martin Baker
----------------------------------------------
(1) -> Pf := PrimeField(17)
(2) -> bL := matrix([[1,1],[0,1]])$SquareMatrix(2,PrimeField(17))
(3) -> Ca := CliffordAlgebra(2,Pf,bL)
(4) -> randc() == reduce('+, [random()$Pf*eFromBinaryMap(i)$Ca for i in 0..3])
(5) -> a := randc()
(5) 10 + 3e + e + 4e e
1 2 1 2
(6) -> b := randc()
(6) 15 + 2e + 16e + 2e e
1 2 1 2
(7) -> c := randc()
(7) 12 + 6e + 9e e
1 1 2
(8) -> (a*b)*c - a*(b*c)
(8) 0
Martin Baker
the tests that I have done indicate that it now works correctly for
the non-diagonal case.
I have put the working pamphlet file here:
http://github.com/martinbaker/multivector/
and here:
http://www.euclideanspace.com/maths/standards/program/clifford/clifford.spad.pamphlet
In addition to checking that the Clifford multiplication results are
associative, as required, I have also added these commands to help
with debugging and give additional confidence:
setMode("orthogonal",false)
The "orthogonal" flag is set to true if the non-diagonal terms in the
matrix are zero.
This allows a optimised Clifford multiplication for this case. The
above setMode command
can now turn that optimisation off forcing all multiplications to be
done by the more general algorithm.
This allows the output of the two algorithms to be compared. The two
methods produce the same result in the diagonal case as required.
setMode("debug",true)
This "debug" flag causes the internal working of the algorithms to be
displayed during calculations.
Martin Baker
Waldek Hebisch
> I have just fixed the bug that Waldek found in CliffordAlgebra and all
> the tests that I have done indicate that it now works correctly for
> the non-diagonal case.
>
I have now commited it to trunk. I had to adjust tests and
documentation. In the clifford.spad.pamphlet I changed few
comments. Additionally, given that about half of lines come
from old file I added back Stephen M. Watt to '\author'
line.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> documentation. In the clifford.spad.pamphlet I changed few
> comments. Additionally, given that about half of lines come
> from old file I added back Stephen M. Watt to '\author'
> line.
Waldek,
Have you left the QuadraticForm in the same pamphlet? Now that
CliffordAlgebra no longer uses QuadraticForm does it make sense for
them to be bundled together?
Also the HyperDoc 9.10 need to be amended to reflect the change to the
CliffordAlgebra constructor (use SquareMatrix instead of
QuadraticForm).
Since I don't have a lot of experience with version control tools I'll
defer to any convention you come up with on line length. I'm also
happy to go along with any conventions on authorship, I think what I
wrote was:
++ Author: Martin Baker (adapted from a version by Stephen M. Watt)
just so that Stephen M. Watt did not get the blame for anything I did!
Martin Baker
Waldek Hebisch
> > I have now commited it to trunk. ?I had to adjust tests and
> > documentation. ?In the clifford.spad.pamphlet I changed few
> > comments. ?Additionally, given that about half of lines come
> > from old file I added back Stephen M. Watt to '\author'
> > line.
>
> Waldek,
>
> Have you left the QuadraticForm in the same pamphlet? Now that
> CliffordAlgebra no longer uses QuadraticForm does it make sense for
> them to be bundled together?
>
ATM I see no reason to drop QuadraticForm, but it is not used in
other parts, so current place is as good as any other. For
Clifford algebras we may wish to use bilinear forms so actually
connection may be restored in the future.
> Also the HyperDoc 9.10 need to be amended to reflect the change to the
> CliffordAlgebra constructor (use SquareMatrix instead of
> QuadraticForm).
I have updated 9.10. We want better description, but this has to wait
for Bertfried Fauser. AFAICS Cliffod algebras with non-symmetric
form are his invention and I have found no decription beyond his paper.
ATM I either do not understand the paper or he make some wrong claims
(he claims that base space is embedded differently than in symmetric
case which is equivalent to saying that multiplication is different,
but AFAICS multiplication is the same, only extra structures
(possibly) differ). Current description is correct in symmetric
case and I am right also in non-symmetric case.
Note that 9.10 is example, so incomplete description here is not
a big problem (once the definition is cleared we probably want to
expand it).
BTW: I just noticed that I intoduced problem with TeX macros in 9.10,
I will fix it.
> Since I don't have a lot of experience with version control tools I'll
> defer to any convention you come up with on line length. I'm also
> happy to go along with any conventions on authorship, I think what I
> wrote was:
> ++ Author: Martin Baker (adapted from a version by Stephen M. Watt)
> just so that Stephen M. Watt did not get the blame for anything I did!
>
Your copy of clifford.spad.pamphlet in line 7 had:
\author{Martin J Baker}
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> Note that 9.10 is example, so incomplete description here is not
> a big problem (once the definition is cleared we probably want to
> expand it).
>
> BTW: I just noticed that I intoduced problem with TeX macros in 9.10,
> I will fix it.
I have just remembered that there is one other important change required to
the hyperdoc and all other documentation about this domain. That is there is a
known bug (feature?) which is that the infix operator precedence is wrong,
users would expect the /\ operator to bind more tightly than the other
multiplications. This is not the case and so people need to be made aware that
they need to use brackets when mixing different multiplication types (or use
operators in prefix form).
I am talking mostly about users of the interpreter here and if I understand
what you said before on this issue this can't be fixed? So users just need to
be made aware of it, otherwise users will get a bad impression of FriCAS.
There are other known issues, which I would like to fix given enough time (or
help from Bertfried) so I would not mention them in the documentation for now.
> Your copy of clifford.spad.pamphlet in line 7 had:
>
> \author{Martin J Baker}
ahhh I realise what this is now, there are at least 3 author lines in the
pamphlet file, there is an author for each spad which I took to be the author
of the code and this author line which I took to be the author of the
documentation, is this not correct?
More importantly I was going to ask you about the replacement that I made to
the documentation: I replaced the exiting documentation which is an extract
from Paul Leopardi's presentation which was pure theory, without reference to
the way the domain is implemented, with information about how to use the
program. What type of documentation would you expect in the pamphlet file? I
get the impression that the pamphlet file documentation won't get a lot of
readers so is not that important? I am not saying documentation isn't
important, on the contrary I believe very strongly in good documentation, I'm
just questioning what documentation should go where?
Martin Baker
Waldek Hebisch
> On Sunday 24 Jan d2010 15:57:10 Waldek Hebisch wrote:
> > I will fix it.
>
> I have just remembered that there is one other important change required to
> the hyperdoc and all other documentation about this domain. That is there is a
> known bug (feature?) which is that the infix operator precedence is wrong,
> users would expect the /\ operator to bind more tightly than the other
> multiplications. This is not the case and so people need to be made aware that
> they need to use brackets when mixing different multiplication types (or use
> operators in prefix form).
>
> I am talking mostly about users of the interpreter here and if I understand
> what you said before on this issue this can't be fixed? So users just need to
> be made aware of it, otherwise users will get a bad impression of FriCAS.
>
ATM priorities of operators in interpreter are "hardwired". This part
will change in the future, so "can't be fixed" is too strong: if we
decide that fix is needed we can do this. But please understand
that operators priorities are used before typechecking, so in
given place priorities are fixed (we can not have different priority
for /\ working as logical connective from /\ used for Grassman
product). Additionally, dynamically changing priorities from
place to place may be quite confusing and lead to subtle errors,
so it is probably bad idea even if possible -- currently changing
priority is only possible in Spad compiler, but in the future
I see no technical reason to inhibit such possibility in the
interpreter. The real question is if we _want_ ability to
change priorities -- I would say that ability to add operators
is useful, ability to change priority of existing operator
seem undesirable.
> There are other known issues, which I would like to fix given enough time (or
> help from Bertfried) so I would not mention them in the documentation for now.
>
> > Your copy of clifford.spad.pamphlet in line 7 had:
> >
> > \author{Martin J Baker}
>
> ahhh I realise what this is now, there are at least 3 author lines in the
> pamphlet file, there is an author for each spad which I took to be the author
> of the code and this author line which I took to be the author of the
> documentation, is this not correct?
>
Normally 'author' line at the top of file asserts authorship of the
whole file. In FriCAS there is redundancy, most reliable information
is from revision control: the change log entry contains author of
change and svn can tell you exactly what was changed. Then you have
notices at top of file and separate notices in constructors. I am
not sure how much notices we should have: in few files that I
created I just put my name on top and did not bother with notices
in constructors. In some places that I have extensively modified
I added my name, but mostly I just keep existing notices in place
without any change.
> More importantly I was going to ask you about the replacement that I made to
> the documentation: I replaced the exiting documentation which is an extract
> from Paul Leopardi's presentation which was pure theory, without reference to
> the way the domain is implemented, with information about how to use the
> program. What type of documentation would you expect in the pamphlet file? I
> get the impression that the pamphlet file documentation won't get a lot of
> readers so is not that important? I am not saying documentation isn't
> important, on the contrary I believe very strongly in good documentation, I'm
> just questioning what documentation should go where?
Here you hit area where there was (and AFAIK still is) substantial
disagreement. Below is my personal opinion, other member of the
project (may) have different opinions and actual practice is a
compromise...
First, currently our main "user level" documentation lives in
HyperDoc. One part is description of functions and constructors
(in +++ comments), the other are regular HyperDoc pages -- longer
parts should go there. In particular, user level documentation
of CliffordAlgebra probably should go to the Clifford algebra
example page (another possibility is to create a new topic,
say "geometric computation").
Currently you can see pamplets by clicking on 'Source File' in
HyperDoc (this puts you at start of relevant constructor, but
you should be able to see whole pamphlet if you wish). But
I think that only few people use this feature...
I prefer to keep main body of documentation sepatate from code.
It is useful to keep some pieces of documentation (like current
+++ comments) together with the code, but I feel that this
is exception rather then rule. Also, noweb markup is rather
heavy, so actually instead of current pamphlets I would just
have plain files with code and stylized comments.
Let me add that much of disagreement is related to tools. I believe
that we should have a single source for each piece of documentation
and a toolchain that can present whole documentation in several formats.
Also, we should keep documentation in simple format so that we
can easily process it. IMHO HyperDoc format is reasonably good.
MathML is IMHO requires too much effort to write by hand. Unrestricted
Latex is too complicated to process mechanically. Other simple
format could do, but given that we already have large body of
documentation in HyperDoc format and a few tools it make sense
to continue use it (possibly improving the format).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> Let me add that much of disagreement is related to tools. I believe
> that we should have a single source for each piece of documentation
> and a toolchain that can present whole documentation in several formats.
> Also, we should keep documentation in simple format so that we
> can easily process it. IMHO HyperDoc format is reasonably good.
> MathML is IMHO requires too much effort to write by hand. Unrestricted
> Latex is too complicated to process mechanically. Other simple
> format could do, but given that we already have large body of
> documentation in HyperDoc format and a few tools it make sense
> to continue use it (possibly improving the format).
My vote (if I had one) would be for HTML, most people could find a program
that could create HTML and it would look far more modern and less clunky than
a custom format.
If you want to encourage people to write documentation you don't want to
create artificial barriers by forcing people to learn a whole set of custom
tags and syntax just for the documentation.
I don't know about Lisp but most languages have libraries for rendering HTML
pages.
I have written a package HTMLFormat described here:
http://www.euclideanspace.com/maths/standards/program/output/
It is intended to allow me to cut and paste from the FriCAS command line to my
web pages but perhaps it could be some help in allowing user interaction in
HyperDoc to be rendered directly in HTML?
Martin Baker
Waldek Hebisch
> On Tuesday 26 Jan 2010 19:08:56 Waldek Hebisch wrote:
> > Let me add that much of disagreement is related to tools. I believe
> > that we should have a single source for each piece of documentation
> > and a toolchain that can present whole documentation in several formats.
> > Also, we should keep documentation in simple format so that we
> > can easily process it. IMHO HyperDoc format is reasonably good.
> > MathML is IMHO requires too much effort to write by hand. Unrestricted
> > Latex is too complicated to process mechanically. Other simple
> > format could do, but given that we already have large body of
> > documentation in HyperDoc format and a few tools it make sense
> > to continue use it (possibly improving the format).
>
> My vote (if I had one) would be for HTML, most people could find a program
> that could create HTML and it would look far more modern and less clunky than
> a custom format.
Using HTML as source is a bad idea. Basically HTML has rather bad ratio
of useful features to complexity. We want quality rendering and
AFAICS rendering from web browsers is not so good and complexity
of rendering engine (that is responsible part of the browser) is
quite high.
We want HTML as output format, but to render math we need more:
either MATHML in browser or some other way. BTW: "portable" method
is to convert formulas to GIF-s (and clearly we do not want GIF-s
as formula "source"). People who want to stay sane and have HTML
use XML and use transformation tools to get HTML when needed.
Popular choice for documentation is DocBook DTD, but again there
is question of formulas.
Note that HyperDoc format is a small subset of TeX with few macros
for links. TeX is still de-facto standard for mathematical text,
so while it is not "modern" for our target audience is more
familiar than HTML. And we may good quality, see online .pdf
of Axiom book. Current book was hand edited, but the same
is possible (and was done in NAG times) using single sources
for online help and for book.
> If you want to encourage people to write documentation you don't want to
> create artificial barriers by forcing people to learn a whole set of custom
> tags and syntax just for the documentation.
Yes, thats why HyperDoc is TeX based.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> of useful features to complexity.
<irony> I don't approve of unnecessary tags </irony> but I think a lot of
HTMLs complexity is what allows it to produce rich and visually interesting
content.
> We want quality rendering and
> AFAICS rendering from web browsers is not so good
<flippancy> but better than command line interface, </flippancy> I'm not
suggesting using HTML for print.
> and complexity
> of rendering engine (that is responsible part of the browser) is
> quite high.
<seriousPoint>Does the complexity matter? It could all be hidden from us.
</seriousPoint> The point is there is a big ecosystem of tools that allows
wysiwyg entering of html (OpenOffice.org, Kompozer, Quanta Plus, etc.) and
class libraries that mean that programmers don't have to deal with html
directly. I guess most of us would prefer to work on maths code than text
processing code <irony> even though I have just done so!</irony>
> People who want to stay sane and have HTML
> use XML and use transformation tools to get HTML when needed.
The output of the HTML formatter is well formed XML, that is: it has matching
opening and closing tags, so all the tools like XSLT can be used directly on
it.
> Note that HyperDoc format is a small subset of TeX with few macros
> for links. TeX is still de-facto standard for mathematical text,
> so while it is not "modern" for our target audience is more
> familiar than HTML.
<joke>You'll be telling me next that mathematicians still use FORTRAN</joke>
Martin Baker
Waldek Hebisch
> > Using HTML as source is a bad idea. Basically HTML has rather bad ratio
> > of useful features to complexity.
>
> <irony> I don't approve of unnecessary tags </irony> but I think a lot of
> HTMLs complexity is what allows it to produce rich and visually interesting
> content.
Complexity of HTML has much to do with historical developement (remember
"browser wars"). Also, HTML mixed logical markup with presentation.
And for math HTML is actually feature poor, you need something extra
for formulas and AFAIK graphs are images, so anything supporting
images is as good.
> > We want quality rendering and
> > AFAICS rendering from web browsers is not so good
>
> <flippancy> but better than command line interface, </flippancy> I'm not
> suggesting using HTML for print.
So what are you discussing here? We want HTML output. The question
is which source format is simple and can produce all formats we need.
In particular printed output and high quality output for screen
viewing.
And if you want browser interface then HTML helps you only a little,
interesting things are done using Javascript. You first send
a script to the browser and the script interprests the rest of data
as needed.
> > and complexity
> > of rendering engine (that is responsible part of the browser) is
> > quite high.
>
> <seriousPoint>Does the complexity matter? It could all be hidden from us.
> </seriousPoint> The point is there is a big ecosystem of tools that allows
> wysiwyg entering of html (OpenOffice.org, Kompozer, Quanta Plus, etc.) and
> class libraries that mean that programmers don't have to deal with html
> directly. I guess most of us would prefer to work on maths code than text
> processing code <irony> even though I have just done so!</irony>
Yes, complexity maters. External tools are dependencies. Everybody
has web browser, but only few folks have developements tools. And
folks who do have tools do not want to change toolset, so either
you make sure that your HTML works with all tools (and even getting
HTML to display properly in all browsers is tricky) or some will
be upset.
To put it in perspective: Martin Rubey has shown very simple way
to display hyperdoc pages in a browser. The catch is the you
need to have the tex4ht program. You may be lucky and your
Linux distribution may have it as a package. But otherwise
to build it you need to install several other packages (IIRC
about 20). Most folks will _not_ even try, and the one
trying are likely to discover some problem with one of
dependencies.
>
> > People who want to stay sane and have HTML
> > use XML and use transformation tools to get HTML when needed.
>
> The output of the HTML formatter is well formed XML, that is: it has matching
> opening and closing tags, so all the tools like XSLT can be used directly on
> it.
The point is semantics, semantics of HTML is complicated and fuzzy
(each browser has it own tricks). Once you restrict what you
handle and tighten semantics it is really no longer HTML... Of course
tools desigend for HTML may help in handling XML, but that is
different story.
> > Note that HyperDoc format is a small subset of TeX with few macros
> > for links. TeX is still de-facto standard for mathematical text,
> > so while it is not "modern" for our target audience is more
> > familiar than HTML.
>
> <joke>You'll be telling me next that mathematicians still use FORTRAN</joke>
>
Martin, in real life people use tools that get work done. Beeing modern
does not imply that tool works well (actually, there is a weak correlation
in opposite direction).
Concerning TeX, go to http://arxiv.org/ and choose some random papers.
Chose 'other' as a format and then fetch source. Then looks what
format you got.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> to display hyperdoc pages in a browser. The catch is the you
> need to have the tex4ht program. You may be lucky and your
> Linux distribution may have it as a package. But otherwise
> to build it you need to install several other packages (IIRC
> about 20). Most folks will _not_ even try, and the one
> trying are likely to discover some problem with one of
> dependencies.
I don't care about such dependencies. Martin, where can I find the
description of how you did this translation? Not that I've got time to
spend on this, but sometimes I wished I had my firefox reading the
contents of hyperdoc. At least then I could compile such html pages
locally on my computer.
Ralf
Martin Rubey
I'm still sick, so no long mails. Attached is what I have. The idea
was simple, but is meanwhile probably outdated. moreover, very likely
gcl-only.
"instructions" in hyper.input
Martin