Review Managers Needed

We need volunteer review managers for most of the libraries in the review queue. If your interested, let us know. Preferably, you would have a background in the problem domain, but no association with the library and a contributer to the boost mailing list. The review schedule is available here: http://www.boost.org/more/formal_review_schedule.html . You can read the "review manager" requirements at the following link: http://www.boost.org/more/formal_review_process.htm Most of the libraries are located at the Boost Sandbox Vault, located here: http://boost-consulting.com/vault/ Maintainers of the Review Queue: Ronald Garcia (garcia (at) cs.indiana.edu) Tom Brinkman (reportbase (at) gmail.com) If there is any errors or ommisions in this report, please send them to Ron or Tom. Here is a summary of the libraries that are in the queue. ------------------------------------- Library: Exception Author: Emil Dotchevski Location: http://www.revergestudios.com/boost-exception/boost-exception.zip Review Manager: Needed Date: Needed Summary: The purpose of Boost Exception is to free designers of exception classes from having to consider what data needs to be stored in exception objects in order for the catch site to be able to make sense of what went wrong. When Boost Exception is used, arbitrary values can be stored in any exception. This can be done directly in the throw-expression, or at a later time as the exception object propagates up the call stack. The ability to add data to any exception object after it has been thrown is important, because often some of the information needed to handle an exception is unavailable at the time of the throw. ----------------------------------------- Library: Bimap Author: Matias Capeletto Location: Boost Sandbox Vault Review Manager: Ion Gaztañaga Date: February 15 2007- February 25, 2007 Summary: With Boost.Bimap you can create associative containers where both types can be used as key. You can think a `bimap<X,Y>` as a merge of a `std::map<X,Y>` and a `std::map<Y,X>`. The learning curve of bimap is almost zero if you know how to use standard containers. A big effort was put in mapping the naming scheme of the STL in Boost.Bimap. The library is designed to match the STL common containers. ----------------------------------------- Library: Globally Unique Identifier Author: Andy Tompkins Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: A guid, or globally unique identifier, is an identifier standard used in many disciplines including computer networks, distributed computing, and databases. They can be used to tag objects with very short lifetimes, to reliably identify very persistent objects across a network. An attractive feature of guids is their relative small size, of 128-bits, compared to alternatives. Also the creation of guids does not require a centralized authority. ----------------------------------------- Library: Intrusive Containers Author: Ion Gaztañaga Location: Boost Sandbox Vault Review Manager: Joaquín Mª López Muñoz Date: March 1, 2007 - March 10, 2007 Summary: Existing practice have shown the need for intrusive containers. Widely used C++ libraries, such as C++ Standard Library and Boost have long missed such facilities so that users had to refrain from using those due to mandatory element copying or fall back to techniques like two phase construction to insert logically non-copyable elements in containers and initialize them after that or insert pointers to dynamically allocated objects which is rather inelegant and inefficient since containers also dynamically allocate nodes. The most common use cases for intrusive containers are, when one would like to store non-copyable elements in a container when it's beneficial to avoid needless data copy in performance critical applications. The most prominent example of both the use cases, although written for the most part in C rather than C++, is Linux kernel built solely upon intrusive lists, hash tables and trees. ----------------------------------------- Library: Scope Exit Author: Alexander Nasonov Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: The scope-exit-arg-pp-seq is Boot.Preprocessor sequence of identifiers that can be used inside scope-exit-body. The direct-declarator is declarator-id followed by optional argument of type boost::scope_exit_group (inside brackets or after the equal sign). This construct executes scope-exit-body at the close of the current scope. ----------------------------------------- Library: Finite State Machines Author: Andrey Semashev Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept. There are many cases when a developer would like to distinguish the behavior of a given object depending on some conditions or its internal state. For example, when making software to control an underground charging tourniquiet a programmer would like to separate states in which the tourniquiet may persist: an idle state, when the device awaits for another passenger that would like to pass; a processing state, when the passenger have come and put his ticket into the device; and the passing state, when the tourniquiet lets the passenger pass through. In fact, each state describes different reaction of the machine at the same events (a passenger may only pass after paying for ticket). Obviously, the tourniquiet have to be able to change its internal state in order to function properly, this is called state switching or transitions between states (or just transitions for short). ----------------------------------- Library: Statistical Distributions Author: John Maddock Location: Boost Sandbox Vault (math-toolkit) Review Manager: Needed Date: Needed Summary: Provides many of the tools required to implement mathematical special functions: hopefully the presence of these will encourage other authors to contribute more special function implementations in the future. There are helpers for the evaluation of infinite series, continued fractions and rational approximations. There is a fairly comprehensive set of root finding and function minimisation algorithms: both with and without derivative support. A Remez algorithm implementation allows for the locating of minimax rational approximations. There are also (experimental) classes for the manipulation of polynomials, for testing a special function against tabulated test data, and for the rapid generation of test data and/or data for output to an external graphing application. ----------------------------------- Library: Floating Point Utilities Author: Johan Råde Location: Boost Sandbox Vault http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics Review Manager: Needed Date: Needed Summary: Proposed Additions to the Boost Math Library <boost/math/fpclassify.hpp> Functions for floating point number classification: fpclassify, isfinite, isinf, isnan, isnormal. Follows TR1. <boost/math/signbit.hpp> Functions for floating point number sign bit access and modification: signbit, copysign, changesign. Follows TR1. <boost/math/nonfinite_num_facets.hpp> Facets that parse and format infinity and NaN according to the C99 standard. Used for portable handling of infinity and NaN in text streams. ----------------------------------- Library: mcs::units Author: Matthias Schabel Location: Boost Sandbox Vault http://www.boost-consulting.org/vault/ (units) Review Manager: Needed Date: Needed Summary: mcs::units is a library providing zero-runtime overhead dimensional analysis for unit and quantity calculations. It provides support for 1) unit systems comprised of arbitrary sets of base units 2) arbitrary user-defined value types 3) support for heterogenous operator algebras (i.e. Z op(X,Y)) 4) support for basic outputting of quantities 5) optional support for implicit unit conversions It does not support 1) runtime units or quantities 2) input or parsing of quantities ----------------------------------- Library: Switch Author: Steven Watanabe Location: Boost Sandbox Vault http://tinyurl.com/yvssgx Review Manager: Needed Date: Needed Summary: Needed

Hi Tom,
We need volunteer review managers for most of the libraries in the review queue. If your interested, let us know. Preferably, you would have a background in the problem domain, but no association with the library and a contributer to the boost mailing list.
I am willing to act as review manager for the Statistical Distributions library. I have read the job description and believe that I am qualified to assist with this library. At the outset, I would also like to ask John and Paul to consider the possibility of either a) splitting the library up into three components, corresponding to the statistical distributions, the special functions, and the utilities. That split is already reflected in the documents, and it might be easier to discuss and review smaller pieces separately... Regards, Matthias
----------------------------------- Library: Statistical Distributions Author: John Maddock Location: Boost Sandbox Vault (math-toolkit) Review Manager: Needed Date: Needed Summary: Provides many of the tools required to implement mathematical special functions: hopefully the presence of these will encourage other authors to contribute more special function implementations in the future. There are helpers for the evaluation of infinite series, continued fractions and rational approximations. There is a fairly comprehensive set of root finding and function minimisation algorithms: both with and without derivative support. A Remez algorithm implementation allows for the locating of minimax rational approximations. There are also (experimental) classes for the manipulation of polynomials, for testing a special function against tabulated test data, and for the rapid generation of test data and/or data for output to an external graphing application.
---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------

I am willing to act as review manager for the Statistical Distributions library. I have read the job description and believe that I am qualified to assist with this library. At the outset, I would also like to ask John and Paul to consider the possibility of either a) splitting the library up into three components, corresponding to the statistical distributions, the special functions, and the utilities. That split is already reflected in the documents, and it might be easier to discuss and review smaller pieces separately...
...or... b) renaming the library to reflect the broader scope. Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------

Matthias Schabel wrote:
I am willing to act as review manager for the Statistical Distributions library. I have read the job description and believe that I am qualified to assist with this library. At the outset, I would also like to ask John and Paul to consider the possibility of either a) splitting the library up into three components, corresponding to the statistical distributions, the special functions, and the utilities. That split is already reflected in the documents, and it might be easier to discuss and review smaller pieces separately...
...or... b) renaming the library to reflect the broader scope.
Thanks for volunteering Matthias! The library is indeed a bit of a large conglomerate that will be tricky to review - unfortunately the three parts are quite intertwined from an implementation POV :-( So I guess renaming would be the easiest option for us: it's something that Paul and I have discussed in the past, but we didn't come up with a better name: any suggestions? Thanks, John.

John Maddock wrote:
The library is indeed a bit of a large conglomerate that will be tricky to review - unfortunately the three parts are quite intertwined from an implementation POV :-(
Is the inteface equally intertwined, or just the implementation? If it is purely implementation, it might make sense to have a 3-stage review, where each component is focussed on. That might better support reviews from those with knowledge of one or two domains, but not the whole system. Whether you go the whole way and name each component as it was its own library, seprate to the shared implementation, would be another matter. e.g. phoenix and fusion have clearly grown a life of their own away from the libraries that spawned them, and I suspect proto will do the same. Coversely, Wave is a distinct library from Spirit, although entirely build on top of it. -- AlisdairM

If it is purely implementation, it might make sense to have a 3-stage review, where each component is focussed on. That might better support reviews from those with knowledge of one or two domains, but not the whole system.
I need to look at the code in more detail, but my suspicion is that the dependencies are something like this : special functions depend on utilities statistical distributions depend on utilities and special functions If this is the case, we ought to be able to review the statistical distributions portion of the code independently, regarding the special functions and utilities as implementation details, then consider the special functions as a separate library, with utilities as an implementation detail, then finally the utilities themselves... Having separate boost::math::statistics, boost::math::special_functions, and boost::math::statistics::distributions namespaces might help to compartmentalize things a bit more, too... Matthias

Matthias Schabel wrote:
If it is purely implementation, it might make sense to have a 3-stage review, where each component is focussed on. That might better support reviews from those with knowledge of one or two domains, but not the whole system.
I need to look at the code in more detail, but my suspicion is that the dependencies are something like this :
special functions depend on utilities statistical distributions depend on utilities and special functions
Yes, that's basically the way it goes.
If this is the case, we ought to be able to review the statistical distributions portion of the code independently, regarding the special functions and utilities as implementation details, then consider the special functions as a separate library, with utilities as an implementation detail, then finally the utilities themselves...
Having separate boost::math::statistics, boost::math::special_functions, and boost::math::statistics::distributions namespaces might help to compartmentalize things a bit more, too...
Special functions are currently in boost::math (this is inherited from the existing special functions that are in that namespace), distributions in boost::math::distributions, and the tools in boost::math::tools. So there is some separation already, but namespaces will no doubt get talked about at the review :-) I guess from an end user POV the tools part is the least important, while special functions are important BTW because we can't get a complete Boost.TR1 implementation without them. John.

Hi John,
I guess from an end user POV the tools part is the least important, while special functions are important BTW because we can't get a complete Boost.TR1 implementation without them.
This, I would argue, lends support for the idea of breaking things up a bit. If some or most of the special functions are essential for TR1, perhaps that portion of the review should be fast-tracked to move things forward on that front. The tools, I am sure, will be of interest, but things like root-finding and optimization are huge areas of interest in their own right and will benefit from the input of people with expertise in optimization, for example. Keeping them an implementation detail for the moment would give us much more design flexibility to accommodate the outcome of those discussions. Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of AlisdairM Sent: 08 February 2007 11:04 To: boost@lists.boost.org Subject: Re: [boost] Review Managers Needed
John Maddock wrote:
The library is indeed a bit of a large conglomerate that will be tricky to review - unfortunately the three parts are quite intertwined from an implementation POV :-(
I don't really see three parts. Any distinction between distributions and so-called special functions, or indeed the 'not-so-special' functions like log, exp sin is purely arbitrary: they are all math functions IMO. It is true that, in general, distribution functions use 'special functions' which in turn use 'not-so-special' functions, but IMO it would be confusing to try to divide them. A review does indeed need input from various people with different areas of expertise, but I don't realy see how to avoid this. Hopefully they will just limit their comments to what they know about ;-) There are also some serious practical problems about a retrospective division - not least the documentation, where we have worked quite hard to provide cross linking, and now over 250 pages as a pdf! Not to mention the code, cross function use, and common error handling etc. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

I don't really see three parts. Any distinction between distributions and so-called special functions, or indeed the
I was just drawing on the fact that the top-level of documentation is split into three sections : Statistical Distributions, Special Functions, and Toolkit.
'not-so-special' functions like log, exp sin is purely arbitrary: they are all math functions IMO. It is true that, in general, distribution functions use 'special functions' which in turn use 'not-so-special' functions, but IMO it would be confusing to try to divide them.
I'm not sure I agree with this; the distinction between 'not-so- special' functions and 'special' functions is arguably shady, but pretty well ensconced in the mathematics/numerical analysis literature. However, distributions are clearly a special case - while they can be viewed as functions, they have a very specific interpretation and behaviors that are not shared, in general, by other functions (CDF/PDF makes sense for them, for example)...
A review does indeed need input from various people with different areas of expertise, but I don't realy see how to avoid this. Hopefully they will just limit their comments to what they know about ;-)
My concern is that we're effectively building a Boost version of the GSL (GNU Scientific Library) from the bottom up rather than the top down. If we aren't very careful about certain design decisions made at the outset, there may come a point where it is discovered that some poor and difficult to fix choices were made. So there are two levels that need consideration : 1) the low-level implementation (accuracy/performance) of the various functions and 2) the overall architecture including error handling and higher-level implementation issues.
There are also some serious practical problems about a retrospective division - not least the documentation, where we have worked quite hard to provide cross linking, and now over 250 pages as a pdf! Not to mention the code, cross function use, and common error handling etc.
I understand the difficulties involved and have great respect for the effort you and John have put into this work. I certainly wouldn't expect that you completely revamp the documentation, especially given its extensiveness. In any case, I want to make it clear that I will not let my personal opinions on the library impact any decisions I make in the Review Manager capacity. At the same time, I hope it is acceptable to provide input and opinions as a normal Boost member... Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------

Matthias Schabel wrote:
A review does indeed need input from various people with different areas of expertise, but I don't realy see how to avoid this. Hopefully they will just limit their comments to what they know about ;-)
My concern is that we're effectively building a Boost version of the GSL (GNU Scientific Library) from the bottom up rather than the top down. If we aren't very careful about certain design decisions made at the outset, there may come a point where it is discovered that some poor and difficult to fix choices were made. So there are two levels that need consideration : 1) the low-level implementation (accuracy/performance) of the various functions and 2) the overall architecture including error handling and higher-level implementation issues.
There are also some serious practical problems about a retrospective division - not least the documentation, where we have worked quite hard to provide cross linking, and now over 250 pages as a pdf! Not to mention the code, cross function use, and common error handling etc.
I understand the difficulties involved and have great respect for the effort you and John have put into this work. I certainly wouldn't expect that you completely revamp the documentation, especially given its extensiveness. In any case, I want to make it clear that I will not let my personal opinions on the library impact any decisions I make in the Review Manager capacity. At the same time, I hope it is acceptable to provide input and opinions as a normal Boost member...
Absolutely. OK, so how best to proceed? My gut feeling is that the "tools" part is the least well developed, and as you rightly say there are sections that could be later developed into fuller libraries in their own right (I've already had feedback from people interested in doing just this incidentally). How about if we re-label the tools section as an internal implementation detail - which is basically what it is - it can then serve as a placeholder or "seeder-library" for future work. A bit like what fusion was to spirit, or the few current special functions we have are to quaternions/octonions. Which leaves the question of how best to review the two main thrusts of the library: the special functions and distributions. Would it work if we roughly divided the review time into two halves with each half notionally devoted to one section or the other? There's bound to be some overlap but it might help to focus our collective minds better :-) Of course if one half is accepted but not the other we've in a lot of bother 'cos they're too entwined to separate, but I'm not going to think about that right now! How does this sound? If we go this way then how much time should each section need do you think? Thanks, John.

OK, so how best to proceed?
First off, thanks for being willing to accommodate this request. I know it's painful to contemplate the prospect of rejiggering a library, especially one this extensive.
My gut feeling is that the "tools" part is the least well developed, and as you rightly say there are sections that could be later developed into fuller libraries in their own right (I've already had feedback from people interested in doing just this incidentally).
How about if we re-label the tools section as an internal implementation detail - which is basically what it is - it can then serve as a placeholder or "seeder-library" for future work. A bit like what fusion was to spirit, or the few current special functions we have are to quaternions/ octonions.
I agree - tools are probably of the least general interest as well, so fewer potential users will miss them anyway...
Which leaves the question of how best to review the two main thrusts of the library: the special functions and distributions. Would it work if we roughly divided the review time into two halves with each half notionally devoted to one section or the other? There's bound to be some overlap but it might help to focus our collective minds better :-)
I expect that the discussion will be somewhat intertwined, so it may run in parallel whether that's what we want or not. I will endeavor to encourage reviewers to be clear on which parts of the library they have focused and to submit separate reviews for each part, but I think the informal discussion can meander some.
Of course if one half is accepted but not the other we've in a lot of bother 'cos they're too entwined to separate, but I'm not going to think about that right now!
I'm not sure that it is necessary to separate them; if, for example, the distributions portion was accepted, in my mind that would just mean that the special functions would be considered an implementation detail so Boost wouldn't be making any promises, implicit or explicit, to support that interface in the future. Naturally, I hope both parts will get accepted...
How does this sound? If we go this way then how much time should each section need do you think?
I guess, in fairness, if we're going to split into two semi-separate reviews, each should be allocated a week. My inclination would be to run the review in parallel, but for two weeks instead of one... Review wizard comments? Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------

Well, the distinction between the theory of probability and analysis is equally arbitrary. However it is a real-life fact that they form two separate branches of mathematics: different people work in these areas, they evolved substantially independently, though with some cross pollination, they use different terminology as characteristic functions vs. Fourier transforms, etc., etc. There is a good reason for the separation: the users of probability / statistics and of analysis form two distinct sets with a tiny intersection. The same is likely to happen with readers / users of Statistical Distribution and Special Functions parts of your manual. For example, in my seventeen years of experience with economic modeling, we worked every day with normal, log-normal, Poisson, Pareto, and many other distributions, but I cannot remember a singe case when a single researcher used spherical harmonics or elliptic integrals. Our economists, probably, never hear these words, and most likely even mathematicians all but completely forgot them. I can imagine easily my former colleagues intimidated by special functions when browsing documentation, and putting aside the library completely. A typical user of special functions hardly will be intimidated by statistical distributions, but more often than not he will regard this part of manual as a mildly distracting noise. Of course, gamma is gamma and beta is beta, but this message is about manual, not about codes. And, by the way, Pareto is not mentioned in the manual. Sincerely, Yura On 2/8/07, Paul A Bristow <pbristow@hetp.u-net.com> wrote:
I don't really see three parts. Any distinction between distributions and so-called special functions, or indeed the 'not-so-special' functions like log, exp sin is purely arbitrary: they are all math functions IMO. It is true that, in general, distribution functions use 'special functions' which in turn use 'not-so-special' functions, but IMO it would be confusing to try to divide them.
A review does indeed need input from various people with different areas of expertise, but I don't realy see how to avoid this. Hopefully they will just limit their comments to what they know about ;-)
There are also some serious practical problems about a retrospective division - not least the documentation, where we have worked quite hard to provide cross linking, and now over 250 pages as a pdf! Not to mention the code, cross function use, and common error handling etc.
Paul

Yuriy Koblents-Mishke wrote:
For example, in my seventeen years of experience with economic modeling, we worked every day with normal, log-normal, Poisson, Pareto, and many other distributions, but I cannot remember a singe case when a single researcher used spherical harmonics or elliptic integrals. Our economists, probably, never hear these words, and most likely even mathematicians all but completely forgot them. I can imagine easily my former colleagues intimidated by special functions when browsing documentation, and putting aside the library completely. A typical user of special functions hardly will be intimidated by statistical distributions, but more often than not he will regard this part of manual as a mildly distracting noise.
Of course, gamma is gamma and beta is beta, but this message is about manual, not about codes.
Nod, understood. For many users you are completely correct of course, though for scientific programmers the distinction is less clear cut IMO. It might be possible to split the manual into two separate chapters (not sure about that though, might be a lot of work getting the links sorted out), but at the very least if the library is accepted we can include a direct link from the library index to the distribution-only TOC (see http://freespace.virgin.net/boost.regex/toolkit/html/math_toolkit/dist.html for example). There will always be a lot of cross-linking between the two - I don't believe it would be sensible to try and duplicate accuracy data in both places for example - the docs would quickly become impossible to maintain. There will also be a lot of curious folks who want to know how the distributions and the underlying special functions are implemented - either because they're just curious - or because they need to do a quality-audit on the code before recommending it to their workplace. On the other hand maybe I'm over-estimating how many folks fall into that category, just 'cos those are the kinds of people that get in touch.... hmmm, who knows.
And, by the way, Pareto is not mentioned in the manual.
That's one we haven't implemented yet, we've tried to implement a core set of distributions that were common to the majority of other statistics packages. We're slowly getting requests for more as various people find that their favorite isn't present. So basically, please be patient, but don't be shy in lobbying for for anything we've missed - and of course submissions are always welcome :-) John.

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 11 February 2007 10:14 To: boost@lists.boost.org Subject: Re: [boost] Review Managers Needed
And, by the way, Pareto is not mentioned in the manual.
On my TODO list ;-)) Paul PS Are there any others - apart from the non-centrals that we have also ducked for the time being. --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

Let's try to keep the subject line a little less generic and more relevant - it will make everyone's life easier if we ever need to retrospectively pull up relevant postings... Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------
participants (6)
-
AlisdairM
-
John Maddock
-
Matthias Schabel
-
Paul A Bristow
-
Tom Brinkman
-
Yuriy Koblents-Mishke