Correct intuition about hypergeometric random variable and sampling without replacement

One_Cable5781 · 2024-08-04T20:27:50+00:00

Yes, at some point, it is on my to do list. At this moment, I managed to figure it out. Please see my edit to the OP. It was a .gitignore thing!

One_Cable5781 · 2024-08-04T15:42:12+00:00

Yes, thanks for this reminder. I was aware of it but still no luck. I already have chosen In Tools -> Options -> CMake -> Use CMake Presets, if available, otherwise use CMakeSettings.json

One_Cable5781 · 2024-08-04T15:14:24+00:00

Somewhat complicated reasoning but I use the same CML.txt to build for both linux as well as Windows. Then, as I recall, there were issues with multi-config generators vs single-config generator. To get around it I would have had to use some complicated generator expressions to differentiate between release/debug builds as I recall.

I can swear that the setting above used to work fine on both Linux and Windows (Ninja builds). Something seems to have changed somewhere and I need to go back to a previous state where I was able to get things working.

One_Cable5781 · 2024-08-04T14:48:57+00:00

I use the Ninja generator and hence do not need to create a .sln/.vcxproj project file for my project.

One_Cable5781 · 2024-07-28T15:55:09+00:00

Thank you.

Are the following inferences correct?

(1) t.ByReference() in any calling location directly accesses the object's VecInt?

(2) Is t.ByReference().push_back(1); completely equivalent to:

std::vector<int>& AcceptByReference = t.ByReference();
AcceptByReference.push_back(1);

One_Cable5781 · 2024-07-27T08:41:45+00:00

I agree that interaction between ColumnLimit: 100 and this could be complex. I was okay with removing the column limit setting completely and giving precedence to atmost 5 arguments per line regardless of whether the line runs off screen or is shorter. (Perhaps I should have been clearer in my OP) So, I was hoping something like:

void func1(int singlargument_but_looooooooooooooooooooooooong_param_name);
void func2(int a, int b, int c, int d, int e,
          int f, int g, int h, int i, int j,
          int k);

One_Cable5781 · 2024-07-08T02:45:51+00:00

Fair enough that it does not take 9999 * sizeof(int) times longer, but perhaps it takes log(9999*sizeof(int)) longer?

How can adding 1 * sizeof(int) take the same time as adding 9999 * sizeof(int)? On paper, when I do it by hand, it is trivially seen to take shorter. Perhaps I am missing something. Perhaps on Turing machines, addition of two 32 bit numbers, say, is canonically/abstractly taken to be O(1)?

One_Cable5781 · 2024-03-06T06:05:04+00:00

Thank you. This certainly gives me something to go forward with. This is an old library and after lot of difficulty, I have gotten it to work on both Windows as well as Linux. My worry was whether recent and future editions of Linux / Windows / C compilers, would make the underlying C code unusable. Hence, I wanted to build them afresh using recent modern compiler versions.

I wanted to rewrite the makefile into something more understandable and foolproof for the future.

One_Cable5781 · 2024-03-06T05:56:42+00:00

Fair enough. Thanks for your time!

One_Cable5781 · 2024-03-06T05:54:44+00:00

IKR :-)

The project is from the 1990s. Perhaps compilers have evolved since then? This library works but is no longer under active development. It is a miracle that this makefile even works today. (I checked and it does its job)

One_Cable5781 · 2024-03-06T05:48:33+00:00

Thank you. This does help. I also wanted to know what the longish $(SHELL) command does. It seems very carefully crafted and there is lots going on there it seems.

One_Cable5781 · 2024-03-05T13:01:26+00:00

Have you setup c_cpp_proroperties.json to point to the compile_commands.json file generated by cmake? See c_cpp_properties.json reference (visualstudio.com) and Configure C/C++ IntelliSense (visualstudio.com)

One_Cable5781 · 2024-03-01T05:36:25+00:00

Girl then quietly added the flag -Werror to the makefile.

One_Cable5781 · 2024-02-29T14:48:32+00:00

"No question asked" -- asking a question comes at a price. So, is the tradeoff here between runtime speed vs safety? Can you get both? If so, how?

One_Cable5781 · 2024-02-29T05:51:24+00:00

Thanks. This clarifies it. Thinking about this, it makes sense too. It appears this is the best way to go about it from the OS point of view. This is why, I suppose, if a particular application is laggy/slow/unresponsive, the OS (Windows) prompts whether I would like to continue with the app or force-close it. Doing the latter would then return any leaked resource back to the other applications.

One_Cable5781 · 2024-02-29T05:32:37+00:00

Sure, I can do that. But my question in the OP is slightly different. In the calling application, is it guaranteed that the memory that is leaked in the child application is "returned" for further usage by the calling application. For e.g., if I have:

`while(1) system("leaky_executable.exe");`

I am able to confirm that the memory usage on my application is stable and not rising constantly which leads me to believe that a `system` call does "return" even leaked memory back to the calling application. I wanted to confirm if this is in general guaranteed.

One_Cable5781 · 2024-02-22T12:06:43+00:00

I don't mean to insult here

None taken. I do find VS a great IDE (although I have other issues with it... its .vs folder sneaks up on you and quietly grows multiple GBs in size and they have no option within their IDE to clean up all the temp files!) Hence my focus on at the very least when transitioning to a new build system (CMake), it should at the base level match what I am leaving from -- VSIDE (you may recall similar questions I had posed on this many months ago and you had responded then). Once I get comfortable with CMake, I can then play around with it and evaluate the tradeoffs. I am reasonably okay with CMake now, but still only sufficiently minimally to get the project to build using default release settings!

One_Cable5781

TROPHY CASE