June 2004 - Boost - lists.preview.boost.org

[iterator + lambda] transform_iterator and lambda expression
by Vladimir Prus 04 Jun '04

04 Jun '04

I'm again trying to use FP in C++, and having problems. What I wanted to do was: for_each(predecesor(v, g), /* BLL expression */ ); where predecessor(..) returns a pair of 'transform_iterator' instances. The simplest example which illustrates the problem is: struct functor { typedef int result_type; int operator()(int i) const { return i+1; }; }; transform_iterator<functor, vector<int>::iterator> it(v.begin()); (cout << _1)(*it); This does not compile, because operator* of transform_iterator return rvalue which can't be bound to non-const reference that operator() of the lambda expression accepts. Of all workarounds suggsted on BLL docs, only break_const is applicable to my case (I want to pass non-const references to the lambda, so const_parameters won't do), and break_const is scary. It looks like a serious problem with using FP, so I wonder what can be done. Maybe, transform_iterator should have yet another template parameter telling if it should store a value internally, and return reference (i.e. lvalue) in that case? It need not be enabled by default, but functions like my 'predecessor' above would make use of that extra template parameter. - Volodya

4 8

Re:[boost] A question on serialization library
by Robert Ramey 04 Jun '04

04 Jun '04

Virendra Verma wrote: > If a class has a pointer to an object, how does class know that the > pointer was created by library or the class itself before serialization? It doesn't. Why would it need to? Robert Ramey

2 1

transform_iterator( Iterator const& x ) ???
by David Abrahams 04 Jun '04

04 Jun '04

I'm not sure why I never saw this on the list, but since I saw the moderation request and I figure you deserve a reply... boost-owner(a)lists.boost.org writes: > From: "Sascha" <vudu(a)gmx.net> > Subject: boost::transform_iterator( Iterator const& x ) ??? > To: <boost(a)lists.boost.org> > Date: Thu, 3 Jun 2004 00:22:18 +0200 > > hi > > a simple question about the construction of > boost::transform_iterator. > > currently there are two ctors implemented: > > transform_iterator(); > transform_iterator(Iterator const& x, UnaryFunction f); > > why does boost::transform_iterator(Iterator const& x) not exist leaving > the function object default constructed? Are you looking at the source code or the documentation? Oh, I see you're doing as you should and looking at the documentation! Well it turns out that the source code actually contains this constructor: explicit transform_iterator(Iterator const& x) : super_t(x) { // don't provide this constructor if UnaryFunction is a // function pointer type, since it will be 0. Too dangerous. BOOST_STATIC_ASSERT(is_class<UnaryFunction>::value); } > can I add it without getting in trouble? No, but we can fix the documentation ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[Boost-bugs] [ boost-Bugs-966496 ] [BGL] Asymmetry between read_graphviz() and write_graphviz()
by SourceForge.net 04 Jun '04

04 Jun '04

Bugs item #966496, was opened at 2004-06-04 06:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=966496&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: [BGL] Asymmetry between read_graphviz() and write_graphviz() Initial Comment: During some experiments with the BGL-GraphViz interface, I observed a significant asymmetry between a given DOT graph input with boost::read_graphviz() and output with boost::write_graphviz() (without changing any attributes). Given the input DOT file <metro.dot> (which is, of course, much longer with the full set of information), the elementary BGL program <metro.cxx> transforms this into the output DOT file <metro_boost.dot> (the three files are attached to this submission). It seems that somewhere on the way, the graph and node (and edge) attributes get clobbered. Note that even the graph name "metro" gets replaced by the name of the (last) subgraph "ligne_1", and /all/ node attributes get mixed up. This seems to be somewhat similar to the recent edge-related problem posted by Hideaki Hiraki to the boost-users list. I have not (yet) tried to mess with the graphviz parser code, so I am asking here for help. Thanks. Greetings, Andreas <andreas dot scherer at rb-its dot de> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=966496&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

BOOST_NO_STDC_NAMESPACE and LIBCOMO
by Robert Ramey 04 Jun '04

04 Jun '04

Commeau I'm building with como-win32 with the libcomo library. It seems that BOOST_NO_STDC_NAMESPACE is set to true with this combination and that it should be set to false for this combination. Robert Ramey

3 2

RE: [boost] Re: Re: Re: Boost Mathematicians
by Hurd, Matthew 04 Jun '04

04 Jun '04

> Behalf Of Thorsten Ottosen > > > "Hurd, Matthew" <hurdm(a)sig.com> wrote in message <snip> > See Type-Based Alias Analysis: > > http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm?temp=fXniOPb1aS Thanks for the link. > > I my suggestion for Design by Contract I mentioned that aliasing (or lack of > it) > could be expressed by a function precondition: > > void foo( T* l, T* r, size_t sz ) > precondition() { > std::less<T*>( l + sz, r ) || std::less<T*>( r + sz, l ); > }; That's ok for simple contiguous spaces but it becomes intractable with complex object collections, but then perhaps the efficiency probably ain't so important as you've lost the locality anyway. > | You still need to wrap as you can't hope, nor should you try, to offer > | all algorithms from all languages. > > probably not. But simply wrapping stuff is not always an option. For eaxample, > in the > statistics lib I'm working on, I need to invert matrices. If I write wrappers, > I will > probably only be ably to support float,double,complex leaving out higher > precsion > datatypes. Yup. Generic interface first. Implementation with ublas where possible. Other generic implementations. Specialize for performance I guess. I haven't looked at uBLAs for a while but there was an interface to ATLAS for performance and also a partial wrapper for LAPACK. Not sure if the use of ATLAS or otherwise is or can be made to be automatic at compile time, but this would give us most of what we need. Generic implementations with pluggable special high performance specializations wherever possible. Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RE: [boost] Proposed Boost Library for Data Series Analysis
by Hurd, Matthew 04 Jun '04

04 Jun '04

> Behalf Of Tom Brinkman > Sounds very powerful. Is there any additional web > information to help me incorporate > these ideas. Not that I know of, but it isn't overly original in approach. Most interactive tools, such as a spreadsheet, will have something like a DAG structure at their core to represent a model-view type dependency thingo. Wish I had more time to play with this stuff... Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RE: [boost] [assignment library post review]
by Rozental, Gennadiy 04 Jun '04

04 Jun '04

> The post review version can be downloaded from > http://tinyurl.com/38c7d Could you please clean archive from garbage in test directory. Gennadiy.

2 1

RE: [boost] [assignment library post review]
by Max Khesin 04 Jun '04

04 Jun '04

Thorsten, link's dead. > -----Original Message----- > From: Thorsten Ottosen [mailto:nesotto@cs.auc.dk] > Sent: Thursday, June 03, 2004 1:08 PM > To: boost(a)lists.boost.org > Subject: [boost] [assignment library post review] > > > Dear All, > > The post review version can be downloaded from > > http://tinyurl.com/38c7d This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

Proposed Boost Library for Data Series Analysis
by Tom Brinkman 04 Jun '04

04 Jun '04

I've created a library for data series calculation and analysis. I've received permission to open-source the library and I would like to submit it for review to the boost if there is sufficient interest. Simple Example 1: Calculate the 10-day simple-moving-average of the 15 exponential-moving-average. (Demonstrates: boost::algorithm::compose). std::vector<double> v1; v1 += 3,4,4,6,7,8,4,7,8,3,2,3,2,5; typedef boost::algorithm::compose<double, boost::function<double (double)>, boost::function<double (double)> > COMPOSE; std::vector<double> v; std::transform(v1.begin(), v1.end(), std::back_inserter(v), COMPOSE(moving_average(15), exponential_moving_average(10))); Simple Example 2 (contrived): * Add 100 to the results from above. * then divide by 100, * then subtract by 100, * then multiply by 100. std::vector<double> v1; v1 += 3,4,4,6,7,8,4,7,8,3,2,3,2,5; typedef boost::algorithm::compose<double, boost::function<double (double)>, boost::function<double (double), boost::function<double (double), boost::function<double (double)> > COMPOSE2; std::vector<double> v2; std::transform(v.begin(), v.end(), std::back_inserter(v2), COMPOSE2(_1 += 100, _1 /= 100, _1 -= 100, _1 *= 100)); Here is a paritial list of functors currently provided by the library. Many additional functors have been written but are fairly specific to our problem domain. moving_average triangle_moving_average rate_of_change momentum vertical_horizontal_filter volatility weighted_moving_average exponential_moving_average variable_moving_average accumulate_n relative_strengh_index cumulative_sum max_numeric_limit variance standard_deviation correlation z_score Please tell me if there is any interest in this library. I will boostify it and submit it for review if there is sufficient interest. Regards, Tom Brinkman __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

5 4

boost/format/format_class.hpp workaround for aC++
by DY, JERRY U (SBCSI) 03 Jun '04

03 Jun '04

Would the experts let me know if there's a better way of accomplishing the same effect below? I have modified boost/format/format_class.hpp and added a line 93 (See attached) && !BOOST_WORKAROUND( __HP_aCC, != 0) <<format_class.hpp>> Thanks! -Jerry

1 0

RE: [boost] [assignment library post review]
by Rozental, Gennadiy 03 Jun '04

03 Jun '04

> The post review version can be downloaded from > > http://tinyurl.com/38c7d Does not work Gennadiy

1 0

RE: [boost] static sized strings
by Reece Dunn 03 Jun '04

03 Jun '04

Martin wrote: >I have tested the sandbox version of the static sized strings. It works >fine >but there are a few inconveniences that I want to point out. I have been writing a series of test cases (boost-sandbox/libs/test) and fixing several bugs. Have you tried these? Also, what compiler(s) are you using? >1. The abstract base class. >--------------------------- >Having an ABC to handle fixed strings of various lengths is a good idea but >it >is not very practical. I understand that the main purpose is to allow fixed >strings to be passed to functions without using templates. > >int countwords(const boost::char_string & str); > >unfortunatly the ABC makes it difficult to pass anything but fixed strings. >If >you want to pass a string literal, a character array or a std::string you >must >create a temporary fixed_string<>. > >countwords(boost::fixed_string<20>("The quick brown fox")); This is an unfortunate side-affect of using the ABC technique that affects John's implementation as well. Your proposed solution looks interesting, but I don't know how practical it will be for the string manipulation operations (w.r.t. buffer safety). Rob proposed a "make_string" function, which would simplify this a little. >2. Substrings >------------- >One of the applications I can see for fixed_string is when you want to >avoid >dynamic allocation but still want to use the std::string interface and >algorithms. In that perspective it seems strange that substr returns a >std::string instead of a fixed_string. This is related to the above problem. You cannot create an instance of boost::char_string, etc. and as such cannot implement substr in the usual way (this is the proplem I was having with operator+). The solution would be to defione an alternate substr function in fixed_string, but this would not solve the problem for boost::char_string, etc. The alternative would be to use a ranged string (pointer to the fixed_string buffer and length), but the problem with this is null-termination. I do not see an easy way around this without removing the ABC design, since it is not possible to do fixed_string< length() > or something similar. >3. resize >--------- >Still missing a method to update the length to reflect the current string >length. I think a resize without arguments would be a good solution. > >boost::fixed_string str<10> >strtime(str.buffer()); >str.resize(); I'll add this soon. I have mainly been focusing on getting documentation and the test cases up. >4. operator[] >------------------------- >I don't have the standard basic_string interface available but I am pretty >sure that operator[] doesn't throw an exception if the argument is outside >max_size(). This is a deviation from the standard. If i > capacity() then the index will be out of the string buffer range and a buffer overrun can occur. This generates an exception to prevent the overrun. I should add this to the docs. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re: [boost] Re: static sized strings
by Reece Dunn 03 Jun '04

03 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Rob Stewart wrote: > > >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > John Nagle wrote: > > [snip] > > I think you misunderstand what I am trying to say. See my comments >below. > >Actually, I think you misunderstood my points. ok. > > [1] You need to specify the size of the buffer. You cannot declare an >object > > of type fixed_string_base (as it is abstract), you can only have >references > > and pointers to it so you can operate on variable-capacity strings. > >Ah, but you missed that I was declaring a fixed_string_base, >where string capacity is not known. I was relying on >make_fixed_string() to deduce the array length and create an >appropriate fixed_string for it. I didn't miss it, just misunderstood what you intended. > > [2] This is the point that we are discussing. Should this line be: > > > > fixed_string< LENGTH > t; > > > > as will work with the current sandbox implementation (my suggestion #2), >or > > should it be: > > > > fixed_string< LENGTH + 1 > t; > >And that's exactly my point. It should be the former as shown by >my equivalencies. > > > Different programmers favour the different semantics, so I ask: why not > > parameterise it, providing a default behaviour. > >I'm not so sure they do and I'm not sure you need to allow for >it. If you do, I suspect you'll encourage off-by-one mistakes. >Granted, those mistakes won't result in overruns, but they will >be annoying. Furthermore that will result in different >fixed_string types; will you provide for conversions among them? >(That is, for example, from a fixed_string that adds one to the >capacity to one that doesn't?) It is the former in the implementation I have, but if you have char data[ 100 ]; // manipulate and use the data buffer in this example, the buffer is 100 characters, but only 99 are writable, with the 100th being a null character (assuming this is a C-style string). Using the current implementation, this would lead to fixed_string< 100 > data; having an extra character. This would transfer to the other model. > > >(I know there is no make_fixed_string() -- yet -- but such a > > >facility would be appropriate.) > > > > Er... the fixed_string constructors! When you declare the object, you >should > > know the size of the buffer you are using, e.g.: > > > > fixed_string< 100 > data; > >The problem is that you don't know the length of the string. >That is, with this code: > > char s[] = "1234"; > >s is a fixed size array of char with five elements. The >programmer didn't have to write: > > char s[5] = "1234"; > >Instead, the compiler figured out the length. > >That's what I'm trying to provide an equivalence for: > > fixed_string_base & s = make_fixed_string("1234"); > >With that approach, the client doesn't need to precompute the >length of the literal and can rely on the compiler (and template >magic) to deduce it and use it to create a fixed_string<5>. > >I've shown returning by value (with the temporary bound to the >reference s), but it could return a smart pointer just as well. Your original example didn't have fixed_string_base as a reference. It should be easy to implement a make_fixed_string function. > > >I think this clearer reveals that fixed_string's size parameter > ^^^^^^^ >That should have been "clearly." > > > >should specify the number of characters. Remember, one can use > > >boost::array to manage a fixed size, non-string buffer. If > > >buffer overrun protection is insufficient in boost::array, that > > >should be fixed (or a new class should be added to Boost). Thus, > > >fixed_string can ignore that usage. I am not disputing this. The question is, is the null terminator counted as a character. For the example you show, it is, but for buffers (see the example above) it isn't. I haven't got a conversion between the two models because I am only implementing the one model at the moment, but conversion would be automatic because the functions that take strings as arguments take fixed_string_base & arguments, so they should be usable regardless, consider: boost::fixed_string< 20 > str1( "This is a long string!" ); boost::fixed_string< 10 > str2; str2.assign( str1 ); This will work (cutting the string short in str2) even though the strings are of different capacities. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

3 5

A question on serialization library
by Virendra Verma 03 Jun '04

03 Jun '04

If a class has a pointer to an object, how does class know that the pointer was created by library or the class itself before serialization?

1 0

Re:[boost] NEW lib: Named Variable - safe & convenient output of expressions together with their name
by Robert Ramey 03 Jun '04

03 Jun '04

M G wrote: > the "Named Variable Lib" is a lightweight macro & > template library which allows you to write: This looks equivalent to the Name-Value Pair implemented as part of the serialization library already accepted into boost. It not documented separately as other candidates for separate boost components are - maybe it should have been. I don't see this as a problem. The one in the serialization library only has the functionality required to support serialization and I have often expressed the desire that appropriate pieces be moved out of the serialization library and into boost generally - along with the responsibilities of maintenance, documentation, testing, etc. So please look at the serialization library one and see if you can reconcile all of this. Robert Ramey

1 0

Bug, signals, use of default Combiner
by Ville Varis 03 Jun '04

03 Jun '04

Hi, The next piece of code fails with assertion when calling signals without any connections attached to it. <code> #include <boost/signal.hpp> void test_signaling() { ::boost::signal0<int> sig; /* Next call asserts in boost/last_value.hpp line 29 assert(first != last); */ sig(); } </code> This is due to usage of default Combiner boost::last_value<R>. The problem occures when using non-void return values in signals. I use boost version 1.30.0 but I didn't noticed any changes for this in version 1.31.0. Quick workaround is to use other Combiner as default, where this problem is removed. for example <code> ... last_value .... T operator()(InputIterator first, InputIterator last) const { if (first == last) return T(); ... </code> best regards, Ville Varis ville.varis(a)bonum.biz mail.bonum.biz

2 1

[Boost-bugs] [ boost-Support Requests-965747 ] problem with debug builds on Solaris
by SourceForge.net 03 Jun '04

03 Jun '04

Support Requests item #965747, was opened at 2004-06-03 06:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=965747&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem with debug builds on Solaris Initial Comment: When I build an application with -g option (Solaris, Forte compiler), I get undefined symbol errors when it tries to link with Boost. I've tried rebuilding boost with -g, but get undefined sybols at link time from within boost - failing to find symbols in other parts of boost. Without -g option everything is fine Boost version 1.28.0 dlowry_uk(a)yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=965747&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

NEW lib: Named Variable - safe & convenient output of expressions together with their name
by M G 03 Jun '04

03 Jun '04

Greetings BOOST developers, the "Named Variable Lib" is a lightweight macro & template library which allows you to write: os << NV(character) << NV(std_string); os << NV(array_char_text) << NV(array_char_null); os << NV(p_float)<< NVP(p_float); p_float = 0; os << NVP(p_float); os << NV(the_answer_over_pi); os << NVB(((p_device==0) || f > 1.2) && name=="rsd0a"); to get e.g. character='A' std_string="test" array_char_text[]="text" array_char_null=NULL p_float=0012FD9C *p_float=1.234 p_float=NULL the_answer_over_pi=13.36901522 (((p_device_name==0) || f > 1.2) && name=="rsd0a")=1 written to the std::ostream os (" << std::endl" in C++ source omitted for better readability). Its main goal is to standardize the 5 macros NV,NVP,NVB,NVM,NVMP to let one output variable/expression together with their names conveniently (just one very short macro per expression) and safely (e.g. prevents os << "x1=" << x2;). Apart from that the NV concept could be used for other applications, where one needs a variable/expression and its name as a string. For more info & download of the library goto http://groups.yahoo.com/group/boost/files/Named%20Variable/ Feel free to try & comment ;-) Markus __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

weak_ptr doc problem
by Daniel Wallin 03 Jun '04

03 Jun '04

The weak_ptr docs says this: weak_ptr(); Effects: Constructs an **empty** weak_ptr. Postconditions: use_count() == 0. long use_count() const; Returns: if *this is **empty**, an unspecified nonnegative value; otherwise, the number of shared_ptr objects that share ownership with *this. use_count() seems underspecified and contradicts weak_ptr(). It should return exactly 0 when *this is empty. -- Daniel Wallin

2 1

RE: [boost] Proposed Boost Library for Data Series Analysis
by Tom Brinkman 03 Jun '04

03 Jun '04

Response to Matthew Hurd post: >> Efficiency is often paramount with these types of apps. Being able to do finite difference approaches, backwards and forwards, and in absolute terms is important (often you only want the latest data point). Agreed. >> You have the incremental case covered in your notes. Being able to calculate it at a point in an absolute sense, optional caching of results, working with series of unknown lengths and accuracy / validity enabling would be nice too. Agreed. >> By accuracy / validity enabling I mean, for say, your example of a 5 step moving average, it is not valid for the first four points as these are not an accurate average, so there is a length modification for the result. The value for the first four elements is invalid. The user has to adjust for this when they iterate over the returned vector. Example: (three day moving average) std::vector<double> out; std::transform(in.begin(), in.end(), std::back_inserter(out), moving_average(3)); out[0] = NA out[1] = NA out[2] = NA out[3] = NA std::transform(out.begin()+4, out.end(), std::cout << _1 << "\n"); >> Another simple example would be an exponential moving average where the number of significant digits required will determine how far back you need to go in the series. At another level, quality of service for some functors, the fast or accurate spectrum, is often appropriate. >> Perhaps expression templates might help here. Compile time results for validity calcs for series of known lengths would be helpful where possible. Agreed. Expression templates could be used very effecitively here. I will look into this. >> It would be nice if the algorithms could be simply specified, similar to your approach, and then "mounted" into the appropriate framework. Perhaps SFINAE or another technique could be used to determine an algorithm's capabilities. That is, the framework could juggle the most appropriate methods to use based on the results required. E.g. use incremental if you can otherwise absolute. >> Based on what I've done the past you also end up wanting arbitrary n-dimensional structures with other data types flowing through as well. Being able to associate ids/names with data items and keeping them associated through sorting/ranking. E.g. tag the series with data codes, rank them, and you can get the code for the best. You also want grouping n dimensional constructs and splitting dimensions and "slicing" operators that operate across the current dimension, which, with the appropriate framework, are one in the same. E.g. choose the minimum or sum the results of a bunch of functions. >> Then soon you want to split the computation amongst processors and machines and you want treat the computation as a dataflow graph and parallelise it some way, which I did a few years ago with BGL's precursor the GGCL. A topological sort gets you most of the way there... Also, you can then use things like Metis to partition your computation graph in nice ways. >> I think a way approach it would be an expression template approach with some adaptability in terms of absolute and incremental analytics with some accuracy (at least something like the number of points being chewed up and not valid or some such). Everything else could come on top of this. Sounds very powerful. Is there any additional web information to help me incorporate these ideas. >> You need to ensure that you can easily reuse code out there. No one wants to spend their life writing the zillions of numerical algorithms already out there. If you want a vector ARMA model, there are only a couple out there I think, and they are in FORTRAN, for example, wrap it, don't write it, I'd hope. Agreed. Thank you for your comments and spending the time to look at the library. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

Re: Boost Mathematicians
by Tom Brinkman 03 Jun '04

03 Jun '04

http://mathworld.wolfram.com/ Tens of thousands of visitors view MathWorld each day, and thousands of denizens of the mathematical and internet communities have contributed material over the last five years. As a result of this collaboration, MathWorld has grown to become the web's most extensive single source of educational and reference material about mathematics. If you havn't checked out this site you should take a quick look. I propose that we utilize the MathWorld community as the primary resource for ideas about our boost::math::algorithm library. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

static sized strings
by Martin 03 Jun '04

03 Jun '04

I have tested the sandbox version of the static sized strings. It works fine but there are a few inconveniences that I want to point out. 1. The abstract base class. --------------------------- Having an ABC to handle fixed strings of various lengths is a good idea but it is not very practical. I understand that the main purpose is to allow fixed strings to be passed to functions without using templates. int countwords(const boost::char_string & str); unfortunatly the ABC makes it difficult to pass anything but fixed strings. If you want to pass a string literal, a character array or a std::string you must create a temporary fixed_string<>. countwords(boost::fixed_string<20>("The quick brown fox")); Don't really have a good solution but maybe the base class could use an external buffer with constructors from char* and std::string. class char_string { const char* const extbuf; size_t len; protected: char_string() : extbuf(NULL) {} // not used since derived implements its own buffer public: char_string(const char* c) : extbuf(c), len(strlen(c)) {} char_string(const std::string& str) : extbuf(str.c_str()), len(str.length()) {} ... // virtual basic_string interface } Don't know how to handle non-const char[]. 2. Substrings ------------- One of the applications I can see for fixed_string is when you want to avoid dynamic allocation but still want to use the std::string interface and algorithms. In that perspective it seems strange that substr returns a std::string instead of a fixed_string. 3. resize --------- Still missing a method to update the length to reflect the current string length. I think a resize without arguments would be a good solution. boost::fixed_string str<10> strtime(str.buffer()); str.resize(); 4. operator[] ------------------------- I don't have the standard basic_string interface available but I am pretty sure that operator[] doesn't throw an exception if the argument is outside max_size(). I also looked at the alternative fixed_string implemenatation but since that version doesn't have full std::string interface I didn't test it. I am not sure I like the lazy length calculation for two reasons. - In my view, strlen is normally a "cheap" operation comparable to a function call. If the lazy evaluation prevents a function from being inlined, the benefit is lost. - It is tricky to detect when the length is invalid. With the current implementation, I can't say if the length is valid or not after "str[4] = str [5]" since that depends on the order of evaluation of "str[4]" and "str[5]".

1 0

RE: [boost] Re: Re: Boost Mathematicians
by Hurd, Matthew 03 Jun '04

03 Jun '04

> Behalf Of Thorsten Ottosen > Sent: Thursday, 3 June 2004 4:25 PM > > > "Reid Sweatman" <drunkardswalk(a)earthlink.net> wrote in message > > | Oddly enough, scientists is usually pretty > | conservative folk; they like what they know. > > Is that so odd? Yesterday I talked with a matematician here in Sydney about > Fortran. > He uses Fortran because it is good enough for what he is doing. It would > probably take quite some > time for him to learn C++, so why should he? > > br > > Thorsten There is an often seen misconception that C/C++ should be as fast as it gets as the programming model is close to the instruction model of the machine. In practice FORTRAN is usually faster. At one level, in C++ this slowness this is usually because of temporaries and expression templates and modern optimizing compilers can often mitigate this for typical math calcs. Other abstraction penalties apply. Another level is the fundamental differences in aliasing between the language definitions. FORTRAN as a language does not allow aliasing ambiguities which makes the optimizers job a lot easier and the code can be a lot faster. C/C++ assumes aliasing potential which makes optimizing very hard. A C/C++ compiler may allow aliasing to be disabled for a section of code or for the whole program, but you need to be confident in what you are doing. Very clever global analysis is needed to cure the aliasing problem, and given the potential for run time gymnastics, it may not be possible at all. Have a look at these benchmarks judging Todd V's blitz to FORTRAN: http://www.oonumerics.org/blitz/benchmarks/ Boost's equivalent to Blitz++ is uBLAs. More discussion on C++ versus FORTRAN speed can be found here: http://osl.iu.edu/~tveldhui/papers/iscope97/ I do think it is worthwhile writing C++ to do this stuff as the abstraction is much better for the library client IMO. At some levels the implementation may be tougher for the library writer, as some of the optimizer gymnastics ends up in the expression templates, but given the right framework it may be simply extensible and suitable for even relatively unsophisticated mathematicians to contribute library components. You still need to wrap as you can't hope, nor should you try, to offer all algorithms from all languages. Another lobbed $0.005, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna Sydney _______________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[test] [minmax] failure on gcc 2.95
by Vladimir Prus 03 Jun '04

03 Jun '04

As shown in http://tinyurl.com/3xdyq, Boost.Test fails to build on gcc 2.95 with stlport. The error message is: /boost/head-regression/boost/boost/minmax.hpp: In function `const size_t & boost::std_min<size_t>(const size_t &, const size_t &)': /boost/head-regression/boost/libs/test/build/../src/test_tools.cpp:375: instantiated from here /boost/head-regression/boost/boost/minmax.hpp:26: `min' undeclared (first use this function) Is it possible that authors of either Boost.Test or boost/minmax.hpp take care of this error? Thanks, Volodya

1 0