- Boost - lists.boost.org

Re: [boost] [Boost.Random]Comments/Questions
by Darren O'Driscoll 09 Jun '06

09 Jun '06

---------- Forwarded message ---------- > > > From: Neal Becker <ndbecker2(a)gmail.com> > > > To: boost(a)lists.boost.org > > > Date: Wed, 24 May 2006 21:56:03 -0400 > > > Subject: Re: [boost] [Boost.Random]Comments/Questions > > > Darren O'Driscoll wrote: > > > > > > > > > snip > > > > I hope noone's switched off during my long pre-amble, on to the meat > > > of my > > > > post: > > > > > > > > 1. In general I've noticed that deviates for specific distributions > > > are > > > > generated in one of two ways - a) according to a special algorithm, > > > which > > > > usually involves generating one or more uniforms and doing some > > > optimised > > > > transforms, or b) by generating a (0,1) uniform, and inverting the > > > > Cumulative distribution function. > > > > > > > > Method a), which seems to have been stuck to in Boost.Random is > > > generally > > > > the more efficient of the two methods, but there are a number of > > > cases > > > > where b) is necessary, specifically when using low-discrepancy > > > sequences > > > > such as SOBOL as a base for the generation, of when using the > > > stratified > > > > sampling technique in Monte Carlo. > > > > > > > > Would it be beyond the scope of this library to provide this kind of > > > > support? > > > > > > > > 2. Following on from the last point, it would be very useful if > > > SOBOL > > > > sequence generation was included in the library. > > > > > > > > 3. I've noticed that at least one of the generators (Normal) uses a > > > > sub-optimal generator. I've attached an alternative implementation > > > which I > > > > knocked together this evening which in my tests is about 30% faster. > > > Note > > > > this was heavily influenced by an algorithm described in "Numerical > > > > Recipies in C". > > > > > > > > 4. The list of distributions where deviate generators are provided > > > is > > > > quite short. As mentioned before, I'm quite interested in this area, > > > and > > > > would be happy to help with algorithms for some other distributions, > > > > though sadly I would estimate that my C++ skills are still quite a > > > lot > > > > below the median here. > > > > > > > > > > > Neal Becker wrote: > > > > Have you looked at unuran? Looks interesting: > > > http://statistik.wu-wien.ac.at/unuran/ > > > > > Cheers for that Neal, It does look like an interesting site. I've had a > look around and found some useful stuff there. However my post was more aimed at suggestions for possible improvements to the Boost.Random library. I notice I didn't really get a responce on this. Is that because it was all unteresting stuff / stuff which has been gone over in detail previously, or is that library now closed to changes / unsupported?

2 1

Re: [boost] [review] pqs
by Martin Bonner 09 Jun '06

09 Jun '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: 09 June 2006 10:33 To: boost(a)lists.boost.org Subject: Re: [boost] [review] pqs > "Martin Bonner" wrote > > [adding PQS quantity units info cut] > >> That is not good. Not good at all. > > FWIW David Walthall suggested another scheme by which the struct used > as a > container for the units was derived from another struct in another > header in a > user directory intended for the user to be able to add their own > units. Would > that be an improvement? > It would. Even better would be a scheme whereby the user /could/ define a struct of their own, but if they didn't, the library provided one. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

Libraries supporting compilers
by Edward Diener 09 Jun '06

09 Jun '06

From this end users point of view, Boost needs a standard and easy to find way of specifying for any future release which compilers are supported by each library. The current way of determining this, by having to interpret regression tests, when and if they are run by a different people against particular libraries using particular compilers, seems very poor as a method of creating such information. Furthermore while some libraries may mention, to some extent in their documentation, what compilers they support in general, many say nothing in this regard, and often such information changes between releases. Please understand I am speaking from the end-users point of view. An end-user using a particular compiler release wants to be able to find out, fairly quickly, whether that release in a particular Boost release which the end-user is using is supported by a particular library. I urge Boost to set up a means by which the end-users expectations of easily finding this information will be met without the hit-and-miss examination of multiple regression tests or the reliance of such information somewhere in the documentation for a particular library.

2 3

Re: [boost] [Review][PQS] Review deadline
by Reece Dunn 09 Jun '06

09 Jun '06

Gerhard Wesp wrote: > On Wed, Jun 07, 2006 at 03:16:47PM +0100, Paul Giaccone wrote: > > Reece Dunn wrote: > > > However, if you are working in *pounds*, and you want the *result* > > > in pounds (e.g. how many pounds of flour do I need to order?) then > > > you are going to end up with the result in kg!! > > mass flour = x * pounds; > // Do some computation > std::cout << "You need " << flour / pounds << " pounds of flour\n"; > > Yes, if there is no other computation involved, we have an extra > division and multiplication here. But as I wrote, I would like to > encourage the users of a physical quantities library to actually use SI > units. This could lead to errors (re: Mars lander) if people forget that they are working in one unit (SI meters) when they should be working in another (e.g. miles). For example, it would be easy to write: std::cout << "You need " << flour << " pounds of flour\n"; and not realise that flour is not in pounds! > > So including imperial (or even just non-metric) units is, I would say, > > quite important, not least because these are the official standard in > > I agree. But let them be themselves in SI, e.g. > > const length foot = .3048 ; > const mass pound = .4535924; Ok, but if you are working in atomic/theoretical physics, you have: // pseodo C++ for plank's constant (h) const physics::units::J plank_J = 6.62607554e-34 ± 3.97565e-40; const physics::unit::eV plank_eV = 4.135669212e-15 ± 1.2407e-21; so, which value is correct? The one in Joules (sp?) or the one in electron volts? It all depends on which units you are working with. Converting between the J and eV values for the sole purpose of using SI units, where you *need* eV would introduce (1) rounding errors due to the inaccuracies of floating point math and (2) the errors introduced when you take the intervals into account. So having 2h and converting from eV -> J -> eV will not give you 2h! As well as this, if you are working on the level of plank length: const si::units::meters plank_length = 1.616051e-35 ± 1.03427e-39; (and yes, plank length is in meters!) it would be easier, faster, more acurate ... to do the calculations with plank_length as the base unit so you do not use interval arithmetic! Is it not easier to say: const physics::units::l_p plank( 2 ); // 2 * plank length std::cout << plank << std::endl; // output: 2.l_p rather than: const si::units::meters plank_length = 1.616051e-35 ± 1.03427e-39; const si::units::meters plank = 2 * plank_length; std::cout << plank << std::endl; // 3.2... +/- ... std::cout << ( plank / plank_length ) << std::endl; // 2.0 +/- ... Q: Would the last one give 2.0 +/- 2.0?! I don't know that much about interval arithmetic. Another thought: if you are loading/saving data to/from a database that keeps say the fundamental particle masses as eV, will these not degrade over time due to rounding errors when converting to/from SI units? What happens as the value of the eV changes as physical constants do?! What happens with the interval value that you need to convert back to a float? Do you take the average, where you *will* have greater value precision degredation!! Using eV as a base unit for these calculations will ease most of these and lessen others. The disadvantage to your idea of doing value / unit_desired when you need to output it is that: (1) it complicates matters -- doing that should only be required when conversions are needed (making the places where those conversions are explicit); (2) people are lazy and can get distracted, so they will not always use the above where needed; (3) it will have greater runtime penalties, especially if used in a loop; (4) can have inacuracies when dealing with large or small physical constant-based values; (5) is bad if those constants are changing! (6) can penalize you if intervals come into play. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

4 4

Re: [boost] [serialization] MSVC8 runtime check error
by Reece Dunn 09 Jun '06

09 Jun '06

John Reid wrote: > > I'm getting a runtime check error from MSVC8 in the following code > checked out from cvs_head: > > serialization/collections_load_imp.hpp > line 116 > > ... > > template<class Archive, class Container, class InputFunction, class R> > inline void load_collection(Archive & ar, Container &s) > { > s.clear(); > // retrieve number of elements > unsigned int count; > unsigned int item_version; > ar >> BOOST_SERIALIZATION_NVP(count); > if(3 < ar.get_library_version()){ > ar >> BOOST_SERIALIZATION_NVP(item_version); > } > R rx; > rx(s, count); > InputFunction ifunc; > while(count-- > 0){ > ifunc(ar, s, item_version); > } > } > > ... > > The debugger breaks every time ifunc() is called which is frustrating to > say the least. > > If load_collection() is wrapped with > > #pragma runtime_checks( "u", off ) > ... > #pragma runtime_checks( "u", restore ) > > it doesn't help - perhaps I've rebuilt it incorrectly, perhaps the > pragma needs to be around where the code is instantiated. I managed to > get around the problem by assigning 0 to item_version. What happens when you break into the debugger. VC8 supports range checked iterators, dereferencing an invalid iterator, etc. What is the exception/assert message being generated? Can you use the VC8 debugger and see what values each of the variables are at the point where the assert/exception was generated? Is there any information you can gather by looking up the callstack? > Has anyone specifically chosen to turn runtime checks on for debug > builds with MSVC8 or is this just the default? VC8 has additional error checking when compiling for debug. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

mutex::scoped_lock question
by jmzorko＠mac.com 09 Jun '06

09 Jun '06

Hello, all ... I've a very simple question, but i've not found my answer in the Boost source. How do I manually acquire the lock on a boost::mutex::scoped_lock() e.g. without using the constructor? The reason is that I need to make my instance of the lock on the heap, so I want to use the default ctor and acquire (and release) the lock myself. I'm wrapping the scoped_lock in another higher-level class (called Lock, funnily enough) and I want to insulate the code above me from specifics. I'm going to continue looking through the source, but any help would be appreciated! Regards, John Falling You - exploring the beauty of voice and sound http://www.fallingyou.com

2 1

Re: [boost] [review] pqs
by Reece Dunn 09 Jun '06

09 Jun '06

Carlo Wood wrote: > On Thu, Jun 08, 2006 at 05:36:40PM -0500, David Greene wrote: > > the library. Andy presented this example to justify kg's 0 power: > > > > mass::kg m(1); // 1 kg == 1000 g > > acceleration::m_div_s2 a(1); // 1 meter per second squared > > force::N f = m * a; > > > > The value of f should be 1000 Newtons right? > > > > Of course, the value is 1 Newton. But this has nothing at all to > > do with kg having a prefix power of 0 or 3. The calculation can > > The point is, > > 1 N = 1 kg * 1 m / 1 s / 1 s > > The 1 comes from 10^0, hence 0 is needed. > > 10^0 N = 10^0 kg * 10^0 m / 10^0 s / 10^0 s > > 0 = 0 + 0 - 0 - 0 > > The calculation of the left-hand 0 is done with generic > templates using '+' to add up exponents. How is it logical > to make an exception here for kg? > > If you'd force 'kg' to be 'g' internally, then you will > have to apply the same trick to N that is now applied to kg, > with the exception that then BOTH are internally not in S.I. > units (mN and g, instead of N and kg). That is, you'd end up > with: > > 3 = 3 + 0 - 0 - 0 > > and thus mN. But you still want to print N. > I don't think it will get any better by using a prefix power of 3 for kg. If you know that kg ==> 10^3g and that N = kg.m.s-2 then you have the information right there! Given that N is expressed in terms of kg, the library will know that the powers of each unit are: N = [ 3, 0, 0, 0 ] and that mN is: N = [ 0, -3, -3, -3 ] You don't need to treat kg as a special case here where the math is concerned, as per my unit system toy example. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

Re: [boost] [review] pqs
by Reece Dunn 09 Jun '06

09 Jun '06

Carlo Wood wrote: > On Thu, Jun 08, 2006 at 08:59:36PM +0100, Reece Dunn wrote: > > /** @brief mass */ > > > > typedef base_unit< si_tag, mass, prefix::kilo > kilogram; > > > > typedef scaled_unit< kilogram, prefix::kilo > kg; > > typedef scaled_unit< kilogram, prefix::base > g; > > typedef scaled_unit< kilogram, prefix::milli > mg; > > Surely you mean, > > typedef base_unit< si_tag, mass, prefix::base > kilogram; > > typedef scaled_unit< kilogram, prefix::base > kg; > typedef scaled_unit< kilogram, prefix::milli > g; No. The reason is that kg is *kilo*gram. So: kg = 1x10^3 g g = 1x10^0 g Also note that Newtons is expressed in terms of kilograms as well, so the type system/internal logic will know that: mass = 1kg speed = 1s distance = 1m results in: force = 1N This was a conscious design on my part: the prefixes should *always* follow the SI unit terminology for SI units. That is why prefix::kilo is specified in the base unit -- so the program knows it needs to convert the unit if using grams. If g were to have prefix::milli, it would have a symbol of mg which makes no rational sense. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

Re: [boost] [Review][PQS] Review deadline
by Reece Dunn 09 Jun '06

09 Jun '06

Gerhard Wesp wrote: > Still, I'd like to make one suggestion. > > I think that handling of dimensional quantities and conversion factors > are orthogonal concepts and should be separated. > > I suggest that for maximum transparency the library should *exclusively* > handle quantities expressed in SI units. This would be a BAD thing! > I'm aware that this "mildly forces" developers to adopt SI units. I > consider this a Good Thing. Err... see below. > Conversion factors between non-SI units and SI units should be constant > dimensional quantities, e.g. (assuming constructors from double): > > const length foot = .3048 ; // Meter > const power european_horse_power = 735.4987 ; // Watt > const mass pound = 0.4535924; // Kilogram > // ... > > This way, one could e.g. construct dimensional quantities like this: > const power deux_chevaux = 2 * european_horse_power; However, if you are working in *pounds*, and you want the *result* in pounds (e.g. how many pounds of flour do I need to order?) then you are going to end up with the result in kg!! Also, in Britain we are still using miles per hour (despite having converted to metric a long time ago!). Therefore, it would be silly to answer the question "how fast do I need to travel to get to work in 10 minutes?" And it is silly to use a calculation to determine what horse power car you want to buy in Europe when the calculation says you need a car that supplies 735 watts of power! ("Excuse me, do you have any cars that have a power output of 735 watts?" -- at which point the sales person will look at you blankly!) It's not just silly things like that. If you are computing with really large numbers (e.g. light years) or really small numbers (e.g. on the Planck's constant level), do you really want them to be expressed in - and calculated using - SI units, especially when this would lead to overflow errors. Can you answer this question using *only* SI units on current floating point hardware: how long will it take to travel from here to the Andromeda galaxy travelling at 0.2 light years? And then you are forgetting physicists that need to measure electron volts. And the list goes on. > Non-SI quantities would have to stay "out of the system" in normal > floating point variables: > > length altitude; > double altitude_ft = altitude / foot; > > Ignoring dimensionality, this is the notation Mathematica chooses. > > I have done some engineering simulations, written a flight simulation > framework and used one that uses US units (D6; see www.bihrle.com) The > D6 source code is riddled with magic constants. I've collected some > conversion constants in units.h of cpp-lib, see > http://gwesp.tx0.org/software/. If you are only working in electron volts, or light years, there is no need for "magic" constants. These will only come into play when you need to convert between units. Also, the examples you gave above are plagued with magic constants because you cannot express 1ft as 1.0! BTW: this is not a rant against SI units. It is a rant about *only* supporting SI units! - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

5 5

[review] pqs
by David A. Greene 09 Jun '06

09 Jun '06

I've been waiting in anticipation of pqs for some time. I've had to work with dimensioned values several times and could really have used the compile-time checking pqs offers. It is also, IMHO, one of the best practical examples of template metaprogramming. - Please always explicitly state in your review, whether you think the library should be accepted into Boost. I'm disappointed that for now, I would have to reject the library from Boost. I definitely want to see this library make it in but there is one big drawback that's a showstopper for me. Everything is based on powers of 10. More on this below. There are also some improvements I'd like to see that I don't consider showstoppers. I'll comment on those below as well. - What is your evaluation of the design? The everyday user interface is fine. The myriad of concepts and classes to model them can be overwhelming, however. This might be addressed with better documentation. I don't understand the t1_quantity name. It doesn't convey any useful information to me. It needs a better name. Unit naming: pqs::length::m - Can we also have pqs::length::meter & metre? (Can always typedef this, I suppose) pqs::velocity::m_div_s - m_per_s? I know this is discussed in the documentation but again, typedefs might be nice to have Output: 1 kg.m+2.s-2 - What does this mean? It wasn't clear to me when I first saw it. Why not use ^ or ** for power? Why even have the concept of a prefix_offset? It seems unnecessarily confusing to me. Why does mass default to kg rather than g? If these special cases are really needed, then the documentation needs to explain why. Otherwise, I would prefer that everything work similarly to reduce complexity. The big problem with the design is the assumption that every quantity prefix is based on a power of 10. That's fine for SI units but my hope is that pqs will go beyond just SI. It already does with the incoherent_units so there is some precedent here. Even before pqs was put up for formal review, I had planned to make use of it in some computer simulator work that I'm doing. The ability to create units like Megabytes and Mibibytes would help tremendously. Unfortunately, I could not figure out how to create a unit that uses prefixes that are powers of 2. It might be ok to "fake" it if the calculations always stayed within one system (Mibibytes, Kibibytes, etc.) but as soon as one wants to convert Mibibytes to Megabytes it falls apart. If this can already be done, I'd be overjoyed to be corrected. But I could not puzzle it out from the documentation or a cursory look through the implementation. This is a big gap for me and prevents the use of pqs in most of the day-to-day work that I do. There's also the question of what base_dimension these would fit under. "Amount of substance?" It would be nice to be able to extend the types of base_dimension but I recognize that this could be very difficult given the design of pqs::meta::dimension and classes that depend on it. - What is your evaluation of the implementation? I did not thoroughly review the implementation, just glanced at it to answer some questions. Obviously it does not seem to fulfill my requirements as I stated above. I suspect it will be a bit of work to introduce the new flexibility. - What is your evaluation of the documentation? This needs a lot of work. It seems to assume a deep understanding of SI standards and terminology (beyond the unit names and what they mean) and introduces lots of terms itself (abstract_quantity, named_quantity, concrete_quantity, etc.). The presentation is overwhelming. Some specific suggestions: In the introduction section, we have the following statements about rationale: Increases programmer satisfaction What does this mean, exactly? It's very vague and subjective. enhances productivity How, apart from other rationales given? My suggestion would be to organize the rationale like this: * Increases programmer satisfaction and enhances productivity. * Strong type checking enforces dimensional integrity, catching calculation errors at compile time. * Automated unit conversion reduces drudgery. * Self documenting, helps code clarity. This is done better in the Rationale section itself. Make the presentation in these two sections similar in structure. The ERD was confusing to me. Can this be drawn in UML or a close-to-some-standard way? Reading through the documentation, one is confronted with the ginormous definitions page almost right away. I'd prefer to see some simple examples of use first. The "Getting started" page is a good start, but would be improved by removing references to the more esoteric terms. Those can come later. The definitions page itself needs many more code examples (for example, for named_quantity). It took me a long time to begin to understand what these terms really mean and I'm still not all the way there yet. I found the colored links to the terms all over the documentation to be distracting. It really interrupted the flow of the text. It would be better to make these links that look like ordinary text but are highlighted/underlined when the cursor moves over them. The links need to be there but they should be less intrusive. Typos (fixes in brackets): [t1_quantity features] The t1_quantity has many similar features to an [a] built-in type... Where used the type returned by typeof will not[neither] be a reference nor have cv-qualifiers. [abstract_quantity_id] The abstract_quantity_id has two roles, the first of which is to distinguish between different but dimensionally_equivalent[ ] abstract_quantities. [Unary operations example] [c]ondition_true [Addition and subtraction] If one type has a coherent_unit and the other has an incoherent_unit the operand with the incoherent_unit will first be converted to a t1_quantity in the nearest coherent_unit( simply found by setting the incoherent_unit[']s[ ]unit_multiplier to 1) [unit_output_symbol] A text symbol representing the unit[ ]of a concrete_quantity in stream output. [Lots of these missing spaces, underscores and first letters of example code through the documentation. Too many to enumerate.] [Stream output overview] The output of units for stream output functions for t1_quantities resolves to 3[three] output formats - What is your evaluation of the potential usefulness of the library? Very. IMHO strong typing is essential when designing large systems. - Did you try to use the library? With what compiler? Did you have any problems? I was going to do some experiments to create my own quantities as described above, but I could not figure out how to do it, so I did not do any testing. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth reading of the documentation with a clear idea of how I wanted to extend the framework. Unfortunately, I discovered that I could not do what I'd hoped to accomplish. - Are you knowledgeable about the problem domain? In the same way most scientists and engineers are. I'm certainly no authority on the formal SI standards. I do have a large amount of experience in computer simulation and have run into the need for this kind of package for "computer units" over and over. It would be nice to have a package that went beyond the SI and its rigid assumptions.

17 44