A chicken & egg paradox in the claim that the Human Mind predates the Big Bang

[barakman]

Your claim:

The "intelligent impulses" or even "human mind" itself (because a musician can understand these impulses) had existed long before the "Big Bang" happened.

The problem here, is that you are relying on your own "human mind" in order to determine that these pulses are "intelligent".

In other words, based on the fact that your human mind has interpreted these pulses as intelligent, you have concluded that the human mind must be as old as the data with which you have generated them.

So you've essentially used your own claim in order to prove it.

To put this in more precise (and perhaps tedious) details:

• Let M denote the human mind
• Let f(x) denote whether or not x predates the Big Bang
• Let g(x, y) denote whether or not x interprets y as intelligent pulses
• Let h(x) be your hash function

Your claim can subsequently be formulated as:

Which obviously depicts incorrect logical inference.

---

Note that the above (along with your initial claim) doesn't even take into account the fact that there are many human minds - one per person, some would say (although I guess it depends on your personality as well as your local environment).

If we were to rephrase your claim based on the more generalized assumption that different humans have different minds:

Then it wouldn't even adhere to the most basic logical inference.

At best, you could use it in order to claim that some human minds (yours included) have existed before the Big Bang, and of course - that wouldn't actually resolve the logical error; it would only "decay" into the less obvious error described above.

[avaneev]

It's important to note that the visible scanline is 1 pixel longer than PH_HASH_COUNT, which means the implicit "boundary condition" logic is not synchronized with HashPos resetting to 0.

[avaneev]

@bvssvni I've reviewed my replies on your discovered discrete variant of prvhash-1, and I was mistaken - you've found a complete replica of the original prvhash-1 function, not the bit-inverted variant. But it applies to ReadMode=1 only, which does not start to exhibit "randomness" at some point. After some experiments I've reduced the original function (with ReadMode=1) to this variant:

static inline uint8_t prvhash_core1_min( uint8_t* const Seed,
    uint8_t* const lcg, uint8_t* const Hash )
{
    *Hash ^= (uint8_t) ( *Seed ^ 0x1 );
    const uint8_t out = *Seed;
    *Seed ^= *Hash;
    return( out );
}

It can't exhibit later randomness as well, and it does not seem to produce differentiation on initial hash-array conditions (1010, 100100100, etc). Maybe it is easier for analysis. But equivalence of linear and non-linear variant makes things complicated.

Z-domain features implicit z-factor multipliers that work as a kind of "phase-response rotators". Except at the moment I can't tell how phase-response, which is smooth at z^-1 and more complex at z^-PH_HASH_COUNT can generate such discrete outcomes. There's literally nothing except the phase-response present in the function to be an explanation. Sum of z-delayed signals is known to produce comb-filtering effect in the spectra, but when dealing with F_2 it's practically hard to tell if phase-response is involved: it may be an explanation for some regularities, but not for "cellular automata" behavior of the system in F_2.

[avaneev]

Here's the closest real-number system I was able to find. Of course, it deals with time-domain's implicit Z-multipliers. But the resulting oscillatory behavior (which is unstable in DSP terms and thus unpractical) is non-comparable to ordered F_2 behavior. Maybe you can derive explanation different to mine out of this (mine refers to some questionable pre-engineered orderly behavior). Note that addition and subtraction in F_2 are equivalent.

static inline double prvhash_core1_dbl( double* const Seed,
double* const Hash ) {
*Hash = *Hash - *Seed + 1.0;
const double out = *Seed;
*Seed = *Seed + *Hash;
return( out ); }

[avaneev]

Since I'm fed up with negativity and a lot of "explanatory misses", I'm closing the Issues tab for this project.

If you find something substantial, I'll update the project page immediately - contact me via aleksey.vaneev@gmail.com

If you want to discuss problems with the sinc function, contact me directly as well.