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

Groups > comp.lang.c > #139150 > unrolled thread

Range-aware modulo operator -%

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

Contents

  Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 21:09 -0500
    Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-27 21:34 -0500
      Re: Range-aware modulo operator -% "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2018-12-28 05:37 +0100
      Re: Range-aware modulo operator -% James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-29 16:04 -0500
        Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-29 19:13 -0500
    Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 03:05 +0000
      Re: Range-aware modulo operator -% Robert Wessel <robertwessel2@yahoo.com> - 2018-12-27 21:31 -0600
        Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 04:20 +0000
      Re: Range-aware modulo operator -% James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-27 19:32 -0800
        Re: Range-aware modulo operator -% Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-28 04:18 +0000
    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-28 12:29 +0000
      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 08:10 -0500
        Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 10:25 -0500
          Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-28 15:56 +0000
            Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 17:26 -0500
              Re: Range-aware modulo operator -% Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2018-12-28 23:45 +0100
          Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 11:44 -0500
          Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 12:16 -0500
            Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-28 17:08 -0500
              Re: Range-aware modulo operator -% Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-28 15:01 -0800
              Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 09:04 -0500
                Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 18:07 +0000
                  Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 14:22 -0500
                    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 21:05 +0000
                      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-31 16:32 -0500
                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 23:43 +0000
                          Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 16:44 -0800
                            Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 01:06 +0000
                              Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 19:06 -0800
                                Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 11:32 +0000
                                  Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 12:48 -0800
                                    Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-01 23:54 +0000
                                      Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 16:09 -0800
                                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 00:49 +0000
                                          Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-01 17:53 -0800
                                            Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 02:36 +0000
                                              Leader Kiki is not going to like this... (Was: Range-aware modulo operator -%) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-02 08:36 +0000
                                              Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2019-01-02 00:38 -0800
                                      Re: Range-aware modulo operator -% rbowman <bowman@montana.com> - 2019-01-01 22:40 -0700
                                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2019-01-02 12:12 +0000
                            Re: Range-aware modulo operator -% gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-01 01:53 +0000
                      Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-31 16:57 -0500
                        Re: Range-aware modulo operator -% Bart <bc@freeuk.com> - 2018-12-31 22:33 +0000
                  Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 13:34 -0800
                    Re: Range-aware modulo operator -% Richard Damon <Richard@Damon-Family.org> - 2018-12-31 16:43 -0500
                      Re: Range-aware modulo operator -% Keith Thompson <kst-u@mib.org> - 2018-12-31 15:20 -0800
    Re: Range-aware modulo operator -% Eduardo <abdulai60@gmail.com> - 2018-12-28 07:18 -0800
      Re: Range-aware modulo operator -% "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-28 11:45 -0500

Page 1 of 3  [1] 2 3  Next page →

#139150 — Range-aware modulo operator -%

I think C/C++ needs to have a range-aware modulo operator that will
continue ranging properly when it encounters negative values.

We have this:
     i = (i + 1) % 10;   // Always ranges 0..9

But what if you try this when i = 0:
     i = (i - 1) % 10;

It won't produce the same result in the same pattern seen when you
started at a positive i and tended toward 0.  It begins a new trend,
one which is useful, but not always desirable.

A range-aware modulo operator would know that it should always be
in the range 0..9 (from the example above), and also that it should
continue the pattern seen in the positive integers, such that when
given a negative input value, it handles the processing differently:

     // v=value, m=modulo number
     int range_modulo(int v, int m)
     {
         if (v >= 0)    return (v % m);
         else           return ((m + (v % m)) % m);
     }

     int i;
     for (i = 12; i >= -12; --i)
         printf("%d --> mod 10 = %d\n", i, range_modulo(i, 10));

-----
I propose the -% symbol for the operator.

It would allow things that are sometimes needed in video games,
as just one example, when a player hits the left button instead
of the right button, and you need it to go the other way, AND you
want it to just work while using the same math.

Just sayin'... :-)

-- 
Rick C. Hodgin

[toc] | [next] | [standalone]

#139152

On 12/27/18 9:09 PM, Rick C. Hodgin wrote:
> I think C/C++ needs to have a range-aware modulo operator that will
> continue ranging properly when it encounters negative values.
> 
> We have this:
>     i = (i + 1) % 10;   // Always ranges 0..9
> 
> But what if you try this when i = 0:
>     i = (i - 1) % 10;
> 
> It won't produce the same result in the same pattern seen when you
> started at a positive i and tended toward 0.  It begins a new trend,
> one which is useful, but not always desirable.
> 
> A range-aware modulo operator would know that it should always be
> in the range 0..9 (from the example above), and also that it should
> continue the pattern seen in the positive integers, such that when
> given a negative input value, it handles the processing differently:
> 
>     // v=value, m=modulo number
>     int range_modulo(int v, int m)
>     {
>         if (v >= 0)    return (v % m);
>         else           return ((m + (v % m)) % m);
>     }
> 
>     int i;
>     for (i = 12; i >= -12; --i)
>         printf("%d --> mod 10 = %d\n", i, range_modulo(i, 10));
> 
> -----
> I propose the -% symbol for the operator.
> 
> It would allow things that are sometimes needed in video games,
> as just one example, when a player hits the left button instead
> of the right button, and you need it to go the other way, AND you
> want it to just work while using the same math.
> 
> Just sayin'... :-)
> 

It used to be that an implementation was allowed to define -1 % 10 to be
9, but they standard changed the rule for division so that that wasn't
allowed anymore. (It required -1/10 == -1)

The key fact is that given i, j, m, n as integral types and no overflow
occurring.

If i = m / n and j = m % n
then i * n + j == m

for j to always be positive, i needs to be the floor of the division,
not from round to 0.

The key to remember is that % is NOT the modulus operator, but the
remainder operator (which work the same for positive numbers).

It is simple enough to define a mod function that gets the results you
want, so not that much need for a new operator.

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

#139159

On 28.12.2018 03:34, Richard Damon wrote:
> On 12/27/18 9:09 PM, Rick C. Hodgin wrote:
>> I think C/C++ needs to have a range-aware modulo operator that will
>> continue ranging properly when it encounters negative values.
>>
>> We have this:
>>      i = (i + 1) % 10;   // Always ranges 0..9
>>
>> But what if you try this when i = 0:
>>      i = (i - 1) % 10;
>>
>> It won't produce the same result in the same pattern seen when you
>> started at a positive i and tended toward 0.  It begins a new trend,
>> one which is useful, but not always desirable.
>>
>> A range-aware modulo operator would know that it should always be
>> in the range 0..9 (from the example above), and also that it should
>> continue the pattern seen in the positive integers, such that when
>> given a negative input value, it handles the processing differently:
>>
>>      // v=value, m=modulo number
>>      int range_modulo(int v, int m)
>>      {
>>          if (v >= 0)    return (v % m);
>>          else           return ((m + (v % m)) % m);
>>      }
>>
>>      int i;
>>      for (i = 12; i >= -12; --i)
>>          printf("%d --> mod 10 = %d\n", i, range_modulo(i, 10));
>>
>> -----
>> I propose the -% symbol for the operator.
>>
>> It would allow things that are sometimes needed in video games,
>> as just one example, when a player hits the left button instead
>> of the right button, and you need it to go the other way, AND you
>> want it to just work while using the same math.
>>
>> Just sayin'... :-)
>>
> 
> It used to be that an implementation was allowed to define -1 % 10 to be
> 9, but they standard changed the rule for division so that that wasn't
> allowed anymore. (It required -1/10 == -1)

Yes, C++11 narrowed the permissible behavior of integer division to 
always round towards zero.

In contrast, Python always rounds towards negative infinity, like the 
mathematical floor function.

So, in Python:


---------------------------------------------------------------------
n_persons = int( input( "How many persons? " ) )
max_per_taxi = int( input( "Maximum passengers per taxi? " ) )
n_taxis = -(-n_persons//max_per_taxi)
print( "You need {} taxis. :)".format( n_taxis ) )
---------------------------------------------------------------------


But in C++:


---------------------------------------------------------------------
#include <iostream>
#include <stdexcept>
#include <stdlib.h>         // EXIT_...
#include <string>
using namespace std;

auto fail( const string& s ) -> bool { throw runtime_error( s ); }

auto line_from( istream& stream )
     -> string
{
     string result;
     getline( stream, result ) or fail( "Bah, getline" );
     return result;
}

auto input( const string& prompt )
     -> string
{
     cout << prompt;
     return line_from( cin );
}

void doit()
{
     const int n_persons = stoi( input( "How many persons? " ) );
     const int max_per_taxi = stoi( input( "Maximum passengers per taxi? 
" ) );
     const int n_taxis = (n_persons + max_per_taxi - 1)/max_per_taxi;
     cout << "You need " << n_taxis << " taxis. :)" << endl;
}

auto main() -> int
{
     try
     {
         doit();
         return EXIT_SUCCESS;
     }
     catch( const exception& x )
     {
         cerr << "!" << x.what() << endl;
     }
     return EXIT_FAILURE;
}
---------------------------------------------------------------------


Main test case that 13 persons and max 4 per taxi gives 4 taxis, but 12 
persons and max 4 per taxi gives 3 taxis.


> The key fact is that given i, j, m, n as integral types and no overflow
> occurring.
> 
> If i = m / n and j = m % n
> then i * n + j == m
> 
> for j to always be positive, i needs to be the floor of the division,
> not from round to 0.
> 
> The key to remember is that % is NOT the modulus operator, but the
> remainder operator (which work the same for positive numbers).

Yes.


> It is simple enough to define a mod function that gets the results you
> want, so not that much need for a new operator.


---------------------------------------------------------------------
#include <iostream>
#include <stdexcept>
#include <stdlib.h>         // EXIT_..., div
#include <string>
using namespace std;

auto fail( const string& s ) -> bool { throw runtime_error( s ); }

auto line_from( istream& stream )
     -> string
{
     string result;
     getline( stream, result ) or fail( "Bah, getline" );
     return result;
}

auto input( const string& prompt )
     -> string
{
     cout << prompt;
     return line_from( cin );
}

namespace math
{
     auto is_negative( const int x )
         -> bool
     { return (x < 0); }

     auto div( const int a, const int b )
         -> int
     {
         const div_t r = ::div( a, b );
         return (r.quot < 0 and r.rem != 0? r.quot - 1 : r.quot);
     }

     auto mod( const int a, const int b )
         -> int
     { return a - b*div( a, b ); }
}  // namespace math

void doit()
{
     const int n_persons = stoi( input( "How many persons? " ) );
     const int max_per_taxi = stoi( input( "Maximum passengers per taxi? 
" ) );
     const int n_taxis = -math::div( -n_persons, max_per_taxi );
     cout << "You need " << n_taxis << " taxis. :)" << endl;
}

auto main() -> int
{
     try
     {
         doit();
         return EXIT_SUCCESS;
     }
     catch( const exception& x )
     {
         cerr << "!" << x.what() << endl;
     }
     return EXIT_FAILURE;
}

---------------------------------------------------------------------


Considering that what C++ offers over Python for this task, is strong 
type checking, I wonder if that extreme verbosity and effort is worth it?

Well I'm working on a little C++ band aid library that reduces the above to


---------------------------------------------------------------------
#include <cppx-band-aid/_all_.hpp>
namespace math = cppx::math;
using namespace std;
using cppx::input_line;

void doit()
{
     const int n_persons = stoi( input_line( "How many persons? " ) );
     const int max_per_taxi = stoi( input_line( "Maximum passengers per 
taxi? " ) );
     const int n_taxis = -math::div( -n_persons, max_per_taxi );
     cout << "You need " << n_taxis << " taxis. :)" << endl;
}

auto main() -> int { cppx::run_app( doit ); }
---------------------------------------------------------------------


Standardizing such band-aid functionality for students could be of 
interest to the new working group on supporting C++ in education. But I 
think I remember that they got a very narrow mandate, next to worthless?


Cheers!,

- Alf

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

#139218

On 12/27/18 21:34, Richard Damon wrote:
...
> It used to be that an implementation was allowed to define -1 % 10 to be
> 9, but they standard changed the rule for division so that that wasn't
> allowed anymore. (It required -1/10 == -1)

C90 allowed -1/10 to be either 0 or -1. C99 and later requires -1/10 to
be 0. In all versions of the standard, the values returned by the %
operator are defined by requiring that (a/b)*b + (a%b) == a.

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

#139240

On 12/29/18 4:04 PM, James Kuyper wrote:
> On 12/27/18 21:34, Richard Damon wrote:
> ...
>> It used to be that an implementation was allowed to define -1 % 10 to be
>> 9, but they standard changed the rule for division so that that wasn't
>> allowed anymore. (It required -1/10 == -1)
> 
> C90 allowed -1/10 to be either 0 or -1. C99 and later requires -1/10 to
> be 0. In all versions of the standard, the values returned by the %
> operator are defined by requiring that (a/b)*b + (a%b) == a.
> 

My comment meant that for -1 % 10 to be 9 required that -1/10 to be -1,
if -1/10 was 0 then -1 % 10 wouild need to be -1 (giving an example of
liking / and % )

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

#139153

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> I think C/C++ needs to have a range-aware modulo operator that will
> continue ranging properly when it encounters negative values.

It's just the modulus operator.  I don't think there's a need for
another name, but 'range-aware' seems like an odd suggestion.

Modern C's % is the remainder operator defined to complement C's integer
division: (a/b)*b + a%b = a.  (This was not guaranteed in C90.)

Some languages (e.g. Haskell) also have two division operators and two
corresponding 'remainder' operators.

  (a `quot` b) * b + (a `rem` b) == a
  (a `div`  b) * b + (a `mod` b) == a

> We have this:
>     i = (i + 1) % 10;   // Always ranges 0..9

except when i < -1.

<snip>
-- 
Ben.

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

#139154

On Fri, 28 Dec 2018 03:05:43 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>
>> I think C/C++ needs to have a range-aware modulo operator that will
>> continue ranging properly when it encounters negative values.
>
>It's just the modulus operator.  I don't think there's a need for
>another name, but 'range-aware' seems like an odd suggestion.
>
>Modern C's % is the remainder operator defined to complement C's integer
>division: (a/b)*b + a%b = a.  (This was not guaranteed in C90.)


I think that's wrong.  C89/90 did guarantee that relationship, but did
not guarantee the sign of the reminder.  IOW, -3/2 could result in
either -1 or -2, with a remainder of -1 or +1 respectively.  That
changed in C99.


>Some languages (e.g. Haskell) also have two division operators and two
>corresponding 'remainder' operators.
>
>  (a `quot` b) * b + (a `rem` b) == a
>  (a `div`  b) * b + (a `mod` b) == a
>
>> We have this:
>>     i = (i + 1) % 10;   // Always ranges 0..9
>
>except when i < -1.
>
><snip>


Forth does something similar.

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

#139157

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Fri, 28 Dec 2018 03:05:43 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> I think C/C++ needs to have a range-aware modulo operator that will
>>> continue ranging properly when it encounters negative values.
>>
>>It's just the modulus operator.  I don't think there's a need for
>>another name, but 'range-aware' seems like an odd suggestion.
>>
>>Modern C's % is the remainder operator defined to complement C's integer
>>division: (a/b)*b + a%b = a.  (This was not guaranteed in C90.)
>
> I think that's wrong.

So do I!

> C89/90 did guarantee that relationship, but did
> not guarantee the sign of the reminder.

Yes, I was remembering the wrong difference.  Thanks.

<snip>
-- 
Ben.

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

#139155

On Thursday, December 27, 2018 at 10:06:08 PM UTC-5, Ben Bacarisse wrote:
...
> Modern C's % is the remainder operator defined to complement C's integer
> division: (a/b)*b + a%b = a.  (This was not guaranteed in C90.)

No, that identity was guaranteed in C90. What wasn't guaranteed was the way that a/b gets rounded if either a or b are negative.

"If either operand is negative, whether the result of the / operator is the largest integer less than the algebraic quotient or the smallest integer greater than the algebraic quotient is implementation-defined, as is the sign of the result of the % operator.  If the quotient a/b is representable, the expression
(a/b)*b + a%b shall equal a." (C90 6.3.5)

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

#139156

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On Thursday, December 27, 2018 at 10:06:08 PM UTC-5, Ben Bacarisse wrote:
> ...
>> Modern C's % is the remainder operator defined to complement C's integer
>> division: (a/b)*b + a%b = a.  (This was not guaranteed in C90.)
>
> No, that identity was guaranteed in C90. What wasn't guaranteed was
> the way that a/b gets rounded if either a or b are negative.

You're right.  I was miss-emembering.  Thanks.

-- 
Ben.

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

#139161

On 28/12/2018 02:09, Rick C. Hodgin wrote:
> I think C/C++ needs to have a range-aware modulo operator that will
> continue ranging properly when it encounters negative values.
> 
> We have this:
>      i = (i + 1) % 10;   // Always ranges 0..9
> 
> But what if you try this when i = 0:
>      i = (i - 1) % 10;
> 
> It won't produce the same result in the same pattern seen when you
> started at a positive i and tended toward 0.  It begins a new trend,
> one which is useful, but not always desirable.
> 
> A range-aware modulo operator would know that it should always be
> in the range 0..9 (from the example above), and also that it should
> continue the pattern seen in the positive integers, such that when
> given a negative input value, it handles the processing differently:
> 
>      // v=value, m=modulo number
>      int range_modulo(int v, int m)
>      {
>          if (v >= 0)    return (v % m);
>          else           return ((m + (v % m)) % m);
>      }
> 
>      int i;
>      for (i = 12; i >= -12; --i)
>          printf("%d --> mod 10 = %d\n", i, range_modulo(i, 10));
> 
> -----
> I propose the -% symbol for the operator.
> 
> It would allow things that are sometimes needed in video games,
> as just one example, when a player hits the left button instead
> of the right button, and you need it to go the other way, AND you
> want it to just work while using the same math.

I used this loop to better show the differences:

     for (i = 12; i >= -12; --i) {
         if (i==0) puts("");
         printf("rmod(%3d,10) = %3d, %3d%%10 = %3d\n", i,
            range_modulo(i, 10),i,i%10);
         if (i==0) puts("");
     }

The % operator [which in my language is called 'rem'] shows symmetrical 
behaviour around zero, while your range_modulo doesn't.

Both behaviours are useful for different purposes. But the simplest 
thing to do is to just keep it as a function, as like that it will work 
/now/ on a hundred compilers.

"-%" is unlikely to ever work on any. Apart from which, there's already 
enough confusion as to exactly what "%" does, let alone "-%", especially 
with the /four/ combinations of negative operands.

(Note that when m is negative, eg. i/(-10), then both appear to have the 
same behaviour. The modulo nature of your range_modulo disappears. You 
may wish to use abs(m) inside that function, and perhaps re-apply the 
sign to the result, if that is important.)

-- 
bart

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

#139163

On 12/28/2018 7:29 AM, Bart wrote:
> On 28/12/2018 02:09, Rick C. Hodgin wrote:
>> I think C/C++ needs to have a range-aware modulo operator that will
>> continue ranging properly when it encounters negative values.
>>
>> We have this:
>>      i = (i + 1) % 10;   // Always ranges 0..9
>>
>> But what if you try this when i = 0:
>>      i = (i - 1) % 10;
>>
>> It won't produce the same result in the same pattern seen when you
>> started at a positive i and tended toward 0.  It begins a new trend,
>> one which is useful, but not always desirable.
>>
>> A range-aware modulo operator would know that it should always be
>> in the range 0..9 (from the example above), and also that it should
>> continue the pattern seen in the positive integers, such that when
>> given a negative input value, it handles the processing differently:
>>
>>      // v=value, m=modulo number
>>      int range_modulo(int v, int m)
>>      {
>>          if (v >= 0)    return (v % m);
>>          else           return ((m + (v % m)) % m);
>>      }
>>
>>      int i;
>>      for (i = 12; i >= -12; --i)
>>          printf("%d --> mod 10 = %d\n", i, range_modulo(i, 10));
>>
>> -----
>> I propose the -% symbol for the operator.
>>
>> It would allow things that are sometimes needed in video games,
>> as just one example, when a player hits the left button instead
>> of the right button, and you need it to go the other way, AND you
>> want it to just work while using the same math.
> 
> I used this loop to better show the differences:
> 
>      for (i = 12; i >= -12; --i) {
>          if (i==0) puts("");
>          printf("rmod(%3d,10) = %3d, %3d%%10 = %3d\n", i,
>             range_modulo(i, 10),i,i%10);
>          if (i==0) puts("");
>      }
> 
> The % operator [which in my language is called 'rem'] shows symmetrical 
> behaviour around zero, while your range_modulo doesn't.
> 
> Both behaviours are useful for different purposes. But the simplest thing to 
> do is to just keep it as a function, as like that it will work /now/ on a 
> hundred compilers.

I think -% is a truly fundamental operation and should have operator
support.  It has utility in various cases.

> "-%" is unlikely to ever work on any. Apart from which, there's already 
> enough confusion as to exactly what "%" does, let alone "-%", especially with 
> the /four/ combinations of negative operands.
> 
> (Note that when m is negative, eg. i/(-10), then both appear to have the same 
> behaviour. The modulo nature of your range_modulo disappears. You may wish to 
> use abs(m) inside that function, and perhaps re-apply the sign to the result, 
> if that is important.)

Interesting.  I've never used a negative value that way, so it never
occurred to me.

-- 
Rick C. Hodgin

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

#139167

On 12/28/18 8:10 AM, Rick C. Hodgin wrote:
> On 12/28/2018 7:29 AM, Bart wrote:
>> On 28/12/2018 02:09, Rick C. Hodgin wrote:
>>> I think C/C++ needs to have a range-aware modulo operator that will
>>> continue ranging properly when it encounters negative values.
>>>
>>> We have this:
>>>      i = (i + 1) % 10;   // Always ranges 0..9
>>>
>>> But what if you try this when i = 0:
>>>      i = (i - 1) % 10;
>>>
>>> It won't produce the same result in the same pattern seen when you
>>> started at a positive i and tended toward 0.  It begins a new trend,
>>> one which is useful, but not always desirable.
>>>
>>> A range-aware modulo operator would know that it should always be
>>> in the range 0..9 (from the example above), and also that it should
>>> continue the pattern seen in the positive integers, such that when
>>> given a negative input value, it handles the processing differently:
>>>
>>>      // v=value, m=modulo number
>>>      int range_modulo(int v, int m)
>>>      {
>>>          if (v >= 0)    return (v % m);
>>>          else           return ((m + (v % m)) % m);
>>>      }

In my mind, a cleaner (and actually working) version would be more like:

int modulo(int v, int m) {
   int mod = v % m;
   if (mod < 0) mod += m;
   return mod;
}

This will work even if v is less than -m and not need multiple divide
operations. (For machines with fast divide but bad behavior for
branching, your expression  (m + (v % m) % m could also be used all the
time, if you are going to use the conditional, you don't need the second
% if you do it right.

Neither of these work 'right' if m can be negative, and for that we need
to come up with a real definition of what it means to have a negative
modulus.

>>>
>>>      int i;
>>>      for (i = 12; i >= -12; --i)
>>>          printf("%d --> mod 10 = %d\n", i, range_modulo(i, 10));
>>>
>>> -----
>>> I propose the -% symbol for the operator.
>>>
>>> It would allow things that are sometimes needed in video games,
>>> as just one example, when a player hits the left button instead
>>> of the right button, and you need it to go the other way, AND you
>>> want it to just work while using the same math.
>>
>> I used this loop to better show the differences:
>>
>>      for (i = 12; i >= -12; --i) {
>>          if (i==0) puts("");
>>          printf("rmod(%3d,10) = %3d, %3d%%10 = %3d\n", i,
>>             range_modulo(i, 10),i,i%10);
>>          if (i==0) puts("");
>>      }
>>
>> The % operator [which in my language is called 'rem'] shows
>> symmetrical behaviour around zero, while your range_modulo doesn't.
>>
>> Both behaviours are useful for different purposes. But the simplest
>> thing to do is to just keep it as a function, as like that it will
>> work /now/ on a hundred compilers.
> 
> I think -% is a truly fundamental operation and should have operator
> support.  It has utility in various cases.

There are LOTS of operations that could be argued are worthy of operator
support for some applications. There actually is a language that tried
to give them all operator symbols, the language APL. Many consider APL a
write only language, because it can be nearly impossible to read and
understand a program written in APL if you didn't just write it recently.

Rather than create a bunch of new symbols as part of the language, I
have thought it would be interesting if C++ allowed the creation of new
operators with NAMES, like operator mod(int v, int m) so you could say
something like v mod m. You would need to be able to define their
'precedence' so the compiler would know how to parse the expression, the
simplest would likely be to define them to act like and existing type of
operator, so

> 
>> "-%" is unlikely to ever work on any. Apart from which, there's
>> already enough confusion as to exactly what "%" does, let alone "-%",
>> especially with the /four/ combinations of negative operands.
>>
>> (Note that when m is negative, eg. i/(-10), then both appear to have
>> the same behaviour. The modulo nature of your range_modulo disappears.
>> You may wish to use abs(m) inside that function, and perhaps re-apply
>> the sign to the result, if that is important.)
> 
> Interesting.  I've never used a negative value that way, so it never
> occurred to me.
> 

Let me make a small comment about what I see in CAlive. It seems that
you are trying to define what you want to call a 'Language' by going
something (a bit crudely) like:

Lets start with something like C (which I don't really fully
understand), and then remove these features that don't make sense to me
so I could never make them work right.

Lets then mix in some bits of C++, but not too much, because that
langauge is so complicated that I can't understand it much of it.

Lets then add in all sorts of nifty little micro-tricks that I wish were
in C and/or C++, not worrying about how they might interact.

I can't understand formal documentation, so I can't write anything like
that myself, so I will document the language as with just a list of the
Hodge-podge rules that I built it with, but that's ok, the formal
specification will be the program I will eventually write (which I guess
means there can't be problems in the language definition, as the
language definition will be exactly as what that implementation did)

I have nothing against the idea that you want to create this new
programming environment with all the nifty bells and whistles that you
want. When (and if) it is done, it may even be useful to others, IF you
are able to produce a coherent set of documentation that tells people
how to use it. What does bother me a bit is the idea that you have that
this is somehow something very important (or should be to others). From
what I have heard you describe, your Grand Design is enormous, and very
likely beyond your reach and ability.

There actually isn't anything wrong with aiming for something you likely
can't reach, as long at the journey to it is something that can be
worthwhile (as in the story of Don Quixote). The issues come when you
try to insist that others need to follow or value your efforts.

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

#139170

On 28/12/2018 15:25, Richard Damon wrote:
> On 12/28/18 8:10 AM, Rick C. Hodgin wrote:

> Rather than create a bunch of new symbols as part of the language, I
> have thought it would be interesting if C++ allowed the creation of new
> operators with NAMES, like operator mod(int v, int m) so you could say
> something like v mod m. You would need to be able to define their
> 'precedence' so the compiler would know how to parse the expression, the
> simplest would likely be to define them to act like and existing type of
> operator, so

I think, to start with, it would be more useful to have overloaded 
functions. That means you can write this new feature as mod(v,m), so no 
issues with precedence. And you don't get the problem of parsing an 
expression that looks like this:

    a b c d e f g h

of which some are variables, and some are operators (a mix of prefix, 
infix and postfix), but you have to resolve all of them before you can 
start to parse. (I understand one feature of CAlive is that definitions 
for all these can come later.)

This doesn't help the human reader much either.

> Let me make a small comment about what I see in CAlive.

> I have nothing against the idea that you want to create this new
> programming environment with all the nifty bells and whistles that you
> want. When (and if) it is done, it may even be useful to others, IF you
> are able to produce a coherent set of documentation that tells people
> how to use it. What does bother me a bit is the idea that you have that
> this is somehow something very important (or should be to others). From
> what I have heard you describe, your Grand Design is enormous, and very
> likely beyond your reach and ability.

I think the problem is also the proliferation of weird and wonderful 
features, which are hard to understand, look hard to use, and would make 
any code that uses them completely unreadable:

  https://groups.google.com/forum/#!forum/caliveprogramminglanguage

Whether these all these features can interact with each other is another 
matter.

-- 
bart

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

#139192

On 12/28/18 10:56 AM, Bart wrote:
> On 28/12/2018 15:25, Richard Damon wrote:
>> On 12/28/18 8:10 AM, Rick C. Hodgin wrote:
> 
>> Rather than create a bunch of new symbols as part of the language, I
>> have thought it would be interesting if C++ allowed the creation of new
>> operators with NAMES, like operator mod(int v, int m) so you could say
>> something like v mod m. You would need to be able to define their
>> 'precedence' so the compiler would know how to parse the expression, the
>> simplest would likely be to define them to act like and existing type of
>> operator, so
> 
> I think, to start with, it would be more useful to have overloaded
> functions. That means you can write this new feature as mod(v,m), so no
> issues with precedence. And you don't get the problem of parsing an
> expression that looks like this:
> 
>    a b c d e f g h
> 
> of which some are variables, and some are operators (a mix of prefix,
> infix and postfix), but you have to resolve all of them before you can
> start to parse. (I understand one feature of CAlive is that definitions
> for all these can come later.)
> 
> This doesn't help the human reader much either.
> 

First, yes using functions (as currently available) is currently
available, and in C++ you can use overloaded functions, and in C you can
use _Generics to build such expressions.

The issue is that building an equation with explicit function calls can
get hard to read also. That is why C++ included opererator overloading
and the C added _Generics. And expression like:

assign(d, mult( diff(ax, bx), diff(ay, by)));

just gets hard to read, compare to

d = (ax - bx) * (ay - by); is much clearer.

Yes, misused it can make things an unreadable mess, but an expression like

e(b(a, c(d)), g(f,h));

isn't really any more readable, maybe you know a bit more about what the
various symbols are, but you still need to explore each of them to
figure out what is what. Using good names is always important.

New operators, being effectively globals, would need to be used
sparingly, and well named.

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

#139193

On 28-12-2018 23:26, Richard Damon wrote:
> On 12/28/18 10:56 AM, Bart wrote:
>> On 28/12/2018 15:25, Richard Damon wrote:
>>> On 12/28/18 8:10 AM, Rick C. Hodgin wrote:
>>
>>> Rather than create a bunch of new symbols as part of the language, I
>>> have thought it would be interesting if C++ allowed the creation of new
>>> operators with NAMES, like operator mod(int v, int m) so you could say
>>> something like v mod m. You would need to be able to define their
>>> 'precedence' so the compiler would know how to parse the expression, the
>>> simplest would likely be to define them to act like and existing type of
>>> operator, so
>>
>> I think, to start with, it would be more useful to have overloaded
>> functions. That means you can write this new feature as mod(v,m), so no
>> issues with precedence. And you don't get the problem of parsing an
>> expression that looks like this:
>>
>>     a b c d e f g h
>>
>> of which some are variables, and some are operators (a mix of prefix,
>> infix and postfix), but you have to resolve all of them before you can
>> start to parse. (I understand one feature of CAlive is that definitions
>> for all these can come later.)
>>
>> This doesn't help the human reader much either.
>>
>
> First, yes using functions (as currently available) is currently
> available, and in C++ you can use overloaded functions, and in C you can
> use _Generics to build such expressions.
>
> The issue is that building an equation with explicit function calls can
> get hard to read also. That is why C++ included opererator overloading
> and the C added _Generics. And expression like:
>
> assign(d, mult( diff(ax, bx), diff(ay, by)));
>
> just gets hard to read, compare to
>
> d = (ax - bx) * (ay - by); is much clearer.
>
> Yes, misused it can make things an unreadable mess, but an expression like
>
> e(b(a, c(d)), g(f,h));
>
> isn't really any more readable, maybe you know a bit more about what the
> various symbols are, but you still need to explore each of them to
> figure out what is what. Using good names is always important.
>
> New operators, being effectively globals, would need to be used
> sparingly, and well named.
>
In a c newsgroup, why are you blabbering about c++?

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

#139174

On 12/28/2018 10:25 AM, Richard Damon wrote:
> ... The issues come when you
> try to insist that others need to follow or value your efforts.

Where have I ever insisted that anyone needs to follow or value my
efforts?  I have told people recently, "Don't use [CAlive]... You
won't hurt my feelings."

I have only ever asked people to come and help.  They will when
the time is right if this task is for me to complete.  If not, it
will still have been my best attempt at giving back to the Lord
what He first gave me, and there is no failure in that pursuit.

-----
If you'd like to help formalize CAlive's design, come on board
and do so.  It's not my forte, but I know it's other people's.
I truly admire people like Keith Thompson, who can have so much
of the standard memorized and be able to recall it appropriately
on command.  I am that way on Star Trek in many areas. :-)  But,
not for things I must read to absorb.

I welcome people to come on board and help.  It's a design given
over to holiness and prayer, serving the Lord's goals in this
world, meaning we don't go by a pursuit of profit-seeking, or
money-making.  We are designing things correctly from inception,
with the goal being truly to empower people by giving them the
source code in the Public Domain.  It is a goal to replace busi-
ness models with helping-one-another models.  It is a goal to
use our talents to remove the burdens and shackles of proprietary
software and hardware models (as my goals extend not just to
CAlive and RDC, but also to a new operating system (one similar
to a modernized version of OS/2), as well as new hardware (I have
a CPU design called Inspire that's revolutionary in how it ap-
proaches data processing), and I want to provide people with a
full hardware and software stack that allows us to manufacture
things together, for one another, and not for avarice, greed, or
personal gain, but that our gains would all come in helping one
another achieve more and succeed in their personal goals and in-
terests, and then to teach them to have the same goals and inter-
ests in the things they pursue in their life.

It's a goal of togetherness.  It's the motto I've used since
about 2013 on my project:

     In God's sight, we've come together.
     We've come together to help each other.
     Let's grow this project up ... together!
     In service and Love to The Lord, forever

It is a full-on vision of "Thy Kingdom come, Thy will be done,
on Earth as it is in Heaven."

These are the areas to which I have interest and expertise.  I
pursue them, but my goals are to teach other people to use their
personal interests and areas of expertise to serve the Lord from
where they are, in their station, with their calling.

It is a grand vision.  It is in my heart, soul, mind, and pressed
hard upon my spirit ... and I am pursuing it.  Others will come
on board to help when they are so moved to do so.

-- 
Rick C. Hodgin

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

#139178

On 12/28/2018 10:25 AM, Richard Damon wrote:
>>> On 28/12/2018 02:09, Rick C. Hodgin wrote:
>>>>       // v=value, m=modulo number
>>>>       int range_modulo(int v, int m)
>>>>       {
>>>>           if (v >= 0)    return (v % m);
>>>>           else           return ((m + (v % m)) % m);
>>>>       }
> 
> In my mind, a cleaner (and actually working) version would be more like:
> 
> int modulo(int v, int m) {
>     int mod = v % m;
>     if (mod < 0) mod += m;
>     return mod;
> }
> 
> This will work even if v is less than -m and not need multiple divide
> operations. (For machines with fast divide but bad behavior for
> branching, your expression  (m + (v % m) % m could also be used all the
> time, if you are going to use the conditional, you don't need the second
> % if you do it right.
> 
> Neither of these work 'right' if m can be negative, and for that we need
> to come up with a real definition of what it means to have a negative
> modulus.

I'm all for creating an encompassing algorithm.  I only ever use a
positive m in my code, and my values of v should never be more than
relatively small integers away from 0 positive or negative, so it's
not a large need in my specific task.  But, if it works another way,
I'm all for it.

>> I think -% is a truly fundamental operation and should have operator
>> support.  It has utility in various cases.
> 
> There are LOTS of operations that could be argued are worthy of operator
> support for some applications. There actually is a language that tried
> to give them all operator symbols, the language APL. Many consider APL a
> write only language, because it can be nearly impossible to read and
> understand a program written in APL if you didn't just write it recently.
> 
> Rather than create a bunch of new symbols as part of the language, I
> have thought it would be interesting if C++ allowed the creation of new
> operators with NAMES, like operator mod(int v, int m) so you could say
> something like v mod m. You would need to be able to define their
> 'precedence' so the compiler would know how to parse the expression, the
> simplest would likely be to define them to act like and existing type of
> operator, so

How many new symbols have I created, or implemented in CAlive?

When I post things here, it is to gain knowledge about C/C++, so I can
learn something I may not know (most times I'm pretty sure the thing
I'm in pursuit of doesn't already exist) ... and then also to convey
the thought I have so that other people can take it, modify it, extend
it, revise it, and implement it however they want to.

With CAlive, I'm moving forward as I am doing.  With C/C++, these are
all offerings given to spark the minds and creative resources of those
people involved in authoring their compilers for those languages, or
those who are influential in moving things this way or that way within
the ecosystem.

People are free to disregard (or mock, as Leigh does), my posts to their
full pleasure.  While it sometimes hurts and is annoying, I'm pretty
tough.  I can take it.  I have a solid foundation in knowing who it is
I serve, and my goals are to please Him first, the rest of the world
will either see value in what I do/post or not.  That's not up to me.
I do my best at all points continuously, and I still fail a lot.  But
my heart's intent is right, true, proper, and is becoming even more
honed over time.  It is from that place, sanctified and focused unto
the Lord, that I continue with all of these efforts.

It's a real thing.  Not a trifle.  Not a joke.  Not a delusion.  And
I do not have one negative thing at work in any of my intents or
goals.  I may make mistakes, but that's different from a purposeful
intent away from doing all things positive.

I stand before the Lord regularly in prayer asking Him if this is for
me to do, being willing many times to walk away from it all because it
is such a big task.  Every time, literally every time I've begun to
have those thoughts, something comes along to re-encourage me, and I
go back into prayer and again ask the Lord if I am to continue as I
press in again toward the goal.

My life is not just lived.  I have a purpose in the things I do.  They
are not for trivial wants, wishes, desires, etc.  I am truly seeking
to give the world something better than it has, and to lift people up
from their pressed-down place by entities that focus on money-interests,
on proprietary goals.  I am seeking to free everyone from those chains
with my labor, my talent focused to improve and augment and enhance
their personal lives.

It is a proper goal on all accounts, and it's the one I've been pursu-
ing now for seven years this Spring, and formally as an effort seven
years on July 12, 2019.

-- 
Rick C. Hodgin

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

#139191

On 12/28/18 12:16 PM, Rick C. Hodgin wrote:
> On 12/28/2018 10:25 AM, Richard Damon wrote:
>>>> On 28/12/2018 02:09, Rick C. Hodgin wrote:
>>>>>       // v=value, m=modulo number
>>>>>       int range_modulo(int v, int m)
>>>>>       {
>>>>>           if (v >= 0)    return (v % m);
>>>>>           else           return ((m + (v % m)) % m);
>>>>>       }
>>
>> In my mind, a cleaner (and actually working) version would be more like:
>>
>> int modulo(int v, int m) {
>>     int mod = v % m;
>>     if (mod < 0) mod += m;
>>     return mod;
>> }
>>
>> This will work even if v is less than -m and not need multiple divide
>> operations. (For machines with fast divide but bad behavior for
>> branching, your expression  (m + (v % m) % m could also be used all the
>> time, if you are going to use the conditional, you don't need the second
>> % if you do it right.
>>
>> Neither of these work 'right' if m can be negative, and for that we need
>> to come up with a real definition of what it means to have a negative
>> modulus.
> 
> I'm all for creating an encompassing algorithm.  I only ever use a
> positive m in my code, and my values of v should never be more than
> relatively small integers away from 0 positive or negative, so it's
> not a large need in my specific task.  But, if it works another way,
> I'm all for it.
> 
>>> I think -% is a truly fundamental operation and should have operator
>>> support.  It has utility in various cases.
>>
>> There are LOTS of operations that could be argued are worthy of operator
>> support for some applications. There actually is a language that tried
>> to give them all operator symbols, the language APL. Many consider APL a
>> write only language, because it can be nearly impossible to read and
>> understand a program written in APL if you didn't just write it recently.
>>
>> Rather than create a bunch of new symbols as part of the language, I
>> have thought it would be interesting if C++ allowed the creation of new
>> operators with NAMES, like operator mod(int v, int m) so you could say
>> something like v mod m. You would need to be able to define their
>> 'precedence' so the compiler would know how to parse the expression, the
>> simplest would likely be to define them to act like and existing type of
>> operator, so
> 
> How many new symbols have I created, or implemented in CAlive?
> 

Looking over the past 6 months of messages, I see suggested:

min/max: \/  /\  \/=  /\=
swap:    ><
shortcut indirect: ~> which later became ~~
modulus:  -%

and that doesn't count syntax changes like a < b < c

I don't know how many have actually been implemented (and is CAlive
actually far enough along to 'implement' something?

> When I post things here, it is to gain knowledge about C/C++, so I can
> learn something I may not know (most times I'm pretty sure the thing
> I'm in pursuit of doesn't already exist) ... and then also to convey
> the thought I have so that other people can take it, modify it, extend
> it, revise it, and implement it however they want to.
> 

But you DON'T ask to gain knowledge. You post that there should be a way
to do xyz, and then state how you think it will work in CAlive.

> With CAlive, I'm moving forward as I am doing.  With C/C++, these are
> all offerings given to spark the minds and creative resources of those
> people involved in authoring their compilers for those languages, or
> those who are influential in moving things this way or that way within
> the ecosystem.
> 
> People are free to disregard (or mock, as Leigh does), my posts to their
> full pleasure.  While it sometimes hurts and is annoying, I'm pretty
> tough.  I can take it.  I have a solid foundation in knowing who it is
> I serve, and my goals are to please Him first, the rest of the world
> will either see value in what I do/post or not.  That's not up to me.
> I do my best at all points continuously, and I still fail a lot.  But
> my heart's intent is right, true, proper, and is becoming even more
> honed over time.  It is from that place, sanctified and focused unto
> the Lord, that I continue with all of these efforts.

But this is comp.lang.c and comp.lang.c++ so extensive discussion of
CAlive is really off topic in both of these, as CAlive is NOT either of
these languages, or even a minor variation/extension on it like gcc
c/c++ (many of those extension are still conformant to the C/C++
Standards.)

You seem to want to pretend that you are offering 'legitimate' ideas for
extensions to C and/or C++ but seem to have zero understanding of the
hows and whys these languages are the way they are, and you don't seem
to care.

It would be one thing if you came here asking HOW to implement some
feature of CAlive in your chosen implementation language in the
appropriate group (but choose the language to use, and thus the group to
ask, as things are done significantly differently between those two
languages).

You could also ask about general language design issues in a different
appropriate group (NOT clc or clc++).

> 
> It's a real thing.  Not a trifle.  Not a joke.  Not a delusion.  And
> I do not have one negative thing at work in any of my intents or
> goals.  I may make mistakes, but that's different from a purposeful
> intent away from doing all things positive.
> 
> I stand before the Lord regularly in prayer asking Him if this is for
> me to do, being willing many times to walk away from it all because it
> is such a big task.  Every time, literally every time I've begun to
> have those thoughts, something comes along to re-encourage me, and I
> go back into prayer and again ask the Lord if I am to continue as I
> press in again toward the goal.
> 
> My life is not just lived.  I have a purpose in the things I do.  They
> are not for trivial wants, wishes, desires, etc.  I am truly seeking
> to give the world something better than it has, and to lift people up
> from their pressed-down place by entities that focus on money-interests,
> on proprietary goals.  I am seeking to free everyone from those chains
> with my labor, my talent focused to improve and augment and enhance
> their personal lives.
> 
> It is a proper goal on all accounts, and it's the one I've been pursu-
> ing now for seven years this Spring, and formally as an effort seven
> years on July 12, 2019.
> 

Scripture tells us to obey the rules of the land. The one exception
given is if those rules tell you to do something that directly
contradicts a rule of God. One of these rules is that these groups have
a defined topic space, which is discussion of things closely related to
the C or C++ languages and their use. Unless you can find some direct
command of God that following this rule will make you violate, you
should try to follow that rule, for to do otherwise inflicts a bad
report onto your God.

Your posts as 'offerings' are really nothing but SPAM, which is not
something I think God wants, nor does he want to be thought of as
connected to a spammer.

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

#139194

Richard Damon <Richard@Damon-Family.org> writes:

[...]

> Your posts as 'offerings' are really nothing but SPAM, which is
> not something I think God wants, nor does he want to be thought of
> as connected to a spammer.

Please stop responding to him.  Anyone responding to his postings
only makes things worse.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web