It is not computable, because for high enough n you can't prove that you got the right integer.
And also you can prove that if a sequence a_n is always larger than BB(n) for some n, that sequence a_n is also not computable.
for all n there is some natural number x such that BB(n) = x
x like all natural numbers is trivially computable.
But BB(n) as a function that you could run and _find_ x, is not computable in general, because it would entail solving the halting problem.
The busy beaver function is uncomputable. That is well understood. However, for any given n, there is a number BB(n). Since that number is an integer, it is computable, even though it is the value of an incomputable function applied to a particular n. In particular, for numbers > 5, we have no idea what that number is. But whatever number it is, that number is computable.
Look at the post that I was responding to. It made the bad inference that because Graham's Number is computable, it ought to be smaller than BB(10). That confuses computability of a given number with computability of a function.
Meaning stack, pointer Location, etc.
Extending a state with additional variables doesn't make a unique state less unique anyway, so "total state" is always more or same unique as "just tape".
If the tape, instruction position, and all other variables are the same as any previous step, then the deterministic machine is going to continue to find itself in that loop, and never halt.
Think Collatz like functions - if the output starts into a loop, you know the end result.
However, any program trying to detect all loops by maintaining a bloom filter of every previous state doesnt work, that drags any computation down by a scale of its inputs^runtime.
State isnt just tape, its all dependent variables.