May 2006 - Boost - lists.preview.boost.org

Re: [boost] Stream input and output of NaN and infinity
by Martin Bonner 16 May '06

16 May '06

Robert Ramey wrote > Geoffrey Irving wrote: >> Arguing that 1/0 should crash because that's what happens in "math" >> is the same as arguing that 2*max_int should crash because that's >> what happens in math...unless you have modulo arithmetic. > > True - I would argue that as well Except that 2*max_int doesn't crash in mathematics. If we are talking about the integers then then depending on /exactly/ which set of integers we are talking about, either there isn't a value 'max_int', or it is positive infinity (and doubling it leaves it unchanged). If we are talking about modulo arithmetic, then doubling the largest possible integer is perfectly well defined - it's just that the result is smaller than the original value. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

Re: [boost] Stream input and output of NaN and infinity
by Martin Bonner 16 May '06

16 May '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 16 May 2006 03:43 To: boost(a)lists.boost.org Subject: Re: [boost] Stream input and output of NaN and infinity > Martin Bonner wrote: >> -----Original Message----- >> Robert Ramey wrote: >> >>> Peter Dimov wrote: >>> >>>> It depends. Where do you draw the line? Is inf a number? Is -0.0 a >>>> number? You have to have NaN if you want to be able to represent >>>> x/y as a float. >> >>> That's the problem. x/y is not a valid operation if y is equal to >>> 0. So >>> it can't be represented as a number. >> >>> The fact that C++ permits such an operation makes C++ different >>> than arithmetic. >> "different than SOME arithmetics". The arithmentic C++ (well, >> actually IEEE) defines is a perfectly sensible arithmetic. >> >>> The fact that C++ uses operators like "/" and defines them >>> similar to - but not identical to - the way they are defined by >>> standard arithmetic >> >> Granted. It isn't the standard arithmetic. >> >>> is the source of all these problems. >> What problems? (Apart from the extra work involved for authors of >> libraries like serialization I mean!) > > suppose that z = x * y generates a Nan or +Inf or whatever one some > machine for some x and y. Now z contains an undefined value which > is used on some other operations which presumably result in other > types of Nan's. This behavior has the following problems: > > a) it's undefined But MANY implementations define the behaviour, and define it in a way that is useful. > b) it varies from machine to machine. On some machines the hardware > will trap an abort the program as it won't throw a C++ exception. > Other machines will store some variety of Nan in the result Right. So if you need a maximally portable program you can't use NaN or +/-Inf. But many people /don't/ need a maximally portable program. > c) if it doesn't trap we're just massaging undefined values. > d) we're getting some useless result but don't know it untill maybe > later or many never. > > How can any "real program" find this useful? How can such a program > not be "broken". I suppose there might be some case where its OK > but they would have to be special in some way. I think what is special is that the authors would need to understand the issues. I used to work in transport modelling. We used to model different types of things (people, coal, food) travelling by different transport modes (bus, truck, boat) between different places. It makes perfect sense to talk about the cost of moving a ton of (eg) food between two places by boat being +infinity (it implies there is no boat route between the two places). It doesn't hurt the algorithm, because it will later assign the amount of food to be transported in proportion to exp(-cost) ... and hence it won't try and transport any food by boat. It might also makes sense to talk about the cost of moving a ton of coal between two places be NaN if there is no coal to move. >>> I say that C++ should be changed to so that the floats and operators >>> which apply to them should implement what people expect from >>> arithmetic operators. > >> Yes, but realistically that is never going to happen. > > LOL - it seems you're right there. But that is not my point here. > >> Wouldn't it be better to support the use-cases that people have in >> real code? > > well that's what we have to do. But it raises the issue of whether > its worth spending time to support programs that are most likely > broken in any case. You could EASILY extend that argument to say that you shouldn't support floating point. I would suggest that in the set of float-point programs that want to use serialization the proportion of non-broken programs will be HIGHER in the sub-set that want support for +/-Inf and NaN than in the sub-set that don't want that support. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

3 2

Re: [boost] Stream input and output of NaN and infinity
by Martin Bonner 16 May '06

16 May '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 16 May 2006 15:57 To: boost(a)lists.boost.org Subject: Re: [boost] Stream input and output of NaN and infinity > Martin Bonner wrote: >>>> Robert Ramey wrote: > >>> How can any "real program" find this useful? How can such a program >>> not be "broken". I suppose there might be some case where its OK >>> but they would have to be special in some way. >> >> I think what is special is that the authors would need to understand >> the issues. >> >> I used to work in transport modelling. We used to model different >> types of things (people, coal, food) travelling by different >> transport modes (bus, truck, boat) between different places. >> >> It makes perfect sense to talk about the cost of moving a ton of (eg) >> food between two places by boat being +infinity (it implies there is >> no boat route between the two places). It doesn't hurt the >> algorithm, because it will later assign the amount of food to be >> transported in proportion to exp(-cost) ... and hence it won't try >> and transport any food by boat. > > Ahhh - at last a short, concrete, believable scenario. > > so now we're evalating exp(-cost) where cost might be +Inf. How > do you know what the exp function does in such a case? Is it defined? > documented? etc. It certainly is documented for Microsoft Visual C++ 8.0. It so happens that MS have chosen to describe an argument of -inf when passed to exp as "invalid". Other platforms will make other choices, and probably document them. > I can't see how the result of such a program can > be trusted - even if one is not concerned about portability. How does > one check such a result? Is it just assumed to be right if it looks > reasonable? I don't know. Believe me, handling exceptional values when there is no route is the LEAST of the validation problems. >> It might also makes sense to talk about the cost of moving a ton of >> coal between two places be NaN if there is no coal to move. > > so our algorithm calculates the cost 0 tons of coal of moving from > point a to point b (for which there is no route) with the expression > exp(-Inf) * Nan and compares it > to other floating point numbers and branches accordingly. No. The algorithm detects that there is no movement of coal between the two places and says the average cost is NaN. If there /is/ movement, then it works out the cost of each possible transport method, and calculates the "average" cost as log( sum( exp(-cost) ) ). (The strange "average" is standard for this sort of modelling. It ensures that opening a new hyper-expensive route does not increase the average cost.) > It is the core of my concern that the current system permits and > encourages programs like this to be written. Which is a good thing. > Of course they might > work in some instances but I don't think that's a good argument > for doing things this way. I think that reflects your lack of experience of numerical modelling. >> You could EASILY extend that argument to say that you shouldn't >> support floating point. > > I don't see how I could do that. > >> I would suggest that in the set of >> float-point programs that want to use serialization the proportion of >> non-broken programs will be HIGHER in the sub-set that want support >> for +/-Inf and NaN than in the sub-set that don't want that support. > > That's where we disagree. Fair enough :-) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

[Boost-bugs] [ boost-Bugs-1489545 ] strange compiling problem for transitive_closure
by SourceForge.net 16 May '06

16 May '06

Bugs item #1489545, was opened at 2006-05-16 06:20 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=1489545&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: strange compiling problem for transitive_closure Initial Comment: Dears, I've found a strange compilation problem. By adding the following line to the file boost_1_33_1/libs/graph/example/transitive_closure.cpp #include <boost/graph/depth_first_search.hpp> before the inclusion of transitive_closure.hpp, the compilation broke. Please check the attached example. Best Regards, Fabrizio Ferrandi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1489545&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Review] Fusion
by Douglas Gregor 16 May '06

16 May '06

My review of the Fusion library follows, but I'll spoil the ending now: I vote to accept Fusion into Boost. I was very interested to look into this library. I've found heterogeneous sequences to be extremely interesting and, in some cases, precisely the right answer. I've had to write about 1/3 to 1/2 of the heterogeneous algorithms provided by Fusion at various times, time which could have been saved and code that could have been cleaner if Fusion was around. So, I'm quite familiar with heterogeneous containers and algorithms. I was not able to review the library in-depth, unfortunately, but I'm itching to get my fingers on it when time allows. So, what follows is really just a bunch of minor nits from reading the documentation. Overall: - I'm not a fan of naming libraries anything but what they do. "Fusion" makes sense when you understand the context, but nobody searching through the list of libraries will see "Fusion" and think "AHA! That's what I need". Alas, I don't have a name in mind. Description: - Spelling error: "hetrogenous" Introduction: - Parts of the introduction are a bit too colloquial for my taste, in particular, the paragraph. "Hmmm, kinda reminds us of STL right? Right! Can you imagine how it would be like if you used STL without the algorithms? Everyone will have to reinvent their own algorithm wheels." I'd rather see them written in a more direct manner. Not that I prefer boring, but at some point the whimsical writing trivializes the library. Top of the Iceberg: - In the [1] footnote, spelling error: "Orgainization" Support: tag_of: I believe I understand the usefulness of this trait, but only because I understand tag dispatching already. Could the description be expanded a little, to at least say that tags uniquely identify the kind of sequence or iterator, e.g., list, map, etc.? category_of: I'm not keen on using the same trait (category_of) for two different kinds of entities (sequences and iterators). Traits classes should be tied to a particular concept, so I'd much rather see separate "iterator_category" and "sequence_category" metafunctions. pair: I tripped over the name of this entity a bit. It's a little odd to have a "pair" with only one kind of data. I guess I'd feel better if this were called "keyed_value" or "key_value", because it's easier for me to copy with a typed key than it us for me to have a pair that's very different from std::pair. Iterators: distance: Is the return type of distance(i, j) "int" or "convertible to int"? I could imagine that in many cases it could be an integral_constant<int, N>... It looks like Joel and Dan did a great job. Cheers, Doug

4 8

[Boost-bugs] [ boost-Bugs-1489486 ] is_base_and_derived: no workaround needed fo SunPro CC 5.5
by SourceForge.net 16 May '06

16 May '06

Bugs item #1489486, was opened at 2006-05-16 04:38 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=1489486&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: type_traits Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: is_base_and_derived: no workaround needed fo SunPro CC 5.5 Initial Comment: boost/type_traits/is_base_and_derived.hpp, line 27 27 : && !BOOST_WORKAROUND(__SUNPRO_CC , BOOST_TESTED_AT(0x540)) \ probably should be changed to 27 : && !BOOST_WORKAROUND(__SUNPRO_CC , <= 0x540)) \ since with SunPro compiler v.5.5 it works fine (the exact compiler verion I checked is: Sun C++ 5.5 Patch 113817-09 2004/08/03) The broken is_base_and_derived version fails to detect private inheritance which in turn prevents from using such libraries as multi_index. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1489486&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1489352 ] evc4 port: Interlocked*-functions without volatile
by SourceForge.net 16 May '06

16 May '06

Patches item #1489352, was opened at 2006-05-16 10:20 Message generated for change (Comment added) made by pdimov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Fink (vividos) >Assigned to: Peter Dimov (pdimov) Summary: evc4 port: Interlocked*-functions without volatile Initial Comment: This patch fixes the definition of the Interlocked*-functions when using Windows CE (_WIN32_WCE is defined). The functions use the "old" (VC6 without platform SDK) forms of the functions without the volatile keyword. The patch can be applied to both CVS HEAD and the 1_34 branch, since the file wasn't modified since then. ---------------------------------------------------------------------- >Comment By: Peter Dimov (pdimov) Date: 2006-05-16 13:42 Message: Logged In: YES user_id=305912 The patch doesn't look correct to me. Using WINAPI would require inclusion of <windows.h>; in this case just defining BOOST_USE_WINDOWS_H would be a better approach. It also patches the intrinsic section without also declaring the functions as intrinsics; is this intended? Does evc4 have intrinsic support for these functions? If it doesn't, we need to disallow the intrinsic path for _WIN32_WCE and patch the WIN32 section instead. ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 2006-05-16 10:40 Message: Logged In: YES user_id=124874 Changed summary: it's only evc4 of course, since evc3 is too non-standard to support boost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [filesystem][program_options][serialization][test]fromcomp.lang.c++
by bwood 16 May '06

16 May '06

David Abrahams wrote: >bwood <brass(a)mailvault.com> writes: > >> David Abrahams wrote: >>>>"Le Chaud Lapin" <unoriginal_usern...(a)yahoo.com> writes: >>>>More than anything in programming, I depend on type to create form. >>>>Versioning implies that types are semi-weak. >>> >>> >>>If versioning in serialized form implies that, then so do revisions of >>>your type in a version control system. So, basically, once you design >>>a class, it never evolves? >>> >> >> Along the lines of what Lapin is thinking, I think B.Ser's "versioning" >> support is problematic. For example, consider wanting to move (or >> delete) a data member out of a type between versions 1.1 and 1.2. >> B.Ser needs that member to remain in the type in order to support 1.1. > >No, you just read it and throw it away. > > if (version == 11) > { > type_of_deleted_member ignored; > ar & ignored; > } Wait a minute. The code above looks like you may have focused on deleting a member and not relocating it. "ignored" isn't coming from anywhere else with a 1.1 client and it needs to be stored somewhere. Also if a 1.2 server is sending to a 1.1 client, it doesn't matter whether the member has been deleted or relocated, it still has to send the right thing back. Brian Wood www.webEbenezer.net

2 1

[Boost-bugs] [ boost-Bugs-1489362 ] USES_CONVERSION is used in once.cpp
by SourceForge.net 16 May '06

16 May '06

Bugs item #1489362, was opened at 2006-05-16 09:50 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=1489362&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Fink (vividos) Assigned to: Mike Glassford (glassfordm) Summary: USES_CONVERSION is used in once.cpp Initial Comment: The file libs/thread/src/once.cpp uses the ATL macros USES_CONVERSION and A2CW when the macro BOOST_NO_ANSI_APIS is defined (it's the case when compiling for Windows CE). This leads to compiler errors, since the needed header <atlconv.h> is not included anywhere. One possible fix would be to put the following in the file: #ifdef BOOST_NO_ANSI_APIS #include <atlbase.h> #include <atlconv.h> // for USES_CONVERSION and A2CW #endif (atlconv.h needs atlbase.h) Another possible fix would be to change the way to convert the string used in the call to CreateMutexW(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1489362&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1489352 ] evc4 port: Interlocked*-functions without volatile
by SourceForge.net 16 May '06

16 May '06

Patches item #1489352, was opened at 2006-05-16 09:20 Message generated for change (Comment added) made by vividos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Fink (vividos) Assigned to: Nobody/Anonymous (nobody) >Summary: evc4 port: Interlocked*-functions without volatile Initial Comment: This patch fixes the definition of the Interlocked*-functions when using Windows CE (_WIN32_WCE is defined). The functions use the "old" (VC6 without platform SDK) forms of the functions without the volatile keyword. The patch can be applied to both CVS HEAD and the 1_34 branch, since the file wasn't modified since then. ---------------------------------------------------------------------- >Comment By: Michael Fink (vividos) Date: 2006-05-16 09:40 Message: Logged In: YES user_id=124874 Changed summary: it's only evc4 of course, since evc3 is too non-standard to support boost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0