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

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

Detect Math Errors in Functions

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

Contents

  Detect Math Errors in Functions Joseph Hesse <joeh@gmail.com> - 2021-09-01 07:31 +0200
    Re: Detect Math Errors in Functions Barry Schwarz <schwarzb@delq.com> - 2021-08-31 23:54 -0700
      Re: Detect Math Errors in Functions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 09:30 +0200
        Re: Detect Math Errors in Functions Barry Schwarz <schwarzb@delq.com> - 2021-09-01 07:53 -0700
          Re: Detect Math Errors in Functions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 17:50 +0200
          Re: Detect Math Errors in Functions James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-01 12:28 -0400
          Re: Detect Math Errors in Functions Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-09-01 17:38 +0100
      Re: Detect Math Errors in Functions David Brown <david.brown@hesbynett.no> - 2021-09-01 09:50 +0200
        Re: Detect Math Errors in Functions Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-09-01 16:38 +0100
          Re: Detect Math Errors in Functions David Brown <david.brown@hesbynett.no> - 2021-09-01 19:25 +0200
            Re: Detect Math Errors in Functions Hope Rouselle <hrouselle@jevedi.com> - 2021-09-06 11:04 -0300
        Re: Detect Math Errors in Functions Cholo Lennon <chololennon@hotmail.com> - 2021-09-06 00:20 -0300
          Re: Detect Math Errors in Functions "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-09-06 07:23 +0200
            Re: Detect Math Errors in Functions Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2021-09-06 20:34 -0400
    Re: Detect Math Errors in Functions Juha Nieminen <nospam@thanks.invalid> - 2021-09-01 18:22 +0000
    Re: Detect Math Errors in Functions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 21:02 +0200
      Re: Detect Math Errors in Functions David Brown <david.brown@hesbynett.no> - 2021-09-02 11:53 +0200
    Re: Detect Math Errors in Functions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-01 21:10 +0200
      Re: Detect Math Errors in Functions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-02 05:31 +0200
        Re: Detect Math Errors in Functions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-02 07:51 +0200
      Re: Detect Math Errors in Functions Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2021-09-06 20:47 -0400
        Re: Detect Math Errors in Functions red floyd <no.spam.here@its.invalid> - 2021-09-06 20:24 -0700
          Re: Detect Math Errors in Functions Juha Nieminen <nospam@thanks.invalid> - 2021-09-08 10:20 +0000
            Re: Detect Math Errors in Functions David Brown <david.brown@hesbynett.no> - 2021-09-08 13:17 +0200
              Re: Detect Math Errors in Functions Hope Rouselle <hrouselle@jevedi.com> - 2021-09-08 10:24 -0300
        Re: Detect Math Errors in Functions Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-07 09:10 +0200

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

#81074

Bonita Montero wrote:
> I think the most portbale solution is this:
> 
> #include <iostream>
> #include <stdexcept>
> 
> using namespace std;
> 
> void GenerateSequence( unsigned long start )
> {
>      unsigned long x = start;
>      try
>      {
>          while( x != 1 )
>          {
>              if( !(x % 2) )
>                  x /= 2;
>              else
>                  if( 3 * x / x == x && 3 * x + 1 > 3 * x )
>                      x = 3 * x + 1;
>                  else
>                      throw range_error( "GenerateSequence: out of range" );
>              cout << x << endl;
>          }
>      }
>      catch( range_error &re )
>      {
>          cout << re.what() << endl;
>      }
> }
IMHO, this is UB if x ever grows bigger than ULONG_MAX / 3, so the 
portability point is moot. (I tend to think UB is non-portable by 
definition).

-Pavel

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

#81075

On 9/6/2021 5:47 PM, Pavel wrote:
> Bonita Montero wrote:
>> I think the most portbale solution is this:
>>
>> #include <iostream>
>> #include <stdexcept>
>>
>> using namespace std;
>>
>> void GenerateSequence( unsigned long start )
>> {
>>      unsigned long x = start;
>>      try
>>      {
>>          while( x != 1 )
>>          {
>>              if( !(x % 2) )
>>                  x /= 2;
>>              else
>>                  if( 3 * x / x == x && 3 * x + 1 > 3 * x )
>>                      x = 3 * x + 1;
>>                  else
>>                      throw range_error( "GenerateSequence: out of 
>> range" );
>>              cout << x << endl;
>>          }
>>      }
>>      catch( range_error &re )
>>      {
>>          cout << re.what() << endl;
>>      }
>> }
> IMHO, this is UB if x ever grows bigger than ULONG_MAX / 3, so the 
> portability point is moot. (I tend to think UB is non-portable by 
> definition).
> 

I don't think so.  I believe unsigned rollover is defined.  If x was a
regular long, that's another matter.

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

#81087

red floyd <no.spam.here@its.invalid> wrote:
> I don't think so.  I believe unsigned rollover is defined.  If x was a
> regular long, that's another matter.

Indeed. Unsigned integers use 2's complement arithmetic as per the standard.
(Well, pratically speaking 2's complement.)

It's only with signed integers that overflow and underflow are undefined.
(And for a reason, as there are architectures where this may cause a fault
signal to be thrown.)

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

#81091

On 08/09/2021 12:20, Juha Nieminen wrote:
> red floyd <no.spam.here@its.invalid> wrote:
>> I don't think so.  I believe unsigned rollover is defined.  If x was a
>> regular long, that's another matter.
> 
> Indeed. Unsigned integers use 2's complement arithmetic as per the standard.
> (Well, pratically speaking 2's complement.)
> 

I think I know what you are trying to say, but it is a strange way to
say it.  "Two's complement" only makes sense for signed integers - it
has no meaning for unsigned types.

Unsigned types in C and C++ are defined as modulo types.
Conventionally, we may say they "wrap on overflow" - but to be more
accurate, there is no overflow.  The result of adding unsigned ints "a"
and "b" is the value of "(a + b) % 2^n" using standard mathematical
arithmetic, where "n" is the number of value bits in unsigned int.


> It's only with signed integers that overflow and underflow are undefined.

Yes.

> (And for a reason, as there are architectures where this may cause a fault
> signal to be thrown.)
> 

That is perhaps one of several reasons, but it is not the only one.  The
primary reason, as I see it, is that overflow of signed integer
arithmetic will give you the wrong answer.  Picking a definition for the
result does not make it correct or useful - it merely hinders tools in
helping you to find the errors in your code.

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

#81095

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

> On 08/09/2021 12:20, Juha Nieminen wrote:
>> red floyd <no.spam.here@its.invalid> wrote:
>>> I don't think so.  I believe unsigned rollover is defined.  If x was a
>>> regular long, that's another matter.
>> 
>> Indeed. Unsigned integers use 2's complement arithmetic as per the standard.
>> (Well, pratically speaking 2's complement.)
>
> I think I know what you are trying to say, but it is a strange way to
> say it.  "Two's complement" only makes sense for signed integers - it
> has no meaning for unsigned types.
>
> Unsigned types in C and C++ are defined as modulo types.
> Conventionally, we may say they "wrap on overflow" - but to be more
> accurate, there is no overflow.  The result of adding unsigned ints "a"
> and "b" is the value of "(a + b) % 2^n" using standard mathematical
> arithmetic, where "n" is the number of value bits in unsigned int.

FWIW, here's the exact language of C89.

--8<---------------cut here---------------start------------->8---
  A computation involving unsigned operands can never overflow, because
  a result that cannot be represented by the resulting unsigned integer
  type is reduced modulo the number that is one greater than the largest
  value that can be represented by the resulting unsigned integer type.
  -- C89, section 3.1.2.5
--8<---------------cut here---------------end--------------->8---

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

#81079

Am 07.09.2021 um 02:47 schrieb Pavel:
> Bonita Montero wrote:
>> I think the most portbale solution is this:
>>
>> #include <iostream>
>> #include <stdexcept>
>>
>> using namespace std;
>>
>> void GenerateSequence( unsigned long start )
>> {
>>      unsigned long x = start;
>>      try
>>      {
>>          while( x != 1 )
>>          {
>>              if( !(x % 2) )
>>                  x /= 2;
>>              else
>>                  if( 3 * x / x == x && 3 * x + 1 > 3 * x )
>>                      x = 3 * x + 1;
>>                  else
>>                      throw range_error( "GenerateSequence: out of 
>> range" );
>>              cout << x << endl;
>>          }
>>      }
>>      catch( range_error &re )
>>      {
>>          cout << re.what() << endl;
>>      }
>> }
> IMHO, this is UB if x ever grows bigger than ULONG_MAX / 3, so the 
> portability point is moot. (I tend to think UB is non-portable by 
> definition).

No, as red floyd said: that's not UB with unsigned.

[toc] | [prev] | [standalone]

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

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

csiph-web