Re: [boost] Release Manager's Checklist added
- Original Message - From: "Beman Dawes" <[EMAIL PROTECTED]> To: "Boost Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, August 07, 2003 5:43 PM Subject: [boost] Release Manager's Checklist added > I've added a detailed Release Manager's Checklist > (boost-root/more/release_mgr_checklist.html). > > It will take up to 24 hours for this to be reflected on SourceForge's > public CVS (although it is available right away for those with write > access). > > There are five items on the checklist that take up the bulk of the release > manager's time (see abbreviated descriptions below). The release manager is > near exhaustion by the time these are complete. I think we need to figure > out a way to delegate this management effort to more people. (There are > already quite a number of people helping with bits and pieces of the > overall process, but we need to formalize that a bit more, IMO, so the > release manager doesn't get lost in the details.) > > --Beman > > * Monitor inspection report to verify problems are being dealt with. Unsure about that. I remember some mails from a wizard ;-) > * Monitor regression tests to verify that errors are dealt with. Unsure about that. ublas has some test failures (for ICC on windows for example) which nobody is going to fix probably. OTOH this is the only verification if cvs is consistent. > * Monitor mailing lists to verify that patches are being dealt with. Doesn't sf have a tracker for patches? > * Monitor mailing lists and bug tracker to verify that bug reports are > being dealt with. Doesn't sf have a tracker for bugs? > * Monitor CVS commits to verify content gets committed as planned. Yep, seems like this one is a problem. Prereleases? Regards, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Release Manager's Checklist added
Hi Beman, you wrote: > >> * Monitor regression tests to verify that errors are dealt with. > > > >Unsure about that. ublas has some test failures (for ICC on windows for > >example) which nobody is going to fix probably. OTOH this is the only > >verification if cvs is consistent. > > The actual process for future releases is going to be more sophisticated > than in the past. For key compilers (those on major platforms with few > enough bugs that it is possible to look at errors in detail), we can try to > account for failures (as boost problems, compiler bugs, whatever). For > example, see the random library tests at > http://boost.sourceforge.net/regression-logs/cs-win32.html > > There are seven failures. Jens has looked each failure, and each has been > classified. (Except Borland classification which will show up tomorrow.) > You could say each failure has been "accounted for". Impressive. > Thus the release manager can see at a glance that this library is ready for > release. OK. > >> * Monitor mailing lists to verify that patches are being dealt with. > > > >Doesn't sf have a tracker for patches? > > > >> * Monitor mailing lists and bug tracker to verify that bug reports are > >> being dealt with. > > > >Doesn't sf have a tracker for bugs? > > Yes, to both but we aren't using them fully and/or properly. Exactly. > Also, people > post patches and bug reports direct to the mailing lists. That's probably wrong. They should use a tracker first and then discuss them on the mailing lists. > Sometimes they > get handled promptly, sometimes not. There's no assignment process currently. > I've got at least a dozen email > messages to the main list flagged as "awaiting response", plus lots of S/F > reports too. So you are responsible for all that stuff? ;-) > I keep meaning to research the best way to track bugs/patches, but haven't > found the time. Note that the "best way" may just mean learning to use > existing SourceForge features better. I believe it's a matter of discipline of the community to use the trackers. > >> * Monitor CVS commits to verify content gets committed as planned. > > > >Yep, seems like this one is a problem. Prereleases? > > Some kind of task list is more what I had in mind. SourceForge has such a > feature already; we aren't using it. OK. > Thanks for the questions. Even though programming is much more fun, I'm currently working in maintenance mode ;-) > we need > to do a certain amount of management to ensure release quality. Agreed. Best, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: ublas and gcc (was: Re: [boost] Re: Compiler status for GCC 3.3)
- Original Message - From: "Gabriel Dos Reis" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Monday, August 11, 2003 1:02 AM Subject: Re: ublas and gcc (was: Re: [boost] Re: Compiler status for GCC 3.3) > [EMAIL PROTECTED] (Joerg Walter) writes: > > [...] > > | > This whole thing (-fabi-version) is messy. It is what one gets by > | > taking users for beta testers ;-) > | > | That's not the whole story. When testing with GCC 3.3.1 prerelease I noticed > | that setting -fabi-version isn't necessary anymore. So I filed a bug report > | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11812, which immediately got > | closed ;-). The subsequent discussion at > | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11105 leads me to believe that > | GCC 3.3 was too conservative w.r.t. ABI compatibility. > | > | Due to this and the fact that there's been another bug in GCC 3.3 > | (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11198) which manifests when > | using ublas, I tend to advise against using GCC 3.3 for ublas. > > GCC-3.3 is GCC-3.3.0 in disguise and I tend to refrain myself from > using .0 releases outside of experimental works :-). > > More seriously, did you have a chance to test GCC-3.3.1? Yes, GCC 3.3.1 works OK for me. Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release Manager's Checklist added
Hi Daniel, you wrote: [snip] > > That's probably wrong. They should use a tracker first and then discuss them > > on the mailing lists. > > I disagree. I think that we should try to focus information instead of > spreading them around. That's exactly what a tracker is good for IMHO. > If we use the CVS-tree for the code, the mailing > list(s) for discussion and regression tests (in CVS) to track bugs, this > should be enought. The regression tests are IMHO superior to > bug-trackers as they provide a much better feedback and are easier to > maintain. Regression tests and tracker do not contradict. > Bug-trackers are just administrative overhead in my eyes, YMMV. Maybe that's a question of the project's size. And boost is still growing. > Let's make a small survey on what part we should keep and what might be > obsoleted for the future. AFAIK the items to note are: > > Mandatory and IMHO not controversal: > > - CVS > - Mailing list(s) > - Website > - Releases on SF Agreed. > Other sources: > > - Wiki Inofficial. > - Yahoogroup's files-section > - SF *-tracker > > Personally, I'd like to get rid of the latter two. The reason against > the files-section is, that it was very useful in the beginning, but as > we have a main- and a sandbox-CVS and we can use branches on them, there > shouldn't be any need for a files-section any longer. Unsure: one first needs CVS access then. > This is also > backuped by the fact that the files-section isn't used as frequently as > in the beginning (AFAICS). > > The trackers are IMHO a problem because they require a lot of work. That could be, yes. > The > current state shows that it is not maintained well, e.g. there are open > bugs which are long closed in CVS, see #451535. Sure we could do better > in theory, but is it worth it? Why not use regression tests to track > bugs? AFAICS people pay a lot of attention to the regression tests and > the whole systems work pretty well. > > Also, I hope that it could make the release manager's work easier to > have fewer sources to track :) In my opinion it should be easier for the release manager to look into the tracker than to follow *all* mailing list traffic. > OK, what do others think? Am I the only one who feels uncomfortable with > the SF-trackers? Yep, I'm curious, too. > >>we need > >>to do a certain amount of management to ensure release quality. > > I would like to remind you of "KISS". Too much managment can also > decrease quality as it might rule out some people. And I don't think > that we really have a problem in tracking bugs. Then we'd be the first probably ;-) > For features, it's up to > the maintainers to handle this, but it's IMHO better to discuss this on > the list and probably extend the libraries FAQ- or futute-section. No > new system required :) Maybe features are another story. Best, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Support for gcc-2.95 in 1.31
- Original Message - From: "Martin Wille" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Tuesday, August 12, 2003 5:14 PM Subject: Re: [boost] Re: Support for gcc-2.95 in 1.31 [...] > >>a couple of libraries are regressing for gcc-2.95.3/Linux: [...] > >> numeric/ublas (only with stlport) Confirmed and fixed in Boost CVS. [...] > The results for CVS HEAD can be found at: > http://boost.sourceforge.net/regression-logs/cs-Linux/developer_summary_page .html Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: File missing from Boost 1.30.1 release?
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 06, 2003 10:06 PM Subject: [boost] Re: File missing from Boost 1.30.1 release? > David Abrahams <[EMAIL PROTECTED]> writes: > > > Zak Kipling <[EMAIL PROTECTED]> writes: > > > >> I've just tried to build Boost 1.30.1, and it failed with the error: > >> > >> /home/zak/current/unpacked/boost/src/boost-1.30.1/boost/pending/integer_rang e.hpp:15:39: > >> boost/counting_iterator.hpp: No such file or directory > >> > >> This file doesn't appear to be there at all... it's in CVS, but only > >> on the MAIN branch. > > > > That's very strange; somehow the tag must've been dropped. > > permutation_iterator.hpp is missing too. Ouch. > > > > Maybe we need to release a 1.30.2? > > Definitely. Here's a complete list of files that were removed from > RC_1_30_0 between 1.30.0 and 1.30.1. This can't be intentional: [...] OK, I believe bugfix releases are necessary, but we're 60+ developers, so some kind of planning is neccessary, too. Personally I can't cope with a time frame of a week or two. Appreciating-the-release-manager's-efforts-ly y'rs, Joerg P.S.: Daniel, it's seems you're going to have challenging times ;-) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Bug tracking (was: Re: [boost] Re: Release Manager's Checklist added)
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 09, 2003 11:58 PM Subject: [boost] Re: Release Manager's Checklist added [...] > >> > That's probably wrong. They should use a tracker first and then discuss > >> > them on the mailing lists. > >> > >> I disagree. I think that we should try to focus information instead of > >> spreading them around. > > > > That's exactly what a tracker is good for IMHO. > > Yes, agreed. One big problem though is that the SF trackers kinda > suck. I'd be interested in trying something else, like > http://roundup.sourceforge.net/ Interestingly enough they seem to use the SF trackers for their own bugs ;-). But the more important question probably is if there are any volunteers providing an alternative tracker for us? [...] > >> The trackers are IMHO a problem because they require a lot of work. > > > > That could be, yes. > > Yeah, but that might just be the SF trackers. We don't have to use > them as-is. Quality assurance simply is a lot of work. > >> The current state shows that it is not maintained well, e.g. there > >> are open bugs which are long closed in CVS, see #451535. Sure we > >> could do better in theory, but is it worth it? Why not use > >> regression tests to track bugs? AFAICS people pay a lot of > >> attention to the regression tests and the whole systems work pretty > >> well. > >> > >> Also, I hope that it could make the release manager's work easier to > >> have fewer sources to track :) > > > > In my opinion it should be easier for the release manager to look > > into the tracker than to follow *all* mailing list traffic. > > Yeah. Also, you can't always get people who find bugs to make > reproducible test cases in a form that integrates with the regression > suite. OK, I'd be willing to spend some time working with the SF trackers in the near future (assumed we don't change the tracking system). > >> OK, what do others think? Am I the only one who feels uncomfortable with > >> the SF-trackers? > > Nope; I dislike them also. That doesn't mean trackers in general are > a bad idea. I'd still be interested to hear some more opinions, especially user's. Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ublas and gcc (was: Re: [boost] Re: Compiler status for GCC 3.3)
Hi Gabriel, you wrote: > | >>> On the other hand if your native compiler is GCC and your system was > | >>> not configured with that setting, then you may get into trouble -- > | >>> since you'll be mixing translation units with different ABIs. > | >> > | >> Furthermore, that sounds like a workaround. Isn't it still a > | >> compiler bug that it doesn't work without -fabi-version=0? > | > > | >No, it's correctly fixed, but since it's a fix that breaks ABI, the > | >version number was bumbed. By default, GCC 3.3 uses the GCC 3.2 ABI. > | >If you want to > | >activate the new version, you have to explicitally say so. > | >"-fabi-version=0" always selects the last version of the ABI. > | > | So are you are saying we should add "-fabi-version=0"? > > If you do that unconditionally, you may get ABI incompatible > libraries/programs compared to what your system come with. > > The default ABI version for GCC-3.3.x is 1. You might want to set it > to 2 and see what happens (for GCC-3.3.x) -- some bugs are fixed in > -fabi-version=2. > > > This whole thing (-fabi-version) is messy. It is what one gets by > taking users for beta testers ;-) That's not the whole story. When testing with GCC 3.3.1 prerelease I noticed that setting -fabi-version isn't necessary anymore. So I filed a bug report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11812, which immediately got closed ;-). The subsequent discussion at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11105 leads me to believe that GCC 3.3 was too conservative w.r.t. ABI compatibility. Due to this and the fact that there's been another bug in GCC 3.3 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11198) which manifests when using ublas, I tend to advise against using GCC 3.3 for ublas. Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: uBlas and linear algebra questions
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 21, 2003 3:51 AM Subject: [boost] Re: uBlas and linear algebra questions > Kirill Lapshin <[EMAIL PROTECTED]> writes: > > > David Abrahams wrote: > >> Ah, I understand. It seems as though the choices for linear algebra > >> in C++ haven't improved much since I first started looking at them > >> several years ago. > > > > Right, and even blas implementation provided by uBlas seemed to be > > quite far from good old C-style routines (e.g. ATLAS). Good news that > > there are atlas bindings. > > Hmph. ? I've done some experiments recently with Intel's CC 7.1 on i86, which indicate that one is able to teach it to vectorize some ublas codes and to try to take advantage of L1 and L2 cache (BTW, are these constructions part of the C++ standard? ;-). Newer versions of ATLAS are still a lot faster. What do you expect? > >> Well, that's disturbing! http://tinyurl.com/hinz plainly says: > >> Mailing lists > >> - > >> uBLAS has no dedicated mailing list. Feel free to use the mailing > >> lists of Boost . > >> What's the address of the mailing list? [EMAIL PROTECTED] That's > >> the only other thing I can find in your posting's header. > > > > There is ublas-dev mail list on yahoo > > (http://groups.yahoo.com/group/ublas-dev/). > > Thanks. Sorry, I'll fix this later. Regards, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: uBlas and linear algebra questions
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 21, 2003 2:25 AM Subject: [boost] Re: uBlas and linear algebra questions > Kirill Lapshin <[EMAIL PROTECTED]> writes: > > > David Abrahams wrote: > >> I'm trying to get a grip on what facilities are available for doing > >> linear algebra with uBlas, but I can't seem to find any good > >> information. I'm interested in such things as: > >> LU factorization > >> Cholesky factorization > >> Gaussian Elimination > >> Ordinary Least Squares Regression > >> ...etc... > >> Can somebody help me out? > > > > uBlas does not provide such high level algorithms. You can try to use > > lapack bindings (available in files section of ublas mail list). The > > bindings are still work in progress, subject to change, and they wrap > > only very limited subset of lapack algos. > > Ah, I understand. It seems as though the choices for linear algebra > in C++ haven't improved much since I first started looking at them > several years ago. I'm still curious to write some generic linear algebra algorithm, but my time is limited and I'm a bit unsure about the requirements. Currently most users seem to be more interested in high performance implementations than in generic use cases (with boost::interval as scalar type for example). Regards, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: uBlas and linear algebra questions
- Original Message - From: "Kirill Lapshin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 21, 2003 2:59 AM Subject: [boost] Re: uBlas and linear algebra questions > David Abrahams wrote: > > Ah, I understand. It seems as though the choices for linear algebra > > in C++ haven't improved much since I first started looking at them > > several years ago. > > Right, and even blas implementation provided by uBlas seemed to be quite > far from good old C-style routines (e.g. ATLAS). ATLAS uses a bit of platform specific stuff, no? > Good news that there > are atlas bindings. Agreed. [snip] Regards, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
- Original Message - From: "Daniel Frey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, July 15, 2003 11:38 PM Subject: [boost] Re: plans for a bugfix release ? > On Tue, 15 Jul 2003 16:26:43 +0200, David Abrahams wrote: > > > What does everybody think about doing a 1.30.1 release "RSN?" > > I think it's too late, let's go for a 1.31.0. Agreed. > I think that we'll hear > about problems with the 1.31.0 really soon after release and probably a > 1.31.1 can follow shortly after. And 1.31.x, yes. > For 1.30.0, we IMHO missed the > opportunity do to a 1.30.1 without lots of pain/work. As Beman already > said there is too much in CVS to "backport" it to a 1.30.1. The question > is, whether we learn from it for a 1.31.1 :) Personally I'd have to learn to manage different CVS branches accordingly. I believe, we'd need some kind of approximate schedule, too. Oh, and someone should volunteer for the job of the release manager. > My 2 cents... Already 4 cents, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Compiler status for GCC 3.3
- Original Message - From: "Gabriel Dos Reis" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Monday, June 30, 2003 12:06 PM Subject: Re: [boost] Compiler status for GCC 3.3 [...] > | I'm not sure about this. Paul C. Leopardi and Guillaume Melquiond already > | reported the issue, Paul also analyzed it here > | http://groups.yahoo.com/group/ublas-dev/message/676 > | > | In essence: setting -fabi-version=0 should solve the problem. > > On the other hand if your native compiler is GCC and your system was > not configured with that setting, then you may get into trouble -- > since you'll be mixing translation units with different ABIs. It sounds as if GCC 3.3 itself could be affected by -fabi-version=?. If say for example libstdc++ isn't binary compatible when build with different -fabi-version settings don't we have two different compilers depending on configure's -fabi-version then? Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Compiler status for GCC 3.3
- Original Message - From: "Gabriel Dos Reis" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Monday, June 30, 2003 3:55 AM Subject: Re: [boost] Compiler status for GCC 3.3 > Beman Dawes <[EMAIL PROTECTED]> writes: > > > [...] > > | But some of the problems are clearly GCC bugs. For example, all the > | ublas tests are failing with this message: > | > | ...error: due to a defect in the G++ 3.2 ABI, G++ has assigned the > | same mangled name to two different types... > > :-( > > Indeed, a bug report in in order. I'm not sure about this. Paul C. Leopardi and Guillaume Melquiond already reported the issue, Paul also analyzed it here http://groups.yahoo.com/group/ublas-dev/message/676 In essence: setting -fabi-version=0 should solve the problem. It's now more of a boost.build problem to support different configurations for GCC versions prior to 3.3 and 3.3 (because -fabi-version is a new flag ;-(. FWIW I believe to have seen a more serious regression in GCC 3.3 and filed bug report #11198: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11198 Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Re: Math Constants Formal Review - is extensible.
- Original Message - From: "Daniel Frey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 14, 2003 9:47 PM Subject: [boost] RE: Re: Math Constants Formal Review - is extensible. > On Wed, 11 Jun 2003 15:49:05 +0200, Paul A. Bristow wrote: > > > The proposal is for several header files each containing the same > > constants, only one of which would be used for any compilation. (Users > > have been warned against using more than one! Nobody has suggested a way > > to guard against this mistake, but I think that it would be apparent > > pretty soon, probably at compile time, and at link time if not.) The > > macros constants header is the simplest and could be used to provide the > > appropiate value(s) above. > > The difference IMHO is, that this is not a generic approach. During my last discussion with Paul I realized that math_constants<> probably isn't the same as numeric_limits<> (nevertheless I'd try to write them based upon the supplied constants ;-). > It's a bit > like replacing templates with macros. I haven't seen any convincing > arguments against the code I showed, which *is* generic I like that code. > IMHO, but as I > don't have the background of the "long saga" you mentioned, I think I'm > not the right one to say what's the best way to go. I'm a bit surprised, that we currently are reviewing some ideas instead of a library as far as I understood. Regards, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Slips of the pen in boost/numeric/ublas/matrix.hpp(version1.11)
Hi Alexey, you wrote: > Please correct this who can: > > 408c408 > < #ifdef BOOST_UBLAS_NO_NESTED_CLASS_RELATION > --- > > #ifdef BOOST_UBLAS_MSVC_NESTED_CLASS_RELATION [snip a couple of similar corrections] Will do. Thanks for your feedback, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Matrix Multiplication Benchmark: uBLAS, Matlab 6.5,Matlab 5.3, ATLAS
Hi Patrick,
you wrote:
> I just want to send you a small table with time needed for multiplications
> in several cases. The first column represent the used data_types
> R=row_major,C=column_major. The 6 last columns are classical
multiplications
> with loops. rkc->rck is just a differnent order of the loops. I used uBlas
> there as the container and I think the result is pretty close to the use
of
> valarray or double*.
Never checked that so completely, so thanks for doing the work.
> Big surprise: Take the right configuration and uBlas runs extremly!!!
fast,
> but taking the wrong one.
> I will try it for 1500x1500 now as well, but as far as I have seen, it
will
> produce more or less the same result.
Probably.
> size of metrices - 500x500
> ublas rkc rck krc kcr crk ckr
> RRR 2.453 2.218 4.141 2.515 5.344 3.343 4.937
> RRC 1.0934.36 2.329 3.235 5.375 2.359 4.844
> RCR 3.922 2.391 4.984 2.437 4.5 4.782 2.859
> RCC1.86 4.235 3.4063.14 4.4374.25 2.813
> CRR 1.906 2.875 4.203 4.422 3.2823.254.25
> CRC 1.078 5.109 2.453 5.437 3.125 2.407 4.172
> CCR 3.922 2.937 4.875 4.531 2.563 4.828 2.422
> CCC 2.4384.89 2.9845.25 2.516 4.062 2.375
I've added another test for blocked products and get the following results:
size of metrices - 500x500
prodblock rkc rck krc kcr crk ckr
RRR2.44 1.2 2.14.322.56 6.73.446.15
RRC1.060.554.342.073.456.842.116.11
RCR4.183.432.166.112.524.64 6.2 2.9
RCC1.73 1.24.383.353.434.674.522.85
CRR1.731.27 34.394.773.33 3.3 4.4
CRC1.030.545.672.136.55 3.42.124.37
CCR4.153.413.076.094.742.536.062.13
CCC2.451.125.613.466.282.554.442.07
RCR and CCR possibly could be the reason to add another couple of
axpy_prod() overloads.
Tests ran on my Intel 1.7 GHz P4 box under Linux with GCC.3.2.1. Best result
is around 500 MFlops and not half as fast as ATLAS dgemm IIRC.
> YES, I FEEL SORRY TO POST CODE SNIPPETS WITH THESE MACROS IN
> THE C++ COMMUNITY, ... anyway.
I've seen incredible things done with the preprocessor here, so probably no
need to worry.
> #define mul2(xtype) \
> { \
> initmatrix(A); \
> initmatrix(B); \
> t.restart(); \
> X = ublas::prod< xtype >(A,B); \
> time = t.elapsed(); \
> cout << setw(8) << time; \
> }
Changed/added:
--
#define mul2(xtype) \
{ \
zeromatrix(X); \
initmatrix(A); \
initmatrix(B); \
t.restart(); \
X.plus_assign(prod(A,B)); \
time = t.elapsed(); \
cout << setw(8) << time; \
cerr << equals(X,prod(A,B)) << endl; \
}
#define mul3(xtype) \
{ \
zeromatrix(X); \
initmatrix(A); \
initmatrix(B); \
t.restart(); \
X.plus_assign(ublas::block_prod(A,B,64)); \
time = t.elapsed(); \
cout << setw(8) << time; \
cerr << equals(X,prod(A,B)) << endl; \
}
--
[snip more code]
Thanks again,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [ublas] Weakness in large sparse matrices
Hi Johan, you wrote: > Thanks for all your info. I've run the tests with a Boost from CVS (from > january 31st), compressed_matrix and axpy_prod, and the results give > roughly the same speed as our implementation, and ca. 30% better memory > efficiency. Great! Kudos to the guys on groups.yahoo.com/group/ublas-dev. Without them sparse matrices would be as bad as in boost_1_29_0. > The -DNDEBUG flag also seems critical, without it > performance is terrible (quadratic). Oh yes. That's my paranoia. Without -DNDEBUG defined ublas is in debug mode and even double checks sparse matrix computations with a dense control computation. You could customize this using the BOOST_UBLAS_TYPE_CHECK preprocessor symbol. > Alexei's proposed optimizations seem interesting. I tried the axpy_prod > you provided, but it didn't give any significant change. I trust your > figures however. Yup. I didn't post the necessary dispatch logic. I'll later update Boost CVS with my current version. > I will propose that we start using ublas as soon as the linear complexity > functions appear in the stable branch. > > I provide our benchmark below for reference (with the timing calls, and > other dependencies stripped out): Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [ublas] Weakness in large sparse matrices
Hi Johan, you wrote: [snip] > Let's look at just assembly for now. We start by creating an 1e5 x 1e5 > sparse matrix. We then successively insert 1e5 elements in the diagonal. > What happens is that the insertion speed is linear for the first ~5 > elements, and then grinds to a halt. The initial insertion speed is > somewhere at 1e5 elements/s, after 5 elements it sharply falls to > 1000 elements/s (to compare, our naive implementation gets 1e6 elements / > s). On 32-bit systems the upper dimensions for sparse_matrix are 65535 x 65535 due to the internal mapping of (i, j) -> (i * size2+j) (or (i + j * size1). I've added a corresponding check to the debug version. For larger dimension consider to use compressed_matrix (FORTRAN CRS/CCS format) or coordinate_matrix (FORTRAN COO format) please. I'm also assuming you're checking the boost_1_29_0 release, so you'll probably have to look into the current CVS version for these (many changes). > This is quite bizarre. > > With an 1e6 x 1e6 matrix, the insertion speed is smoother, but slow > throughout (on the order 1000 elements / s). > > I've tested this on two different computers, one dual Athlon and one PII > laptop, and the result is identical (aside from the absolute speed > numbers). Memory is not at all full, so that can't be an issue. > > The code for this simple test is at the end. > > The compiler used was g++-2.95 (in Debian) and Boost 1.29 (also Debian). > > I've also observed a quadratic time complexity (in the non-zero elements) > in sparse matrix-vector multiplication. I think this has been brought up > before though. Using the experimental (means undocumented ;-( axpy_prod() functions one achieves the correct complexity. > We've also tested MTL, and while it doesn't produce these kinds of wild > irregularities, the performance is a factor 2 or 3 worse than our naive > implementation, and the memory usage is a factor 1.5-2 worse. > > This makes me question the claim that genericity does not add overhead (in > practice). 10-20% overhead is acceptable, but when we have 100-200% > overhead, both in performance and memory, then it makes it impossible to > justify its use. Alexei Novakov's benchmarks show an overhead of around 100% for the better ublas sparse matrix vector multiply implementations currently. He proposed an improvement of sparse matrix iterators already, which we'll tackle immediately after the upcoming 1_30_0 release. Thanks for your feedback, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
- Original Message - From: "Andrei Alexandrescu" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 03, 2003 8:44 PM Subject: [boost] Re: Array support [was SmartPtr (Loki) -auto_ptr/movec'torissue] > "Howard Hinnant" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote: > > > > > By and large, I believe "smart pointers to arrays" are an oxymoron and > > > should not be supported. > > > > Why? > > The reasons are explained in MC++D. Here's my take: > > 1. Arrays of polymorphic objects don't work. > > 2. If I wanna arrays of monomorphic objects I can use std::vector. > > 3. If I wanna arrays of monomorphic objects and std::vector's performance > is unsatisfactory to me, I can use the typed buffers > (http://www.moderncppdesign.com/publications/cuj-08-2001.html, > http://www.moderncppdesign.com/publications/cuj-10-2001.html, > http://www.moderncppdesign.com/publications/cuj-12-2001.html) that are > present in the up-and-coming YASLI. > > 4. So there's no reason I'd ever wanna have smart pointers to arrays. I needed something with exactly boost::shared_array's interface to add reference counting to ublas. With shared_array I'm able to run the CLAPACK test suite on ublas containers. Best, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [ublas-dev] Re: abs doesn't work with VC .NET
Hi Michael (hi Kresimir, hi Julius, hi all ;-), you wrote: > I have come across this problem before. The same problem occured when I > was working on .NET patches for boost::quaternion. So there's at least another boost library affected. > The following is from memory of VC7, so actual names may be slightly > different. I no longer have access to the MSVC compilers. Luck me!! :-) > If turn on compiler warning level 3 you should see warnings for line > such as "abs(1.5)" that a double is being converted to and integer. > If look in the header you will see why All the C++ definitions > are in there. The problem is that many (includeing abs(float/double) are > NOT defined when the macro _MSC_EXTENSIONS is defined. This is for some > stupid backwards compatibilty with their previous broken headers!! > > To make things work, you must either > Use the compiler switch /Za to disable microsoft extensions. > OR use > #ifdef _MSC_EXTENSIONS > #undef _MSC_EXTENSIONS > #include > #define _MSC_EXTENSIONS > #else > #include > #endif > > I do not recommend /Za. The compiler has even more problems then normal > when it is set. VC7 cannot compile uBLAS and many other boost libraries > with /Za. This agrees with Julius' statements. > My long term solution was simply to edit to remove the > offending conditional compilation! :-) > The is no specific solution in boost/config for this problem. I don't > see there is an easy fix either as _MSC_EXTENSIONS needs to be define > for some of MS own header files. OK. I've prepared the following patch for ublas: - Add the following to the MSVC section of ublas/config.hpp #ifdef _MSC_EXTENSIONS #define BOOST_UBLAS_NO_CMATH #endif - Change the problematic parts of ublas/traits.hpp to #if defined (BOOST_NO_STDC_NAMESPACE) || defined (BOOST_UBLAS_NO_CMATH) return ::fabsf (t); #else return std::abs (t); #endif I'll commit this later, if noone objects. Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: ublas::type_traits::abs doesn't work with VC.NET
Hi Julius, you wrote: [snip] > > IIRC the signatures 'float abs(float)' and 'double abs(double)' should be > > part of , which is included in . > I think they should, too, but they aren't. I don't know why, but the Standard (Table 81, > Section, 26.5, p596) puts abs, div, rand and srand into cstdlib and all the others like sqrt > and asin into cmath. The reason why ublas/type_traits.hpp still compiles is that Microsoft > says "using ::abs" in cmath, although the Standard doesn't put it there. OK, this raises the question, if 26.5.5 and 26.5.6 must be read together or if the overloads of 26.5.6 should be splitted into and according to table 80/81. > By the way: VC 6 does have cmath and cstdlib headers, too. These headers just import > math.h and stdlib.h within namespace std brackets. This apparently wasn't enough to > convince boost to omit the BOOST_NO_STDC_NAMESPACE #define for VC 6. > > It seems that probably for legacy reasons most cmath headers declare abs, at least as int > abs(int), although it's seems to be against the Standard. Otherwise you would have had > many compiler errors already: ublas::type_traits is fully specialized so they are always > compiled. Still, I think you maybe should #include in ublas/type_traits to be > ready for a really conforming library implementation. OK, I'll add #include to ublas/traits.hpp. Does this solve the original problem with .NET? Thanks, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ublas::type_traits::abs doesn't work with VC .NET
Hi Julius,
it looks as if your mail didn't find it's way to the boost ml. You wrote:
> Hello Joerg,
> and hello to whoever deals with MSVC .NET Standard conformance at boost:
>
> I found a small but nasty bug between MSVC .NET and ublas which I believe
is
> Microsoft's fault.
>
> #include
> #include
> #include
>
> int main()
> {
> std::cout <<
boost::numeric::ublas::type_traits::abs( -10.2f ) << " "
> <<
boost::numeric::ublas::type_traits::abs( -10.2 );
> return 0;
> };
>
> gives me
>
> 10 10
>
> (not 10.2 10.2 as expected). The same code works fine with VC 6.0
Ouch.
> As fas as I can tell, the reason is:
> Unlike VC 6.0, VC .NET ships with the cstdlib header, where std::abs is
declared.
> However, the Microsoft folks basically just wrote
>
> namespace std{
> using ::abs;
> }
>
> in cstdlib so they have
>
> int abs( int )
>
> imported into namespace std from stdlib.h, while forgetting to add the
signatures float
> abs(float) and double abs(double) and so on as required by the Standard,
26.5.
IIRC the signatures 'float abs(float)' and 'double abs(double)' should be
part of , which is included in .
> Boost doesn't #define BOOST_NO_STDC_NAMESPACE in VC .NET, while in VC >
6.0 it is defined.
> Therefore, with VC .NET, ublas:.type_traits<>::abs uses int std::abs(int),
implicitly
> converting the floats to integers and back.
>
> Joerg: I think you could use ::fabs for VC .NET in ublas just like you do
with VC 6.0,
> the signature is double ::fabs(double) and long doubles are doubles so
there is no round > off.
I'll do this, if we don't find a better workaround.
> Maybe #defining BOOST_NO_STDC_NAMESPACE for MSVC .NET is too
> drastic, but yes I think you need to do something about it. There may well
be other
> libraries in boost that would use
> std::abs if BOOST_NO_STDC_NAMESPACE is not defined.
That's what I think, too. Is there a known boost workaround for this
already?
Thanks,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
boost@lists.boost.org
Hi Kresimir,
you wrote:
> >> now that sparse matrix_row's works with Joerg's latest CVS upload
> >> (thanks Joerg), a const& parameter that used to work with 1_29_0
doesn't
> >> anymore:
> >>
> >> using namespace boost::numeric;
> >> typedef ublas::matrix TM;
> >>
> >> double InnerProdConst( const TM& A, const ublas::vector& x )
> >> {
> >> return ublas::inner_prod( ublas::matrix_row< const TM >( A, 2 ),
> x );
> >> }
> >>
> >> VC++.NET complains that some internal conversion loses qualifiers,
> >> This does compile with a non const matrix reference parameter, the
same
> >> is true if I use a sparse_matrix or a compressed_matrix. I didn't try
> >> the other matrix types, but since this breaks with three matrix types,
> >> it looks like it has to do with matrix_row itself.
>
> ... or with VC++.NET ;o)
... or with ublas' perception of MS compilers ;-). I've just upgraded boost
on my old Win98 box from 1_25_1 to 1_29_0 and checked Julius' sample with
MSVC 6.0. He is right that it doesn't compile with the latest ublas
snapshot, but the fix is surprisingly simple. I only had to disable the
definition of
// #define BOOST_UBLAS_NO_SMART_PROXIES
in the MSVC section of config.hpp. This now seems to work due to our
migration to MPL (thanks, Aleksey!). The last compiler which doesn't support
these constructs is Borland.
> Joerg Walter wrote:
>
> > The following code compiles successfully with GCC 3.2.1:
> >
> > #include
> >
> > using namespace boost::numeric;
> > typedef ublas::matrix TM;
> >
> > double InnerProdConst( const TM& A, const ublas::vector& x )
> > {
> > return ublas::inner_prod( ublas::matrix_row< const TM >( A, 2 ),
x );
> > }
> >
> > int main()
> > {
> > ublas::matrix< double > A( 3, 3 );
> > ublas::vector< double > x( 3 );
> > std::cout << InnerProdConst( A, x ) << std::endl;
> > }
>
> ... and with Comeau's C++ compiler 4.3.0.1, too.
And with MSVC 6.0 now, too.
> Also with the following addition to `main()':
>
>ublas::matrix< double > const CA( A );
>std::cout << InnerProdConst( CA, x ) << std::endl;
Hopefully, too. Didn't check this yet.
Thanks,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
boost@lists.boost.org
Hi Julius,
you wrote:
> now that sparse matrix_row's works with Joerg's latest CVS upload (thanks
> Joerg), a const& parameter that used to work with 1_29_0 doesn't anymore:
Ouch ;-(
> using namespace boost::numeric;
> typedef ublas::matrix TM;
>
> double InnerProdConst( const TM& A, const ublas::vector& x )
> {
> return ublas::inner_prod( ublas::matrix_row< const TM >( A, 2 ), x );
> }
>
> VC++.NET complains that some internal conversion loses qualifiers,
> This does compile with a non const matrix reference parameter, the same is
> true if I use a sparse_matrix or a compressed_matrix. I didn't try the
> other matrix types, but since this breaks with three matrix types, it
looks
> like it has to do with matrix_row itself.
The following code compiles successfully with GCC 3.2.1:
#include
using namespace boost::numeric;
typedef ublas::matrix TM;
double InnerProdConst( const TM& A, const ublas::vector& x )
{
return ublas::inner_prod( ublas::matrix_row< const TM >( A, 2 ), x );
}
int main()
{
ublas::matrix< double > A( 3, 3 );
ublas::vector< double > x( 3 );
std::cout << InnerProdConst( A, x ) << std::endl;
}
I'll try to check this with MSVC 6.0 tomorrow.
> I think this should work with const&'s since inner_prod is non mutating.
> I'd like to keep the const&'s.
>
> Joerg: You suggested using compressed_matrix instead of sparse_matrix in
> your recent response to my matrix_row access problem. I couldn't find much
> in the documentation about the pros and cons of either type. Can you give
> me hint where to look for more information? Thanks.
Alexei Novakov's benchmarks show that Fortran like CRS/CCS schemes are more
efficient in most cases.
Best,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Another ublas CVS commit
Hi all, I've just committed my current ublas version to Boost CVS. It contains support for the newly added interval library and corresponding tests. Best, Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ublas bug(?): sparse_matrix and matrix_row
Hi Julius,
you wrote:
> to me it looks like there may be a bug with sparse_matrix and matrix_row.
> I was building a large sparse matrix from some smaller ones. When I tried
to assign a
> matrix_row of a sparse_matrix to another matrix_row of another
sparse_matrix, nothing > happened. When I mix sparse_matrix with matrix, it
works as I expected, but then the
> sparse matrix isn't sparse anymore.
>
> I tried this with the following code:
>
> void SparseBug()
>{
>using namespace boost::numeric;
>typedef ublas::sparse_matrix TSM;
>typedef ublas::matrix TM;
>TSM sm1(3,3);
>TSM sm2(3,3);
>TM m1(3,3);
>TM m2(3,3);
>sm1(1,1) = m1(1,1) = 2.;
>ublas::matrix_row (sm2,1) = ublas::matrix_row (sm1,1);
>ublas::matrix_row (m2,1) = ublas::matrix_row (m1,1);
>std::cout << "matrix=matrix: m2(1,1) should be " << m1(1,1) << ",
is "<< m2(1,1) > << std::endl;
> std::cout << "sparse_matrix=sparse_matrix: sm2(1,1) should be " <<
sm1(1,1) << > ", is "<< sm2(1,1) << std::endl;
> ublas::matrix_row (sm2,1) = ublas::matrix_row (m1,1);
> std::cout << "sparse_matrix=matrix: sm2(1,1) should be " <<
m1(1,1) << ", is "<< > sm2(1,1) << std::endl;
> ublas::matrix_row (m2,1) = ublas::matrix_row (sm1,1);
> std::cout << "matrix=sparse_matrix: m2(1,1) should be " <<
sm1(1,1) << ", is "<< > m2(1,1) << std::endl;
> };
>
> and got
>
> matrix=matrix: m2(1,1) should be 2, is 2
> sparse_matrix=sparse_matrix: sm2(1,1) should be 2, is 0
> sparse_matrix=matrix: sm2(1,1) should be 2, is 2
> matrix=sparse_matrix: m2(1,1) should be 2, is 2
>
> on my Win2000 SP3 machine with Microsoft VC++.net in debug mode.
>
> Has anyone an idea?
I just fed this into GCC 3.2.1 and got the following results with my current
version (in debug & release mode):
matrix=matrix: m2(1,1) should be 2,is 2
sparse_matrix=sparse_matrix: sm2(1,1) should be 2, is 2
sparse_matrix=matrix: sm2(1,1) should be 2, is 2
matrix=sparse_matrix: m2(1,1) should be 2, is 2
So I'm assuming you're using the boost_1_29_0 distribution. ublas had an
undocumented restriction regarding sparse proxy assignment at that time,
which was later resolved thanks to Michael Stevens.
I'm a bit surprised that ublas's debug mode didn't alert you, though.
Sorry for the inconvenience,
Joerg
P.S.: Please see Boost CVS for a more current version of ublas.
P.P.S.: Did you already consider to use compressed_matrix<>?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: math constant - generic function circle_area example.
Hi Paul,
you wrote:
> > I've again tried to compile this with GCC 3.2.1. Here are the
diagnostics:
> >
> > In file included from test_circle_area.cpp:12:
> > function_constants.hpp:83: uninitialized const `
> >boost::math::float_constants::pi
> >
> > The following workaround (applied to all constants) heals this
> >
> > namespace float_constants
> > {
> > #ifndef __GNUC__
> >constant< float, pi_tag > const pi;
> > #else
> >constant< float, pi_tag > const pi = constant< float, pi_tag >();
> > #endif
> > }
>
> This may be better for all platforms? I'll think about this.
Some more information: ICC 7.0 seems to accept both forms and Kylix none of
them (didn't analyze further) ;-(
> > The preprocessor symbol __TIMESTAMP__ seems to be platform specific.
> Agreed - but I personally find it useful so tend to use it. I should
bracket
> with #ifdef MSVC ...
> >
> > Ok, back to my earlier question. If I understand you correctly, we
better
> > should write
> >
> > return boost::math::constant< T, boost::math::pi_tag >() * radius *
radius;
> >
> > instead of something like
> >
> > return boost::math::constant< T >::pi() * radius * radius;
> >
> > in generic code? I'll have to think about this.
>
> It depends if Boosters decide to accept this fancy presentation of pi.
>
> If not, then going back to the macro (long double)
>
> #define PI 3.141592653589793238462643383279502884197L
>
> and using the compiler to convert to type T
As far as I understand long double is optional (in IEEE 754). This would
mean you'd have to provide the double constant, too.
> template
> T circle_area(const T& radius)
> {
> // Usage example: circle_area( 2.) // Explicit type double.
> // or circle_area(2.F) // Implicit type float.
> return T(PI) * radius * radius;
> }
Interesting option. I'll probably play with it one day.
> *_probably yields_* the same end result
> (as will the appropriate function of float pi(), double pi(), long double
pi()).
When these use the same (long double) constant internally?
> But if you want the exactly representable value for interval arithmetic,
> then I think the form
>
> return boost::math::constant< T, boost::math::pi_tag >() * radius *
radius;
>
> will always give the exact value for pi.
>
> (But, to confuse the matter further, is it not going to be more accurate,
if
> less portable, to calculate PI * radius * radius using long double before
a
> final rounding to type T? So we are choosing portability over accuracy
here,
> rightly in my view. Anyone who wants maximum accuracy will have to do
their own
> thing with the 40 decimal digit macro value for pi, and probably only
wants long
> double type anyway.)
Thanks,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: math constant - generic function circle_area example.
Hi Paul,
you wrote:
> Please send me your amended code. I had thought that the Kenniston stuff
was
> included in the zip uploaded, but I will check. Apologies if not.
OK. I've just learned that the file function_constants.hpp attached to your
last posting is an updated version of the same file in the
math_constants3.zip at groups.yahoo.com.
[snip]
> > > Attached is an example using Michael Kenniston's Kunning Function
> > constants.
> > >
> > > Briefly
> > >
> > > template
> > > T circle_area(const T& radius)
> > > {
> > > // Usage example: circle_area( 2.) // Explicit type double.
> > > // or circle_area(2.F) // Implicit type float.
> > > return boost::math::constant< T, boost::math::pi_tag >() * radius *
> > radius;
> > > }
[snip]
I've again tried to compile this with GCC 3.2.1. Here are the diagnostics:
In file included from test_circle_area.cpp:12:
function_constants.hpp:83: uninitialized const `
boost::math::float_constants::pi'
function_constants.hpp:87: uninitialized const `
boost::math::double_constants::pi'
function_constants.hpp:91: uninitialized const `
boost::math::long_double_constants::pi'
function_constants.hpp:122: uninitialized const `
boost::math::float_constants::sqrt2'
function_constants.hpp:126: uninitialized const `
boost::math::double_constants::sqrt2'
function_constants.hpp:130: uninitialized const `
boost::math::long_double_constants::sqrt2'
function_constants.hpp:150: uninitialized const `
boost::math::float_constants::e'
function_constants.hpp:154: uninitialized const `
boost::math::double_constants::e'
function_constants.hpp:158: uninitialized const `
boost::math::long_double_constants::e'
test_circle_area.cpp: In function `int main()':
test_circle_area.cpp:34: `__TIMESTAMP__' undeclared (first use this
function)
test_circle_area.cpp:34: (Each undeclared identifier is reported only once
for
each function it appears in.)
The following workaround (applied to all constants) heals this
namespace float_constants
{
#ifndef __GNUC__
constant< float, pi_tag > const pi;
#else
constant< float, pi_tag > const pi = constant< float, pi_tag >();
#endif
}
The preprocessor symbol __TIMESTAMP__ seems to be platform specific.
> > > It compiles with MSVC 7.0 (but not 6 - see MK's original example for
why
> > not).
> > > (long double == double for MSVC, so long double not fully
> > testable/useful).
> > >
> > > It seems to do the trick, without too many surprises. I have
displayed
> > the
> > > output using the 17 significant digits for double so one can see the
> > difference
> > > between a float pi 3.1415927410125732 and a double pi
3.1415926535897931
> > (even
> > > though only 9 are really significant for float).
> > >
> > > cout << "circle_area(1.) = " << circle_area(1.) <<
endl; //
> > > Explicit type float.
> > > cout << "circle_area(1.) = " << circle_area(1.) <<
endl;
> > //
> > > Explicit type double.
> > > cout << "circle_area(1.F) = " << circle_area(1.F) << endl; //
Implicit
> > type
> > > float.
> > > cout << "circle_area(1.) = " << circle_area(1.) << endl; // Implicit
type
> > > double.
> > > cout << "circle_area(1.L) = " << circle_area(1.L) << endl; //
implicit
> > type
> > > long double.
> > > cout << "circle_area(1.F) = " << circle_area(1.F) <<
> > endl; //
> > > Explicit over-rides implicit.
> > >
> > > And silly types like int fail helpfully.
> > > // cout << "circle_area(1) = " << circle_area(1)<< endl; //
Implicit
> > int -
> > > does not link!
> > > // cout << "circle_area(1.) = " << circle_area(1.)<<
endl; //
> > > Explicit int - does not compile!
> > >
> > > Output is
> > >
> > > Test test_circle_area.cpp Thu Jan 23 00:06:28 2003
> > > float pi = 3.14159274
> > > double pi = 3.1415926535897931
> > > float pi = 3.1415927410125732
> > > circle_area(1.) = 3.1415927410125732
> > > circle_area(1.) = 3.1415926535897931
> > > circle_area(1.F) = 3.1415927410125732
> > > circle_area(1.) = 3.1415926535897931
> > > circle_area(1.L) = 3.1415926535897931
> > > circle_area(1.F) = 3.1415926535897931
> > > circle_area(1.) = 3.1415926535897931
> > > circle_area(2.) = 12.566370964050293
> > > circle_area(2.) = 12.566370614359172
> > > circle_area(2.F) = 12.566370964050293
> > > circle_area(2.) = 12.566370614359172
> > > circle_area(2.L) = 12.566370614359172
> > > circle_area(2.F) = 12.566370614359172
> > > boost::math::constant< float, boost::math::pi_tag >()
3.1415927410125732
> > >
> > > I haven't looked at any assembler to check on efficiency, but
believe/hope
> > from
> > > previous examples that it will be optimal if inlined.
> > >
> > > Does this look sensible/useful?
> >
> > Only if I learn to see the relation to your latest upload (which I'm
> > assuming your review request is related to).
Ok, back to my earlier question. If I understand you correctly, we better
should write
return boost::math::constant< T, boost::math::pi_tag >() * radius * radius;
instead of something like
return boost::math::
Re: [boost] RE: math constant - generic function circle_area example.
Hi Paul,
you wrote:
> > I've been looking into an earlier version of the proposed math constants
> > before and asked myself how to implement a generic function like
> >
> > template
> > T circle_area (const T &radius) {
> > return math_constants::pi * radius * radius;
> > }
> >
> > How should this be done?
> >
> > Thanks,
> >
> > Joerg
>
> Attached is an example using Michael Kenniston's Kunning Function
constants.
>
> Briefly
>
> template
> T circle_area(const T& radius)
> {
> // Usage example: circle_area( 2.) // Explicit type double.
> // or circle_area(2.F) // Implicit type float.
> return boost::math::constant< T, boost::math::pi_tag >() * radius *
radius;
> }
OK. I've tried to compile this with GCC 3.2.1 and after applying some
remedies like
#ifdef LATER
// Define constant is namespaces to hold three builtin floating-point
representations.
namespace float_constants
{
constant< float, pi_tag > const pi;
}
namespace double_constants
{
constant< double, pi_tag > const pi;
}
namespace long_double_constants
{
constant< long double, pi_tag > const pi;
}
#endif
it compiled and executed giving the expected results. How is this solution
related to your latest (Dec. 12) upload at groups.yahoo.com/group/boost?
> It compiles with MSVC 7.0 (but not 6 - see MK's original example for why
not).
> (long double == double for MSVC, so long double not fully
testable/useful).
>
> It seems to do the trick, without too many surprises. I have displayed
the
> output using the 17 significant digits for double so one can see the
difference
> between a float pi 3.1415927410125732 and a double pi 3.1415926535897931
(even
> though only 9 are really significant for float).
>
> cout << "circle_area(1.) = " << circle_area(1.) << endl; //
> Explicit type float.
> cout << "circle_area(1.) = " << circle_area(1.) << endl;
//
> Explicit type double.
> cout << "circle_area(1.F) = " << circle_area(1.F) << endl; // Implicit
type
> float.
> cout << "circle_area(1.) = " << circle_area(1.) << endl; // Implicit type
> double.
> cout << "circle_area(1.L) = " << circle_area(1.L) << endl; // implicit
type
> long double.
> cout << "circle_area(1.F) = " << circle_area(1.F) <<
endl; //
> Explicit over-rides implicit.
>
> And silly types like int fail helpfully.
> // cout << "circle_area(1) = " << circle_area(1)<< endl; // Implicit
int -
> does not link!
> // cout << "circle_area(1.) = " << circle_area(1.)<< endl; //
> Explicit int - does not compile!
>
> Output is
>
> Test test_circle_area.cpp Thu Jan 23 00:06:28 2003
> float pi = 3.14159274
> double pi = 3.1415926535897931
> float pi = 3.1415927410125732
> circle_area(1.) = 3.1415927410125732
> circle_area(1.) = 3.1415926535897931
> circle_area(1.F) = 3.1415927410125732
> circle_area(1.) = 3.1415926535897931
> circle_area(1.L) = 3.1415926535897931
> circle_area(1.F) = 3.1415926535897931
> circle_area(1.) = 3.1415926535897931
> circle_area(2.) = 12.566370964050293
> circle_area(2.) = 12.566370614359172
> circle_area(2.F) = 12.566370964050293
> circle_area(2.) = 12.566370614359172
> circle_area(2.L) = 12.566370614359172
> circle_area(2.F) = 12.566370614359172
> boost::math::constant< float, boost::math::pi_tag >() 3.1415927410125732
>
> I haven't looked at any assembler to check on efficiency, but believe/hope
from
> previous examples that it will be optimal if inlined.
>
> Does this look sensible/useful?
Only if I learn to see the relation to your latest upload (which I'm
assuming your review request is related to).
Best,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ublas CVS commit
Hi all, I've just committed my current ublas version to Boost CVS. Many thanks this time namely to John Maddock for his Borland related fixes (really a big patch) and to Alexei Novakov for his sparse matrix related work. Best, Joerg P.S.: I had to touch status/Jamfile once again. I've hopefully destroyed nothing ;-( ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
math constant formal review request (was: [boost] Interval librarymerge)
- Original Message -
From: "Paul A. Bristow" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, January 21, 2003 11:23 AM
Subject: RE: [boost] Interval library merge
> I agree with this - intervals seem more numeric to me - though where that
leaves
> constants (especially interval constants) I am less clear.
>
> Paul
>
> PS I think it is time to have another Formal Review of Math Constants.
Please
> can the Review Wizard schedule this?
[snip]
I've been looking into an earlier version of the proposed math constants
before and asked myself how to implement a generic function like
template
T circle_area (const T &radius) {
return math_constants::pi * radius * radius;
}
How should this be done?
Thanks,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ublas int*vector != double*vector?
- Original Message -
From: "Julius Muschaweck" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 14, 2003 10:15 AM
Subject: [boost] ublas int*vector != double*vector?
> Hi,
>
> this is my first posting, so please give me guidance if this is going into
> the wrong direction.
>
> I'm using ublas (with Visual Studio .NET) , and I like it a lot.
> However, in scalar * vector operations, ublas doesn't handle implicit
int -
> double conversions like the compiler, which resulted in a hard to trace
bug
> for me:
>
> using namespace boost::numeric::ublas;
> vector v(3);
> v[0] = 1.1;
> v[1] = 2.2;
> v[2] = 3.7;
> vector v2;
> v2 = 2.0 * v; // double times vector
> std::cout << v2 << std::endl;
> v2 = 2 * v; // integer times vector
> std::cout << v2 << std::endl; //oops
> std::cout << 2*3.7 << ' ' << 2.0 * 3.7 << std::endl;
>
> produces
>
> (2.2,4.4,7.4)
> (2.,4.,7.)
> 7.4 7.4
>
> What seems to happen is that ublas first rounds the doubles in v to ints,
> performs integer multiplication and then converts the result back to
> double, whereas the compiler converts an int to double and then performs
> floating point multiplication.
Exactly. Kresimir Fresl noticed this bug recently and my current version
contains the following fix in traits.hpp already:
template
struct promote_traits {
// Default promotion will badly fail, if the types are different.
// Thanks to Kresimir Fresl for spotting this.
BOOST_STATIC_ASSERT ((boost::is_same::value));
typedef T1 promote_type;
};
I couldn't check the Boost CVS version, because Sourceforge seems to have
problems.
> It's maybe not good style to rely on implicit conversions like this, but
> I'm surely not the only one.
>
> My opinion is that ublas should do int*vector like the compiler
> does int*double, or am I missing a reason why this is intended?
Yes, it is one of the options to extend promote_traits to cover integral
types, too.
Thanks for your feedback (and sorry for the inconvenience),
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, December 05, 2002 9:38 PM Subject: Re: [boost] [Config] Testing instructions for compiler vendors > [EMAIL PROTECTED] (Joerg Walter) writes: > > >> > >> 1. Should we do something to make this easier for them? > > > > No. We should focus on serving our users. > > Our users will be happy and our lives will be easier if their > compilers finally start working. Didn't they have enough time and resources to work this out 'til now? Best regards Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Config] Testing instructions for compiler vendors
- Original Message - From: "David Abrahams" <[EMAIL PROTECTED]> To: "boost" <[EMAIL PROTECTED]> Sent: Wednesday, December 04, 2002 9:27 PM Subject: [boost] [Config] Testing instructions for compiler vendors > > Hi, > > I'm trying to come up with instructions for compiler vendors who want > to use Boost to test their compilers. What preprocessor symbols do > they need to define? So far, it looks like: > > - BOOST_NO_COMPILER_CONFIG > - BOOST_NO_STDLIB_CONFIG - if they want to check the library > - BOOST_STRICT_CONFIG - to disable some checks in source code > - macros for any known-not-implemented features, >e.g. BOOST_NO_TEMPLATE_TEMPLATES. > > Right? > > Questions: > > 1. Should we do something to make this easier for them? No. We should focus on serving our users. > 2. What about all the places we make compiler-specific checks in >Boost code? Could we define some macros which make it easier >and less error-prone to write these, and which can be globally >turned off when needed? > > # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540) > ... > #else > ... > #endif I'm sometimes not even able to decide who is wrong ;-( Best regards Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] UBLAS: preserving matrix resize.
- Original Message - From: "Stas Fomin" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Tuesday, December 03, 2002 12:16 PM Subject: Re: [boost] UBLAS: preserving matrix resize. > > > This sample works if "typedef ublas::matrix Mat;" > > > and does not work with "typedef > > ublas::sparse_matrix Mat"; > > > > I understand. This is probably a bug in the 1_29_0 release: I've just tested > > that change against the CVS version and see the same results as in the dense > > case. After one more thought: this is an artificial restriction in the 1_29_0 release. Thanks to Michael Stevens for resolving it. > Yes. I just upgrade to CVS version, > and this sample works (compiled GCC 3.1 and MSVC 6.0). Please be especially careful regarding the MSVC 6.0 code pathes. I'm mainly developing with GCC and Intel under Linux now and 6.0 is way to broken ;-) > >>Which compiler are you using? > GCC 3.1 under Cygwin and MSVC 6.0. > > > > Sorry for inconvenience. If you upgrade to the CVS version, you may also > > consider to use the new coordinate_matrix implementing Fortran COO storage > > layout. > Thanks, I would try it. > > > > > I write reading matrices from files in some sparsed formats > > (MatrixMarket, MPS). > > > I will implement one-pass reading, so the number of rows, columns and > > nonzeros > > > are not known in advance. > > > > I've just rechecked MatrixMarket format and they usually provide rows, > > column and nonzeros in a header record?! > Yes, there are no such problems with MatrixMarket, but with "MPS Stream Format" > (a de facto standard for mathematical programming software). > > > I'd like to invite you to the recently founded ublas-dev mailing list, if > > you'd be interested. There we could discuss such usage and maybe development > > related question. > I glad to be invited. > How to subscribe? Here's the link: groups.yahoo.com/groups/ublas-dev Regards Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] UBLAS: preserving matrix resize.
- Original Message - From: "Stas Fomin" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Monday, December 02, 2002 9:31 PM Subject: Re: [boost] UBLAS: preserving matrix resize. > Thanks for the answer! > > > > I have to make matrix resize with preserving of the content of the matrix. > > > (add rows, columns...) > > > > I've just tested the following program under GCC 3.1: > > > > -- > > #include > > > > > typedef ublas::matrix Mat; > > This sample works if "typedef ublas::matrix Mat;" > and does not work with "typedef ublas::sparse_matrix Mat"; I understand. This is probably a bug in the 1_29_0 release: I've just tested that change against the CVS version and see the same results as in the dense case. > > > 2. How to do "preserving matrix resize" efficiently? > > > > I.e. without copying/swapping? Why don't you start with your final matrix > > referencing the smaller sub matrices via matrix_range<>? > > This isn't clear to me. What do you mean? > > I write reading matrices from files in some sparsed formats (MatrixMarket, MPS). > I will implement one-pass reading, so the number of rows, columns and nonzeros > are not known in advance. > I use "sparse_matrix" for fast random access, > and I will to know how implement "preserving matrix resize" efficiently. > The only way I found does not work :(. Sorry for inconvenience. If you upgrade to the CVS version, you may also consider to use the new coordinate_matrix implementing Fortran COO storage layout. > Also I plan to use uBLAS in some linear programming algorithms, > so adding/deleting rows/columns in sparse matrices will be very desirable... Regards Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] UBLAS: preserving matrix resize.
- Original Message -
From: "Stas Fomin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 30, 2002 6:57 PM
Subject: [boost] UBLAS: preserving matrix resize.
> I have to make matrix resize with preserving of the content of the matrix.
> (add rows, columns...)
>
>
> I try to do this using matrix ranges:
[snip sample]
> Questions:
> 1. Why this do not work? (see examples from
> http://lists.boost.org/MailArchives/boost/msg31729.php)
I've just tested the following program under GCC 3.1:
--
#include
#include
#include
namespace ublas = boost::numeric::ublas;
typedef ublas::matrix Mat;
int main() {
Mat A(2,2);
A(0,0)=11;
A(0,1)=12;
A(1,0)=21;
A(1,1)=22;
Mat _A(4,4);
_A.project(ublas::range(0,A.size1()),
ublas::range(0,A.size2())).assign(A);
/* or ublas::project(_A, ublas::range(0,A.size1()),
ublas::range(0,A.size2(.assign(A); */
std::cout << A << std::endl;
std::cout << _A << std::endl;
A.swap(_A);
std::cout << A << std::endl;
std::cout << _A << std::endl;
Mat B(2,2);
B(0,0)=11;
B(0,1)=12;
B(1,0)=21;
B(1,1)=22;
Mat _B(4,4);
ublas::matrix_range _Br(_B, ublas::range(0,B.size1()),
ublas::range(0,B.size2()));
_Br.assign(B);
std::cout << B << std::endl;
std::cout << _B << std::endl;
B.swap(_B);
std::cout << B << std::endl;
std::cout << _B << std::endl;
return 0;
}
--
Output as I'd expect:
--
[2,2]((11,12),(21,22))
[4,4]((11,12,0,0),(21,22,0,0),(0,0,0,0),(0,0,0,0))
[4,4]((11,12,0,0),(21,22,0,0),(0,0,0,0),(0,0,0,0))
[2,2]((11,12),(21,22))
[2,2]((11,12),(21,22))
[4,4]((11,12,0,0),(21,22,0,0),(0,0,0,0),(0,0,0,0))
[4,4]((11,12,0,0),(21,22,0,0),(0,0,0,0),(0,0,0,0))
[2,2]((11,12),(21,22))
--
I have to admit that I've checked against the current CVS version only.
We've recently fixed some temporary lifetime issues w.r.t. project()
functions. If these cause your problem and you can't afford to upgrade to
the CVS version, maybe the second implementation in the test program can
help.
> 2. How to do "preserving matrix resize" efficiently?
I.e. without copying/swapping? Why don't you start with your final matrix
referencing the smaller sub matrices via matrix_range<>?
Regards
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ublas regression test problems
- Original Message - From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]> To: "'Boost mailing list'" <[EMAIL PROTECTED]> Sent: Thursday, November 21, 2002 9:57 AM Subject: RE: [boost] ublas regression test problems > Joerg Walter wrote: > > OK. The mpl::if_ problem vanished, the remaining problems with VC7 are > > home-grown (I'll look into these later). But now all ublas > > GCC tests fail to compile due to > > > > In file included from C:/boost/site/boost/type_traits.hpp:43, > > from C:/boost/site/boost/numeric/ublas/config.hpp:24, > > from > > C:/boost/site/libs/numeric/ublas/concepts.cpp:12: > > C:/boost/site/boost/type_traits/is_polymorphic.hpp:20: > > warning: `typename > >boost::remove_cv::type' is implicitly a typename > > C:/boost/site/boost/type_traits/is_polymorphic.hpp:20: > > warning: implicit > >typename is deprecated, please see the documentation for details > > C:/boost/site/boost/type_traits/is_polymorphic.hpp:28: > > duplicate base type ` > >boost::remove_cv::type' invalid > > > > I'm lost again. > > A missing 'typename', fixed in the CVS. Thanks. > On an aside note, including individual type traits headers you need (e.g. > "boost/type_traits/add_reference.hpp") instead of monolithic > "boost/type_traits.hpp" would reduce chances for the library to be broken > down on the events like this. Fixed in my local copy. Best regards Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ublas regression test problems
- Original Message - From: "Beman Dawes" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]>; "'Boost mailing list'" <[EMAIL PROTECTED]> Sent: Wednesday, November 20, 2002 9:41 PM Subject: RE: [boost] ublas regression test problems > At 06:35 AM 11/20/2002, Aleksey Gurtovoy wrote: > > > >> because ublas doesn't depend from mpl. So I've to assume, > >> that somebody is changing either boost.config, boost.type_traits, > >> boost.smart_ptr or boost.timer. > > > >Hmm, compiles fine for me on the clean CVS get (ignoring "test31/32.cpp" > >errors, see the attached log). Are you sure you are in sync with the main > >trunk? > > I've just cleared off all old Win32 test bin directories, in case testing > artifacts are causing those failures. Running the tests now, but they take > several hours when starting from scratch, so it will be awhile before they > are posted. OK. The mpl::if_ problem vanished, the remaining problems with VC7 are home-grown (I'll look into these later). But now all ublas GCC tests fail to compile due to In file included from C:/boost/site/boost/type_traits.hpp:43, from C:/boost/site/boost/numeric/ublas/config.hpp:24, from C:/boost/site/libs/numeric/ublas/concepts.cpp:12: C:/boost/site/boost/type_traits/is_polymorphic.hpp:20: warning: `typename boost::remove_cv::type' is implicitly a typename C:/boost/site/boost/type_traits/is_polymorphic.hpp:20: warning: implicit typename is deprecated, please see the documentation for details C:/boost/site/boost/type_traits/is_polymorphic.hpp:28: duplicate base type ` boost::remove_cv::type' invalid I'm lost again. Thanks Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ublas regression test problems
Hi all, I've recently committed a couple of bugfixes, extensions and compatibility hacks. The last regression tests seem to be OK for Linux, but some tests under Windows fail to compile. I'm especially concerned about VC7 failures with the diagnostic concepts.cpp C:\boost\site\boost\mpl\if.hpp(158) : error C2976: 'boost::mpl::if_' : too few template arguments C:\boost\site\boost\mpl\if.hpp(102) : see declaration of 'boost::mpl::if_' C:\boost\site\boost\mpl\if.hpp(158) : error C2504: '' : base class undefined because ublas doesn't depend from mpl. So I've to assume, that somebody is changing either boost.config, boost.type_traits, boost.smart_ptr or boost.timer. Thanks in advance Joerg P.S.: Why aren't there any regression tests for mpl? P.P.S.: Thanks very much for the regular regression tests! These are an invaluable tool, especially if one isn't able to test on all supported platforms. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Restricted pointers/references in uBlas ?
- Original Message - From: "Alaeddin A. Aydiner" <[EMAIL PROTECTED]> To: "Boost Lists" <[EMAIL PROTECTED]> Sent: Saturday, November 09, 2002 4:45 AM Subject: [boost] Restricted pointers/references in uBlas ? > I have browsed the uBlas source code, and I wonder why the alias > assumptions that lead to relatively bad uBlas performance How did you compare performance? > are not > alleviated by the various restrict keywords compilers have. GCC e.g. > accepts __restrict or __restrict__, and it seems one can easily use a > macro defined appropriately for each compiler. Yes, this could be a useful enhancement w.r.t. performance. Best regards Joerg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
