Saturday, April 10, 2021

Digest for comp.lang.c++@googlegroups.com - 8 updates in 3 topics

Juha Nieminen <nospam@thanks.invalid>: Apr 10 07:21AM


> William Kahan, the father of the IEEE-854 standard, said that 64-bits
> were chosen so that the average programmer would not have to hire
> an expensive error analyst to ensure that his code was correct.
 
That explanation sounds completely nonsensical, at least without
further explanation.
 
(What does the size of the floating point value have anything to do
with "ensuring that the average programmer's code is correct"?
Implying that any other number of bits would have made it impossible,
and exactly 64 bits somehow magically ensures program correctness?
What?)
Richard Damon <Richard@Damon-Family.org>: Apr 10 09:03AM -0400

On 4/10/21 3:21 AM, Juha Nieminen wrote:
> Implying that any other number of bits would have made it impossible,
> and exactly 64 bits somehow magically ensures program correctness?
> What?)
 
15-16 digits of precision are enough that for most practical
calculations using actual measurements or implemented with actual
measurements will have enough precision that the amount lost in typical
calculations will still be better than you could expect from the
accuracy of the measurements.
 
More, would just be a waste of computation resources (which were still
expensive when the standards were forming). The next logical step down
was 32 bits, and that often shows the effects of numerical accuracy with
real measurements.
 
48 bits might have worked, but can be close enough to the computation
limit that you would need to be carefull.
 
At 64 bits, the only real problem you need to watch out for is precision
cancellation, where you subtract two nearly equal numbers or add two
number that are almost equal, just with different signs. You can
normally ignore things like adding the small magnitude numbers first and
then getting to the larger, because you are unlikely to be adding enough
smaller numbers that order makes a significant difference.
 
Perhaps the biggest problem with that idea is that since there still are
a few spots where it makes a difference, the fact that you don't need to
normally worry about the other cases lulls you into a false sense of
security.
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 10 02:25PM -0400

On 4/10/21 3:21 AM, Juha Nieminen wrote:
> Implying that any other number of bits would have made it impossible,
> and exactly 64 bits somehow magically ensures program correctness?
> What?)
 
He's not implying that 64 bits is somehow magical. Nor that 64 bits is
optimal. Nor that it ensures program correctness.
What he's suggesting is that 32 bit floating point is often sufficiently
imprecise to be a serious problem, and that average programmers don't
have the skills needed to figure out how to restructure their algorithms
to produce acceptable accuracy when carried out using 32-bit floating point.
However, for most purposes, 64 bit floating point is enough to avoid
serious problems, so ordinary programmers can use it with a fair amount
of confidence that it will produce acceptable accuracy.
That doesn't mean that program correctness is assured when using 64
bits, only that code using 64 bits is substantially less likely to
result in accuracy problems than the same code using 32 bits. On the
other hand, further increases in the size produce only marginal
reductions in the accuracy problems. 64 bit's isn't exactly determined
optimal length. Most real floating point formats occupy a number of
bytes that is a power of 2, so the reasonable options tend to be 32
bits, 64 bits, and 128 bits. Basically, if you need 128-bit floating
point, you probably also need a numerical analyst anyway.
 
And, of course, even 128 bit floating point with the help of numerical
analyst is not sufficient to ensure program correctness, and he said
nothing to suggest that it would. It's not even sufficient to ensure
that the floating point math is correct, and it has no bearing at all on
those aspects of code correctness that don't involve floating point math.
Juha Nieminen <nospam@thanks.invalid>: Apr 10 07:31AM

> You don't need scanf() to get incorrect numbers, you can easily have
> them also with C++ streams (a design bug IMO, stream exceptions should
> be on by default, but that's just me):
 
But the thing is, std::sscanf() is probably going to be more efficient
than std::istringstream. Notice in your very own example:
 
> const char* buffer = "12345678912345678";
> std::istringstream is(buffer);
 
That's probably going to cause an extra memory allocation and
deallocation (not to talk about the needless copying of the string
contents into the allocated memory).
 
I know that the problem may be not as bad when reading directly
from a file or standard input, but notice how in this particular
case, when parsing a value from a string in memory, C++ doesn't
really offer a good alternative. C++17 did introduce the
std::from_chars() family of functions that are designed to
read integers and floating point values from strings as
efficiently as possible (probably even surpassing the efficiency
of std::sscanf()), in-place, without any allocations nor copying,
which is a great addition to the standard library, but they can only
be used to parse one single value at a time.
 
That being said, the std::scanf() functions are quite limited in
their usefulness, and I personally have almost never used any of
them for anything. Just pointing out that it's not automatically a
bad thing that C++ supports them.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 10 02:36AM -0700

> of std::sscanf()), in-place, without any allocations nor copying,
> which is a great addition to the standard library, but they can only
> be used to parse one single value at a time.
 
There's always strtol() and friends.
 
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Ian Collins <ian-news@hotmail.com>: Apr 10 09:49PM +1200

On 10/04/2021 21:36, Keith Thompson wrote:
>> which is a great addition to the standard library, but they can only
>> be used to parse one single value at a time.
 
> There's always strtol() and friends.
 
Which are usually the best option!
 
Our code base has a couple of variadic function templates that replace
sscanf with type safe conversions and no annoying format specifiers. I
wrote them to clean up a bunch of equally annoying clang-tidy
cert-err34-c warnings.
 
--
Ian.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 10 04:06PM +0300

10.04.2021 10:31 Juha Nieminen kirjutas:
 
> That's probably going to cause an extra memory allocation and
> deallocation (not to talk about the needless copying of the string
> contents into the allocated memory).
 
iostreams are slow anyway, so I would not worry about such details too
much. For me, both the scanf() and iostreams are convenience interfaces
which can be used when the speed is not so critical. And scanf() is
losing here as it is not so easy or convenient to use it safely.
 
If speed is critical, one often has to turn to special libraries
optimized for that purpose, like Google's double_conversion for example.
Hopefully std::to_chars()/std::from_chars() become a viable alternative
here (or maybe they already are, I have not had chance to try them out yet).
 
> C++17 did introduce the std::from_chars() [...] but they can only
> be used to parse one single value at a time.
 
It ought to be relatively easy to build a stream-like interface on top
of std::from_chars/std::to_chars. For keeping up with the performance it
should also be locale-independent, non-allocating, and should not
involve virtual functions.
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 09 08:24PM -0500

On 4/9/2021 11:14 AM, Cholo Lennon wrote:
> Cholo Lennon
> Bs.As.
> ARG
 
You are welcome. I thought so too.
 
Lynn
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)