- Boost - lists.boost.org

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

17 May '06

Robert Ramey: > My basis for citing this is page 122 of "The C++ Progamming Language" > by Stroustrup, copyright 2000, reprinted May 2003 with corrections. > It says, "In particular, underflow, overflow and division by zero do > not > throw standard exceptions". If that's wrong, incomplete or out > of date, I would be curious to know about it. It seems to comport > with my personal experience with C++ numeric operations. Feel free > to expand upon this. C++PL is not the standard. A conforming implementation could throw a standard exception on divide-by-zero (although I don't think any actually do). > > The kind of situation I'm thinking of is more like the following. > I've got > a program which among its operations is a matrix inversion. The > program > correctly implements the chosen algorithm. Now I load a near-singular > matrix and invoke the matrix inversion operation. The sequence of > operatons results in over/under flows in some intermediate results. Nit: underflow usually results in zero, overflow in Inf. Neither of these are NaN. On the other hand, 0/0 and Inf/Inf _are_ NaN. > No exception > is thrown but some NaN's are propagated through the calculations. The > final result Matrix may or may not have one or many Nan's. So now I > have a result that is wrong but do not know it and have no way of > knowing > it. Given that NaNs are very persistant, if you generated NaNs in your intermediate calculations, then there will be NaNs in your inverted matrix. You can know it, by looking for those NaNs. Of course that won't work on implementations which don't support quiet NaNs (or don't generate them for eg 0/0), but if your implementation happens to be one which /does/, why would you care? > In FORTRAN this was never a problem as the program aborts at the > first overflow/underflow or whatever. Really? Can you point to the standard requirement for this. It may well be true for the implementation you were using, but I would be surprised if the standard required it (but I could be wrong). > What am I expected to do here? I could recode the matrix inversion to > check each intermediate result to see if its a NaN? I can't imagine > that's what I'm expected to do. How do people handle this now? Matrix inversion algorithms usually include checks for detecting singular matrices. -- 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-Patches-1489352 ] evc4 port: Interlocked*-functions without volatile
by SourceForge.net 17 May '06

17 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: 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: Michael Fink (vividos) Date: 2006-05-17 09:57 Message: Logged In: YES user_id=124874 I added a new version of the patch that avoids WINAPI (replaced by __cdecl, as used by the BOOST_MSVC part of the file. Including <windows.h> is not needed here, I think. In evc4 there are no intrinsics for the Interlocked-functions and the pragmas produce errors telling so. The _WIN32_WCE part of the file provides the BOOST_INTERLOCKED_ macros in its own section now. ---------------------------------------------------------------------- Comment By: Peter Dimov (pdimov) Date: 2006-05-16 12: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 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

[fusion][test bug?]in test/sequence/list_value_at.cpp
by Larry Evans 17 May '06

17 May '06

test/sequence/list_value_at.cpp looks like a copy of test/sequence/vector_value_at.cpp. Should the first few lines of list_value_at.cpp be: #include <boost/fusion/sequence/container/list/list.hpp> #define FUSION_SEQUENCE list instead of: #include <boost/fusion/sequence/container/vector/vector.hpp> #define FUSION_SEQUENCE vector ?

2 1

Re: [boost] BigInt divide-by-zero handling
by Sohail Somani 16 May '06

16 May '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Ray > Sent: Tuesday, May 16, 2006 3:11 PM > To: boost(a)lists.boost.org > Subject: [boost] BigInt divide-by-zero handling > > I'm planning to finish the BigInt library for SoC. I'm looking for > some input about whether divide-by-zero should throw an exception, or > just store a NaN and propagate that through any subsequent operations. > Since ordinary ints just throw an exception, and my goal is to make > BigInts have virtually the same interface as ints but never > overflow, it seems > reasonable to throw an exception. Any objections? Isn't it a hardware exception here? I don't think it's a C++ exception.

1 0

[review] Fusion review begins
by Ronald Garcia 16 May '06

16 May '06

The review of Joel de Guzman's Fusion library begins today, May 1, 2006, and continues through May 10, 2006. :Download: http://spirit.sourceforge.net/dl_more/fusion_v2.zip :Description: Fusion is a library of heterogenous containers and views and algorithms. A set of heterogenous containers (vector, list, set and map) is provided out of the box along with view classes that present various composable views over the data. The containers and views follow a common sequence concept with an underlying iterator concept that binds it all together, suitably making the algorithms fully generic over all sequence types. The architecture is somewhat modeled after MPL which in turn is modeled after STL. It is code-named "fusion" because the library is the "fusion" of compile time metaprogramming with runtime programming. Review questions ================ Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Cheers, Ron

15 93

[mpl][patch] std::pair compatiblity
by Tobias Schwinger 16 May '06

16 May '06

WHAT: ===== The patch changes the internal pair concept, so STL pairs and Fusion pairs also work as MPL pairs. STL pair: first (value) second (value) first_type (type) second_type (type) Fusion pair: second (value) first_type (type) second_type (type) MPL pair (CVS): first (type) second (type) MPL pair (after applying this patch): first_type (type) second_type (type) FILES: ====== - mpl.patch changes in boost/mpl (note: preprocessed files for mpl::map are not included to not flood the list) - test.patch changes in libs/mpl/test (some tests access the type members directly) diffed against: CVS HEAD TESTED WITH: ============ - MSVC 8.0 - MSVC 7.1 - GCC 3.4.2 Index: boost/mpl/pair.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/pair.hpp,v retrieving revision 1.5 diff -u -r1.5 pair.hpp --- boost/mpl/pair.hpp 14 Dec 2004 14:05:31 -0000 1.5 +++ boost/mpl/pair.hpp 15 May 2006 23:31:20 -0000 @@ -28,8 +28,8 @@ struct pair { typedef pair type; - typedef T1 first; - typedef T2 second; + typedef T1 first_type; + typedef T2 second_type; BOOST_MPL_AUX_LAMBDA_SUPPORT(2,pair,(T1,T2)) }; @@ -40,9 +40,9 @@ struct first { #if !defined(BOOST_MPL_CFG_MSVC_70_ETI_BUG) - typedef typename P::first type; + typedef typename P::first_type type; #else - typedef typename aux::msvc_eti_base<P>::first type; + typedef typename aux::msvc_eti_base<P>::first_type type; #endif BOOST_MPL_AUX_LAMBDA_SUPPORT(1,first,(P)) }; @@ -53,9 +53,9 @@ struct second { #if !defined(BOOST_MPL_CFG_MSVC_70_ETI_BUG) - typedef typename P::second type; + typedef typename P::second_type type; #else - typedef typename aux::msvc_eti_base<P>::second type; + typedef typename aux::msvc_eti_base<P>::second_type type; #endif BOOST_MPL_AUX_LAMBDA_SUPPORT(1,second,(P)) }; Index: boost/mpl/unique.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/unique.hpp,v retrieving revision 1.7 diff -u -r1.7 unique.hpp --- boost/mpl/unique.hpp 2 Sep 2004 15:40:42 -0000 1.7 +++ boost/mpl/unique.hpp 15 May 2006 23:45:40 -0000 @@ -36,8 +36,8 @@ { template< typename Pair, typename T > struct apply { - typedef typename Pair::first seq_; - typedef typename Pair::second prior_; + typedef typename Pair::first_type seq_; + typedef typename Pair::second_type prior_; typedef typename eval_if< and_< is_not_na<prior_>, apply2<Predicate,prior_,T> > , identity<seq_> Index: boost/mpl/aux_/apply_1st.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/aux_/apply_1st.hpp,v retrieving revision 1.4 diff -u -r1.4 apply_1st.hpp --- boost/mpl/aux_/apply_1st.hpp 2 Sep 2004 15:40:43 -0000 1.4 +++ boost/mpl/aux_/apply_1st.hpp 15 May 2006 23:37:58 -0000 @@ -22,8 +22,8 @@ { template< typename Pair, typename T > struct apply : apply2< - typename Pair::first - , typename Pair::second + typename Pair::first_type + , typename Pair::second_type , T > { Index: boost/mpl/aux_/partition_op.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/aux_/partition_op.hpp,v retrieving revision 1.4 diff -u -r1.4 partition_op.hpp --- boost/mpl/aux_/partition_op.hpp 28 Nov 2004 01:46:37 -0000 1.4 +++ boost/mpl/aux_/partition_op.hpp 15 May 2006 23:38:44 -0000 @@ -31,8 +31,8 @@ template< typename State, typename T > struct apply { - typedef typename State::first first_; - typedef typename State::second second_; + typedef typename State::first_type first_; + typedef typename State::second_type second_; typedef typename apply1< Pred,T >::type pred_; typedef typename eval_if< Index: boost/mpl/aux_/sort_impl.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/aux_/sort_impl.hpp,v retrieving revision 1.5 diff -u -r1.5 sort_impl.hpp --- boost/mpl/aux_/sort_impl.hpp 28 Nov 2004 01:47:44 -0000 1.5 +++ boost/mpl/aux_/sort_impl.hpp 15 May 2006 23:39:47 -0000 @@ -63,8 +63,8 @@ , back_inserter< vector<> > >::type partitioned; - typedef typename quick_sort< typename partitioned::first, Pred >::type part1; - typedef typename quick_sort< typename partitioned::second, Pred >::type part2; + typedef typename quick_sort< typename partitioned::first_type, Pred >::type part1; + typedef typename quick_sort< typename partitioned::second_type, Pred >::type part2; typedef joint_view< joint_view< part1, single_view< typename deref<pivot>::type > > Index: boost/mpl/map/aux_/contains_impl.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/map/aux_/contains_impl.hpp,v retrieving revision 1.2 diff -u -r1.2 contains_impl.hpp --- boost/mpl/map/aux_/contains_impl.hpp 2 Sep 2004 15:41:00 -0000 1.2 +++ boost/mpl/map/aux_/contains_impl.hpp 15 May 2006 23:40:57 -0000 @@ -30,9 +30,9 @@ : is_same< typename at_impl<aux::map_tag>::apply< Map - , typename Pair::first + , typename Pair::first_type >::type - , typename Pair::second + , typename Pair::second_type > { }; Index: boost/mpl/map/aux_/erase_impl.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/map/aux_/erase_impl.hpp,v retrieving revision 1.3 diff -u -r1.3 erase_impl.hpp --- boost/mpl/map/aux_/erase_impl.hpp 5 Sep 2004 09:42:58 -0000 1.3 +++ boost/mpl/map/aux_/erase_impl.hpp 15 May 2006 23:41:34 -0000 @@ -31,7 +31,7 @@ > struct apply : erase_key_impl<aux::map_tag> - ::apply<Map,typename Pos::type::first> + ::apply<Map,typename Pos::type::first_type> { }; }; Index: boost/mpl/map/aux_/insert_impl.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/map/aux_/insert_impl.hpp,v retrieving revision 1.4 diff -u -r1.4 insert_impl.hpp --- boost/mpl/map/aux_/insert_impl.hpp 14 Dec 2004 14:05:31 -0000 1.4 +++ boost/mpl/map/aux_/insert_impl.hpp 15 May 2006 23:42:00 -0000 @@ -33,15 +33,15 @@ , Map #if defined(BOOST_MPL_CFG_TYPEOF_BASED_SEQUENCES) , m_item< - typename Pair::first - , typename Pair::second + typename Pair::first_type + , typename Pair::second_type , Map > #else , m_item< next< typename Map::size >::type::value - , typename Pair::first - , typename Pair::second + , typename Pair::first_type + , typename Pair::second_type , Map > #endif Index: boost/mpl/map/aux_/numbered.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/map/aux_/numbered.hpp,v retrieving revision 1.4 diff -u -r1.4 numbered.hpp --- boost/mpl/map/aux_/numbered.hpp 14 Dec 2004 14:05:32 -0000 1.4 +++ boost/mpl/map/aux_/numbered.hpp 15 May 2006 23:42:50 -0000 @@ -39,8 +39,8 @@ > struct BOOST_PP_CAT(map,i_) : m_item< - typename BOOST_PP_CAT(P,BOOST_PP_DEC(i_))::first - , typename BOOST_PP_CAT(P,BOOST_PP_DEC(i_))::second + typename BOOST_PP_CAT(P,BOOST_PP_DEC(i_))::first_type + , typename BOOST_PP_CAT(P,BOOST_PP_DEC(i_))::second_type , AUX778076_MAP_TAIL(map,BOOST_PP_DEC(i_),P) > { @@ -93,8 +93,8 @@ struct BOOST_PP_CAT(map,i_) : m_item< i_ - , typename BOOST_PP_CAT(P,BOOST_PP_DEC(i_))::first - , typename BOOST_PP_CAT(P,BOOST_PP_DEC(i_))::second + , typename BOOST_PP_CAT(P,BOOST_PP_DEC(i_))::first_type + , typename BOOST_PP_CAT(P,BOOST_PP_DEC(i_))::second_type , AUX778076_MAP_TAIL(map,BOOST_PP_DEC(i_),P) > { ? libs/mpl/test/Jamfile_timestamp ? libs/mpl/test/results.7.1 ? libs/mpl/test/results.8.0 Index: libs/mpl/test/partition.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/mpl/test/partition.cpp,v retrieving revision 1.2 diff -u -r1.2 partition.cpp --- libs/mpl/test/partition.cpp 28 Nov 2004 03:35:12 -0000 1.2 +++ libs/mpl/test/partition.cpp 15 May 2006 23:56:24 -0000 @@ -37,6 +37,6 @@ , mpl::back_inserter< vector<> > >::type r; - MPL_ASSERT(( equal< r::first, vector_c<int,1,3,5,7,9> > )); - MPL_ASSERT(( equal< r::second, vector_c<int,0,2,4,6,8> > )); + MPL_ASSERT(( equal< r::first_type, vector_c<int,1,3,5,7,9> > )); + MPL_ASSERT(( equal< r::second_type, vector_c<int,0,2,4,6,8> > )); } Index: libs/mpl/test/stable_partition.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/mpl/test/stable_partition.cpp,v retrieving revision 1.3 diff -u -r1.3 stable_partition.cpp --- libs/mpl/test/stable_partition.cpp 2 Sep 2004 15:41:35 -0000 1.3 +++ libs/mpl/test/stable_partition.cpp 15 May 2006 23:56:54 -0000 @@ -31,8 +31,8 @@ , less< _, int_<3> > >::type result; - MPL_ASSERT(( equal< result::first,manual_first > )); - MPL_ASSERT(( equal< result::second,manual_second > )); + MPL_ASSERT(( equal< result::first_type,manual_first > )); + MPL_ASSERT(( equal< result::second_type,manual_second > )); } MPL_TEST_CASE() @@ -42,6 +42,6 @@ , greater_equal< _, int_<3> > >::type result; - MPL_ASSERT(( equal< result::first,manual_second > )); - MPL_ASSERT(( equal< result::second,manual_first > )); + MPL_ASSERT(( equal< result::first_type,manual_second > )); + MPL_ASSERT(( equal< result::second_type,manual_first > )); }

2 5

[Boost-bugs] [ boost-Patches-1489713 ] Adjusts mpl::pair concept to be compatible with STL pairs
by SourceForge.net 16 May '06

16 May '06

Patches item #1489713, was opened at 2006-05-16 19:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489713&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: Tobias Schwinger (t_schwinger) Assigned to: Nobody/Anonymous (nobody) Summary: Adjusts mpl::pair concept to be compatible with STL pairs Initial Comment: WHAT: ===== The patch changes the MPL pair concept, so STL pairs and Fusion pairs also work as MPL pairs. The old type members have been added after testing for backward compatiblity with 3rd party code. STL pair: first (value) second (value) first_type (type) second_type (type) Fusion pair: second (value) first_type (type) second_type (type) MPL pair (CVS): first (type) second (type) MPL pair (after applying this patch): first_type (type) second_type (type) AFFECTED LIBRARIES: =================== - MPL (numerous files, code and documentation) - Variant (2 files) - Parameter (1 file) FILES: ====== - boost/mpl.patch - boost/parameter.patch - boost/variant.patch - libs/mpl.patch TESTED WITH: ============ - MSVC 8.0 - MSVC 7.1 - GCC 3.4.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489713&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] 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