Title: Open Issues for Numerics Libraries (Chapter 26) Author: Judy Ward Document Number: X3J16/95-0037 WG21/N0637 Work Group: Library Clause 26 Issue Number: 001 Title: Should complex operator arguments be ref or not? Section: 26.1 New Status: active Description: There seems to be a minor inconsistency in the complex number classes (94-0164 / N0551). The templates which provide for mixed complex & scalar operations are not consistent as to whether their non-complex parameter is passed by reference: template int operator==(T, const complex&); template complex operator+ (const T &, const complex&); I don't see why the first parameter is passed by value for "==" and by reference for "+". If "T" is always intended to be a scalar type (float, double, long double) then it makes more sense to pass by value. If "T" could be a non-scalar type (my_long_precision_type), then it makes more sense to pass by reference. But this reasoning applies equally well to "==" and "+", so shouldn't they be consistent? Since the primary uses of complex are based on scalar types, I think all instances of "const T&" should be changed to "T". Bill Gibbons bgibbons@taligent.com Resolution: see proposed resolution above. Requestor: Bill Gibbons Owner: Judy Ward Emails: (email reflector messages that discuss this issue) Papers: (committee documents that discuss this issue) Work Group: Library Clause 26 Issue Number: 002 Title: Should complex insertion operator be allowed to take scalar input? Section: 26.1.1.2.8 New Status: active Description: The current working draft gives an implementation as a way of describing the semantics of the insertion operator for complex. The implementation 1. does not address what happens on error and 2. does not allow a scalar input. i.e. this would be allowed: (2.0 + 0.0) but not: (2.0) or: 2.0 Since you can create a complex with just a scalar, it seems consistent to be able to use the insertion operator to allow the the second form above. Also, there are no semantics defined for bad input. Resolution: Proposed resolution: specify the following semantics for operator>> istream& operator>>(istream& is, T& x); reads a complex number x of in the form u, (u), or (u,v) where u is the real part and v is the imaginary part. If bad input is encountered, the ios::badbit flag is set. Requestor: Judy Ward Owner: Judy Ward Emails: (email reflector messages that discuss this issue) c++std-lib-3067 c++std-lib-3070 c++std-lib-3099 c++std-lib-3102 Papers: (committee documents that discuss this issue) Work Group: Library Clause 26 Issue Number: 003 Title: Should complex real() and imag() be member functions or friends? Section: 26.1.1.2.8 New Status: active Description: In document 94-0204 (the amendment to document N0551) the real() and imag() member functions are described as members. This paper said the original document had omitted them, which is not true. The original document had them as friends, thus having the interface to them be: real(c); rather than: c.real(); The first interface is the one I've found to be used in existing libraries (Rogue Waves, AT&T's, etc.) So I think we should stick with it. The amendment also left out the fact that all the numerous mathematical functions which use the private parts of the complex have to be specialized for float, double and long double. Resolution: Proposed resolution: Keep real() and imag() as global. Requestor: Judy Ward Owner: Judy Ward Emails: (email reflector messages that discuss this issue) c++std-lib-3067 c++std-lib-3070 c++std-lib-3071 c++std-lib-3072 c++std-lib-3083 Papers: (committee documents that discuss this issue) Work Group: Library Clause 26 Issue Number: 004 Title: should typedefs be provided in complex for backward compatability? Section: 26.1 New Status: active Description: To: C++ libraries mailing list Message c++std-lib-3190 The WP in many places (e.g. clause 14) uses class complex , to mean what it always used to mean. I'm not up-to-date with the very latest complex proposal, but I'm not sure that it supports this old usage. This observation comes with a proposal: provide something like typedef double_complex complex; for backward compatibility. Don't use complex as a template name, use some slightly different name. Taking away complex will penalize exactly those C++ pioneers who have made use of the (ten years?) existing implementations. However, if this suggestion is rejected, and complex is no longer available for its old uses, then Andy probably needs to grep the language portions for complex and make a suitable replacement. Thomas Plum Plum Hall Inc, PO Box 44610 plum@plumhall.com Kamuela HI 96743 USA +1-808-882-1255 FAX +1-808-882-1556 --------------------------------------------------------------------- Resolution: see proposed resolution above. Requestor: Thomas Plum Owner: Judy Ward c++std-lib-3237 c++std-lib-3240 c++std-lib-3245 c++std-lib-3247 c++std-lib-3251 c++std-lib-3252 c++std-lib-3253 (discussion about eliding <> for templates) c++std-ext-2733 c++std-ext-2734 c++std-ext-2738 c++std-lib-3251 c++std-lib-3263 c++std-lib-3296 c++std-lib-3366 Papers: (committee documents that discuss this issue) Work Group: Library Issue Number: 005 Title: const questions with valarray Section: 26.2 New Status: active Description: Original-From: kgbudge@nwer.sandia.gov (Kent G. Budge) Message-Id: <9501041517.AA14267@artemis.nwer.sandia.gov> Subject: Valarray Query Status: R To: C++ libraries mailing list Message c++std-lib-3362 It seems appropriate to forward this to the library working group. --Kent Budge Dear Kent, I will be grateful for your comments on the following issues related to the class valarray and other associated classes. 1. The valarray shift function (26.2.1.19) has 'int' as its parameter type. Thus a -ve value can be passed as an argument to it. However, the DWP does not specify any action to performed in case of a -ve value. We feel that the type should be changed to 'size_t'. The same problem occurs in the slice(int,int,int) ctor (26.2.2.1). See also 26.2.2.2 (for return type), 26.2.4 (gslice ctor and access functions), and 26.2.1.7 ( should be const valarray& instead of const valarray&). 2. In class valarray (chapter 26), most operators and member functions have a return type of "const valarray" or "const T". Similarly, the valarray transcendentals have "const valarray" as their return types. We are not clear as to why the library WG has chosen "const valarray" as the return type rather than "valarray". Most compilers simply give a warning and ignore the const qualifier in the return type. Was there some specific reason for putting the const qualifier in the return type. Thanks Pratul. Resolution: Requestor: Pratul Dublish, Modena Software Owner: Judy Ward Emails: (email reflector messages that discuss this issue) (see issue 006, below. I believe there is overlap.) Papers: (committee documents that discuss this issue) Work Group: Library Issue Number: 006 Title: changes to valarray classes Section: 26.2 New Status: active Description: Subject: Some changes for valarray As I recall from the Valley Forge meeting, you volunteered to be the keeper of the "valarray" piece of the Standard C++ library (Section 26.2). I have some changes to propose to that section, based on review of the section, discussions here at Cray and elsewhere, and implementation experience from other library implementors. I have divided the material into Editorial and Substantive changes below. If you think it is appropriate/necessary, I can recast it as a paper for the March meeting. Please let me know how you want to handle it. ___________________________________ Editorial Changes to section 26.2: ___________________________________ 1. In Table 89, the list of Template classes should include "gslice_array" and "indirect_array". 2. Page 26-14 paragraph 5: "an" should be "a" 3. Based on the passage of motion 31 at VF, which added the keyword "explicit" to identify a non-converting constructor, the second constructor in section 26.2.1 should now read "inline explicit valarray( size_t );" in place of "inline valarray( enum Uninitialized, size_t );" and the text at the top of page 26-19 should now read as follows: valarray::valarray( size_t ); The array created by this constructor has a length equal to the value of its size_t argument. The elements of the array are constructed using the default constructor for the instantiating type T. Since this function is declared with the "explicit" keyword, it cannot be used to convert integers to valarray objects. 4. Page 26-18, paragraph 3 (at the end of the paragraph): there is a reference to the "dynarray" class. This class was removed by motion 19 at VF; the sentence should refer to the "vector" class from the STL, as discussed in paper 94-0154. 5. Page 26-25, section 26.2.1.19 paragraph 1: add the sentence "A positive argument results in a left shift, a negative argument results in a right shift, and a zero argument results in no shift." 6. Page 26-25, section 26.2.1.19 paragraph 2: change the words "value 2" to be "value -2". 7. Page 26-26, section 26.2.3, paragraph 2: the words "from a be 1," should read "from a are 1," 8. Page 26-27, section 26.2.4, paragraph 2, the given formula doesn't make sense; in particular, "sum13j" appears to be a typo, though I don't know what the right formula is. ___________________________________ Substantive Changes to section 26.2: ___________________________________ 9. For completeness, a circular shift function should be added. On page 26-17, just after the shift prototype (near the bottom) add "const valarray cshift(int) const; and insert a subsection after 26.2.1.19 as follows: valarray cshift function const valarray valarray::cshift(int) const; This function returns an array whose length is identical to the "this" array, but whose element values are shifted in circular fashion by the number of places indicated by the argument. A positive argument results in a left circular shift, a negative argument results in a right circular shift, and a zero argument results in no shift. 10. Throughout the 26.2 section, all functions which take an int parameter, or which return an int to specify an index into a valarray, should be changed to use a size_t instead. This would make it clear that a valarray should be indexed through only non-negative values. This modification would affect the following functions : const valarray valarray::operator[] (const valarray&) const; indirect_array valarray::operator[] (const valarray&); const valarray valarray::shift(int) const; slice::slice (int, int, int); int slice::start () const; int slice::length () const; int slice::stride () const; gslice::gslice (int, const valarray& , const valarray&) int gslice::start () const; valarray gslice::length () const; valarray gslice::stride () const; 11. A destructor should be a part of the public interface of the helper template classes slice_array, gslice_array, mask_array and indirect_array. The helper template classes have reference semantics to valarray objects. Consider the expression,( From Section 26.2.3, Page 26-26, DRAFT - Sept. 94) a [ slice(1, 5, 3) ] = b; | ---- The destructor for class slice_array should be accessible here. Any reasonable implementation would be required to do resource allocation when an object of these classes is constructed. As such destructors for these helper classes are bound to be non-trivial and if an implementation does not provide one, the default destructor (with public accessibility) generated by the compiler will not suffice. So, a destructor should be explicitly made part of the public interface of each these helper template classes. 12. The return type "const T" should be changed to "T" throughout. If T is a bultin-type, the type qualifier "const" is meaningless. Otherwise, the restriction that having type qualifier "const" in the return type introduces is that only a const memberfunction can be directly called on const qualified class rvalues. There is no need to impose such a restriction, and thus the "const" qualifier should be removed. This would affect the following functions : const T valarray::operator[] (size_t) const; const T valarray::sum () const; const T valarray::min () const; const T valarray::max () const; 13. The return type "const valarray" should be changed to "valarray" throughout. This makes class valarray consistent with the rest of the library. The restriction introduced by having type qualifier const in the return type is that only a const member function can be directly called on const qualified class rvalues. That is, valarray val("VALARRAY", 7); val.shift(4).mf(); // Here mf must be a const member function // which is an unnecessary restriction This would affect the following functions : const valarray valarray::operator[] (slice) const; const valarray valarray::operator[] (const gslice&) const; const valarray valarray::operator[] (const valarray&) const; const valarray valarray::operator[] (const valarray&) const; const valarray valarray::operator+ () const; const valarray valarray::operator- () const; const valarray valarray::operator~ () const; const valarray valarray::operator! () const; const valarray valarray::shift (int) const; const valarray valarray::cshift (int) const; const valarray valarray::apply (T func(T)) const; const valarray valarray::apply (T func(const T&)) const; const valarray operator* (const valarray&, const T&); const valarray operator* (const T&, const valarray&); const valarray operator* (const valarray&, const valarray&); . . . . . other binary operators. const valarray operator== (const valarray&, const T&); const valarray operator== (const T&, const valarray&); const valarray operator== (const valarray&, const valarray&); . . . . . other comparison operators. const valarray abs (const valarray&); const valarray acos (const valarray&); . . . . . and the remaining transcendentals. Resolution: Requestor: Mike Holly Owner: Judy Ward Emails: (email reflector messages that discuss this issue) c++std-lib-3370 c++std-lib-3371 Papers: (committee documents that discuss this issue) Work Group: Library Issue Number: 007 Title: name change in numeric limits Section: 26.? New Status: active Description: Mats, The rationale for that member is unfortunately not expressed clearly. The name is literally correct: if a specialization is defined, that member is made "true". Typically it only makes sense to define such a specialization for a scalar type, because the values are meaningful only for such types. I think this is an editorial issue only. That doesn't mean it shouldn't be fixed; I will forward this to Judy to add to her issues list. Nathan > From: Mats.Henricson@eua.ericsson.se (Mats Henricson) > Date: Wed, 18 Jan 95 17:14:19 +0100 > To: ncm@netcom.com, myersn@roguewave.com > Subject: static const bool is_specialized = false; > Cc: Mats.Henricson@eua.ericsson.se, todd@roguewave.com > > Hi! > > The numeric_limits class has this member: > > static const bool is_specialized = false; > > The description is this: > > The member is_specialized makes it possible to distinguish between > scalar types, which have specializations, and non-scalar types, > which do not. > > Why, then, isn't the member called is_scalar and by default set to > true? > > Best regards, > > Mats > Resolution: Requestor: Mats Henricson Owner: Judy Ward Emails: (email reflector messages that discuss this issue) c++std-lib-3380 (editorial issue of changing the wording to what's described here -- Mats is then ok with it) Papers: (committee documents that discuss this issue) Work Group: Library Issue Number: 008 Title: numeric limits clarifications Section: 26 New Status: active Description: Suggested clarifications to numeric_limits component: 1. Specify the "full set" of scalar numeric types: wchar_t, float, double, long double, int, short, long, unsigned int unsigned short, unsigned long, signed char, unsigned char, char, bool 2. Specify that the digits member will not count the sign bit. So, for signed types (int, for instance) digits is: digits = (CHAR_BIT) * sizeof(int) - 1; 3. For specialization of bool: min() is false, max() is true, digits is 1, digits10 is 0, is_signed is false, is_integer is true, all other values set to defaults. Resolution: Requestor: Judy Ward Owner: Judy Ward Emails: (email reflector messages that discuss this issue) Papers: (committee documents that discuss this issue) Work Group: Library Issue Number: 009 Title: Section: 26.1 New Status: active Description: To: C++ libraries mailing list Message c++std-lib-3382 /* There seems to be a problem with the current interface of the complex library. At the last meeting complex was changed to a templatized library. This is an example of code that would have worked with the non-templatized float_complex class but will no longer work with the templatized complex class. Shouldn't this code still be valid? Judy Ward ward@roguewave.com */ class float_complex {}; // old non-templatized float complex class float_complex operator/(float,float_complex); template class complex {}; // new templatized complex class template complex operator/(const T&,const complex&); void main() { float_complex fcf; complex cf; fcf=1/fcf; // ok cf=1/cf; // can't match } Resolution: Should we make complex a non-templatized class again? Requestor: Judy Ward Owner: Judy Ward Emails: (email reflector messages that discuss this issue) c++std-lib-3385 c++std-ext-2832 c++std-lib-3386 c++std-lib-3382 c++std-lib-3387 c++std-ext-2833 (same as above) Papers: (committee documents that discuss this issue)