math statistical distribution: multivariate gaussian
Hi, I'm about to start implementing a library for multivariate Gaussian distribution. The goal is to build a lib that provides a container for the definition of multivariate Gaussian, as well as implement various identities of that distributions. The identities are things like mean, variance but also conditional distributions, density gradients vector, linear combinations of multivariate Gaussian, Gaussian chain rule etc. I've seen request for something like this in the boost:math/statistical_distributions todo's list, and was wondering if it's possible to team up, or -if nobody is working on it- initiate development. Best, Thijs -- SITMO Quantitative Financial Consultancy - Software Development M.A. (Thijs) van den Berg Tel.+31 (0)6 2411 0061 Fax.+31 (0)15 285 1984 thijs@sitmo.com <mailto:thijs@sitmo.com> - www.sitmo.com <http://www.sitmo.com>
Thijs van den Berg wrote:
I'm about to start implementing a library for multivariate Gaussian distribution. The goal is to build a lib that provides a container for the definition of multivariate Gaussian, as well as implement various identities of that distributions. The identities are things like mean, variance but also conditional distributions, density gradients vector, linear combinations of multivariate Gaussian, Gaussian chain rule etc.
I've seen request for something like this in the boost:math/statistical_distributions todo's list, and was wondering if it's possible to team up, or -if nobody is working on it- initiate development.
There's nothing in development at present (that I know of), so a submission would certainly be welcome. The main open issue IMO is getting the interface right for the mutivariate case. Regards, John.
John Maddock wrote:
Thijs van den Berg wrote:
I'm about to start implementing a library for multivariate Gaussian distribution. [snip] it's possible to team up, or -if nobody is working on it- initiate development?
There's nothing in development at present (that I know of), so a submission would certainly be welcome. The main open issue IMO is getting the interface right for the mutivariate case.
Yes, exactly, the interface is one of the main reason for me to team up with C++ pears, to try and get that right. That a thing where feedback is very helpful! As I see it, there are a couple of interface issue: * containers for the multivariate parameters (vectors and matrices) and operators on those containers -inverse of a matrix- * specifying generic functions/properties of multivariate densities, that would apply to *any* multivariate density * the number of Gaussian identities/operators/function/algorithms to include, there are many, some widely used, some obscure... I'm trying to form a team -asking friends- and will probably be able to get some knowledgeable C++ developers to contribute to this. As I understand, the procedure is to get it working first & then submit it to the sandbox? How would I be able to get boost developers involved during the early interface design phase? Regards, Thijs
Regards, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thijs van den Berg wrote:
There's nothing in development at present (that I know of), so a submission would certainly be welcome. The main open issue IMO is getting the interface right for the mutivariate case.
Yes, exactly, the interface is one of the main reason for me to team up with C++ pears, to try and get that right. That a thing where feedback is very helpful!
Nod.
As I see it, there are a couple of interface issue: * containers for the multivariate parameters (vectors and matrices) and operators on those containers -inverse of a matrix-
Can we not define a *Concept* for multivariate parameters, and convert them internally to whatever internal representation is used? Boost.uBlas has matrix inversion (via LU decomposition), but it's not necessarily all that stable :-( Is matrix inversion really necessary?
* specifying generic functions/properties of multivariate densities, that would apply to *any* multivariate density
Nod. The list that applies to the univariate densities in Boost.Math would be a good place to start, modulo the ones that cannot be implemented in the multivariate case (quantile for example).
* the number of Gaussian identities/operators/function/algorithms to include, there are many, some widely used, some obscure...
I'm trying to form a team -asking friends- and will probably be able to get some knowledgeable C++ developers to contribute to this. As I understand, the procedure is to get it working first & then submit it to the sandbox?
Yep.
How would I be able to get boost developers involved during the early interface design phase?
Ask here for comments on the design right here: it helps a great deal to have some docs at this point, as it's easier for folks to get their heads around. You're also most welcome to fly your ideas past myself, Paul (Bristow), and whoever else volunteers first of course :-) Cheers, John.
John Maddock wrote:
Thijs van den Berg wrote:
There's nothing in development at present (that I know of), so a submission would certainly be welcome. The main open issue IMO is getting the interface right for the mutivariate case.
Yes, exactly, the interface is one of the main reason for me to team up with C++ pears, to try and get that right. That a thing where feedback is very helpful!
Nod.
As I see it, there are a couple of interface issue: * containers for the multivariate parameters (vectors and matrices) and operators on those containers -inverse of a matrix-
Can we not define a *Concept* for multivariate parameters, and convert them internally to whatever internal representation is used?
Yes, that would be the most flexible approach, separating containers from algorithm acting upon them!
Boost.uBlas has matrix inversion (via LU decomposition), but it's not necessarily all that stable :-( Is matrix inversion really necessary?
It could indeed be the case that inversion is not needed. It all depends on the type of functions what will be supported. I know of some who *do* need inversion.
* specifying generic functions/properties of multivariate densities, that would apply to *any* multivariate density
Nod. The list that applies to the univariate densities in Boost.Math would be a good place to start, modulo the ones that cannot be implemented in the multivariate case (quantile for example).
Yes. that would be a very good start. I'll do that.
Ask here for comments on the design right here: it helps a great deal to have some docs at this point, as it's easier for folks to get their heads around. You're also most welcome to fly your ideas past myself, Paul (Bristow), and whoever else volunteers first of course :-) Thanks! The docs will be someting I'm going to start on tomorrow. What is a good doc format, and what are good tools for that format?
Cheers, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thijs van den Berg wrote:
Ask here for comments on the design right here: it helps a great deal to have some docs at this point, as it's easier for folks to get their heads around. You're also most welcome to fly your ideas past myself, Paul (Bristow), and whoever else volunteers first of course :-) Thanks! The docs will be someting I'm going to start on tomorrow. What is a good doc format, and what are good tools for that format?
If the docs are intended to be eventually merged with the existing Boost.Math docs then it'll have to be quickbook: http://www.boost.org/doc/libs/1_37_0/doc/html/quickbook.html . Once you get the hang of the markup language used it's actually very simple, the only issue is that you can't embed equations directly in the text like you can with say LaTex, there's some info on how I handled equations here: http://www.boost.org/doc/libs/1_37_0/libs/math/doc/sf_and_dist/html/math_too... but maybe you can get by without any to begin with? HTH, John.
2008/11/19 Thijs van den Berg <thijs@sitmo.com>:
Hi,
I'm about to start implementing a library for multivariate Gaussian distribution. The goal is to build a lib that provides a container for the definition of multivariate Gaussian, as well as implement various identities of that distributions. The identities are things like mean, variance but also conditional distributions, density gradients vector, linear combinations of multivariate Gaussian, Gaussian chain rule etc.
I've seen request for something like this in the boost:math/statistical_distributions todo's list, and was wondering if it's possible to team up, or -if nobody is working on it- initiate development.
I would find a boost implementation of a multivariate Gaussian distribution very useful. I'm interested in helping. Best, Stjepan
Stjepan Rajko wrote:
2008/11/19 Thijs van den Berg <thijs@sitmo.com>:
Hi,
I'm about to start implementing a library for multivariate Gaussian distribution. The goal is to build a lib that provides a container for the definition of multivariate Gaussian, as well as implement various identities of that distributions. The identities are things like mean, variance but also conditional distributions, density gradients vector, linear combinations of multivariate Gaussian, Gaussian chain rule etc.
I've seen request for something like this in the boost:math/statistical_distributions todo's list, and was wondering if it's possible to team up, or -if nobody is working on it- initiate development.
I would find a boost implementation of a multivariate Gaussian distribution very useful. I'm interested in helping.
Best,
Stjepan
Hi Stjepan, Great that you want to help! I see a couple of things that we could start working on, perhaps you have other/additional idea's! * define a name for the sandbox folder & create it. * start a doc in that folder where we collect the details: interfaces, function, equations, algorithms. Can that be done in Latex & compiled pdf ? What would be a good doc format? ---- These first two are probably the best way to start... John Maddock suggest starting with docs, I agree with that, that should be covered with these first two points! More thing that we will need to do are: * define a list of generic function for generic multivariate densities (non member properties) along the lines of this: http://www.boost.org/doc/libs/1_37_0/libs/math/doc/sf_and_dist/html/math_too... some things that "I" need to implement -as a user- for some other project can be seen in this list http://www.cs.toronto.edu/~roweis/notes/gaussid.pdf ..and there are many more things being used related to multivariate Gaussians. E.g. a lot of machine learning project work with multivariate Gaussians -they need parameter estimation from data- Some of these things might be too specific to add to boost distributions, and could fill up a whole "Gaussian lib" in itself! I don't know. We might also look at other mathematic packages like Matlab, R, Octave to see what they do with multivariate distributions. * using that list, we will see what type of matrix operators we will need, and that will allow us think about either between making a dependency to ublas & other, or keep it void from external dependencies & implement it ourselves. * We should also collect info on smart numerical solutions for specific multivariate Gaussians. E.g. I know of good 2d and 3d approximations of the cdf, but for higher dimensions we need to do numerical approximations. We can collect information on what to do with those cases in doc. Cheers, Thijs
2008/11/19 Thijs van den Berg <thijs@sitmo.com>:
I see a couple of things that we could start working on, perhaps you have other/additional idea's!
* define a name for the sandbox folder & create it.
How about sandbox/multivariate_distributions ? If this is geared towards Boost.Math, we should probably consider that library's directory structure. Currently, the statistical distributions files appear to be placed as follows: include files: ..../boost/include/math/distributions docs: ..../libs/math/distributions/doc/sf_and_dist tests: ..../libs/math/distributions/test examples: ..../libs/math/distributions/example I'm not sure whether we should re-use all of those directories or change some (or all) of them.
* start a doc in that folder where we collect the details: interfaces, function, equations, algorithms. Can that be done in Latex & compiled pdf ? What would be a good doc format?
I would recommend quickbook, like John suggested. I can set up the basic files for a starting docs build once we decide on the directory structure.
---- These first two are probably the best way to start... John Maddock suggest starting with docs, I agree with that, that should be covered with these first two points! More thing that we will need to do are:
* define a list of generic function for generic multivariate densities (non member properties) along the lines of this: http://www.boost.org/doc/libs/1_37_0/libs/math/doc/sf_and_dist/html/math_too...
I'd suggest following John's suggestion in starting with the subset of that list that applies to multivariate distributions. If we start adding things and this ends up in Boost.Math, then the same things we add for multivariate distributions should also probably be added for the univariate distributions (if they apply) for consistency.
some things that "I" need to implement -as a user- for some other project can be seen in this list http://www.cs.toronto.edu/~roweis/notes/gaussid.pdf ..and there are many more things being used related to multivariate Gaussians. E.g. a lot of machine learning project work with multivariate Gaussians -they need parameter estimation from data- Some of these things might be too specific to add to boost distributions, and could fill up a whole "Gaussian lib" in itself! I don't know.
I think parameter estimation from data would be a very useful thing to add, but if we do we should keep all distributions in mind.
We might also look at other mathematic packages like Matlab, R, Octave to see what they do with multivariate distributions.
* using that list, we will see what type of matrix operators we will need, and that will allow us think about either between making a dependency to ublas & other, or keep it void from external dependencies & implement it ourselves.
I think the concept-based way is the way to go. We can let the user provide the matrix type, as long as it provides the operations we need. Maybe we can use ublas matrices as the default type if it is sufficient, since that is already in boost (and header-only), and maybe test with some other libraries just to make sure we're not requiring syntax that is too ublas-specific. Best, Stjepan
Stjepan Rajko wrote:
2008/11/19 Thijs van den Berg <thijs@sitmo.com>:
I see a couple of things that we could start working on, perhaps you have other/additional idea's!
* define a name for the sandbox folder & create it.
How about sandbox/multivariate_distributions ?
very good!
If this is geared towards Boost.Math, we should probably consider that library's directory structure. Currently, the statistical distributions files appear to be placed as follows:
include files: ..../boost/include/math/distributions docs: ..../libs/math/distributions/doc/sf_and_dist tests: ..../libs/math/distributions/test examples: ..../libs/math/distributions/example
I'm not sure whether we should re-use all of those directories or change some (or all) of them.
I agree, let's keep it simple for a start-we are in the sandbox- put the doc & code directly in sandbox/multivariate_distributions? We can also split things up once we have a start
* start a doc in that folder where we collect the details: interfaces, function, equations, algorithms. Can that be done in Latex & compiled pdf ? What would be a good doc format?
I would recommend quickbook, like John suggested. I can set up the basic files for a starting docs build once we decide on the directory structure.
I like quickbook too, I'm almost ready installing the generation tools. It would be great if you could set up the basic files!
---- These first two are probably the best way to start... John Maddock suggest starting with docs, I agree with that, that should be covered with these first two points! More thing that we will need to do are:
* define a list of generic function for generic multivariate densities (non member properties) along the lines of this: http://www.boost.org/doc/libs/1_37_0/libs/math/doc/sf_and_dist/html/math_too...
I'd suggest following John's suggestion in starting with the subset of that list that applies to multivariate distributions. If we start adding things and this ends up in Boost.Math, then the same things we add for multivariate distributions should also probably be added for the univariate distributions (if they apply) for consistency.
very good, but there will indeed be some things that only apply to multivariate
some things that "I" need to implement -as a user- for some other project can be seen in this list http://www.cs.toronto.edu/~roweis/notes/gaussid.pdf ..and there are many more things being used related to multivariate Gaussians. E.g. a lot of machine learning project work with multivariate Gaussians -they need parameter estimation from data- Some of these things might be too specific to add to boost distributions, and could fill up a whole "Gaussian lib" in itself! I don't know.
I think parameter estimation from data would be a very useful thing to add, but if we do we should keep all distributions in mind.
Yes, and that a big extension! For consistency, this would imply that all current univariate distributions would also need param estrimation. Another feature used a lot (in code) is to draw random samples from distributions. Anther possibility I see is to keep some of those things ouside this scope, and put it somewhere else.
We might also look at other mathematic packages like Matlab, R, Octave to see what they do with multivariate distributions.
* using that list, we will see what type of matrix operators we will need, and that will allow us think about either between making a dependency to ublas & other, or keep it void from external dependencies & implement it ourselves.
I think the concept-based way is the way to go. We can let the user provide the matrix type, as long as it provides the operations we need. Maybe we can use ublas matrices as the default type if it is sufficient, since that is already in boost (and header-only), and maybe test with some other libraries just to make sure we're not requiring syntax that is too ublas-specific.
Yes I agree!
Best,
Stjepan
2008/11/19 Thijs van den Berg <thijs@sitmo.com>:
Stjepan Rajko wrote:
If this is geared towards Boost.Math, we should probably consider that library's directory structure. Currently, the statistical distributions files appear to be placed as follows:
include files: ..../boost/include/math/distributions docs: ..../libs/math/distributions/doc/sf_and_dist tests: ..../libs/math/distributions/test examples: ..../libs/math/distributions/example
I'm not sure whether we should re-use all of those directories or change some (or all) of them.
I agree, let's keep it simple for a start-we are in the sandbox- put the doc & code directly in sandbox/multivariate_distributions? We can also split things up once we have a start
I made 4 subdirectories (boost, test, example, doc) just to have a little organization, and because it plays better with the boost build system. If you set your BOOST_ROOT environment variable to the root of your boost distribution, you *should* be able to go to any of {test, example, doc} and run bjam to build a skeleton test, example or docs. Let me know if you run into any problems. Best, Stjepan
Stjepan Rajko wrote:
2008/11/19 Thijs van den Berg <thijs@sitmo.com>:
Stjepan Rajko wrote:
If this is geared towards Boost.Math, we should probably consider that library's directory structure. Currently, the statistical distributions files appear to be placed as follows:
include files: ..../boost/include/math/distributions docs: ..../libs/math/distributions/doc/sf_and_dist tests: ..../libs/math/distributions/test examples: ..../libs/math/distributions/example
I'm not sure whether we should re-use all of those directories or change some (or all) of them.
I agree, let's keep it simple for a start-we are in the sandbox- put the doc & code directly in sandbox/multivariate_distributions? We can also split things up once we have a start
I made 4 subdirectories (boost, test, example, doc) just to have a little organization, and because it plays better with the boost build system. If you set your BOOST_ROOT environment variable to the root of your boost distribution, you *should* be able to go to any of {test, example, doc} and run bjam to build a skeleton test, example or docs.
Let me know if you run into any problems.
Best,
Hi Stjepan, Thanks! That's great. I've managed to compile the doc with bjam. Took me a bit of time set things up for the firs time. I started working on the doc and got a dev account for sandbox. The only issue was to commit the update. I kept getting errors 'pre-commit hook' ... but then it suddenly worked! Is adding a comment-text to a commit perhaps mandatory? anyway, a first sketch (unstructured with some idea & questions) is in /doc Best, Thijs
I've had this problem in the past. Perhaps Doug Gregor's reply will help http://archives.free.net.ph/message/20070819.120801.6c717a68.en.html HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thijs van den Berg Sent: 20 November 2008 14:28 To: boost@lists.boost.org Subject: Re: [boost] math statistical distribution: multivariate gaussian
Stjepan Rajko wrote:
2008/11/19 Thijs van den Berg <thijs@sitmo.com>:
Stjepan Rajko wrote:
If this is geared towards Boost.Math, we should probably consider that library's directory structure. Currently, the statistical distributions files appear to be placed as follows:
include files: ..../boost/include/math/distributions docs: ..../libs/math/distributions/doc/sf_and_dist tests: ..../libs/math/distributions/test examples: ..../libs/math/distributions/example
I'm not sure whether we should re-use all of those directories or change some (or all) of them.
I agree, let's keep it simple for a start-we are in the sandbox- put the doc & code directly in sandbox/multivariate_distributions? We can also split things up once we have a start
I made 4 subdirectories (boost, test, example, doc) just to have a little organization, and because it plays better with the boost build system. If you set your BOOST_ROOT environment variable to the root of your boost distribution, you *should* be able to go to any of {test, example, doc} and run bjam to build a skeleton test, example or docs.
Let me know if you run into any problems.
Best,
Hi Stjepan, Thanks! That's great. I've managed to compile the doc with bjam. Took me a bit of time set things up for the firs time.
I started working on the doc and got a dev account for sandbox. The only issue was to commit the update. I kept getting errors 'pre-commit hook' ... but then it suddenly worked! Is adding a comment-text to a commit perhaps mandatory?
anyway, a first sketch (unstructured with some idea & questions) is in /doc Best, Thijs
Paul A. Bristow wrote:
I've had this problem in the past.
Perhaps Doug Gregor's reply will help
http://archives.free.net.ph/message/20070819.120801.6c717a68.en.html
HTH
Paul
I've checked that, but those types were set ok all along I did three things, after which I suddenly was able to commit * I send an email to John Maddock :) * I changed my text editor to use Unix style text * Instead of leaving the commit comment/remark empty as I did in previous attempts, I added some text
Thijs van den Berg wrote:
I did three things, after which I suddenly was able to commit * I send an email to John Maddock :)
That doesn't change much ;-)
* I changed my text editor to use Unix style text
Ah, line endings must match your platform's default, and the whatever svn:eol-style property is set to ("native" usually).
* Instead of leaving the commit comment/remark empty as I did in previous attempts, I added some text
I suspect commits with no message will get rejected as well. John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 20 November 2008 16:06 To: boost@lists.boost.org Subject: Re: [boost] math statistical distribution: multivariate gaussian
Thijs van den Berg wrote:
I did three things, after which I suddenly was able to commit * I send an email to John Maddock :)
That doesn't change much ;-)
On the contrary, my experience is that it makes many errors go away ;-) Paul PS Here's one for example: This is triggered by changing to use the latest docbook using boostbook : "C:/Program Files/docbook/docbook-xsl-1.74.0" : "C:/Program Files/docbook/docbook-xml-4.5" ; quickbook.quickbook-to-boostbook ..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.xml Generating Output File: ..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.xml xslt-xsltproc ..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.docbook file:///C%3A/Program%20Files/docbook/docbook-xml-4.5/dbpoolx.mod:7254: validity error : Redefinition of element code <!ELEMENT code %ho; (%cptr.char.mix;)*> ^ validity warning : Attribute id of element code: already defined %common.attrib; ^ lang CDATA #IMPLIED ^ validity warning : Attribute last-revision of element code: already defined %code.role.attrib; ^ role CDATA #IMPLIED ^ xslt-xsltproc I:\Boost_sandbox\math_toolkit\libs\math\doc\sf_and_dist\..\..\bin.v2\doc\sf_ and_dist\msvc-9.0\debug\threading-multi\math.fo Making portrait pages on A4 paper (210mmx297mm) ... And the resulting pdf looks fine. Or is this a case of "Doctor, doctor it hurts when I uses version 4.5" Doctor: "Don't do that." --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
Thijs van den Berg wrote:
I did three things, after which I suddenly was able to commit * I send an email to John Maddock :)
That doesn't change much ;-)
On the contrary, my experience is that it makes many errors go away ;-)
LOL!
PS Here's one for example:
This is triggered by changing to use the latest docbook
using boostbook : "C:/Program Files/docbook/docbook-xsl-1.74.0" : "C:/Program Files/docbook/docbook-xml-4.5" ;
quickbook.quickbook-to-boostbook ..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.xml Generating Output File: ..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.xml xslt-xsltproc ..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.docbook file:///C%3A/Program%20Files/docbook/docbook-xml-4.5/dbpoolx.mod:7254: validity error : Redefinition of element code <!ELEMENT code %ho; (%cptr.char.mix;)*>
Grrr, this message: http://lists.boost.org/MailArchives/boost-docs/2005/04/1106.php suggests that all Docbook versions post 4.3 have this issue. No idea what the problem is though :-( John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 20 November 2008 18:00 To: boost@lists.boost.org Subject: Re: [boost] math statistical distribution: multivariate gaussian
Paul A. Bristow wrote:
Thijs van den Berg wrote:
I did three things, after which I suddenly was able to commit * I send an email to John Maddock :)
That doesn't change much ;-)
On the contrary, my experience is that it makes many errors go away ;-)
LOL!
PS Here's one for example:
This is triggered by changing to use the latest docbook
using boostbook : "C:/Program Files/docbook/docbook-xsl-1.74.0" : "C:/Program Files/docbook/docbook-xml-4.5" ;
quickbook.quickbook-to-boostbook ..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.xml Generating Output File: ..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.xml xslt-xsltproc
..\..\bin.v2\doc\sf_and_dist\msvc-9.0\debug\threading-multi\math.docbook
file:///C%3A/Program%20Files/docbook/docbook-xml-4.5/dbpoolx.mod:7254: validity error : Redefinition of element code <!ELEMENT code %ho; (%cptr.char.mix;)*>
Grrr, this message: http://lists.boost.org/MailArchives/boost-docs/2005/04/1106.php suggests that all Docbook versions post 4.3 have this issue. No idea what the problem is though :-(
Ah well, you can't win them all ;-)) The new section in version 4.5 is <!ENTITY % code.module "INCLUDE"> <![%code.module;[ <!ENTITY % local.code.attrib ""> <!ENTITY % code.role.attrib "%role.attrib;"> <!ENTITY % code.element "INCLUDE"> <![%code.element;[ <!--doc:An inline code fragment.--> <!ELEMENT code %ho; (%cptr.char.mix;)*> <!--end of code.element-->]]> <!ENTITY % code.attlist "INCLUDE"> <![%code.attlist;[ <!ATTLIST code language CDATA #IMPLIED %common.attrib; %code.role.attrib; %local.code.attrib;
<!--end of code.attlist-->]]> <!--end of code.module-->]]> Looks as though I may need to climb another learning curve :-(( A mistake in the syntax perhaps? I'll look into it. Paul
participants (4)
-
John Maddock -
Paul A. Bristow -
Stjepan Rajko -
Thijs van den Berg