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 4 of 4 — ← Prev page 1 2 3 [4]

#47986

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

> 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.

I agree.

My personal choice would be std::invalid_argument or std::domain_error.

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

#48025

On 1/11/2017 10:17 AM, 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?
>

FWIW, in my current line of working with floating point divide-by-zero 
conditions is that they should be detected _before_ any execution that 
would produce the deadly nan, during iteration. So, I check a value v 
for zero, if v is zero I make a log in a report and set v to the current 
epsilon of the iteration before the divide operation is allowed to be 
realized, therefore avoiding divide-by-zero inserting a nan into an 
iteration and basically destroying any subsequent iterations.

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

#48026

On 13/01/2017 23:34, Chris M. Thomasson wrote:
> FWIW, in my current line of working with floating point divide-by-zero 
> conditions is that they should be detected _before_ any execution that 
> would produce the deadly nan, during iteration.


Another question is that what should happen if somebody forgets to check 
that divide by zero before calling average. In your case seems like tha 
program crashes?

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

#48027

On 1/13/2017 4:14 PM, JiiPee wrote:
> On 13/01/2017 23:34, Chris M. Thomasson wrote:
>> FWIW, in my current line of working with floating point divide-by-zero
>> conditions is that they should be detected _before_ any execution that
>> would produce the deadly nan, during iteration.
>
>
> Another question is that what should happen if somebody forgets to check
> that divide by zero before calling average. In your case seems like tha
> program crashes?
>

No crash. However, the div-by-zero cases get detected, logged, and then 
epsilon is divided instead of a zero case, and the iteration can 
continue on its merry way, without spreading nan's like a damn virus.

The resulting log can be examined, and the renderings wrt replacing 
div-by-zero via epsilon can be useful as well.

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

#48030

On 1/13/2017 4:56 PM, Chris M. Thomasson wrote:
> On 1/13/2017 4:14 PM, JiiPee wrote:
>> On 13/01/2017 23:34, Chris M. Thomasson wrote:
>>> FWIW, in my current line of working with floating point divide-by-zero
>>> conditions is that they should be detected _before_ any execution that
>>> would produce the deadly nan, during iteration.
>>
>>
>> Another question is that what should happen if somebody forgets to check
>> that divide by zero before calling average. In your case seems like tha
>> program crashes?
>>
>
> No crash. However, the div-by-zero cases get detected, logged, and then
> epsilon is divided instead of a zero case, and the iteration can
> continue on its merry way, without spreading nan's like a damn virus.
>
> The resulting log can be examined, and the renderings wrt replacing
> div-by-zero via epsilon can be useful as well.

A possible rational for replacing zero with "very close to zero" can be:

Well, is was close to zero anyway, and we have a log to see why it got 
that close for the iteration in question anyway.

;^)

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

#48031

On 14/01/2017 00:56, Chris M. Thomasson wrote:
> No crash. However, the div-by-zero cases get detected, logged, and 
> then epsilon is divided instead of a zero case, and the iteration can 
> continue on its merry way, without spreading nan's like a damn virus. 


no I am talking about the situation where you DO NOT check the zero case 
but just call that function WITHOUT check. Then it crashes, if the 
function does no checks.

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

#48032

On 1/13/2017 5:51 PM, JiiPee wrote:
> On 14/01/2017 00:56, Chris M. Thomasson wrote:
>> No crash. However, the div-by-zero cases get detected, logged, and
>> then epsilon is divided instead of a zero case, and the iteration can
>> continue on its merry way, without spreading nan's like a damn virus.
>
>
> no I am talking about the situation where you DO NOT check the zero case
> but just call that function WITHOUT check. Then it crashes, if the
> function does no checks.
>

Without checking for div-by-zero, and just let it "fly"... Humm...

Well, beware of the infectious nan's that will most likely be cast 
throughout subsequent iterations from point crap, of exotic experimental 
algorithms in the complex plane. I personally like to be able to log 
patient zero, or iteration zero if you will. The infecting agents 
point/iteration of origin, so to speak. Nan or infinity, they both 
posses the ability to simply ruin/destroy the damn fractal renderings! 
Nans, lol, watch this:

https://youtu.be/-EaHLaZbMFs

;^)

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

#48039

"Chris M. Thomasson" <invalid@invalid.invalid> writes:

> FWIW, in my current line of working with floating point divide-by-zero
> conditions is that they should be detected _before_ any execution that
> would produce the deadly nan, during iteration. So, I check a value v
> for zero, if v is zero I make a log in a report and set v to the
> current epsilon of the iteration before the divide operation is
> allowed to be realized

So, instead of getting NaN as answer, you get the wrong answer?
Or is this just for 0./0. (since 1/0. is Inf)?

Of course, if it very much depends on the algorithm you're iterating over

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

#48048

On 1/14/2017 3:21 AM, Gareth Owen wrote:
> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
>
>> FWIW, in my current line of working with floating point divide-by-zero
>> conditions is that they should be detected _before_ any execution that
>> would produce the deadly nan, during iteration. So, I check a value v
>> for zero, if v is zero I make a log in a report and set v to the
>> current epsilon of the iteration before the divide operation is
>> allowed to be realized
>
> So, instead of getting NaN as answer, you get the wrong answer?

In a sense you are correct, however I can review the log and see exactly 
how things got to a div-by-zero. This is for rendering pictures, and a 
nan or infinity can gum up the works.

> Or is this just for 0./0. (since 1/0. is Inf)?

Therefore, I try to avoid both nan and infinity. I am worried about 
passing sqrt a negative number...


> Of course, if it very much depends on the algorithm you're iterating over

The algorithm is computing a Julia set in reverse. Here is some more 
information:

https://en.wikipedia.org/wiki/Julia_set#Using_backwards_.28inverse.29_iteration_.28IIM.29

I am also computing the Buddha brot using normal forward iteration on 
the roots generated by reverse iteration. Nan aside for a moment, these 
iterations can escape into infinity. So, I test to see if it goes off 
into never never land before I commit the iteration. If it does I log 
it, set z to epsilon in the output structure of the function, and return 
it to the caller.

The main problem is that an iteration uses information from previous 
iterations. Nans and/or Infinities can propagate throughout the 
subsequent iterations, and drastically alter the rendering. Like a virus.

;^o

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

#48050

On 14/01/2017 20:45, Chris M. Thomasson wrote:
> The main problem is that an iteration uses information from previous 
> iterations. Nans and/or Infinities can propagate throughout the 
> subsequent iterations, and drastically alter the rendering. Like a virus. 


Yes sure 0 is better in most cases as a wrong value. And if its logged 
to the file then sure its quite ok, then can see the error.

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

#48053

On 1/14/2017 1:02 PM, JiiPee wrote:
> On 14/01/2017 20:45, Chris M. Thomasson wrote:
>> The main problem is that an iteration uses information from previous
>> iterations. Nans and/or Infinities can propagate throughout the
>> subsequent iterations, and drastically alter the rendering. Like a virus.
>
>
> Yes sure 0 is better in most cases as a wrong value. And if its logged
> to the file then sure its quite ok, then can see the error.
>

Indeed. Except I set 0 to epsilon. Sometimes, I also try to propagate 
the signs of the offending formula and/or value of z, wrt to +-epsilon 
for each offense. This is dangerous wrt sqrt, and other nasal demons.

Think of running an unknown formula, and you have to look after the damn 
possible moron!

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

#48051

On 1/14/2017 12:45 PM, Chris M. Thomasson wrote:
> On 1/14/2017 3:21 AM, Gareth Owen wrote:
>> "Chris M. Thomasson" <invalid@invalid.invalid> writes:
>>
>>> FWIW, in my current line of working with floating point divide-by-zero
>>> conditions is that they should be detected _before_ any execution that
>>> would produce the deadly nan, during iteration. So, I check a value v
>>> for zero, if v is zero I make a log in a report and set v to the
>>> current epsilon of the iteration before the divide operation is
>>> allowed to be realized
>>
>> So, instead of getting NaN as answer, you get the wrong answer?
>
> In a sense you are correct, however I can review the log and see exactly
> how things got to a div-by-zero.
[...]
> I am worried about
> passing sqrt a negative number...

Not sure why I was so focused on the div-by-zero case, and sort of mixed 
it up with nan and infinities individual cases. Sorry for the confusion 
I had to of caused.

;^o

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

#48559

In article <zEudA.1117322$_a3.924316@fx42.am4>, 
no@notvalid.com says...
> 
> 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?

My feeling is that if the interviewer tells you 
to throw an exception you throw an effing 
exception unless you see a compelling reason not 
to.

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

#48573

On Wed, 2017-01-11, 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?

I'd just document that average() has undefined behavior if you feed it
the empty set.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#48578

On 05/02/2017 10:21, Jorgen Grahn wrote:
> I'd just document that average() has undefined behavior if you feed it
> the empty set.


I had an interview at the central of London. And after i finished the 
avarage() function, he asked "thats all?" (I did not mention any error 
handling). then he said: "..and maybe to throw an exception ?". So he 
seemed to see that a good one..

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

#48595

On 05/02/2017 14:26, Stefan Ram wrote:
> template< typename I >
> inline static double narrow_average( I first, I top, size_t size )
> { return ::std::accumulate( first, top, 0.0 )/ size; }


yes should have been something like that. I use for-loop at that time, 
but was not so experienced that time.

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

#48579

On 05/02/2017 10:21, Jorgen Grahn wrote:
> I'd just document that average() has undefined behavior if you feed it
> the empty set.


maybe in a release version, but surely in a debug version an assert() 
would be a good there...

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

#48588

On Sun, 2017-02-05, JiiPee wrote:
> On 05/02/2017 10:21, Jorgen Grahn wrote:
>> I'd just document that average() has undefined behavior if you feed it
>> the empty set.
>
> maybe in a release version, but surely in a debug version an assert() 
> would be a good there...

The documentation would be the same in both cases.

Yes, maybe an assertion ... although the difference between an abort()
and division by zero is slight.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [standalone]

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

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

csiph-web