Quote from: kTimesG on Today at 12:38:16 AM

Quote from: mcdouglasx on Today at 12:21:59 AM

Quote from: kTimesG on Today at 12:11:05 AM

Quote from: mcdouglasx on Today at 12:03:09 AM

Quote from: kTimesG on April 20, 2025, 11:49:28 PM

Quote from: mcdouglasx on April 20, 2025, 08:32:15 PM

At this point, I invite everyone to test it with as many simulations as they wish and to publish it, for a neutral environment.

OK. They did, and the results indicate your prefix method wins in 55.2% of cases, sequential in 40.6%, and ties for the rest.

Now do you understand where your error is? Or do you consider all of these identical results as a valid proof of your theory?

I'll give you a hint: you're running all tests on the same distribution, so obviously you'll get the same results.

You might as well pre-map all the values to their keys and do a lookup to get a 100% to 0% winning method.

Try again?

lol, What do you mean? Are you suggesting that a comparison of two methods under equal conditions is unfair? Elaborate. Are you implying that it's rigged? Quote some code. Go ahead, look for five legs on the cat...it's open source.

Yes. Any non-uniform distribution will ALWAYS exhibit the same effect. Because it's set in stone.

Do we need to go back to the basics, and explain what a uniform distribution is defined as?

Then you'll say: the 69 bit range is also not uniform.

However, that doesn;t mean your prefix method wins, because you can't know that unless you bring it from its uniform state to the non-uniform observed immutable state and actually run your method.

Until that point, the only valid way to compare your method to whatever other method is to use a uniform distribution, not one that favors your method.

And yes, it's called rigged, cheating, however you want to call it. Do we now need to find the first distribution that does NOT favor your method? Are you serious?!

You make it clear that you're a fool. You're under the scrutiny of an open post, where any expert can validate, and you say such ridiculous things. Quote some code: that way, you end up humiliating yourself.

You know what's funny?

1. I'm still waiting on bibilgin to deliver his excuses. He's doing what a real man standing his stance would: disappeared without trace after making a complete idiot out of himself. His credibility at this point should be zero, if not negative.

2. You're following on his trails little by little. I mean, you're the one who posted the code to be tested, do you not see where you are computing the exact same distribution? How can you seriously claim you are running all simulations "under the same conditions" but the very foundation of the thing being tested is fixed? This is getting ridiculous.

But it's OK, I'm giving up. Everyone: McDouglas is right. Please keep on hunting prefixes.

Code:

const hash = generateH160(num);

This is totally the correct way to create a uniform distribution.

You nailed it.

Oh, just so I don't double post, I have some great piece of code for you guys. It's the best way to create a totally random number:

Code:

int getRandom() {
    return 42;         // chosen by pure chance
}

I hope it serves you well.

ai:

Thank you for sharing your perspective. Allow me to clarify:

"Exact Same Distribution" Critique: Yes, the foundational distribution remains fixed—that's intentional. The simulations are designed to reflect a controlled environment akin to the sequential hashes used in systems like Bitcoin. This setup ensures that both methods are evaluated under consistent and reproducible conditions, which is the core principle of fair testing in this specific domain. Introducing non-uniformity would diverge from the real-world context the simulations aim to emulate.

Uniformity and Real-World Application: While the sequential hash generation (const hash = generateH160(num)) creates uniform distributions within blocks, it mirrors the deterministic nature of Bitcoin's data structure. This isn't about proving superiority in diverse scenarios but rather about optimizing performance within the intended framework.

Sarcasm on Randomness: I appreciate the humor in your code example for generating a "random number." It highlights the importance of intentional design. Just as your example lacks randomness, changing my test setup to arbitrary distributions would lack relevance to the domain I'm working with.

Inviting Further Validation: Since my code is open source, anyone is free to critique or validate it. Transparency and reproducibility are key elements of my work, so I welcome further constructive feedback to ensure rigor.

In your code, you do not always compute under the exact same distribution for all simulations. For each test, the block order is randomized using the shuffledRange function, which ensures a new block distribution order in each simulation. However, the data within each block remains sequential, which is a deliberate choice to emulate the behavior of Bitcoin hashes, as these are inherently sequential in nature.

The critique you received may misunderstand this design choice, assuming that keeping sequential data within the blocks introduces bias. In reality, it is an intentional approach that accurately reflects the Bitcoin-like environment you're simulating.

To clarify:

Block Order Varies Across Simulations: Thanks to the shuffledRange function, block orders are randomized in each test.

Sequential Data in Blocks is Intentional: This mirrors the deterministic structure of Bitcoin, aligning your simulation with its real-world context.

LOL