Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #47934 > unrolled thread

Best way to handle mathematical divide-by-zero case

Back to article view | Back to comp.lang.c++

Contents

  Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-11 18:17 +0000
    Re: Best way to handle mathematical divide-by-zero case "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2017-01-11 20:00 +0100
      Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-11 19:16 +0000
        Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-12 10:36 +0100
          Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 13:16 +0000
            Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-12 15:23 +0100
              Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 16:13 +0000
                Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-12 17:35 +0100
              Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 16:27 +0000
                Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-12 17:37 +0100
                  Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 16:44 +0000
                    Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 16:46 +0000
                    Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-13 12:06 +0100
                      Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-13 11:36 +0000
                        Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-13 13:12 +0100
                          Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-13 13:11 +0000
                            Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-13 15:23 +0100
                              Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-13 14:57 +0000
                              Re: Best way to handle mathematical divide-by-zero case "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 17:35 -0800
                      Re: Best way to handle mathematical divide-by-zero case Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 20:25 +0000
                        Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-14 18:08 +0100
                          Re: Best way to handle mathematical divide-by-zero case Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-14 20:30 +0000
                            Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-15 00:16 +0100
                              Re: Best way to handle mathematical divide-by-zero case Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-15 00:34 +0000
                              Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-15 01:01 +0000
                                Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-15 16:57 +0100
                                  Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-15 17:17 +0000
                                    Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-15 19:13 +0100
                  Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 16:48 +0000
                    Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 16:51 +0000
                Re: Best way to handle mathematical divide-by-zero case Manfred <mx2927@gmail.com> - 2017-02-06 01:08 +0100
                  Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-02-06 00:39 +0000
                    Re: Best way to handle mathematical divide-by-zero case Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2017-02-06 00:50 +0000
                    Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-02-06 02:01 +0100
                    Re: Best way to handle mathematical divide-by-zero case Manfred <noname@invalid.add> - 2017-02-06 13:56 +0100
                      Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-02-06 22:25 +0000
                        Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-02-06 22:26 +0000
                          Re: Best way to handle mathematical divide-by-zero case Robert Wessel <robertwessel2@yahoo.com> - 2017-02-06 16:46 -0600
                            Re: Best way to handle mathematical divide-by-zero case Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2017-02-06 23:49 +0000
                          Re: Best way to handle mathematical divide-by-zero case scott@slp53.sl.home (Scott Lurndal) - 2017-02-07 13:24 +0000
                        Re: Best way to handle mathematical divide-by-zero case Manfred <mx2927@gmail.com> - 2017-02-07 00:58 +0100
                          Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-02-07 00:43 +0000
                            Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-02-07 09:22 +0100
                              Re: Best way to handle mathematical divide-by-zero case Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-07 14:06 +0000
                                Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-02-07 15:58 +0100
                            Re: Best way to handle mathematical divide-by-zero case Öö Tiib <ootiib@hot.ee> - 2017-02-07 01:00 -0800
                            Re: Best way to handle mathematical divide-by-zero case Manfred <noname@invalid.add> - 2017-02-07 15:31 +0100
                        Re: Best way to handle mathematical divide-by-zero case scott@slp53.sl.home (Scott Lurndal) - 2017-02-07 13:22 +0000
          Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 13:20 +0000
            Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-12 15:28 +0100
              Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 15:40 +0000
                Re: Best way to handle mathematical divide-by-zero case David Brown <david.brown@hesbynett.no> - 2017-01-12 16:52 +0100
      Re: Best way to handle mathematical divide-by-zero case Wouter van Ooijen <wouter@voti.nl> - 2017-01-11 23:20 +0100
    Re: Best way to handle mathematical divide-by-zero case Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2017-01-11 21:43 +0000
      Re: Best way to handle mathematical divide-by-zero case Gareth Owen <gwowen@gmail.com> - 2017-01-12 19:12 +0000
    Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 00:07 +0000
    Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 00:12 +0000
    Re: Best way to handle mathematical divide-by-zero case Real Troll <real.troll@trolls.com> - 2017-01-12 12:55 -0400
      Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-12 16:53 +0000
    Re: Best way to handle mathematical divide-by-zero case Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2017-01-12 19:10 +0000
      Re: Best way to handle mathematical divide-by-zero case Gareth Owen <gwowen@gmail.com> - 2017-01-12 19:17 +0000
    Re: Best way to handle mathematical divide-by-zero case "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 15:34 -0800
      Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-14 00:14 +0000
        Re: Best way to handle mathematical divide-by-zero case "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 16:56 -0800
          Re: Best way to handle mathematical divide-by-zero case "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 17:46 -0800
          Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-14 01:51 +0000
            Re: Best way to handle mathematical divide-by-zero case "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-13 18:09 -0800
      Re: Best way to handle mathematical divide-by-zero case Gareth Owen <gwowen@gmail.com> - 2017-01-14 11:21 +0000
        Re: Best way to handle mathematical divide-by-zero case "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-14 12:45 -0800
          Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-01-14 21:02 +0000
            Re: Best way to handle mathematical divide-by-zero case "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-14 13:47 -0800
          Re: Best way to handle mathematical divide-by-zero case "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-14 13:03 -0800
    Re: Best way to handle mathematical divide-by-zero case "J. Clarke" <j.clarke.873638@gmail.com> - 2017-02-04 07:56 -0500
    Re: Best way to handle mathematical divide-by-zero case Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-02-05 10:21 +0000
      Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-02-05 13:33 +0000
        Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-02-06 07:33 +0000
      Re: Best way to handle mathematical divide-by-zero case JiiPee <no@notvalid.com> - 2017-02-05 13:34 +0000
        Re: Best way to handle mathematical divide-by-zero case Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-02-05 18:51 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#48606

On 02/06/2017 11:25 PM, JiiPee wrote:
> On 06/02/2017 12:56, Manfred wrote:
>> On 2/6/2017 1:39 AM, JiiPee wrote:
>>> On 06/02/2017 00:08, Manfred wrote:
>>>> I would indeed go for the exception.
>>>
>>>
>>> But Bjarne seems to be against exception in this kind of situation...
>>>
>> I don't recall when/where he may have said that, I would be curious;
>> could you be more specific if you like?
>
> http://stackoverflow.com/questions/6121623/catching-exception-divide-by-zero
>
>
> Stroustrup says, in "The Design and Evolution of C++" (Addison Wesley,
> 1994), "low-level events, such as arithmetic overflows and divide by
> zero, are assumed to be handled by a dedicated lower-level mechanism
> rather than by exceptions. This enables C++ to match the behaviour of
> other languages when it comes to arithmetic. It also avoids the problems
> that occur on heavily pipelined architectures where events such as
> divide by zero are asynchronous."`
>
Thanks for the quote.
I may have two comments about this:

1) Appearently Bjarne is referring here to exceptions thrown by the 
language itself (or the standard library), and he explains why they 
choose not to have the language throw a division-by-zero exception - in 
which the argument to match the behaviour of other languages (including 
C) is a strong one.
In the average example() I would explicitly throw an exception if the 
set is empty, I would not execute the division by zero, or anyway assume 
that the division itsels throws an exception.

2) In the general case of floating point arithmetic division by zero 
would have some real-valued denominator expression that can evaluate to 
zero or any value arbitrarily close to it. In the average() example the 
denominator is an integer value, and this is a relevant difference.

As I wrote earlier, when there is a real-valued denominator that can 
evaluate to zero or any value close to it, quite often (expecially when 
the expression models a physical process) if you happen to have the 
expression evaluate to 0/0 (which would yield a NaN) you can in fact 
refactor the expression so as to have a well defined form over your 
problem domain.
If you happen to get nonzero/0, you may either choose different 
variables, or rely on the processor or math library handling of +/-INF 
if this suits your problem.
This is to say that with real-valued floating point arithmetic, you have 
significant alternatives to handle (or prevent) division by zero before 
you treat it as an error condition. Obviously all of this must be 
studied in the specifics of the problem at hand.
In my experience division by zero is not the hardest part of floating 
point arithmetic. Actually much easier than its finite precision and 
rounding errors, which would result e.g. in DBL_EPSILON to be returned 
where a zero was expected. This can be much trickier.

[toc] | [prev] | [next] | [standalone]

#48607

On 06/02/2017 23:58, Manfred wrote:
> In the average example() I would explicitly throw an exception if the 
> set is empty, I would not execute the division by zero, or anyway 
> assume that the division itsels throws an exception. 


what if the average is calculated 10 million times per second? would you 
still ldo the check eatch time?

But isnt it this a similar issue to vectors v.at(2) against v[2]?

[toc] | [prev] | [next] | [standalone]

#48613

On 07/02/17 01:43, JiiPee wrote:
> On 06/02/2017 23:58, Manfred wrote:
>> In the average example() I would explicitly throw an exception if the
>> set is empty, I would not execute the division by zero, or anyway
>> assume that the division itsels throws an exception. 
> 
> 
> what if the average is calculated 10 million times per second? would you
> still ldo the check eatch time?
> 
> But isnt it this a similar issue to vectors v.at(2) against v[2]?
> 

Do you prefer correct code, or code that is a fraction of a percent
faster but wrong?

It is really quite simple, and I cannot understand why you are taking so
long to get the hang of it.

Let me give you the /one/ rule that actually matters:


* Do not divide by zero - it is a mistake in the code. *


OK?

Now you have that as a rule, you can decide the best way to be sure that
the rule is not broken.  That will depend on the circumstances - what
code you have, who is going to call the code, who might make the mistake
of threatening a division by zero, and what you can do about it.
Options include everything from ignoring it (because if some moron calls
your function with an empty set, it is /their/ fault - and you don't
want to slow down the code for competent users), returning fixed values,
throwing an exception, up to automatically sending out an email to the
developers with a deviation report.


The same applies to /all/ other undefined behaviour in the code (such as
accessing an array out of bounds) and all other kinds of errors.  Your
target is to avoid them happening.  If you think an error /might/
happen, then you find ways to detect the situation and deal with it as
best you can.

[toc] | [prev] | [next] | [standalone]

#48619

David Brown <david.brown@hesbynett.no> writes:

> On 07/02/17 01:43, JiiPee wrote:
<snip>
>> what if the average is calculated 10 million times per second? would you
>> still ldo the check eatch time?
<snip>
> It is really quite simple, and I cannot understand why you are taking so
> long to get the hang of it.
>
> Let me give you the /one/ rule that actually matters:
>
> * Do not divide by zero - it is a mistake in the code. *
>
> OK?

I don't think that's a good universal rule.  It very often a good rule,
and if you are writing portable C it is an essential rule, but there are
times when you can rely on behaviour outside of the C++ standard.  In
those cases writing simpler code and letting IEEE floating point take
care of the NaNs and the Infinities might be the way to go.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#48621

On 07/02/17 15:06, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 07/02/17 01:43, JiiPee wrote:
> <snip>
>>> what if the average is calculated 10 million times per second? would you
>>> still ldo the check eatch time?
> <snip>
>> It is really quite simple, and I cannot understand why you are taking so
>> long to get the hang of it.
>>
>> Let me give you the /one/ rule that actually matters:
>>
>> * Do not divide by zero - it is a mistake in the code. *
>>
>> OK?
> 
> I don't think that's a good universal rule.  It very often a good rule,
> and if you are writing portable C it is an essential rule, but there are
> times when you can rely on behaviour outside of the C++ standard.  In
> those cases writing simpler code and letting IEEE floating point take
> care of the NaNs and the Infinities might be the way to go.
> 
> <snip>
> 

There is always going to be scope for making things more complicated to
suit particular cases - C and C++ are flexible languages, and compilers
often have a range of options or features that go beyond the bare
requirements of the standards.

However, I think unless you are an expert who is aware of all the
subtleties and has a solid understanding of the target platform(s),
compiler(s) and compiler options, then it /is/ a good rule.  And a
poster who wonders if it is okay to skip a check purely on the basis of
the number of times a function is to be called, is not such an expert
(in this particular area).


Actually, I'd go beyond that and keep my rule even for experts -
dividing by zero is a mistake (unless you are dealing with projective
planes and other fun maths).  Relying on features such as IEEE floating
point NaNs, infinities, or exceptions is one way of dealing with such
mistakes.  Sometimes it is more efficient to do your calculations hoping
there is no problem such as division by zero, with the intention of
detecting the problem afterwards, rather than checking for problems
/before/ doing the calculation.  That's fine - but you are not actually
dividing by zero any more.  You are doing speculative calculations that
may be aborted by exceptions, or calculations using functions specified
as returning NaN for a denominator of 0 or the quotient otherwise.  In
other words, you are using specified, defined behaviour - not the
undefined behaviour of a division by zero.

[toc] | [prev] | [next] | [standalone]

#48615

On Tuesday, 7 February 2017 02:43:43 UTC+2, JiiPee  wrote:
> On 06/02/2017 23:58, Manfred wrote:
> > In the average example() I would explicitly throw an exception if the 
> > set is empty, I would not execute the division by zero, or anyway 
> > assume that the division itsels throws an exception. 
> 
> what if the average is calculated 10 million times per second? would you 
> still ldo the check eatch time?

Sure. It is dirt cheap compared to everything else involved.
* Do we really have tens of millions of little vectors? 
* Why we produce these at such a rate?
* Are we averaging same (smaller set) of vectors over and over again?
* Do we average every vector's contents after every little change to it? 
And so on.

Every case imaginable means that we have some design issue that
likely allows us to improve the performance ten times *without* 
removing that check. ;)

> 
> But isnt it this a similar issue to vectors v.at(2) against v[2]?

The out of bounds index may be received from some dirty
and potentially malicious source (external file, user input,
code of team of your competitor). On rest of the cases out
of bounds index means programming errors. On most of 
those cases we likely should not continue whatever we
were doing.

The need to average unexisting values may be normal. For
example readings of some sensor. Checking that we have
received any readings from sensor before we average those
makes perfect sense, continuing to work without those
readings from (one?) sensor may make perfect sense.
 

[toc] | [prev] | [next] | [standalone]

#48620

On 2/7/2017 1:43 AM, JiiPee wrote:
> On 06/02/2017 23:58, Manfred wrote:
>> In the average example() I would explicitly throw an exception if the
>> set is empty, I would not execute the division by zero, or anyway
>> assume that the division itsels throws an exception.
>
>
> what if the average is calculated 10 million times per second? would you
> still ldo the check eatch time?
Yes, unless in the program by some means it can be guaranteed that the 
set can /never/ be empty.
As others have already replied, ensuring a correct result is more 
important than saving a few (or many) clock cycles: if you want to save 
processing time, you have to do so in such a way that still guarantees 
correct results.

>
> But isnt it this a similar issue to vectors v.at(2) against v[2]?
>
It is a different context (out of range is not division by zero). Anyway 
for vector elements the designers of the language decided to provide two 
access methods, only one of which guarantees range checking. Obviously 
this implies that if you want to use the [] form (unchecked) you /need/ 
to ensure that the vector will /never/ be accessed out of range.
IMHO the rationale for choosing between the two is not speed, it is 
whether you can /guarantee/ that out-of-range does not happen. If it is 
so, the library gives you a way to save a few machine code instructions.
OTOH, if you cannot guarantee this and still want the [] syntax, Bjarne 
gives explicit examples on how to implement a range-checked [] operator.

[toc] | [prev] | [next] | [standalone]

#48616

JiiPee <no@notvalid.com> writes:
>On 06/02/2017 12:56, Manfred wrote:
>> On 2/6/2017 1:39 AM, JiiPee wrote:
>>> On 06/02/2017 00:08, Manfred wrote:
>>>> I would indeed go for the exception.
>>>
>>>
>>> But Bjarne seems to be against exception in this kind of situation...
>>>
>> I don't recall when/where he may have said that, I would be curious; 
>> could you be more specific if you like?
>
>http://stackoverflow.com/questions/6121623/catching-exception-divide-by-zero
>
>Stroustrup says, in "The Design and Evolution of C++" (Addison Wesley, 
>1994), "low-level events, such as arithmetic overflows and divide by 
>zero, are assumed to be handled by a dedicated lower-level mechanism 

In particular, hardware detection and SIGFPE generation.

[toc] | [prev] | [next] | [standalone]

#47952

On 12/01/2017 09:36, David Brown wrote:
> Possibilities include returning 0


What do you mean by "returning 0"? Lets says the function header is:

double average(double values[], int count);

So do you mean this functions return value would be 0 if there is an error?

[toc] | [prev] | [next] | [standalone]

#47955

On 12/01/17 14:20, JiiPee wrote:
> On 12/01/2017 09:36, David Brown wrote:
>> Possibilities include returning 0
> 
> 
> What do you mean by "returning 0"? Lets says the function header is:
> 
> double average(double values[], int count);
> 
> So do you mean this functions return value would be 0 if there is an error?
> 

double average(double values[], int count) {
	if (count <= 0) return 0;
	return std::accumulate(values, values + count, 0.0) / count;
}

It won't return 0 on all errors - such as mismatches between the actual
array size and count.  But it will return 0 on an empty set.

[toc] | [prev] | [next] | [standalone]

#47956

On 12/01/2017 14:28, David Brown wrote:
> double average(double values[], int count) {
> 	if (count <= 0) return 0;
> 	return std::accumulate(values, values + count, 0.0) / count;
> }


But this would give a wrong answer if you call this function with:

values[] = {-1,0,1}

isnt it? Because it would return 0 and so the receiver would think there 
was some kind of error, right?

But +1 for the std::accumulate! :)

[toc] | [prev] | [next] | [standalone]

#47957

On 12/01/17 16:40, JiiPee wrote:
> On 12/01/2017 14:28, David Brown wrote:
>> double average(double values[], int count) {
>>     if (count <= 0) return 0;
>>     return std::accumulate(values, values + count, 0.0) / count;
>> }
> 
> 
> But this would give a wrong answer if you call this function with:
> 
> values[] = {-1,0,1}

No, it gives the correct answer - 0.

> 
> isnt it? Because it would return 0 and so the receiver would think there
> was some kind of error, right?

No, the receiver would got 0 would only think there is an error if he
did not understand how to use the function properly.  And if that is the
case, then returning 0 is just minimising the spread of damage due to
the user's mistake.

The user cannot use a result of 0 to conclude that there was an error
any more than he can use a result of 1 to conclude that the set passed
was { 0, 1, 2 }.


> 
> But +1 for the std::accumulate! :)
> 

[toc] | [prev] | [next] | [standalone]

#47940

> ....
> I think the most practically useful behavior would be the 0 return,
> documented as such.
>
> But, this opinion could be subject to revision if someone makes a good
> case for some other possibility! ;-)

I might not agree with 'return 0', but your approach is IMO the only 
sound approach: try to find out what makes the most sense for the user. 
But alas, that might not be the same for all users...

My approach is often 'let the user decide', which might be done by an 
extra lambda/std::function parameter, which gets called in the 
divide-by-zero cause. The default could be []{ return 0; }, to match 
your case.

For a faster run in the normal cases, but undefined behaviour in the 
divide-by-zero case, the caller should have the option to specify []{} 
to signify that nothing is to be done, but I don't yet see how that 
could be done. (Some template magic will probably help.)

An exception-oriented user could specify []{ throw <something>; }

Wouter "Objects? No Thanks!" van Oijen

[toc] | [prev] | [next] | [standalone]

#47939

On 11/01/2017 21:42, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> the behavior is undefined.
>
>   The physicists call »undefined behavior« a "singularity".
>
>   The big bang (the time between 0 and some early time)
>   was a singularity.
>
>   That means we own our existence to undefined behavior.
>
>   Blessed are you, undefined behavior.

Word salad.

/Flibble

[toc] | [prev] | [next] | [standalone]

#47984

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:

> On 11/01/2017 21:42, Stefan Ram wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> the behavior is undefined.
>>
>>   The physicists call »undefined behavior« a "singularity".
>>
>>   The big bang (the time between 0 and some early time)
>>   was a singularity.
>>
>>   That means we own our existence to undefined behavior.
>>
>>   Blessed are you, undefined behavior.
>
> Word salad.
>
> /Flibble

Game recognise game

[toc] | [prev] | [next] | [standalone]

#47944

On 11/01/2017 21:28, Stefan Ram wrote:
> #include <interview.h>


haha

[toc] | [prev] | [next] | [standalone]

#47945

On 11/01/2017 22:54, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> double average( const double * a, size_t n );
>> If n is 0, the behavior is undefined.
>    Because, what's usually better than
>
> try { ave = average( a, n ); }
> catch( average_of_zero_exception e ) { oops(); }
>
>    is
>
> if( n == 0 )oops(); else ave = average( a, n )
>
>    .
>

I kind of agree with average(). But with opening-a-file error exception 
is better. Somehow it feels strainge to use exception with mathematical 
calculations. But yes, my interviewer seemed to like it...Well, i forgot 
to mention actually any error handling (which was a mistake obviously).


I kind of agree that in this case its more a documentation issue. 
Obviously asserts need to be there for debugging.

[toc] | [prev] | [next] | [standalone]

#47965

On 11/01/2017 18:17, JiiPee wrote:
> In my interview the interviewer asked me to write a function to 
> calculate an average value/mean.
>
> And at the end he added: "..and if you divide by zero then you would 
> maybe throw an exception....". But I have since been thinking is this 
> the way:
>
>
> double average(array of values)
>
> {}
>
> Seems like Bjarne recommends not to use exceptions when dividing by 
> zero but other ways. What would be the best way for the function to 
> report about "dividing by zero" case? How would you do it?
>
>
> I kind of agree with Bjarne here.... do you?
>

Try this:

<http://stackoverflow.com/questions/6121623/catching-exception-divide-by-zero>

Good luck.

[toc] | [prev] | [next] | [standalone]

#47967

On 12/01/2017 16:55, Real Troll wrote:
> Try this:
>
> <http://stackoverflow.com/questions/6121623/catching-exception-divide-by-zero> 
>
>
> Good luck.


the third answer there says:

"Stroustrup says, in "The Design and Evolution of C++" (Addison Wesley, 
1994), "low-level events, such as arithmetic overflows and divide by 
zero, are assumed to be handled by a dedicated lower-level mechanism 
rather than by exceptions. This enables C++ to match the behaviour of 
other languages when it comes to arithmetic. It also avoids the problems 
that occur on heavily pipelined architectures where events such as 
divide by zero are asynchronous."`"

[toc] | [prev] | [next] | [standalone]

#47983

On 11/01/2017 18:17, JiiPee wrote:
> In my interview the interviewer asked me to write a function to
> calculate an average value/mean.
>
> And at the end he added: "..and if you divide by zero then you would
> maybe throw an exception....". But I have since been thinking is this
> the way:
>
>
> double average(array of values)
>
> {}
>
> Seems like Bjarne recommends not to use exceptions when dividing by zero
> but other ways. What would be the best way for the function to report
> about "dividing by zero" case? How would you do it?
>
>
> I kind of agree with Bjarne here.... do you?

The correct thing to do in C++ is to throw an exception derived from 
std::logic_error as dividing by zero is undefined in mathematics and a 
bug in code.

/Flibble

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web