Thursday, June 4, 2020

Digest for comp.lang.c++@googlegroups.com - 14 updates in 4 topics

Bonita Montero <Bonita.Montero@gmail.com>: Jun 04 06:11PM +0200

> a vector nor does it contain bool objects. You could use
> this as a kind of an array of single bits and do the
> combining of pairs of two bits yourself.
 
Very inefficient !
Bo Persson <bo@bo-persson.se>: Jun 04 07:25PM +0200

On 2020-06-04 at 18:11, Bonita Montero wrote:
>>    this as a kind of an array of single bits and do the
>>    combining of pairs of two bits yourself.
 
> Very inefficient !
 
It's space efficient. Sometimes that is what's needed.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 04 07:42PM +0200

>> Very inefficient !
 
> It's space efficient. Sometimes that is what's needed.
 
The OP just asked for 2 bits.
Bart <bc@freeuk.com>: Jun 04 06:49PM +0100

On 02/06/2020 22:21, Stefan Ram wrote:
> a vector nor does it contain bool objects. You could use
> this as a kind of an array of single bits and do the
> combining of pairs of two bits yourself.
 
One of my languages (dynamic not static yet) allows arrays of 1, 2 and 4
bits (a natural extension, at the small end, to the sequence 8, 16, 32,
64 bits).
 
A 100M-element array of 2 bits (an unsigned type called 'bit2' or 'u2')
occupies 25MB (plus some loose change for the descriptors). It is
indexed and sliced as any normal array. Bounds can be N-based not just
0-based.
 
I got the impression such a thing is routine to add in C++ if it is not
already in some library.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 04 02:17PM -0400

On 6/4/20 1:25 PM, Bo Persson wrote:
>>>    combining of pairs of two bits yourself.
 
>> Very inefficient !
 
> It's space efficient. Sometimes that is what's needed.
 
Also, what the standard says about std::vector<bool> is somewhat
different from what it says about std::vector<T> for generic T. Those
differences allow std::vector<bool> to be implemented using bit-wise
operators (&, |, ^, ~, <<, and >>) and inline functions which would
allow code using std::vector<bool> to be optimized to be comparable in
speed to hand-optimized code using bit-wise operators directly.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 04 12:01PM -0700

> operators (&, |, ^, ~, <<, and >>) and inline functions which would
> allow code using std::vector<bool> to be optimized to be comparable in
> speed to hand-optimized code using bit-wise operators directly.
 
It's too late to change it now, but I wonder if it might have made more
sense to treat std::vector<bool> like a vector of anything else, and add
a distinct type, say std::vector_bool, that has the special behavior.
 
--
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 */
"Öö Tiib" <ootiib@hot.ee>: Jun 04 01:44PM -0700

On Thursday, 4 June 2020 22:01:15 UTC+3, Keith Thompson wrote:
 
> It's too late to change it now, but I wonder if it might have made more
> sense to treat std::vector<bool> like a vector of anything else, and add
> a distinct type, say std::vector_bool, that has the special behavior.
 
The issue #96 "vector<bool> is not a container" is AFAIK still open
and proposed was std::bit_vector ... but it sort of hangs there.
 
Meanwhile there are also boost::dynamic_bitset in Boost,
Qt::QBitArray in QT ... bm::bvector in BitMagic and so on.
 
Issue with those seems to be that when we are desperate to go for
single bits then we likely also want to squeeze the performance
of our specific use-case to max ... and do not care how generic
and flexible it is for different usages.
Paavo Helde <eesnimi@osa.pri.ee>: Jun 04 11:50PM +0300

04.06.2020 22:01 Keith Thompson kirjutas:
> It's too late to change it now, but I wonder if it might have made more
> sense to treat std::vector<bool> like a vector of anything else, and add
> a distinct type, say std::vector_bool, that has the special behavior.
 
Yes, of course, std::bitvector or whatever. std::vector<bool> is a clear
example of trying to be too smart for no reason. Been there, done that
(many times, unfortunately).
"Öö Tiib" <ootiib@hot.ee>: Jun 04 02:13PM -0700

On Thursday, 4 June 2020 23:44:15 UTC+3, Öö Tiib wrote:
> The issue #96 "vector<bool> is not a container" is AFAIK still open
> and proposed was std::bit_vector ... but it sort of hangs there.
 
I was wrong ... it is NAD (not a defect), upgraded to
N2050 and N2160
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html
 
So it is not "hanging", but "evolving".
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 04 04:16PM -0700


> Yes, of course, std::bitvector or whatever. std::vector<bool> is a
> clear example of trying to be too smart for no reason. Been there,
> done that (many times, unfortunately).
 
Yes, std::bitvector is a much better name than std::vector_bool.
(std::bitset already exists but isn't the same thing.)
 
--
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 */
Vir Campestris <vir.campestris@invalid.invalid>: Jun 04 09:38PM +0100

On 02/06/2020 22:10, Öö Tiib wrote:
 
>> Everyone knows that the C character constant 'a' has a value of 129 (in
>> EBCDIC-US, of course).
> Weird, dinosaurs who use EBCDIC-037 usually say that 'a' is 0201.
 
I last used EBCDIC on ICL2900s. Everything was hex, surprised to see octal.
 
Or lower case for that matter!
 
Andy
"Öö Tiib" <ootiib@hot.ee>: Jun 04 02:26PM -0700

On Thursday, 4 June 2020 23:38:33 UTC+3, Vir Campestris wrote:
> > Weird, dinosaurs who use EBCDIC-037 usually say that 'a' is 0201.
 
> I last used EBCDIC on ICL2900s. Everything was hex, surprised to see octal.
 
> Or lower case for that matter!
 
Few who still maintain such things keep it arcane and cryptic.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 04 10:16PM +0200

On 03.06.2020 21:12, Alf P. Steinbach wrote:
 
>> and again, since the basic math ops are done in hardware now it's
>> questionable whether a software Newton/Raphson loop would be faster
>> than hardware `pow`. Still one could try, and measure.
 
I measured, and apparently the only real and portable optimization of
the ones mentioned above, is to use `norm` instead of `abs`.
 
- - -
 
For the express-sin-vis-cos possibility I measured these functions:
 
struct Stdlib
{
static auto func( const double v )
-> double
{ return sin( v )*cos( v ); }
};
 
struct Pythagoras
{
static auto func( const double v )
-> double
{
const double cos_value = cos( v );
const double abs_sin_value = sqrt( 1 - cos_value*cos_value );
return (sgn( v )*abs_sin_value)*cos_value;
}
};
 
... with the following results with 64-bit compilers in Windows 10,
where a.exe is produced by MinG g++ 9.2, and b.exe by MSVC 2019:
 
[H:\forums\clc++\058 complex roots]
> a
Stdlib : 0.315015 in 4.17709e-10 seconds (average over
262144 iterations).
Pythagoras : 0.315015 in 4.18091e-10 seconds (average over
262144 iterations).
 
[H:\forums\clc++\058 complex roots]
> b
Stdlib : 0.315015 in 4.17709e-10 seconds (average over
262144 iterations).
Pythagoras : 0.315015 in 2.12463e-08 seconds (average over
16384 iterations).
 
With g++ I used option `-O3`, and with MSVC I used option `/O2`.
 
So with MinGW g++ it's a tie, and with MSVC the standard library wins
handily.
 
- - -
 
For the compute-root-via-Newton/Raphson idea I measured these functions:
 
struct Stdlib
{
static auto func( const double power, const int base )
-> double
{ return pow( power, 1.0/base ); }
};
 
struct Newton
{
static auto func( const double power, const int base )
-> double
{
// x^base = power => f(x) = x^base - power, f'(x) =
base*x^(base - 1)
 
double xp = power; // previous x
for( ;; ) {
const double p = intpow( xp, base - 1 );
const double fx = p*xp - power;
const double fdx = base*p;
const double new_guess = xp - fx/fdx;
if( abs( new_guess - xp )/xp < 1e-14 ) {
return new_guess;
}
xp = new_guess;
}
}
};
 
... with results
 
[H:\forums\clc++\058 complex roots]
> a
Stdlib : 5 in 4.17709e-10 seconds (average over 262144
iterations).
Newton : 5 in 7.95996e-07 seconds (average over 2048
iterations).
 
[H:\forums\clc++\058 complex roots]
> b
Stdlib : 5 in 4.20666e-10 seconds (average over 1048576
iterations).
Newton : 5 in 4.17709e-10 seconds (average over 262144
iterations).
 
So for these functions with MinGW g++ the standard library wins handily,
while with MSVC it's a tie, opposite of the previous function pair.
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 04 06:53PM +0100

Hi!
 
Spacecraft displays should be 4:3 and NOT widescreen to ensure consistency with 2001: A Space Odyssey.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
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.

No comments: