Wednesday, January 18, 2023

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

Muttley@dastardlyhq.com: Jan 18 09:23AM

On Tue, 17 Jan 2023 18:18:25 +0100
>> be biased.
 
>You can initialize mt19937_64( (random_device())() ).
>That's enough randomness for this task.
 
So is random() then.
Muttley@dastardlyhq.com: Jan 18 09:23AM

On Tue, 17 Jan 2023 17:32:34 +0000
 
>> Just out of interest, what would be a better way?
 
>"Better" depends on the context. This thread has been split between
>comp.lang.c and comp.lang.c++ and if you have not been reading both you
 
I wish people wouldn't do that, its very annoying.
gazelle@shell.xmission.com (Kenny McCormack): Jan 18 12:26PM

In article <tq8dr8$ctf$1@gioia.aioe.org>, <Muttley@dastardlyhq.com> wrote:
...
>>"Better" depends on the context. This thread has been split between
>>comp.lang.c and comp.lang.c++ and if you have not been reading both you
 
>I wish people wouldn't do that, its very annoying.
 
But it is the correct thing. Annoying (to you) or not.
 
--
Nov 4, 2008 - the day when everything went
from being Clinton's fault to being Obama's fault.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 18 01:31PM +0100


>> You can initialize mt19937_64( (random_device())() ).
>> That's enough randomness for this task.
 
> So is random() then.
 
Of course not. Mersenne Twister is the best of all non-cryptogra-
phical random number generators. It calculates a number of results
as a whole block for the next value-requests and thereby gets's a
unbeaten performance for this degree of randomness (mt19937_64 has
a period of of 2 ^ 19937 !). It's designed in a way that genrating
that block can easily optimized with vectoring instruction sets
like SSE or AVX.
Paul N <gw7rib@aol.com>: Jan 18 06:50AM -0800

On Tuesday, January 17, 2023 at 9:29:16 PM UTC, Chris M. Thomasson wrote:
 
> > That depends on how it is shuffled.
 
> > https://en.wikipedia.org/wiki/Faro_shuffle
> Touche. How about riffle shuffles?
 
I think a Faro shuffle is just a perfect riffle shuffle. 8 out-shuffles or 52 in-shuffles put the deck back into its original order.
 
Also, any sort of shuffle based on a 32-bit seed will give one of about 4 billion orders for the cards. This sounds a lot but is dwarfed by the 52! possible orders, and it means that once you've seen about 6 or 7 of the cards you can work out exactly what all the others are.
Muttley@dastardlyhq.com: Jan 18 04:09PM

On Wed, 18 Jan 2023 12:26:53 -0000 (UTC)
>>>comp.lang.c and comp.lang.c++ and if you have not been reading both you
 
>>I wish people wouldn't do that, its very annoying.
 
>But it is the correct thing. Annoying (to you) or not.
 
Says who, you? Why split a thread that is as relevant (or not) for both
groups?
Muttley@dastardlyhq.com: Jan 18 04:16PM

On Wed, 18 Jan 2023 13:31:23 +0100
>a period of of 2 ^ 19937 !). It's designed in a way that genrating
>that block can easily optimized with vectoring instruction sets
>like SSE or AVX.
 
I'll say again - there is no such thing as random for formula generated
"random" number sequences. Given the same start conditions the same sequence
will be generated whether its 2^19937 or 2^infinity. You'd be better off using
/dev/random, at least its entropy comes from nominally external sources so
is unpredictable in a busy enviroment.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 18 05:20PM +0100


> I'll say again - there is no such thing as random for formula generated
> "random" number sequences. ...
 
I was talking about a non-cryptographical PRNG, and you talk about sth.
different because you have a constant feeling of uncertainty and you
think nothing is reliable in that sense.
Muttley@dastardlyhq.com: Jan 18 04:24PM

On Wed, 18 Jan 2023 17:20:23 +0100
 
>I was talking about a non-cryptographical PRNG, and you talk about sth.
>different because you have a constant feeling of uncertainty and you
>think nothing is reliable in that sense.
 
Pop psychology now? Really? Stick to writing over complicated code then
bragging about how perfect it is so someone else can prove you wrong. Again.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 18 12:02AM -0800

On 1/16/2023 12:49 PM, Mr Flibble wrote:
 
> As your codebase doesn't look as involved as mine do you think you are in
> a position to create a test case and create a MSVC defect report? In the
> meantime I recommend downgrading to VS2019.
 
Perhaps... I am working hard on a bone system, to make any model dance.
I am learning about geometry shaders... MSVC let me down.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 18 12:04AM -0800

On 1/18/2023 12:02 AM, Chris M. Thomasson wrote:
>> meantime I recommend downgrading to VS2019.
 
> Perhaps... I am working hard on a bone system, to make any model dance.
> I am learning about geometry shaders... MSVC let me down.
 
Trying to stick figure the model in a sense with a fractal shape. Use it
as bones. The model of the girl is made up of 103 separate meshes, with
their own indices. Just experimenting along... ;^)
Muttley@dastardlyhq.com: Jan 18 09:27AM

On Tue, 17 Jan 2023 12:36:06 -0800
>> bug or design error which in itself goes unnoticed.
 
>Touche. Well, if there is a bug in my OpenGL code, I have not found it
>yet. Humm... So far, everything works and renders perfectly. My
 
The sort of bugs we're discussing here arn't the obvious "Oh, that result isn't
correct" type. They're the "Oh, why has is suddenly hung/crashed when its run
fine for 2 months" type.
Christian Gollwitzer <auriocus@gmx.de>: Jan 18 04:22PM +0100


> The sort of bugs we're discussing here arn't the obvious "Oh, that result isn't
> correct" type. They're the "Oh, why has is suddenly hung/crashed when its run
> fine for 2 months" type.
 
Yes, and here are my 2cents to debug these: valgrind, helgrind and
address sanititzer (million times more worth than 2 cents)
 
Christian
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 06:00PM -0800

On 1/17/2023 2:44 PM, Alf P. Steinbach wrote:
 
>> Study up on condition variables.
 
> Yes, I use them, but as I understand it a condition variable doesn't
> remember that it's been signaled.
 
A condition variable depends on its state. You are in full control of
said state.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 06:19PM -0800

On 1/17/2023 6:00 PM, Chris M. Thomasson wrote:
>> remember that it's been signaled.
 
> A condition variable depends on its state. You are in full control of
> said state.
 
Fwiw, imvho, condition variables are a heck of a lot more "flexible"
than windows events. Creating a windows event (think auto-reset for now)
from a condvar and its state, is doable. Creating a condvar from windows
event's is a nightmare...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 07:35PM -0800

On 1/17/2023 2:44 PM, Alf P. Steinbach wrote:
 
>> Study up on condition variables.
 
> Yes, I use them, but as I understand it a condition variable doesn't
> remember that it's been signaled.
 
Think of conditional waiting on a predicate. Read Programming with Posix
Threads by David Butenhof...
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 18 01:36AM -0500

On 1/17/23 18:22, Scott Lurndal wrote:
 
>> Yes, I use them, but as I understand it a condition variable doesn't
>> remember that it's been signaled.
 
> If it is used properly, it doesn't need to.
 
That would be a far more useful comment if accompanied with an
explanation of how to use one properly, despite the fact that it doesn't
remember. You could, in particular, use the code provided in the
original message, and show how to implement it using standard C++ threads.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 10:55PM -0800

On 1/17/2023 7:35 PM, Chris M. Thomasson wrote:
>> remember that it's been signaled.
 
> Think of conditional waiting on a predicate. Read Programming with Posix
> Threads by David Butenhof...
 
If you are trying to model a semaphore, what would be predicate be for
decrementing it? Keep in mind that a thread must wait when it tries to
decrement a semaphore with a count that is less than one... There are
other ways to implement a semaphore, but the predicate must hold.
 
Now think of a binary semaphore. This is basically a windows auto reset
event.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 11:13PM -0800

On 1/17/2023 10:36 PM, James Kuyper wrote:
> explanation of how to use one properly, despite the fact that it doesn't
> remember. You could, in particular, use the code provided in the
> original message, and show how to implement it using standard C++ threads.
 
Have you ever seen the Benaphore? This can be implemented in pure std C++:
 
https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html
Paavo Helde <eesnimi@osa.pri.ee>: Jan 18 02:50PM +0200

17.01.2023 23:31 Alf P. Steinbach kirjutas:
 
>         auto handle() const -> HANDLE { return m_event_handle; }
>         void send() { ::SetEvent( m_event_handle ); }
>     };
 
This class can be easily implemented in terms of a std::mutex, a boolean
flag and a std::condition_variable. Alas, that would not make use of
Windows Event objects (for starters, Events are kernel objects and thus
way too slow), so there is no way it can return a Windows event handle
which you need below.
 
There is Boost.Interprocess but I'm not aware if any of its classes wrap
a Windows Event, and if they expose its handle.
 
 
> handles );
>         const int retval = ::WaitForMultipleObjects( int_size_of(
> handles ), handles, false, INFINITE );
 
What becomes cumbersome is to combine std::condition_variable with a
wait on keyboard input. WaitForMultipleObjects() is very Windows-specific.
 
First you should come up with how to wait for keyboard input in standard
C++, then we can see how one can abort this wait.
 
Boost.asio might provide something like this, it has e.g.
basic_stream_socket::cancel(). But boost.asio is not yet in the
standard, and wrapping keyboard input into an asio stream would also
require some custom platform-specific code as far as I can see.
scott@slp53.sl.home (Scott Lurndal): Jan 18 03:10PM

>explanation of how to use one properly, despite the fact that it doesn't
>remember. You could, in particular, use the code provided in the
>original message, and show how to implement it using standard C++ threads.
 
Yes, I suppose I could have, had I the time. They key word here is 'predicate'
which in and of itself generally encodes the 'signaled' state of the
condition variable. I did find VMS event flags useful back in the day,
to be sure, but haven't found any use for the windows version; having
never had the desire to program under windows.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 10:24PM -0800

https://youtu.be/_p6okLK3sq0
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 10:26PM -0800

On 1/17/2023 10:24 PM, Chris M. Thomasson wrote:
> https://youtu.be/_p6okLK3sq0
 
God damn it. That was meant for sci.math, wrt a discussion about
so-called dark numbers. God damn it!!!!!
 
Sorry everybody. ;^o
Richard Damon <Richard@Damon-Family.org>: Jan 17 10:15PM -0500

On 1/17/23 7:29 AM, Paul N wrote:
 
> but this does not work, even if I make b inline.
 
> Presumably if would work if I made b a macro, but these are generally discouraged. I'm guessing that some syntax using constexpr might work (I've never used one of them before) but would I need to include the code for b twice, once for the constants and once as a normal function?
 
> All thoughts welcome!
 
I might change the encoding of the enum, thinking of it a bit like a
bitfield.
 
Bottom 2 bits is the "Double" status: 01 Undoubled, 10 Doubled, 11
Redoubled (this lets all zeros be the "pass" option"
 
Next 3 bits are the suit 000 = Clubs, 001 = Diamonds, 010 = Hearts, 011
= Spades, 100 = No Trump
 
Top 3 bits are the contract: 001 = 1 bid .... 111 = 7 bid.
 
So actual bits go from 1 Clubs Undoubled = 001 000 01 = 33 decimal to
7 NT Redoubled = 111 100 11 = 243
 
Perhaps even have 3 seperate enums for each of these and since you are
using C++ define a constexpr operator that lets you merge them together.
(you will need another enum type for Contract + Suit to build the full
bids up.)
 
You can also define conversion functions to get you back to the
components (which just need to do bit masking).
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 06:25PM -0800

On 12/26/2022 1:22 PM, Chris M. Thomasson wrote:
 
> B: MEMBAR #StoreLoad | #LoadLoad
 
> C: MEMBAR #LoadStore | #StoreStore
 
> D: MEMBAR #StoreLoad | #StoreStore
 
 
Get the answer by clicking on the following link. The password is membar:
 
http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=b77c814baf6376631199bcdf0a0e763136fceb0f56dd238dba943d05e54a47451c63e2fe25ca4b6b8b9dfaba2fd22dccf20261ad63a409ce2384cb734804bcbb068edcd3a7ae6bf91ba7d88e8c27a82b4c973f7421020e43
 
Just a test of my HMAC cipher... ;^)
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)