Steeeve

Yuur cide genrtes he same numer for differnt outoputs of rand(). Multiple occureces. This means that each numer no long has the same praability, as such it is usekess.

This is getting VERY annoying. You keep bleating the same wrong narrative over and over. No matter how I try to educate you, it's impossible.

My code -- which was an ad-hoc function just in case someone wanted to compile my snippets -- DELIBERATELY discards bits from random(). I made no secret of that. And you figured out, all by yourself, that if you overwrite random()'s LSB with 1, you've in effect discarded another bit.

*That bit doesn't matter.* Look at the two numbers I discuss below.

Take a 6 sided die with the numers 1- 6 on eacf face. Toss and the probukity is 1/6 for each numer.

Put 1,2,2,3,4,5 on the faces and toss. Each number no longer has the same probability.

Totally wrong analogy. Imagine that you want to simulate a six-sided die {1,2,3,4,5,6} and all you have is a 12-sided die {1,2,3,4,5,6,7,8,9,10,11,12}. An easy way to the goal is to add 1 and divide by two. { (1+1)/2-->1 , (2+1)/2-->1 , (3+1)/2-->2 , et cetera }. **THAT** is the proper analogy for the effect of "|1".
The definition of a uniform distribution is theoretically all numbers in the distribution have equal probability. Your code fails.

Wrong. Using 28 random bits (ignoring the bit lost in "|1") as I do, 2^28 different floating point values are possible and (if the random() being invoked is "perfect") each is generated with probability 2^-28. I showed what those 2^28 numbers are: Can you improve on that choice?

Do you even understand that much? Answer a simple True or False, please, right now, so we can verify whether you're playing with a full deck.

Did you ever actually LOOK at the two numbers I asked you to look at? Here they are again. I've increased the font-sizes of the points you are determined to ignore.

The one-liner I posted showing the conversion of a random integer to a random double is NOT taken from my personal library; it was just a throw-away snippet for here. Instead of using 31 random bits, it uses 29 random bits (or 2 less than however many bits random() supplies.).

*I did this to minimize the risk that someone here would compile the snippets and run up against a limit.* My actual library functions are perfectionistic and allow the caller to optionally specify

*how many* random bits to spend when forming a random float.

Let's be clear on the effect of discarding those two random bits. When you call my ad-hoc ruf() to get a random float you might get, by chance

.0186264459

or you might get

.0186264496

But you will never get a number in between those two. Please. Look at those two numbers again. The ad hoc ruf() that I presented above cannot return a number larger than .0186264459 but smaller than .0186264496. The granularity imposed by the ">>2" is just too coarse. (Obviously it's the exact same granularity throughout the 0 < x < 1 range. No cherry-picking here.)

*Look at the two numbers again*. Raise your hand if you think this coarse granularity is likely to be a problem in any of 99.999% of applications.

Rounded to 7 significant digits, the two numbers just mentioned are 0.01862645 and 0.01862645 respectively. Stare at those two numbers. Notice anything?

That is wy I said the mean is not the best indcator of performance or a histogram for that matter. You actually have to look at the outputs..

Whack! NOBODY ever said that "the mean is the best indicator." Whack! I responded to a particularly stupid statement by pointing out that my code's outputs had mean of 0.5 exactly, and an inferior method's did not (it had a very slight bias).

When you said normal distributions can only have a zero mean you lost credibility. That and other threads involving statistics. On the exponential function problem I posed you confused the sum of the probil;ites equalling o1 with the sum of the varibles.

NOBODY ever said that a normal distribution can only have zero mean." I even posted the snippet

y = x*std_dev + mean

to show how to convert a zero-mean variate x into a variate y with specified mean and std_dev. Apparently you need even more hand-holding than that.

I posted an elegant snippet that converts two uniform real variates into a 2D gaussian variate in polar coordinates, and then converts that into two 1D gaussian variates. Your comments showed that that was too much for you to understand, so you've been babbling over and over and over about the "remarkable" fact that discarding two bits with ">>2" DISCARDS TWO BITS!! Wow!!

You seem determined to find fault with my code, or my posts in general. Not just here, but in other threads as well. What is your problem?

Anybody can have a brain fart. Yiu are cstently shallow and lacjing comreension.

From your posts over time my guess is that you never word with people who had the savy to ubdertsnd what you did and quetion it. When somebody did you prbably bluff yir way though it.

I've posted synopses of my career. At my last job I worked with one of the top pattern-recognition scientists in the USA. We coauthored papers and coauthored patent applications. I've worked with many other top engineers. Sometimes a stranger would approach and ask for help since they'd heard I was the best mathematician in the company. Et cetera. Evidently you think what I tell about myself is a lie. You think you've caught me "bluffing."

Down the thread you posted a multiply algorithm you said was faster the anything else. I showed it to be false and when I asked you about limitations of the code you went silent.

I think you're referring to the Babylonian approach using a table of squares. I NEVER said it was "faster than anything else." I DID mention that it outperformed the standard multiply on SOME 20th-century machines (without FPU obviously), though there is a storage-vs-speed tradeoff.

You got snarky on the exponential problem I posed and when I listed the solution usng badic clculu, average value of a function, integration yiu went silent.

I don't know what this refers to.

-- -- -- -- -- --

You are intent on criticizing me, nitpicking any code snippet I post.

I've resisted any urge to criticize your code. Yet just recently we learn you don't know what a median is and/or are unsurprised that a uniform distribution's mean and median differ. You conjure up a bubble sort which does twice as many comparisons as needed. And somehow, you can't even figure out how to call qsort()!

That's just from your latest effort. If I were to criticize all your posted code, the list would get quite long.