Topic: Inconsistences in numeric_limits<> description in CD2
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/12/21 Raw View
Stan Brown<brownsta@concentric.net> wrote:
>ncm@nospam.cantrip.org (Nathan Myers) wrote:
>>
>>Vlad Harchev<vladhar@imimail.ssau.ru> wrote:
>>> In CD2 ...
>>> I think that standard should ...
>>> Any opinions?
>>
>>Yes. Comment on the Standard, not on a two-year-old draft.
>
>Wow, Nathan! I'm surprised to hear you be so abrupt ...
>and I think we ought to cut [non-americans] a little slack.
I agree. I offer a public apology to Mr. Harchev for my abruptness.
However, since the standard is already finished, suggestions for what
"should" be in it are generally out of place here. (Defect reports
are welcome, and we all know there are plenty of defects to report.)
The wording of the text Mr. Harchev quoted is unfortunate. The
intent was that one-dimensional types should have a numeric_limits<>
specialization, but that composite types such as complex or quaternion
should not. Unfortunately the word chosen, "fundamental", is defined
elsewhere in the standard to refer to built-in types.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Vlad Harchev" <vladhar@imimail.ssau.ru>
Date: 1998/12/23 Raw View
AllanW@my-dejanews.com wrote in message <75ed5c$geq$1@nnrp1.dejanews.com>
....
>The standard C++ library does not provide any arbitrary-precision
>types, so this value should be false for every predefined class.
>Technically, I suppose the standard is wrong from a theoretical
>point of view, but it can't hurt anything because it should always
>be false anyway. If the user or a third-party library defined an
>arbitrary-precision class, they should set this value true -- but
>this is beyond the scope of the standard.
>
>--
>AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
>Please reply in USENET only, sorry.
May be the standard should be modified in the way I suppose - ie it at
least should recommend specializing the numeric_limits<> for one-dimensional
types? I think that it will greatly stimulate templatization of math
algorithms? Anyway, the text in the standard can be paraphrased in such way,
that it won't prohibit such specializations explicitly, leaving the question
open?
-Vlad
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/12/24 Raw View
Vlad Harchev<vladhar@imimail.ssau.ru> wrote:
> May be the standard should be modified in the way I suppose - ie it at
>least should recommend specializing the numeric_limits<> for one-dimensional
>types? I think that it will greatly stimulate templatization of math
>algorithms? Anyway, the text in the standard can be paraphrased in such way,
>that it won't prohibit such specializations explicitly, leaving the question
>open?
It already specifically allows any standard template to be specialized
for user-defined types.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Vlad Harchev" <vladhar@imimail.ssau.ru>
Date: 1998/12/18 Raw View
In CD2 in section 18.2.1 [lib.limits] the description of 'numeric_limits'
is slightly fuzzy:
quote begin-------------------------
1 The numeric_limits component provides a C++ program with information
about various properties of the implementation's representation of the
fundamental types.
2 Specializations shall be provided for each fundamental type, both
floating point and integer, including bool. The member is_specialized
shall be true for all such specializations of numeric_limits.
3 <...> skipped.
4 Non-fundamental types, such as complex<T> (_lib.complex_), shall not
have specializations.
< .... skipped>
18.2.1.2 numeric_limits members [lib.numeric.limits.members]
<..... skipped>
static const bool is_bounded;
54True if the set of values representable by the type is finite.193) All
built-in types are bounded, this member would be false for arbitrary
precision types.
quote end-------------------------
18.2.1.2#54 says that member 'is_bounded' will be false for arbitrary
precision types but 18.2.1#4 says that non-fundamental types,
such as complex<T>, shall not have specializations.
It seems that these requirements make the description of numeric_limits
ambigious - since 18.2.1.2#54 says that all built-in types are bounded;
arbitrary precision types are non-fundamental, so there shouldn't be
specializations of numeric_limits<> for arbitrary precision types - then
why the note 'this member would be false for arbitrary precision types'
exists in 18.2.1.2#54?
I think that standard should allow specializations of the numeric_limits
for non-fundamental types, provided that ALL values that can
be represented by them belong to subset of values in the range
(-infinity, +infinity) - thus matricies, vectors, complex numbers,
quaterions, intervals
etc will be excluded from the set of types for which the specializations
of numeric_limits<> can exist, and arbitrary precision/multiprecision types
will be included.
Any opinions?
-Vlad
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/12/19 Raw View
Vlad Harchev<vladhar@imimail.ssau.ru> wrote:
> In CD2 ...
> I think that standard should ...
> Any opinions?
Yes. Comment on the Standard, not on a two-year-old draft.
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/12/19 Raw View
In article <367ad07b.0@monster.ssau.ru>,
"Vlad Harchev" <vladhar@imimail.ssau.ru> wrote:
>
> In CD2 in section 18.2.1 [lib.limits] the description of 'numeric_limits'
> is slightly fuzzy:
[snip]
> 18.2.1.2#54 says that member 'is_bounded' will be false for arbitrary
> precision types but 18.2.1#4 says that non-fundamental types,
> such as complex<T>, shall not have specializations.
>
> It seems that these requirements make the description of numeric_limits
> ambigious - since 18.2.1.2#54 says that all built-in types are bounded;
> arbitrary precision types are non-fundamental, so there shouldn't be
> specializations of numeric_limits<> for arbitrary precision types - then
> why the note 'this member would be false for arbitrary precision types'
> exists in 18.2.1.2#54?
>
> I think that standard should allow specializations of the numeric_limits
> for non-fundamental types, provided that ALL values that can
> be represented by them belong to subset of values in the range
> (-infinity, +infinity) - thus matricies, vectors, complex numbers,
> quaterions, intervals
> etc will be excluded from the set of types for which the specializations
> of numeric_limits<> can exist, and arbitrary precision/multiprecision types
> will be included.
>
> Any opinions?
The standard C++ library does not provide any arbitrary-precision
types, so this value should be false for every predefined class.
Technically, I suppose the standard is wrong from a theoretical
point of view, but it can't hurt anything because it should always
be false anyway. If the user or a third-party library defined an
arbitrary-precision class, they should set this value true -- but
this is beyond the scope of the standard.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: brownsta@concentric.net (Stan Brown)
Date: 1998/12/20 Raw View
ncm@nospam.cantrip.org (Nathan Myers) wrote:
>
>Vlad Harchev<vladhar@imimail.ssau.ru> wrote:
>> In CD2 ...
>> I think that standard should ...
>> Any opinions?
>
>Yes. Comment on the Standard, not on a two-year-old draft.
Wow, Nathan! I'm surprised to hear you be so abrupt -- particularly since
the quoted portion is unchanged in the standard (even including the comma
splice in the last quoted sentence).
We in the U.S. have the luxury of $18 copies of the standard. That's not
true to non-U.S. people unless they have a credit card. Also, $18 may not
seem like a lot of money to you or me, but it takes a lot longer to earn
$18 in some foreign countries than in the U.S.
I am not saying the prices or distribution method are unreasonable as
such, just that I think we should recognize that the burden may be
relatively light for some people but insurmountable for others, and I
think we ought to cut them a little slack.
--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.concentric.net/%7eBrownsta/
"I'm not even supposed to BE here!" -- the mantra from /Clerks/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]