- Boost - lists.boost.org

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

17 May '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Gerhard Wesp > Sent: Wednesday, May 17, 2006 9:40 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] BigInt divide-by-zero handling > > On Wed, May 17, 2006 at 09:22:58AM -0700, Sohail Somani wrote: > > Do an assertion in debug mode, U.B. in release. This is > most sensible > > for a type that is an extension of a built-in type. > > Seems OK also. I just happen to think that whereever > behaviour *can* be > defined, it should (and do it as the ints whereever it is defined what > they do!). There's already too much U.B. in C++. > > A division by zero exception in an arbitrary size integer > package would > not incur any measurable overhead, I think. Heres another possible justification: template<typename IntType> T make_T(IntType a) { ... ..b/a.. } This function behaves differently for IntType=int or IntType=BigInt.

1 0

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

17 May '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Gerhard Wesp > Sent: Wednesday, May 17, 2006 2:29 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] BigInt divide-by-zero handling > > > Since ordinary ints just throw an exception, and my goal > is to make > > I don't think ordinary ints throw exceptions. Nevertheless, > I think you > should. I disagree. I check for divide by zero or write code that doesn't allow them to happen. If I wanted an exception for any possible operation, I'd use java (I'm not flaming - I think). Do an assertion in debug mode, U.B. in release. This is most sensible for a type that is an extension of a built-in type.

2 1

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

17 May '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Gerhard Wesp > Sent: Wednesday, May 17, 2006 2:39 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] BigInt divide-by-zero handling > > On Tue, May 16, 2006 at 04:48:37PM -0700, Sohail Somani wrote: > > Further to my other email, maybe it makes sense to force > integer divide > > by zero. i.e.: > > No. You're invoking undefined behaviour. If you want to do as the ints do...

1 0

Stream input and output of NaN and infinity
by Paul A Bristow 17 May '06

17 May '06

Jeff Garland proposed a solution the problem of serialization of NaN and infinity which had beed discussed http://article.gmane.org/gmane.comp.lib.boost.devel/141006/match=langer+nan Although this is probably the right expendient solution which could be done now (if anyone has the time and skill - SoC?), I also feel this is a general problem that needs a Standard solution (some impect on lexical_cast) so I have drafted a proposal for TR2 which is attached for comment. Briefly, it is a KISS solution. All infinities are output (and input) as one string like "Inf", And all the various NaNs are also a single string "NaN", And on input you get the numeric_limits<FPtype>::quiet_NaN() or infinity(), Is the same for ALL FP types (including UDTs) and layouts. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS

10 38

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

17 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? Further to my other email, maybe it makes sense to force integer divide by zero. i.e.: In some operator for BigInt: if(divide_by_zero) { int a =5; int b =0; int c=a/b; }

3 2

BigInt divide-by-zero handling
by Jonathan Ray 17 May '06

17 May '06

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? Cheers, Jonathan Ray

4 3

IMPORTANT: CVS Root Change
by David Abrahams 17 May '06

17 May '06

When SourceForge repaired CVS most recently, they also changed the server names. Yes, this also happened in 2004: in 2004: cvs.<project>.(sourceforge|sf).net -> cvs.(sourceforge|sf).net in 2006: cvs.(sourceforge|sf).net -> <project>.cvs.(sourceforge|sf).net If you have Unix tools available, the following at the root of your working copy will reset the server identity: find /projects/boost-cvs -name Root -exec sed -i -e \ s/cvs[.]s.*[.]net/boost.cvs.sourceforge.net/ \{} \; and this is the formula for the sandbox find /projects/boost-cvs -name Root -exec sed -i -e \ s/cvs[.]s.*[.]net/boost-sandbox.cvs.sourceforge.net/ \{} \; -- Dave Abrahams Boost Consulting www.boost-consulting.com

7 15

[Boost-bugs] [ boost-Patches-1489359 ] [config] evc4 port
by SourceForge.net 17 May '06

17 May '06

Patches item #1489359, was opened at 2006-05-16 09:38 Message generated for change (Comment added) made by vividos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489359&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: [config] evc4 port Initial Comment: This patch is a port for evc3/4 targeting Windows CE. Reason for the changes in auto_link.hpp: STLport with evc4 cannot be compiled in _STLP_DEBUG mode; the compiler issues wrong ARM code and _STLP_DEBUG mode cannot be used with evc4 ARM. I also introduced a new file wince.hpp in boost/config/platform/, since the defines in the _WIN32_WCE part got too big. ---------------------------------------------------------------------- >Comment By: Michael Fink (vividos) Date: 2006-05-17 15:22 Message: Logged In: YES user_id=124874 The only change I made is to rename "evc8" to "msvc8-arm", but since I don't know exactly how to differentiate processors in msvc8 I simply put "msvc8-arm". A possible msvc8 porter has to decide that. I updated the patch since I found another issue: there's no static C runtime for Windows CE, so autolinking always chooses "-gdp" now. Please disregard the first patch. ---------------------------------------------------------------------- Comment By: John Maddock (johnmaddock) Date: 2006-05-17 11:51 Message: Logged In: YES user_id=14804 I notice that the patches are arm-specific, surely VC8 can be used to target other processors? John. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489359&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-1489359 ] [config] evc4 port
by SourceForge.net 17 May '06

17 May '06

Patches item #1489359, was opened at 2006-05-16 07:38 Message generated for change (Comment added) made by johnmaddock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489359&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: [config] evc4 port Initial Comment: This patch is a port for evc3/4 targeting Windows CE. Reason for the changes in auto_link.hpp: STLport with evc4 cannot be compiled in _STLP_DEBUG mode; the compiler issues wrong ARM code and _STLP_DEBUG mode cannot be used with evc4 ARM. I also introduced a new file wince.hpp in boost/config/platform/, since the defines in the _WIN32_WCE part got too big. ---------------------------------------------------------------------- >Comment By: John Maddock (johnmaddock) Date: 2006-05-17 09:51 Message: Logged In: YES user_id=14804 I notice that the patches are arm-specific, surely VC8 can be used to target other processors? John. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489359&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 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