Greg Herlihy wrote:
..
> A C++ implementation is apparently free to choose which type of
> remainder to return in the second example above:
>
> "If both operands [of the / or % operator] are nonnegative then the
> remainder is nonnegative; if not, the sign of the remainder is
> implementation-defined." [   5.6]

Note that this is a carry over from C90. In C99, it was decided to make
this standard-defined.  integer division rounds toward zero, and the
modulus operator is defined to be consistent with the division operator
in the sense that a == b*(a/b)+a%b. I would expect, with C99 making
this standard defined, that C++ compilers which can also compile C99
would define division the same way in both languages, and that future
versions of C++ will adopt C99's definition.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Pete Becker wrote:
> Greg Herlihy wrote:

> > Fortunately, such concerns are misplaced. With regard to the
> > "division-related" operators, it is the Standard's pragmatism that is
> > being showcased: given all the centuries that mathematicians have spent
> > trying to sort these operators out - and not even reaching agreement on
> > how many there are and what to call them - then there is a very real
> > possibility that we will never know what the operator is called or what
> > it does - or at least not in time to squeeze those answeers into the
> > next C++ Standard.

> I don't know about all that, but the reason that the sign of the
> remainder is not specified when either of the operands is negative is
> simply that different hardware uses different conventions.

Or at least it was so believed (and was perhaps true in the
past).  The fact that Fortran specifies it means that pratically
speaking, all hardware designed since the advent of Fortran does
do pretty much the same thing.

C99 has taken the step to define it.  Somehow, I had thought
that C++ had followed, and that it would be defined in the next
version of the standard.  Is this a C compatibility issue that
somehow slipped under the radar?  Or did the committe consider
the question, and actively decide not to follow C in this?

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
>
> C99 has taken the step to define it.  Somehow, I had thought
> that C++ had followed, and that it would be defined in the next
> version of the standard.  Is this a C compatibility issue that
> somehow slipped under the radar?  Or did the committe consider
> the question, and actively decide not to follow C in this?
>

The current working draft has the same words as before: the sign of the
remainder is implementation defined. I don't know if there's any
consideration being given to changing this.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 5 jan, 17:41, "Pedro Lamar   o" <pedro.lama...@gmail.com> wrote:
>
> So let's have only a functor called "xor", because we have only one
> xor operator.
>
> Or let's define "bitwise_xor" and "logical_xor" to mean exactly the
> same
> thing for the sake of completeness. People could just disable them
> by specialization if they want to forbid possible ugly code
> like bitwise_xor(set1, set2).
>
> Or let's introduce a new logical xor operator ^^ meant for the sake of
> set like types and expression template libraries. I bet they would love
> to have more operators to play around with.

Or maybe there is another understanding of these, for the sake of
nomenclature, that's even better.

We call these operators bitwise because they operate on integers as a
string of bits; integers, in this regard, appear as a sequence of bits;
or a set of bits-in-position.

So we may call these operators set operators, and call these functors
set_and, set_or, set_not and set_xor directly.

I'd like to try and write this thing up.
Is there a style sheet somewhere I can follow?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Kuyper wrote
> Greg Herlihy wrote:
> ..
> > A C++ implementation is apparently free to choose which type of
> > remainder to return in the second example above:
> >
> > "If both operands [of the / or % operator] are nonnegative then the
> > remainder is nonnegative; if not, the sign of the remainder is
> > implementation-defined." [=A75.6]
>
> Note that this is a carry over from C90. In C99, it was decided to make
> this standard-defined.  integer division rounds toward zero, and the
> modulus operator is defined to be consistent with the division operator
> in the sense that a =3D=3D b*(a/b)+a%b. I would expect, with C99 making
> this standard defined, that C++ compilers which can also compile C99
> would define division the same way in both languages, and that future
> versions of C++ will adopt C99's definition.
>

Yes I saw this now too in 6.5.5 of n1124. The "fractional part discarded"=
 is
equivalent with "truncated towards zero" (rather than "rounded towards ze=
ro"
in the footnote, because that could also be on a half). The only thing is
that the % operator is the remainder operator, not modulus operator, beca=
use
modulus (or modulo) follows a different truncation rule, as mentioned abo=
ve.
In [expr.mul] % is called remainder, not modulus or modulo. There are man=
y x
and y for which x rem y !=3D x mod y.
Actually I find all names of the function objects strange. "x divides y"
means "x % y =3D=3D 0" in mathematics. And "negate x" means "change the s=
ign of
x" and not "return -x". "plus" and "minus" are simply the + and - signs.
To prevent this confusion I would qualify the function object by insertin=
g
"function_" before the name, for distinguishing it with ordinary member
functions. So that would yield:
function_negate, function_abs, function_increment, function_decrement,
function_add, function_subtract, function_product, function_quotient,
function_remainder, function_shift_left, function_shift_right,
function_bitwise_and, function_bitwise_or, function_bitwise_xor,
function_bitwise_not.
These names are a little bit longer, but in my opinion more clear to the
user what they stand for.
Predicates are similar: equal_to looks more like a member function to me.
Personally I would also insert function_ before those.
Maarten.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Adding to my previous comment:
Just realized that operator[] could also be added to the function objects as
function_array. This may be useful when searching in a STL container for
example for strings with a certain letter at a certain position, or for
vectors with a certain value in a certain element.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

    Pedro Lamar   o wrote:

> logical xor: absent

logical xor: !=

.. Jonathan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

I've seen several posts in the past questioning why there aren't any of
the following in the standard library:

std::bitwise_and
std::bitwise_or
std::bitwise_xor
std::bitwise_not

.but none of them were satisfactorily answered.  I'll ask one more
time before attempting to actually make a proposal to the committee.
Does anyone know a reason why I should not waste my time?

Aaron

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Aaron Graham"  wrote
> I've seen several posts in the past questioning why there aren't any of
> the following in the standard library:
>
> std::bitwise_and
> std::bitwise_or
> std::bitwise_xor
> std::bitwise_not
>
> .but none of them were satisfactorily answered.  I'll ask one more
> time before attempting to actually make a proposal to the committee.
> Does anyone know a reason why I should not waste my time?

Are you referring to <functional>?
In that case on the contrary, and you might as well add:
increment     effect: param + 1 (can also be made with
bind2nd(plus<type>(),1))
decrement    effect: param - 1 (can also be made with
bind2nd(minus<type>(),1))
shift_left       effect: param1 << param2
shift_right     effect: param1 >> param2
Under [arithmetic.operations] it reads:
"The library provides basic function object classes for all of the
arithmetic operators in the language."
When you consider the above as "arithmetic", then they should be added.
Also note that "modulus" should be "remainder",
because a % b is the remainder of the division a / b:
a % b = a - b * ( a / b )
where a / b is truncated towards zero.
For modulus, a / b should truncated downward (toward minus infinity),
which it doesn't.
Perhaps they will correct this as these are seldomly used.
Regards, Maarten.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Maarten Kronenburg" wrote:
> "Aaron Graham"  wrote
> > I've seen several posts in the past questioning why there aren't any of
> > the following in the standard library:
> >
> > std::bitwise_and
> > std::bitwise_or
> > std::bitwise_xor
> > std::bitwise_not

One issue is that some of these proposed function object names could
correlete better with the name of the operator it represents. For
example, consider the corresponding list of operator names:

   bitand
   bitor
   xor
   compl

Now, the operator names suggest to me that only the first two are
conceptually "bitwise" operators. And certainly xor-ing or
complement-ing typically involve set operands - and not the integer
operands that are found in C++.

In fact, I believe that last observation may lead to the reason why
these particular operators (along with the bitshift operators) have no
corresponding function objects in the Standard library: namely that an
overloaded version of any one of these operators is likely to perform
an operation conceptually unrelated to the built-in operator. For
example, a program may overload xor and complement to apply to objects
representing sets - and thefore calling these two "bitwise" operators
would be inaccurate and possibly confusing. In other words the user
would have to define their own function objects with better names
anyway, so the availability of standard function objects for these
operators would probably not be useful in the majority of applications
that overload these operators.

Now, of course the user can always overload any operator to perform any
kind of operation without regard to that operator's built-in semantics
- but any confusion which arises by doing so would be of the user's own
making, and not one the Library itself created or facilitated.

> > .but none of them were satisfactorily answered.  I'll ask one more
> > time before attempting to actually make a proposal to the committee.
> > Does anyone know a reason why I should not waste my time?
>
> Are you referring to <functional>?
> In that case on the contrary, and you might as well add:
> increment     effect: param + 1 (can also be made with
> bind2nd(plus<type>(),1))
> decrement    effect: param - 1 (can also be made with
> bind2nd(minus<type>(),1))

These function objects would not correspond to any built-in increment
or decrement operators in C++ so there is no reason that they should be
added. As for the post- and pre- increment and decrement operators
(which can be overloaded), because they modify their operands,
corresponding function objects would not be able to accept the const
operands that they are expected to accept.

> shift_left       effect: param1 << param2
> shift_right     effect: param1 >> param2

As noted above, the Standard library has appropriated the shift
operators as I/O operators for certain types. Therefore the effect of
applying a "shift_left" or "shift_right" function objects with certain
library types as operands would not result in "shifting" those operands
in any meaningful sense.

> Under [arithmetic.operations] it reads:
> "The library provides basic function object classes for all of the
> arithmetic operators in the language."
> When you consider the above as "arithmetic", then they should be added.
> Also note that "modulus" should be "remainder",
> because a % b is the remainder of the division a / b:
> a % b = a - b * ( a / b )
> where a / b is truncated towards zero.

The name of the function object describes the nature of the operation
and not its result. Otherwise, the "plus" function object would be
named "sum" and "multiplies" would be named "product". Now I do think
that one could argue that the modulus function object would be more
aptly named "modulo", since the operation represented is "x modulo y"
(with y being the modulus), but I don't see a strong case for renaming
the object "remainder", even though it produces the remainder of a
division.

Greg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 5 jan, 16:18, "Greg Herlihy" <gre...@pacbell.net> wrote:
> "Maarten Kronenburg" wrote:
> > "Aaron Graham"  wrote
> > > I've seen several posts in the past questioning why there aren't any of
> > > the following in the standard library:
>
> > > std::bitwise_and
> > > std::bitwise_or
> > > std::bitwise_xor
> > > std::bitwise_not
>
> One issue is that some of these proposed function object names could
> correlete better with the name of the operator it represents. For
> example, consider the corresponding list of operator names:
>
>    bitand
>    bitor
>    xor
>    compl
>
> Now, the operator names suggest to me that only the first two are
> conceptually "bitwise" operators. And certainly xor-ing or
> complement-ing typically involve set operands - and not the integer
> operands that are found in C++.

But we do have a logical complement operator, don't we?
So the only operator where we have such confusion is the xor operator.

If a program needs set set complement, it can just overload operator! .
Or am I missing something?

What I mean is the confusing you mention in the next paragraph
comes from the fact we have only one operator in the language
meaning xor.

All others have a logical and bitwise variety:

logical and: &&
bitwise and: &

logical or: ||
bitwise or: |

logical not: !
bitwise not: ~

logical xor: absent
bitwise xor: ^

> In fact, I believe that last observation may lead to the reason why
> these particular operators (along with the bitshift operators) have no
> corresponding function objects in the Standard library: namely that an
> overloaded version of any one of these operators is likely to perform
> an operation conceptually unrelated to the built-in operator. For
> example, a program may overload xor and complement to apply to objects
> representing sets - and thefore calling these two "bitwise" operators
> would be inaccurate and possibly confusing. In other words the user
> would have to define their own function objects with better names
> anyway, so the availability of standard function objects for these
> operators would probably not be useful in the majority of applications
> that overload these operators.

So let's have only a functor called "xor", because we have only one
xor operator.

Or let's define "bitwise_xor" and "logical_xor" to mean exactly the
same
thing for the sake of completeness. People could just disable them
by specialization if they want to forbid possible ugly code
like bitwise_xor(set1, set2).

Or let's introduce a new logical xor operator ^^ meant for the sake of
set like types and expression template libraries. I bet they would love
to have more operators to play around with.

--
 Pedro Lamar   o


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Greg Herlihy"  wrote
> "Maarten Kronenburg" wrote:
> > Under [arithmetic.operations] it reads:
> > "The library provides basic function object classes for all of the
> > arithmetic operators in the language."
> > When you consider the above as "arithmetic", then they should be added.
> > Also note that "modulus" should be "remainder",
> > because a % b is the remainder of the division a / b:
> > a % b = a - b * ( a / b )
> > where a / b is truncated towards zero.
>
> The name of the function object describes the nature of the operation
> and not its result. Otherwise, the "plus" function object would be
> named "sum" and "multiplies" would be named "product". Now I do think
> that one could argue that the modulus function object would be more
> aptly named "modulo", since the operation represented is "x modulo y"
> (with y being the modulus), but I don't see a strong case for renaming
> the object "remainder", even though it produces the remainder of a
> division.
>

The operation represented is x rem y (or x % y), and not x mod y.
The first is the remainder of division, the second is the mathematical
modulus.
The only book that I can find where the distinction between rem and mod is
very clear is:
Modern Computer Algebra, by Von zur Gathen and Gerhard,
Cambridge, 2nd ed. 2003, pp 696-697.
The term is_modulo in numeric_limits however is correct.
The reason of the confusion is that both rem (%) and mod appear in the
standard, but the distinction is not made clear there. The problem is also
that some other books use them wrongly.
Maarten.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

I would also miss the roll operators, e.g. formulated in the posted
notation:

std::bitwise_rol
std::bitwise_ror

and perhaps

std::bitwise_shift_left_fill_one
(std::bitwise_shift_left_fill_zero)
std::bitwise_shift_right_fill_one
(std::bitwise_shift_right_fill_zero)

Peter

"Aaron Graham" <atgraham@gmail.com> schrieb im Newsbeitrag
news:1167831904.975273.7730@h40g2000cwb.googlegroups.com...
> I've seen several posts in the past questioning why there aren't any of
> the following in the standard library:
>
> std::bitwise_and
> std::bitwise_or
> std::bitwise_xor
> std::bitwise_not
>
> .but none of them were satisfactorily answered.  I'll ask one more
> time before attempting to actually make a proposal to the committee.
> Does anyone know a reason why I should not waste my time?
>
> Aaron
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In addition to my previous comments:
Just adding some examples, see also:
http://www.cs.berkeley.edu/titan/sww/software/man/ansicl/dictentr/modrem.htm
1 rem 5 = 1
1 mod 5 = 1
-1 rem 5 = -1
-1 mod 5 = 4
where rem is equivalent to %.
As mentioned, rem is the remainder of division truncated towards zero, and
mod is the "remainder" of division truncated downward, that is towards minus
infinity.
In [expr.mul] in the standard, there is the footnote 78, pointing to the
correct definition of division (rounding toward zero), but unfortunately not
of the remainder. The remainder with the wrong sign is in my opinion no
longer the remainder.
The argument that shift_left and shift_right should be omitted because <<
and >> can also be stream inserters and extractors, is in my opinion not
applicable, because for example * doesn't have any meaning in combination
with streams, and is not omitted, and the STL containers where the function
objects are applied seldomly contain streams as elements. Therefore in my
opinion this argument against shift_left and shift_right is far fetched.
The names bitand and bitor would signify the and or or of one single bit.
Therefore in my opinion the names bitwise_and, bitwise_or, bitwise_xor and
bitwise_not should be preferred.
Maarten.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

""Peter St=F6cklein""  wrote
> I would also miss the roll operators, e.g. formulated in the posted
> notation:
>
> std::bitwise_rol
> std::bitwise_ror
>
> and perhaps
>
> std::bitwise_shift_left_fill_one
> (std::bitwise_shift_left_fill_zero)
> std::bitwise_shift_right_fill_one
> (std::bitwise_shift_right_fill_zero)
>
The function objects in <functional> can only use functions or operators
that are already supported in C++, like for example << and >> or &, |, ^ =
and
~. The functions you require are not supported in the current C++, and ma=
y
even not be supported by the processor it is running on.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Maarten Kronenburg" wrote:
> In addition to my previous comments:
> Just adding some examples, see also:
> http://www.cs.berkeley.edu/titan/sww/software/man/ansicl/dictentr/modrem.htm
> 1 rem 5 = 1
> 1 mod 5 = 1
> -1 rem 5 = -1
> -1 mod 5 = 4
> where rem is equivalent to %.
> As mentioned, rem is the remainder of division truncated towards zero, and
> mod is the "remainder" of division truncated downward, that is towards minus
> infinity.
> In [expr.mul] in the standard, there is the footnote 78, pointing to the
> correct definition of division (rounding toward zero), but unfortunately not
> of the remainder. The remainder with the wrong sign is in my opinion no
> longer the remainder.

A C++ implementation is apparently free to choose which type of
remainder to return in the second example above:

"If both operands [of the / or % operator] are nonnegative then the
remainder is nonnegative; if not, the sign of the remainder is
implementation-defined." [   5.6]

So the good news is that you merely have to find a different C++
compiler - one in which the % operator returns the result that you
like.

Granted, it may strike some as odd that a computer programming language
would include an arithmatic operator but leave its behavior up to
someone else. And after all if the C++ can't seem to agree on the
behavior of basic arithmatic operators, then what prospect would appear
to exist for agreement on the rest of the language?

Fortunately, such concerns are misplaced. With regard to the
"division-related" operators, it is the Standard's pragmatism that is
being showcased: given all the centuries that mathematicians have spent
trying to sort these operators out - and not even reaching agreement on
how many there are and what to call them - then there is a very real
possibility that we will never know what the operator is called or what
it does - or at least not in time to squeeze those answeers into the
next C++ Standard.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:
>
> Fortunately, such concerns are misplaced. With regard to the
> "division-related" operators, it is the Standard's pragmatism that is
> being showcased: given all the centuries that mathematicians have spent
> trying to sort these operators out - and not even reaching agreement on
> how many there are and what to call them - then there is a very real
> possibility that we will never know what the operator is called or what
> it does - or at least not in time to squeeze those answeers into the
> next C++ Standard.
>

I don't know about all that, but the reason that the sign of the
remainder is not specified when either of the operands is negative is
simply that different hardware uses different conventions.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]