\start
Date: Tue, 01 Dec 2009 09:45:47 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: [Aldor-l] License for FriCAS-Aldor interface files
Cc: Mike Dewar, Stephen Watt

Ralf Hemmecke wrote:
> Dear Mike, dear Stephen,
>
> may I ask you again to consider the attached request.
>
> Thank you
> Ralf
>
>
> On 09/24/2009 11:38 PM, Ralf HEMMECKE wrote:
>> Dear Stephen, dear Mike
>
>> as you might know, I have built some scripts in FriCAS (a fork of 
>> Axiom) (http://fricas.sourceforge.net/) in order to build libaxiom.al 
>> from scratch. Unfortunately, I can neither distribute libaxiom.al nor 
>> some necessary .as files under the same license as FriCAS (mBSD), 
>> since this code is only available under the Aldor Public License 2.0.
>>
>> I hereby kindly ask you to release the following files under a BSD 
>> license (same as for the Axiom code).
>>
>>   https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axiom.as
>>   
>> https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axextend.as
>>   https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axlit.as
>>   https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/stub.as
>>   
>> https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/minimach.as
>>   
>> https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/axllib/src/lang.as
>>
>> Furthermore, in order to distribute a precompiled libaxiom.al 
>> together with FriCAS, it would be helpful to also release
>>
>> $(ALDORROOT)/lib/libfoam.al(runtime.ao)
>>
>> under a BSD license. For 'runtime.ao', also releasing the sources 
>> under a BSD license would be good, but I explicitly ask for the 
>> release of the .ao format.
>>
>> Please help the FriCAS project and don't let Aldor die.
>>
>> Has meanwhile anything been done to release all of the Aldor 
>> compiler+library sources under a GPL-compatible license?
>>
>> Thank you for your time.
>>
>> Yours sincerely
>> Ralf Hemmecke
>
>
> _______________________________________________
> Aldor-l mailing list
> Aldor-l@aldor.org
> http://aldor.org/mailman/listinfo/aldor-l_aldor.org
>
Mike, Stephen,

I have recently decided after two years that Aldor was
never going to become free enough to be integrated back
into Axiom. The FriCAS project has been trying to keep
the connection alive.

It would seem that changing the license on the FriCAS
related files would at least help them in their efforts
to keep the connection alive. Thus, I'm adding my voice
to the request to make this change.

I realize that such changes involve your legal department
and come at a non-trivial cost. I also realize that you
may have prior agreements that prevent it. In any case,
I think that the sense of frustration in FriCAS appears
to be reaching a critical tipping point and this is likely
to end with Aldor being deleted.

\start
Date: Fri, 04 Dec 2009 04:20:54 -0500
From: Tim Daly
To: list
Subject: Re: Literate programming and how it scales


(actual text is snipped out since this was not public but I want to record
the reply on axiom-developer)

...[snip]...comments about scale...

What kind of scaling are you thinking about? Axiom currently has about
20 books that will eventually have all of the source code in literate
form. Some of the books are several thousand pages long. There is
hyperlinking within the files.  Axiom is about 1 million "things of
code" and it will all reside in literate files so I think the
technology scales to really large systems.

If you are talking about scaling in terms of humans I think the
problem is not one of technology. The problem is that you really can't
do a literate work with dozens of authors. Literature requires one, or
at most a few, authors in order to make sure that the "style" and
"voice" of the documentation is coherent. So I think that many people
can work on the system but only a very few are the "editors/primary
authors". I don't think there is a good label for this historically,
except perhaps the "Chief Programmer" from Harlan Mills "Chief
Programmer Teams". I don't care for that label.

Ultimately literate programming requires a complete understanding of
the system.  The point of literate programming is to convey this
understanding to the reader in a smooth, consistent way. Since
programming is involved it is also important that all of the details
are explained, but also important that they are introduced in some
"motivated" fashion. It is the "motivation" for code snippets that is
usually left out of other documentation forms (e.g. doxygen, javadoc,
etc.).

...[snip]...comments about TeX and multiple languages

I see TeX as a major strength since most technical papers are written
in Latex.  TeX is also a strength for Axiom because it handles
mathematical typesetting very well and Axiom is a mathematical system.

Every literate system will have at least 2 languages, one for
programming and one for writing. I find that TeX does everything I
need or can be extended with macros to do what I need. I don't know
how to add macros to an HTML system (without writing in Perl as you
do, which is yet a third language)

... [snip] ...comments about noweb

Axiom is moving away from noweb, although we have used it for years
and I can highly recommend it. Some of Axiom's literate files now have
"straight latex" macros for chunks so where you would write

<<noweb chunk name>>=
   your code
@

now Axiom allows you to write

\begin{chunk}{Axiom chunk name}
  your code
\end{chunk}

This uses straight latex macros which means that your file is pure Latex.
Since the file is pure Latex you no longer need "weave" so half of noweb 
is gone.

The only other remaining function is "tangle". Axiom is being rewritten
to understand Latex files directly so it can "tangle" the file without 
using noweb.
The underlying lisp system (GCL) has been modified to include a "tangle"
function directly so Axiom is not needed to extract code.

Thus we will no longer need noweb in the future.

...[snip]...comments about new tool features for code organization

Programmers have been conditioned to believe that they should work on small
files with "include files" to carry information that is shared.

If you look where this idea comes from historically you'll find there
was a memory limitation on the PDP 11/40 (I worked on one so I know)
that limited a file to about 4K characters. In order to make larger
files you needed to invent "include files".  So C programs started the
idea that files should be really small.

Then you needed to invent directories since groups of files in a
directory made up a single larger idea.

Then you needed to invent "make" because it becomes impossible to
figure out how to compile all the files in all the directories and get
all the parts right.

Then you needed to invent "grep" to find functions.

Then you needed to invent IDEs so you could work with the whole project.

Today I have 4G of memory and a 1T of disk space. I can trivially
handle multi-megabyte files, my functions are all in one file, "make"
is trivial, "grep" is an editor "find" command and I don't need an
IDE. Latex provides an automatic cross-reference mechanism that allows
me to find all of the places where a function is called.

Once we stop pretending we work on a PDP 11/40 life gets so much easier

...[snip]... tool description using HTML, Perl, Javascript

So instead of Latex and Lisp, I now need Lisp, HTML, Perl,
and Javascript?

Is adding new languages an improvement? Are HTML files "documents", i.e.,
are they designed to be read as books? Can you control the layout and fonts
that are so necessary to convey certain information?

...[snip]... features of the new tool

Like any author, I keep my ongoing work in the manuscript, which is
the literate file itself.  There are no auxillary files, no project
files, no directory structure, no includes, nothing.

...[snip]...

I'm sure you have a good tool set that most people would find useful.
Unfortunately, the Axiom project is working to "remove the tools" that
are not absolutely required by making Axiom aware of its own file format
(pamphlet, also known as .tex, files)

\start
Date: Fri, 04 Dec 2009 13:06:57 -0500
From: Tim Daly
To: list
Subject: ISSAC 2011

*---------------------------------------------------------------*

             Call for Proposals for Workshops

                      ISSAC 2011

                    June 8-11, 2011

*---------------------------------------------------------------*


We solicit proposals for satellite workshops to be held in conjunction
with ISSAC 2011.

For the first time, ISSAC will participate in the Federated Computing
Research Conference (FCRC). FCRC occurs once every four years, and is
the world's largest computing research conference.  FCRC consists of a
collection of conferences that agree to share the same conference
facility. To learn more, see http://acm.org/fcrc/  .

The FCRC week in 2011 will run June 4-11  The ACM is able to offer
space for workshops or small conferences at no additional charge.
Participants are responsible for paying a modest FCRC registration fee
(approx. 50 USD for the entire FCRC week) and a ``per diem'' fee to
cover refreshments (approx. 80 USD per day).  These fees are the same
regardless of how many events one attends, i.e., there is no penalty
to register for one conference and attend a different workshop.  ISSAC
will take place at the end of the FCRC week, and space for workshops
is available for us starting the day before, June 7.

Opportunities abound for making connections with other fields of
computer science. Conferences that have confirmed their participation
include the

* ACM Symposium on Theory of Computing (STOC),

* ACM Symposium on Parallelism in Algorithms and Architectures (SPAA),

* ACM Conference on Programming Language Design and Implementation
(PLDI),

* CRA-W Career Mentoring Workshop.


Potential ideas for workshops that take advantage of the presence of
these related conferences might then be Complexity in Computer
Algebra, Parallel Symbolic Computation, Programming Languages for
Computer Algebra, or Mentoring Women in Computer Algebra.

We also welcome proposals for other topics.  Holding your workshop at
an event with international presence might heighten participation.



Please email your proposal to General Chair Eric Schost at
eschost@uwo.ca.  There is no hard deadline, but because space is
limited, we encourage you to submit by December 14, 2009. We will make
decisions on a ``first come, first served'' basis and may close
submissions before December 1st.

For questions concerning the Federated Computing Research Conference,
any organizational details, current list of participating conferences,
or current availability of space, please contact Local Arrangements
Chair Emil Volcheck at Emil Volcheck.

\start
Date: Fri, 04 Dec 2009 21:54:56 -0500
From: Tim Daly
To: Rich Hickey
Subject: Intell SCC chip, Clojure, and Provisos

Rich,

I've been looking at the newly-announced Intel SCC chip.
It looks like 48 processors with local cache connected
by 24 routers.

It seems feasible to me to put a Clojure on each node
and have them share a heap image. The cache is likely
large enough to contain the kernel of the clojure code
(they plan to run 48 linux images).

One question that I'd have is whether there is a way to
present a single-image REPL that can use this chip. I'd
like to experiment with parallel symbolic computing in
Axiom and the combination of Clojure and the SCC seems ideal.

Can multiple Clojures share a heap?

I'd like to be able to dynamically fork tasks to different
lisp images that worked on the same heap. For example, I'd
like to be able to compute f(x) in two ways with different
assumptions as in:
   f(x) x>0
   f(x) x<=0
and the combine the result into a single solution. Computing
under assumptions (provisos) is an ideal mechanism for doing
parallel symbolic computations.

\start
Date: Fri, 4 Dec 2009 19:10:59 -0800
From: Ed Borasky
To: Tim Daly
Subject: Re: Intell SCC chip, Clojure, and Provisos
Cc: Rich Hickey

On Fri, Dec 4, 2009 at 6:54 PM, Tim Daly wrote:
> Rich,
>
> I've been looking at the newly-announced Intel SCC chip.
> It looks like 48 processors with local cache connected
> by 24 routers.
>
> It seems feasible to me to put a Clojure on each node
> and have them share a heap image. The cache is likely
> large enough to contain the kernel of the clojure code
> (they plan to run 48 linux images).
>
> One question that I'd have is whether there is a way to
> present a single-image REPL that can use this chip. I'd
> like to experiment with parallel symbolic computing in
> Axiom and the combination of Clojure and the SCC seems ideal.
>
> Can multiple Clojures share a heap?
>
> I'd like to be able to dynamically fork tasks to different
> lisp images that worked on the same heap. For example, I'd
> like to be able to compute f(x) in two ways with different
> assumptions as in:
> =C2=A0f(x) x>0
> =C2=A0f(x) x<=0
> and the combine the result into a single solution. Computing
> under assumptions (provisos) is an ideal mechanism for doing
> parallel symbolic computations.

Hmmm ... interesting concept. How small an OS can you get away with
and still have the JVM on each node? Surely you don't need a whole
GNU/Linux stack. Perhaps something like the openSUSE JeOS (Just Enough
Operation System)? Which JVM would you be using? Are the parallel /
concurrent hooks in the JVM?

\start
Date: Fri, 04 Dec 2009 22:42:28 -0500
From: Tim Daly
To: Edward Borasky
Subject: Re: Intell SCC chip, Clojure, and Provisos
Cc: Rich Hickey

Ed Borasky wrote:
> On Fri, Dec 4, 2009 at 6:54 PM, Tim Daly wrote:
>   
>> Rich,
>>
>> I've been looking at the newly-announced Intel SCC chip.
>> It looks like 48 processors with local cache connected
>> by 24 routers.
>>
>> It seems feasible to me to put a Clojure on each node
>> and have them share a heap image. The cache is likely
>> large enough to contain the kernel of the clojure code
>> (they plan to run 48 linux images).
>>
>> One question that I'd have is whether there is a way to
>> present a single-image REPL that can use this chip. I'd
>> like to experiment with parallel symbolic computing in
>> Axiom and the combination of Clojure and the SCC seems ideal.
>>
>> Can multiple Clojures share a heap?
>>
>> I'd like to be able to dynamically fork tasks to different
>> lisp images that worked on the same heap. For example, I'd
>> like to be able to compute f(x) in two ways with different
>> assumptions as in:
>>  f(x) x>0
>>  f(x) x<=0
>> and the combine the result into a single solution. Computing
>> under assumptions (provisos) is an ideal mechanism for doing
>> parallel symbolic computations.
>>
>> Tim Daly
>>
>>
>>
>> _______________________________________________
>> Axiom-developer mailing list
>> list
>> http://lists.nongnu.org/mailman/listinfo/axiom-developer
>>
>>     
>
> Hmmm ... interesting concept. How small an OS can you get away with
> and still have the JVM on each node? Surely you don't need a whole
> GNU/Linux stack. Perhaps something like the openSUSE JeOS (Just Enough
> Operation System)? Which JVM would you be using? Are the parallel /
> concurrent hooks in the JVM?
>
>
>   
Intel has been muttering about putting a whole virtual machine on
each of the 48 nodes. I'm thinking more along the lines of a lisp
kernel per node with shared heap. Clojure is interesting because of
its immutable data structures and refs. Asus systems sells a 384
node machine that runs a JVM per node and I had previously looked
at that for a Clojure-based Axiom.

I have been looking for details on the individual nodes and their
cache sizes. I suspect they are planning on a wide range of cache
sizes. Given a 2M cache it would easily hold a lisp kernel although
I'm not sure of minimum JVM sizes. However, byte coding is a way of
minimizing memory footprint.

SCC appears to be optimized for a message passing architecture which
is a style that can easily be adopted in lisp since you can pass
s-expressions directly.

Intel has asked for research ideas and I submitted this idea. Since
this is open source the best we can hope for would be internet access
to a hardware platform (which might be implemented in ASIC chips for
all we know).

I have been collection parallel constructs and building a set of lisp
tools for each one. For example, take, drop, interleave, curry, zip,
filter, etc. would be primitives for control. Rich Hickey made the
interesting observation that essentially amounts to something like
"Loops considered harmful". As I rewrite the Axiom internals I'm
working on lifting it onto the parallel primitives.

The real game is to lift the whole parallel idea into the symbolic
context so algorithms can be fully parallel. My view on that is to use
provisos as the basis for fork/join computations under restricted
assumptions for each fork. Of course, a forked computation of
  f(x,y) such that x > 0
could end up forking again under
  f(x,y) such that x > 0 & y > 0
  f(x,y) such that x > 0 & y = 0
  f(x,y) such that x > 0 & y < 0

Groebner basis computations could be done in parallel with different
orders and terminated when a solution is found (parallel poisoning)

Parallel root finders could use a blackboard structure to use the
discovery of one root to reduce the problem for other parallel finders.
 
There are a lot of interesting paths to take.

\start
Date: Fri, 4 Dec 2009 20:05:19 -0800
From: Edward Borasky
To: Tim Daly
Subject: Re: Intell SCC chip, Clojure, and Provisos
Cc: Rich Hickey

On Fri, Dec 4, 2009 at 7:42 PM, Tim Daly wrote:
> Intel has been muttering about putting a whole virtual machine on
> each of the 48 nodes. I'm thinking more along the lines of a lisp
> kernel per node with shared heap. Clojure is interesting because of
> its immutable data structures and refs. Asus systems sells a 384
> node machine that runs a JVM per node and I had previously looked
> at that for a Clojure-based Axiom.

The nodes are full x86_64, right? I think you need *some* kind of OS /
kernel, although it might well be a "microkernel" along the lines of
the Dresden Real-Time Operating System (DROPS) rather than a full
Linux or BSD kernel. I don't know if there's a "bare metal JVM" or a
hardware implementation of the JVM. Then again, I'm mostly a number
cruncher and operating system programmer, so maybe I see a need for an
OS simply because I like working on them. ;-)

> Intel has asked for research ideas and I submitted this idea. Since
> this is open source the best we can hope for would be internet access
> to a hardware platform (which might be implemented in ASIC chips for
> all we know).

I don't know about that - Intel is pretty supportive of open source,
at least here in Oregon. ;-) And they used to have a pretty strong HPC
team here (Floating Point Systems alumni), although I haven't run into
any of them recently. If there is an upstream market for massively
parallel symbolic computing, I'm sure they'll give you what you need.

> I have been collection parallel constructs and building a set of lisp
> tools for each one. For example, take, drop, interleave, curry, zip,
> filter, etc. would be primitives for control. Rich Hickey made the
> interesting observation that essentially amounts to something like
> "Loops considered harmful". As I rewrite the Axiom internals I'm
> working on lifting it onto the parallel primitives.
>
> The real game is to lift the whole parallel idea into the symbolic
> context so algorithms can be fully parallel. My view on that is to use
> provisos as the basis for fork/join computations under restricted
> assumptions for each fork. Of course, a forked computation of
> =C2=A0f(x,y) such that x > 0
> could end up forking again under
> =C2=A0f(x,y) such that x > 0 & y > 0
> =C2=A0f(x,y) such that x > 0 & y = 0
> =C2=A0f(x,y) such that x > 0 & y < 0
>
> Groebner basis computations could be done in parallel with different
> orders and terminated when a solution is found (parallel poisoning)

I thought there were "massively parallel" Groebner basis solvers
already - is that a wheel that needs re-inventing?

> Parallel root finders could use a blackboard structure to use the
> discovery of one root to reduce the problem for other parallel finders.
>
> There are a lot of interesting paths to take.

Yeah - many of these paths were partially illuminated in the late
1980s - early 1990s and then abandoned. I think, though, this time
around, there's massive commitment to parallel / concurrent
programming from big players like IBM, Intel, Microsoft and Google.
Oracle too, probably. ;-)

\start
Date: Tue, 08 Dec 2009 16:51:57 -0500
From: Tim Daly
To: Franz Lehner
Subject: Re: hyperdoc on the web
Cc: Martin Rubey, Bill Page

Well, since my name came up in discussion I feel I have to respond
with a couple points.

1) My original "translation" from spad files to "literate" files involved
adding a latex header and a footer to every file. Fricas removed this from
almost every other file except the algebra files. Waldek's complaint is that
this makes algebra files hard to use. (Note that Axiom no longer has
any spad files or separate algebra pamphlet files. What you have was
a trivial first step in the process and worthless as it stands.)

I might suggest that since you don't plan to really do literate programming
it would be perfectly sane to remove the header and footer from the
algebra files. This has 2 benefits. First, you can use the spad files 
directly
Second, you no longer need noweb which simplifies your build process
considerably (removing steps and removing the need to fetch noweb)
In fact, you hardly use noweb because it appears you build from the lisp
translations most of the time.

You can't really do literate programming "half way". What you have
now is just a "dust jacket" over an empty novel. What is the point?
Why be irrational?

2) The debate seems to depend on whether Fricas will attract more
users if more functionality is added or if more documentation is added.
I think you will only judge this in the long term by whether Fricas or
Axiom ends up with more users. In fact, though, I don't consider
this an interesting metric; but we disagree on that also.

Given that I'm a complete Knuth fanboi about literate programming,
I have SO much more to say but since Fricas forked the Axiom project
over the literate issue, this is the wrong audience. There is nothing I
can say that would convince you otherwise.

Tim


=================================================

Martuin Rubey asked about stmult routine which I recently
commited to 'sttaylor.spad'.  I think the best explanation
is to give short reconstruction how the routine was
written.

1) Let us look first at general pattern of stream fortines.  Good
example is the simpified version of 'map':

    map(f,x)== delay
      empty? x => empty()
      concat(f frst x, map(f,rst x))

Note that the result is produced by the 'delay' function.  'delay(f)'
takes function 'f' as argument and produces from is a stream, such
that evaluation of the strem causes f to be called.  The name 'delay'
is releated to the fact that 'delay' effectively delayes evaluation
of its argument to the moment when first value from the stream
is requested.  When strean is evaluated: evaluation triggered
by call to 'empty?'.  In other words, before trying to access
first element of the stream we need to call 'empty?' to cause
evaluaton, after the call we know if the element is there (and
if it is present we can use it).  So above the first line calls
'empty?' which either give us true, in which case we simply return
empty stream or we may use the first element of input stream to
produce first element of the result result.  Now, once we have
first element of the result in hand we can produce the result by
concatenating first element of the result with the rest of the
result.  In case of 'map' the result is obtained by recursive
application of 'map' to the rest of input stream.

Important remark: stream are produced and should be consumed
in lazy way.  'delay' makes sure that no computation takes
place before first element of the result is requested.  However
for single request map should produce only one element and to
produce it should consume only one elemet form input stream.
Using 'concat' makes sure that caller will get the computed
element and that request for further elements will go to map
applied to the rest of stream.

Let me also say that the code above looks like unbounded
recursion, but in fact there is _no_ recursion at runtime:
what looks like recursive call to 'map' is done _after_
call to outer map has finished.

2) Having pattern for general operation, how we apply it in a
concrete situation.  For example, we would like to multiply
each element 'n' of the stream by 'n+1'.  To do this we need
to know what 'n' is, so we need to pass 'n' between invocations
of function.  So we need an auxilary function and a wrapper:

   stmuln_aux(n0, x) == delay
       empty? x => empty()
       n := n0 + 1
       firstval := n*frst x
       concat(firstval, stmuln_aux(n, rst x))

   stmuln(x) == stmuln_aux(0, x)

Note: due to stupidity of Spad compiler I can not simply increment
n0, but must introduce extra variable n.

3) Back to multiplication.  For multiplication formula is:

   (f*g)(n) = \sum_{i=0}^{n} f(i)*g(n-i)

This is more complicated then previous case because I need terms
f(0),...,f(n) and g(0),...,g(n) to produce the result.
Naive implementation (assuming infinte streams) may look like:

   stmult(n, x, y) == delay
       valn := sum(coefficient(x, i)*coefficient(y, n - i), i=0..n)
       concat(valn, stmult(n + 1, x, y))

   mult(x, y) == stmult(0, x, y)

However, coefficient for streams has step trough stream from
the start up to requested element, so it is slow if n gets large.
It is easy to see that we can step trough x as we sum saving
half ot the operations:

   stmult(n, x, y) == delay
       valn : A := 0
       xp := x
       for i in 0..n repeat
           empty? xp => break
           valn := frst xp * coefficient(y, n - i)
           xp := rst xp
       concat(valn, stmult(n + 1, x, y))

We still use coefficient on y.  Since we need to go trough y
backwards, it is a bit harder to get rid of.  Easy way it to
have a list which stores the first n elements of y in backward
order:

   stmult(n, x, y0, ll0) == delay
       yval : A
       y := y0
       if empty? y then
           yval := 0
       else
           yval := frst y
           y := rst y
       ll := cons(yval, ll0)
       xp := x
       llp := ll
       valn : A := 0
       for i in 0..n repeat
           empty? xp => break
           valn := valn + frst xp * first(llp)
           llp := rest(llp)
           xp := rst xp
       concat(valn, stmult(n + 1, x, y, ll))

This may be (I did not test it) correct routine to multiply infinite
power series, but it does not conform to expectation of rest of FriCAS.
Namely, if we are given to finite series it will produce infinite
series -- after finite number of nonzero terms we will get infinite
stream of zeros.  There is also unneeded eagerness: if first element
if y is zero we do not need element n of x to produce first element
of the result.  Also, if y is finite there is no need to append
zeros.  First, let us handle leading zeros of 'y'.  I first
element of y is zero we get zero as fist element of the result and
rest of resulst is x times rest of y:

     ...
     yval := frst y
     n = 0 and yval = 0 => concat(0, stmult(n, x, rst y, ll))

Note: we need to test if n is 0 to know that we really have first
elememt and not some zero in the middle.

Next, if we get to the end of y instead of extending ll by zero
we may drop first element of x.  We need to be a little
careful if x is also empty ( possibly after dropping several
elements).  And we need to properly adjust n.  Adjusting n is
easier if we start from n = -1 instead of n = 0.  Also, if at start
y is empty then the result is 0 (empty):

       if empty? y then
            n < 0 => return empty()
            empty? x => return empty()
            x := rst x

If we in the loop we discover that x is empty we can also
return 0.  FinallCollection the changes above we get:

   stmult(n0, x0, y0, ll0) == delay
       x := x0
       y := y0
       ll := ll0
       n = n0
       if empty? y then
           n < 0 => return empty()
           empty? x => return empty()
           x := rst x
       else
           yval := frst y
           n < 0 and yval = 0 => concat(0, stmult(n, x, rst y, ll))
           y := rst y
           ll := cons(yval, ll)
           n := n + 1
       xp := x
       llp := ll
       valn : A := 0
       for i in 0..n repeat
           empty? xp =>
               i = 0 => return empty()
               break
           valn := valn + frst xp * first(llp)
           llp := rest(llp)
           xp := rst xp
       concat(valn, stmult(n + 1, x, y, ll))

This is almost the routine I want to use.  However, there is one
extra problem: if series has unevaluated tail printing routines
print O(..) term even if after further evaluation it turns out
that in fact the tail is empty.  To avoid such artifacts printing
routines check if tail is explicitly empty.  Note that testing
if tail is empty causes evaluation and printing routines are not
allow to evaluate extra terms.  But 'explicitlyEmpty?' does not
cause evaluation, even if 'explicitlyEmpty?' return false
'empty?' may return 'true'.  So, to make printing routines
happy we need to make sure that the tail is explicitely empty.
This is done adding after loop test:

         ....
      explicitlyEmpty? rst x and
        explicitlyEmpty? y => concat(res, empty())

Note that we if x is empty we call return inside loop, so after
loop x is always nonempy and calling rst is safe.  Note that
if x has only one element and y is empty then in the next iteration
we will throw out the only element of x and get empty result.
So the test allows us to produce earlier the empty result.
OTOH if that test fails in principle we can get more elements,
so must use general form.

Martin also asked why the new version uses less space than the
old one and why the old one used so much space.

First, note that stream data is stored in nested anonymous
functions.  The new version creates single function for
each term of the series, so when we want n terms n such
functions are created.  Each function takes fixed amount
of space for variables (the space is actually taken by "frozen"
values of variables from outside which the function uses).
The variables may reference large data structure (for
example x and y may be big), but fortunatly such large
structures may be shared.  In particular parts of x and y are
shared so that at each step we add (compute) only one extra element
of x and of y.  The list ll has in general n + 1 element, but
we share n with previous iteration.  So at each step we
allocate fixed aount of memory.  More precisely, we allocate
whatever memory is needed to store element n of x and element
n of y plus fixed storage (of order 10-15 machine words).
In other words, memory usage is linear in n.

The old version was:

   (x:ST A) * (y:ST A) == delay
     empty? y => zro()
     empty? x => zro()
     concat(frst x * frst y,frst x * rst y + rst x * y)

It is easy to see that this version allocates stream node for
each term in the product, that is of order n^2 nodes.  Theoretically
most of those nodes may be garbage collected.  I did not check
if the FriCAS code for some reason (for example due to keeping
unnecessery extra reference to the data) did not allow collection,
or if this was problem with SBCL garbage collector, but the fact
was that the space usage grow quadratically...

The new version allocates much less memory, so there is no
chance for garbage collector (or FriCAS programmers) to scrow up.

-- 
                              Waldek Hebisch
hebi...@math.uni.wroc.pl

From: Ralf Hemmecke <r...@hemmecke.de>
Date: Sat, 05 Dec 2009 12:23:10 +0100
Local: Sat, Dec 5 2009 6:23 am
Subject: Re: [fricas-devel] Multiplication of power series

Waldek,

Since we have literate programming, I think your explanation would be
best put just next to your implementation. Can you commit that?

In the mailing list archive it will be just forgotten or relatively hard
to find if the code does not (at least) have a link to your message.
Anyway, better put it directly into the code.

Since I've also worked on powerseries in aldor-combinat... does your
code allow to define powerseries by recursion? I think that should be
somehow possible by using "delay".

Further, I still would very much like a native implementation of
"Generator" in SPAD. Do you have any plans for that?

Ralf

On 12/05/2009 04:17 AM, Waldek Hebisch wrote:


 > Martuin Rubey asked about stmult routine which I recently
 > commited to 'sttaylor.spad'.  I think the best explanation
 > is to give short reconstruction how the routine was
 > written.


       

From: Waldek Hebisch <hebi...@math.uni.wroc.pl>
Date: Sat, 5 Dec 2009 16:54:52 +0100 (CET)
Local: Sat, Dec 5 2009 10:54 am
Subject: Re: [fricas-devel] Multiplication of power series


Ralf Hemmecke wrote:
 > Waldek,

 > Since we have literate programming, I think your explanation would be
 > best put just next to your implementation. Can you commit that?

No!!!  I _really_ do not want to see such texts inside source
files.  Such for given person such text may be useful once,
maybe few times, but having to read it or even only look at
it every time when looking at code is simply too distracting.

In other words, persons looking at/modifying algebra code are
supposed to have appropriate background knowledge.  Consider
research article on some fancy rings.  If you put there
elementary introduction to rings every referee will tell
you to delete such material.  Background specific to topic
at hand is welcome, but is normally put in separate
section.  The main body of article simply uses notation/facts
from background section without repeating them.  This is
due to separation of concerns principle: systems with many
interactiong parts are hard to understand.  Splitting them
into pieces and using hierachical description makes things
easier.  Also, people are pretty good at analogy, so explaing
one thing allows them to understand similar thins.  Again,
separating material into background and specific parts
means that background is easier to reuse.

For background we should have documentation (separate
from source code!).  Unfortunatly, past "literate"
effort removed places where normally documentation
should live.  But is relatively easy to cure.

There are practical aspects releated to tools that we
use.  Let me explain my workflow when developing algebra
code:

1) copy XXX.spad file from build directory to work directory
2) start up FriCAS in work directory
3) in separate window start an editor on XXX.spad file (I use vi,
   but any reasonable editor would do).
4) modify the XXX.spad file and save it
5) Do

)compile XXX.spad

(typically the command is in command history so this is fast)
6) Test (frequently test are in history too, so this also is
   fast)
7) if not done goto 4
8) make diff of original XXX.spad and modified XXX.spad
9) Edit the diff replacing XXX.spad by xxx.spad.pamphlet
10) Applay the diff to algebra
11) Do full bootrap to final test.

Typically there are several interations of inner edit-compile-test
loop.  On small files mechanical parts take fraction of second, on
larger few seconds, so it does not intrude too much into natural
flow of developement.  Note that step 10 depends on code inside
pamphlet beeing just wrapped version of code in XXX.spad, any noweb
tricks means to I need to do merging manually -- this looses time
and may introduce extra errors.

In principle good "literate" tools could work as well or better.
But external tools are a dependency while tools specific to
the project take effort ot develop.  So it is better to use
popular tools unless there is some really big gain from nonstandard
tool.  Looking at many project I see to use of exotic tools
frequently limits adoption of otherwise quite good ones.

 > In the mailing list archive it will be just forgotten or relatively hard
 > to find if the code does not (at least) have a link to your message.
 > Anyway, better put it directly into the code.

My fist feeling was that this text was too rough to elevate it
to status of documentation.  But if you think that it is good
enough we can create documentation subdirectory and put it there.

 > Since I've also worked on powerseries in aldor-combinat... does your
 > code allow to define powerseries by recursion? I think that should be
 > somehow possible by using "delay".

Well "my code" is routine for mutiplying power series.  The framework
for computing power series is due to original Axiom developer.  AFAICS
you can use quite general recursive construct when defining power
series.  Note: while conceptualy there is recursion at runtime
typically there are no recursive calls, so no need to worry about
overflowing stack due to deep recursion (but as the power series
example illustrates whithout some care one may exhaust available
memory (heap)).

 > Further, I still would very much like a native implementation of
 > "Generator" in SPAD. Do you have any plans for that?

They are in queue of "nice things that we would do if we had
enough resources", but IMHO other things are more important,
so no specific plans ATM.

-- 
                              Waldek Hebisch
hebi...@math.uni.wroc.pl


From: Martin Rubey <martin.ru...@math.uni-hannover.de>
Date: Sat, 05 Dec 2009 21:44:22 +0100
Local: Sat, Dec 5 2009 3:44 pm
Subject: Re: [fricas-devel] Multiplication of power series


Waldek Hebisch <hebi...@math.uni.wroc.pl> writes:
 > Ralf Hemmecke wrote:
 >> Waldek,

 >> Since we have literate programming, I think your explanation would be
 >> best put just next to your implementation. Can you commit that?

 > No!!!  I _really_ do not want to see such texts inside source
 > files.  Such for given person such text may be useful once,
 > maybe few times, but having to read it or even only look at
 > it every time when looking at code is simply too distracting.

How about putting it into a separate subsection but at least in the same
file?  I'm afraid that there will never be concensus, but maybe we cann
have a compromise?

When working on GUESS, I updated the doc (for myself!!!) at least from
time to time.  I admit it is far from perfect, outdated at places and
often inaccurate.  But it happened already a few times that reading my
old doc helped myself remember what I was trying to do.

 > In other words, persons looking at/modifying algebra code are
 > supposed to have appropriate background knowledge.  Consider
 > research article on some fancy rings.  If you put there
 > elementary introduction to rings every referee will tell
 > you to delete such material. 

So far this didn't happen to me - actually rather the opposite -
although I consider myself as doing "elementary" stuff.  I am frequently
surprised what other mathematicians find "elementary", by the way.

 > Let me explain my workflow when developing algebra code:

 > 1) copy XXX.spad file from build directory to work directory
 > 2) start up FriCAS in work directory
 > 3) in separate window start an editor on XXX.spad file (I use vi,
 >    but any reasonable editor would do).
 > 4) modify the XXX.spad file and save it

I think you might save time in 9, 10 below by editing the pamhlet
directly, and binding some keystroke to notangle or document.

I admit however, that it is probably better to have only one chunk per
function.  Having it in a completely separate section looks "far away"
from me, I probably won't ever update documentation in a different file.

 > 5) Do

 > )compile XXX.spad

 > (typically the command is in command history so this is fast)
 > 6) Test (frequently test are in history too, so this also is
 >    fast)
 > 7) if not done goto 4
 > 8) make diff of original XXX.spad and modified XXX.spad
 > 9) Edit the diff replacing XXX.spad by xxx.spad.pamphlet
 > 10) Applay the diff to algebra
 > 11) Do full bootrap to final test.

The true question probably is: how to allow different workflows in the
same project...

Martin
From: leh...@bayou.uni-linz.ac.at
Date: Sat, 5 Dec 2009 22:02:01 +0100
Local: Sat, Dec 5 2009 4:02 pm
Subject: Re: [fricas-devel] Multiplication of power series

Dear Waldek

thank you for the explanations on streams.
Incidentally I am working with streams too these days
(moments, Jacobi parameters and continued fractions)
and found this extremely helpful.
Also the recent comments on the spad compiler.

On Sat, Dec 05, 2009 at 04:54:52PM +0100, Waldek Hebisch wrote:
 > No!!!  I _really_ do not want to see such texts inside source
 > files.

well after notangle they disappear ... this way everyone is more or less
happy.

 > Such for given person such text may be useful once,

Given many persons it will be useful many times :)

 > In other words, persons looking at/modifying algebra code are
 > supposed to have appropriate background knowledge.

At the moment the source code is an essential part of the documentation.
Most prospective library programmers and readers will be mathematicians
with low programming background (I have almost none),
concentrating on mathematics.
Given that the compiler and the library is mostly undocumented,
where should this background knowledge come from?

 > Consider
 > research article on some fancy rings.  If you put there
 > elementary introduction to rings every referee will tell
 > you to delete such material.

Well, research papers without proofs are also rejected.
Having to reconstruct every proof is even more tedious than
reading too many trivialities. Similarly here some hints
on why and what the code is supposed to do can be helpful.

 > easier.  Also, people are pretty good at analogy, so explaing
 > one thing allows them to understand similar thins.

Indeed. The information should be there and cross referenced
when needed.

 > For background we should have documentation (separate
 > from source code!).  Unfortunatly, past "literate"
 > effort removed places where normally documentation
 > should live.  But is relatively easy to cure.

So where should I put documentation for my domains?
I mostly write it for myself in order to understand my own code later
and where it came from.
Being a forgetful person I very much like having everything in one file,
but understand that this is personal taste.
Another advantage is that I can have multiple alternative versions of
a chunk in _one_ file and being able to quickly switch by just
changing the name of subchunks.

 > )compile XXX.spad

I write a Makefile extracting the *.spad and *.input code from  *.nw and do
)sys make
)compile XXX.spad
)read test
this is almost as fast. And only one source file for everything.
And if this is too much typing,
put the three lines into yet another .input file.

 > 7) if not done goto 4
 > 8) make diff of original XXX.spad and modified XXX.spad
 > 9) Edit the diff replacing XXX.spad by xxx.spad.pamphlet

not needed.

 > My fist feeling was that this text was too rough to elevate it
 > to status of documentation.  But if you think that it is good
 > enough we can create documentation subdirectory and put it there.

Yes, please this is exactly the kind of documentation newcomers like to see.
In any case documentation not written immediately will never be written.
Given that everyone's time on this planet is finite,
things which are not written down will be gone sooner or later.

just my 2c
Franz


From: Ralf Hemmecke <r...@hemmecke.de>
Date: Sat, 05 Dec 2009 23:30:10 +0100
Local: Sat, Dec 5 2009 5:30 pm
Subject: Re: [fricas-devel] Multiplication of power series

On 12/05/2009 04:54 PM, Waldek Hebisch wrote:

 > Ralf Hemmecke wrote:
 >> Waldek,

 >> Since we have literate programming, I think your explanation would be
 >> best put just next to your implementation. Can you commit that?

 > No!!!  I _really_ do not want to see such texts inside source
 > files.  Such for given person such text may be useful once,
 > maybe few times, but having to read it or even only look at
 > it every time when looking at code is simply too distracting.

Hmmm. OK, I cannot and will not force anybody to find literate
programming important.

There are still proper tools missing to support LP. Thank you, Martin
and Franz, that now I know you are more or less on the LP side and find
this a good thing.

Anyway, I guess, what Waldek says should not be overlooked. Looking at
what I did during my work at aldor-combinat

http://www.risc.uni-linz.ac.at/people/hemmecke/aldor/combinat/

I must say that it was a time when I tried to figure out whether LP is
good or bad. Look at the text there, it's not perfect. Not perfect in
terms of structure of the text and not perfect to fit one's workflow.
And, although there is lot's of information, most people will probably
find an overview section missing. Yes, aldor-combinat is unfinished in
terms of documentation.

An important point that Waldek makes is that as the original programmer,
one knows all the background and just wants to code and refactor the
code. Documentation is just getting in the way.

Unfortunately, documentation is more often read than written and the
most important thing is that the documentation is for other people. In
particular for other programmers that want to understand the code and
improve it.

I think, we as the FriCAS team have to make a compromise to make
everyone happy. If Waldek doesn't (yet) like LP, we must accept it. As I
said in my last mail, however, there should at least be a pointer in the
.spad file (write it as -- comment) which points to a file or section
that contains the corresponding information.

Waldek, I'm so happy that you wrote that section in
http://groups.google.com/group/fricas-devel/browse_thread/thread/7bf2...
but please put it into the source code repository. For me it doesn't
matter where. I find that in the same .pamphlet file is the best option,
but if you like, open up another place, but put a link to that place in
the .spad file.

Whenever we become more than 100 developers (smiling a little), we can
be more strict with LP rules. But who knows when this will happen.
Waldek is right in the sense that FriCAS should be made interesting in
term of functionality in order to attract more people.

Ralf

From: Bill Page <bill.p...@newsynthesis.org>
Date: Tue, 8 Dec 2009 13:46:55 -0500
Local: Tues, Dec 8 2009 1:46 pm
Subject: Re: [fricas-devel] Multiplication of power series


- Hide quoted text -
- Show quoted text -
On Sat, Dec 5, 2009 at 5:30 PM, Ralf Hemmecke wrote:
 > On 12/05/2009 04:54 PM, Waldek Hebisch wrote:
 >> Ralf Hemmecke wrote:
 >>> Waldek,

 >>> Since we have literate programming, I think your explanation would be
 >>> best put just next to your implementation. Can you commit that?

 >> No!!!  I _really_ do not want to see such texts inside source
 >> files.  Such for given person such text may be useful once,
 >> maybe few times, but having to read it or even only look at
 >> it every time when looking at code is simply too distracting.

 > Hmmm. OK, I cannot and will not force anybody to find literate
 > programming important.

 > There are still proper tools missing to support LP. Thank you, Martin
 > and Franz, that now I know you are more or less on the LP side and
 > find this a good thing.
 > ...

Perhaps there are also people like me who have "lost faith" in the
concept of literate programming. When I first started with the Axiom
project several years ago I originally thought it was a good idea and
a reasonable response to the serious problem of lack of documentation
of the Axiom system. But now I agree with Waldek that almost always
the "documentation" part of the pamphlet files gets in the way of my
understanding of the code and work almost exclusively with the .spad
files until forced to re-assemble them into the pamphlet form.

I do not think that this is only a result of the lack of proper tools
to support LP although I have long argued that there are better
approaches than the one originally advocated by Donald Knuth. There
are multiple problems but I think the most serious problem is that the
methodology just does not fit the psychology of many (most?) of the
talented people who are able to do this kind of work - particularly
when they do it voluntarily. Advocated "re-education" and greater
self-discipline is simply impractical. And hoping that other motivated
users/developers will appear who are willing to put an effort into
documenting other people's code is simply unrealistic.

Having worked with Sage for awhile it seems to me that the "doc
string" methodology much better suits the current state-of-the-art and
state-of-mind in software development. Ironically this is very similar
to the ++ style comments in Spad and how they interact with hyperdoc.
I am very happy that Waldek has stated elsewhere that he considers the
hyperdoc documentation to be the "definitive source" for documentation
of FriCAS and that he spent considerable effort to resurrect the tools
from the original Axiom source code to help keep Hyperdoc up to date.
It seems that even more can be done in this direction to advance the
original approach developed before Axiom became an open source
project. For example as I understand it the Axiom book was originally
extracted from the same set of enhanced tex files combined with
documentation in the Axiom source code and derived by running Axiom
itself.

I think that it was a great experiment but in the end it is rather
unfortunate that Tim Daly choose to adopt a new "technology" based on
the Knuth literate programming approach when initiating the first open
source Axiom project rather than focusing on extending and expanding
the use of hyperdoc. I cannot see any evidence at all that the use of
literate programming as such in the original Axiom project has
contributed anything to the acceptance of Axiom in the potential
user/developer community.

Needless to repeat I suppose that this is of course only my personal
opinion. :-)

\start
Date: Thu, 10 Dec 2009 03:34:17 -0500
From: Tim Daly
To: Bertfried Fauser, Martin Baker
Subject: GrassmannAlgebra domain

The GrassmannAlgebra domain has been added to Axiom. --Tim

\start
Date: Thu, 10 Dec 2009 18:12:30 +0000
From: Martin Baker
To: list
Subject: Re: GrassmannAlgebra domain

> The GrassmannAlgebra domain has been added to Axiom. --Tim

Tim,

Thanks, do you have any views about how it should evolve from here? I think 
the first stage is to fix the known issues and get the inverse function 
working well enough to be able to implement transforms for any metric.  At 
that stage I think the code should be useful for experimenting with 
geometry/physics applications.

Then at some stage I think it would be good if there were to be some sort of 
discussion about the code and naming structure. For instance: how the 
categories and so on should be designed to relate to other algebra families in 
Axiom such as Cayley-Dickson, Spinor, Hopf and Tensor Algebras.

\start
Date: Thu, 10 Dec 2009 15:03:34 -0500
From: Tim Daly
To: Martin Baker
Subject: Re: GrassmannAlgebra domain

Martin Baker wrote:
>> The GrassmannAlgebra domain has been added to Axiom. --Tim
>>     
>
> Tim,
>
> Thanks, do you have any views about how it should evolve from here? I think 
> the first stage is to fix the known issues and get the inverse function 
> working well enough to be able to implement transforms for any metric.  At 
> that stage I think the code should be useful for experimenting with 
> geometry/physics applications.
>
> Then at some stage I think it would be good if there were to be some sort of 
> discussion about the code and naming structure. For instance: how the 
> categories and so on should be designed to relate to other algebra families in 
> Axiom such as Cayley-Dickson, Spinor, Hopf and Tensor Algebras.
>
> Martin
>
>   

Well Axiom is all about organizing the algebra into hierarchical
categories where each category build on prior ones.

Is there a natural hierarchy of these algebras? If so, I think it is
important to extract that hierarchy, define the operations at the
category level even if they do not have an implementation there, and
layer the categories naturally.

I would start by just writing the Cayley-Dickson, Spinor, Hopf, and
Tensor domain definitions (without implementations), find the common
operations, collect them into a category, and inherit from that
category.

I know a little bit about Clifford algebra and I'm reading the
Grassman algebra book now but I do not know enough to say anything
about what would be common among the various algebras.

\start
Date: Sat, 19 Dec 2009 12:30:32 +0800
From: Lee Duhem
To: list
Subject: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

I have found some typo and formatting problems in
books/bookvol0.pamphlet and books/bookvol1.pamphlet,
this is the fix. You may want take a look.

lee

--001636ed67822270a1047b0d51ef

[encoded data, 10318 characters]
M319LCAge1xmcmFjezR9ezV9fSAK
--001636ed67822270a1047b0d51ef

[encoded data, 5698 characters]
IDN9LCAgezEgXG92ZXIgM30sICB7NCBcb3ZlciA1fSAK
--001636ed67822270a1047b0d51ef--

\start
Date: Sat, 19 Dec 2009 10:19:29 -0500
From: Tim Daly
To: Lee Duhem
Subject: Re: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

Lee Duhem wrote:
> Hi,
>
> I have found some typo and formatting problems in
> books/bookvol0.pamphlet and books/bookvol1.pamphlet,
> this is the fix. You may want take a look.
>
> lee

Lee,

Thanks for the patches. They have been applied.
I also added 2 new sections and cleaned up the dangling
references. The changes should be available after the next
system build.

\start
Date: Sun, 20 Dec 2009 00:12:08 +0800
From: Lee Duhem
To: Tim Daly
Subject: Re: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

On Sat, Dec 19, 2009 at 11:19 PM, Tim Daly wrote:
> Lee,
> Thanks for the patches. They have been applied.

I'm glad that I can help.

\start
Date: Sun, 20 Dec 2009 00:48:56 +0800
From: Lee Duhem
To: Tim Daly
Subject: Re: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

On Sat, Dec 19, 2009 at 11:19 PM, Tim Daly wrote:
> Lee,
> Thanks for the patches. They have been applied.

BTW, there are two typo fixes lost in the applied patches.

lee

--0016368e230edccc8f047b17a165

ZGlmZiAtLWdpdCBhL2Jvb2tzL2Jvb2t2b2wwLnBhbXBobGV0IGIvYm9va3MvYm9va3ZvbDAucGFt
cGhsZXQKaW5kZXggYmUzZDI4OC4uNDUwOTgwNiAxMDA2NDQKLS0tIGEvYm9va3MvYm9va3ZvbDAu
cGFtcGhsZXQKKysrIGIvYm9va3MvYm9va3ZvbDAucGFtcGhsZXQKQEAgLTE2NDIsNyArMTY0Miw3
IEBAIEdpdmVuIHRoYXQgd2UgY2FuIGRlZmluZSBleHByZXNzaW9ucyBpbnZvbHZpbmcgc3ltYm9s
cywgaG93IGRvIHdlIGFjdHVhbGx5CiBjb21wdXRlIHRoZSByZXN1bHQgd2hlbiB0aGUgc3ltYm9s
cyBhcmUgYXNzaWduZWQgdmFsdWVzPyBUaGUgYW5zd2VyIGlzIHRvCiB1c2UgdGhlIHtcYmYgZXZh
bH0gZnVuY3Rpb24gd2hpY2ggdGFrZXMgYW4gZXhwcmVzc2lvbiBhcyBpdHMgZmlyc3QgYXJndW1l
bnQKIGZvbGxvd2VkIGJ5IGEgbGlzdCBvZiBhc3NpZ25tZW50cy4gRm9yIGV4YW1wbGUsIHRvIGV2
YWx1YXRlIHRoZSBleHByZXNzaW9ucwote1xiZiBYRHVtbXl9IGFuZCB7XGJmIHh5RHVtbXl9IHJl
c3VsdGluZyBmcm9tIHRoZWlyIHJlc3BlY3RpdmUgYXNzaWdubWVudHMgCit7XHNsIHhEdW1teX0g
YW5kIHtcc2wgeHlEdW1teX0gcmVzdWx0aW5nIGZyb20gdGhlaXIgcmVzcGVjdGl2ZSBhc3NpZ25t
ZW50cyAKIGFib3ZlIHdlIHR5cGU6CiAKIFxzcGFkY29tbWFuZHtldmFsKHhEdW1teSx4PTMpfQpk
aWZmIC0tZ2l0IGEvYm9va3MvYm9va3ZvbDEucGFtcGhsZXQgYi9ib29rcy9ib29rdm9sMS5wYW1w
aGxldAppbmRleCA1MjgxMDk4Li4yOTYyYzRlIDEwMDY0NAotLS0gYS9ib29rcy9ib29rdm9sMS5w
YW1waGxldAorKysgYi9ib29rcy9ib29rdm9sMS5wYW1waGxldApAQCAtMjE2Niw3ICsyMTY2LDcg
QEAgR2l2ZW4gdGhhdCB3ZSBjYW4gZGVmaW5lIGV4cHJlc3Npb25zIGludm9sdmluZyBzeW1ib2xz
LCBob3cgZG8gd2UgYWN0dWFsbHkKIGNvbXB1dGUgdGhlIHJlc3VsdCB3aGVuIHRoZSBzeW1ib2xz
IGFyZSBhc3NpZ25lZCB2YWx1ZXM/IFRoZSBhbnN3ZXIgaXMgdG8KIHVzZSB0aGUge1xiZiBldmFs
fSBmdW5jdGlvbiB3aGljaCB0YWtlcyBhbiBleHByZXNzaW9uIGFzIGl0cyBmaXJzdCBhcmd1bWVu
dAogZm9sbG93ZWQgYnkgYSBsaXN0IG9mIGFzc2lnbm1lbnRzLiBGb3IgZXhhbXBsZSwgdG8gZXZh
bHVhdGUgdGhlIGV4cHJlc3Npb25zCi17XHNsIFhEdW1teX0gYW5kIHtcc2wgeHlEdW1teX0gcmVz
dWx0aW5nIGZyb20gdGhlaXIgcmVzcGVjdGl2ZSAKK3tcc2wgeER1bW15fSBhbmQge1xzbCB4eUR1
bW15fSByZXN1bHRpbmcgZnJvbSB0aGVpciByZXNwZWN0aXZlIAogYXNzaWdubWVudHMgYWJvdmUg
d2UgdHlwZToKIAogXGluZGV4e2V2YWx9Cg==
--0016368e230edccc8f047b17a165--

\start
Date: Sun, 20 Dec 2009 05:47:06 -0500
From: Tim Daly
To: Lee Duhem
Subject: Re: [PATCH] Fix some typo and formatting problems in books/bookvol0.pamphlet and books/bookvol1.pamphlet

Lee Duhem wrote:
> On Sat, Dec 19, 2009 at 11:19 PM, Tim Daly wrote:
>   
>> Lee,
>> Thanks for the patches. They have been applied.
>>     
>
> BTW, there are two typo fixes lost in the applied patches.
>
> lee
>   

Fixed. Thanks.
I also applied your patches to the HTML version of the book.

\start
Date: Tue, 29 Dec 2009 11:18:14 -0500
From: Tim Daly
To: list
Subject: [Fwd: ITP 2010 - Third Call for Papers]

-------- Original Message --------

                          Call for Papers
        ITP 2010: Conference on Interactive Theorem Proving
                11-14 July 2010, Edinburgh, Scotland
             http://www.floc-conference.org/ITP-cfp.html

                               -----

ITP brings together researchers working in all areas of interactive
theorem proving.  It combines the communities of two venerable
meetings: the TPHOLs conference and the ACL2 workshop.  The inaugural
meeting of ITP will be held on 11-14 July 2010 in Edinburgh, Scotland,
as part of the Federated Logic Conference (FLoC, 9-21 July 2010),
co-located with the other FLoC conferences (CAV, ICLP, IJCAR, LICS,
RTA, SAT) and workshops.

The program committee welcomes submissions on all aspects of
interactive theorem proving and its applications.  Examples of typical
topics include formal aspects of hardware or software (specification,
verification, semantics, synthesis, refinement, compilation, etc.);
formalization of significant bodies of mathematics; advances in
theorem prover technology (automation, decision procedures, induction,
combinations of systems and tools, etc.); other topics including those
relating to user interfaces, education, comparisons of systems, and
mechanizable logics; and concise and elegant worked examples ("Proof
Pearls").

Submission details:

All papers must be submitted electronically, via EasyChair:

 http://www.easychair.org/conferences/?conf=itp10

Papers may be no longer than 16 pages and are to be submitted in PDF
using the Springer "llncs" format.  Instructions may be found at
ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/instruct/authors/typeinst.pdf
with Latex source file typeinst.tex in the same directory.
Submissions must describe original unpublished work not submitted for
publication elsewhere, presented in a way that users of other systems
can understand.  The proceedings will be published as a volume in the
Lecture Notes in Computer Science series and will be available to
participants at the conference.

In addition to regular submissions, described above, there will be a
"rough diamonds" section.  Rough diamond submissions are limited to
four pages and may consist of an extended abstract.  They will be
refereed: they will be expected to present innovative and promising
ideas, possibly in an early form and without supporting evidence.
Accepted diamonds will be published in the main proceedings.  They
will be presented at the conference venue in a poster session.

Authors of accepted papers are expected to present their papers at the
conference, and will be required to sign copyright release forms. 
All submissions must be written in English.

Important dates (midnight GMT):

 Abstract submission deadline:         15 January 2010
 Paper submission deadline:            22 January 2010
 Notification of paper decisions:        15 March 2010
 Camera-ready papers due from authors:    9 April 2010
 Conference dates:                     11-14 July 2010

Web page:

 http://www.floc-conference.org/ITP-cfp.html

Conference co-chairs:

 Matt Kaufmann, University of Texas at Austin, USA
 Larry Paulson, University of Cambridge, United Kingdom

Program Committee:

 Thorsten Altenkirch, Nottingham University, United Kingdom
 David Aspinall, Edinburgh University, United Kingdom
 Jeremy Avigad, Carnegie Mellon University, USA
 Gilles Barthe, IMDEA, Spain
 Jens Brandt, University of Kaiserslautern, Germany
 Thierry Coquand, Chalmers University, Sweden
 Ruben Gamboa, University of Wyoming, USA
 Georges Gonthier, Microsoft Research, United Kingdom
 David Greve, Rockwell Collins Inc., USA
 Elsa Gunter, University of Illinois at Urbana-Champaign, USA
 John Harrison, Intel Corporation, USA
 Joe Hurd, Galois Inc., USA
 Matt Kaufmann, University of Texas at Austin, USA
 Gerwin Klein, NICTA, Australia
 Xavier Leroy, INRIA, France
 Assia Mahboubi, INRIA, France
 Panagiotis Manolios, Northeastern University, USA
 John Matthews, Galois Inc., USA
 J Moore, University of Texas at Austin, USA
 Cesar Munoz, NASA, USA
 Tobias Nipkow, TU Muenchen, Germany
 Michael Norrish, NICTA, Australia
 David Pichardie, INRIA Rennes, France
 Brigitte Pientka, McGill University, Canada
 Lee Pike, Galois Inc., USA
 Sandip Ray, University of Texas at Austin, USA
 Jose Luis Ruiz-Reina, Universidad de Sevilla, Spain
 Larry Paulson, University of Cambridge, United Kingdom
 David Russinoff, Advanced Micro Devices Inc., USA
 Peter Sewell, University of Cambridge, United Kingdom
 Konrad Slind, Rockwell Collins Inc., USA
 Sofiene Tahar, Concordia University, Canada
 Christian Urban, TU Muenchen, Germany

Workshop Chair:

 Michael Norrish, NICTA, Australia

Local Arrangements:

 David Aspinall, Edinburgh University, United Kingdom





