Check out the discussion here!
We're currently holding the voting which decides that whether we should modify the policy in Googology Wiki:Policy#Analysis. In my decision, I agree to all 3 statements, but I have 2 questions.
If a notation is proven to be well-defined, then it should be mathematically make sense. Also, it's a good idea to allow all well-defined notations because this may encourage people to learn more googological notations.
We should allow ill-defined notations only if the notation is relatively famous and they must be notable enough, for example BEAF beyond tetrational arrays, dollar function, strong array notation and maybe UNAN. Their analyses also must have either "(intended)" next to the name of the notation or "(debatable)" next to the expression to show that they are ill-defined. Also, unspecified extensions that are not in the wiki such as {10, 100 ([1]1) 2} and {10, 100 [1 [2 \(1 \ 2) 2] 2] 2} should not be allowed. But I want to ask, why Almighty Array Notation is not notable?
Specifying which OCF the user is using above f_{α}(n) when α > ω (and possibly the system of fundamental sequences) are necessary because if we just provide a random OCF expression, e.g. ψ(Ω^ω), it will have ambiguities and hence the expression will be ill-defined. Also, do we think we should allow OCFs that are from blog posts such as Hyp cos' catching function and Bachmann's ψ as a valid OCF? (Answer is no)
But still, I agree to all of the statements.
Extra information:
I think we should allow Hyperfactorial array notation, strong array notation and Bashicu matrix system but only up to their well-defined levels. I think that Hyperfactorial array notation is well-defined up to at least 200![200([200([200([200([...])200])200])200])200] (Large Veblen ordinal level), strong array notation is well defined up to s(3, 3 {1 ` 2} 2) (ε0 level), and the Bashicu matrix system (with respect to version 2.3 = 4) is well defined up to (0, 0)(1, 1)(2, 2)(3, 3) ... [100] (ψ0(Ω_ω) level with respect to Buchholz's ψ). Also, you must specify which version of BMS you're using if you're not using either BM2.3 or BM4.
I don't think we should allow reflection/stability for extremely large numbers, because they're usually ill-defined.
I don't think we should allow Hyp cos' catching function or Bachmann's ψ (by Hyp cos) because the catching function is ill-defined even at the very first level, and Bachmann's ψ (by Hyp cos) is not formalised. Besides, according to the policy, we shouldn't add links to blog posts in articles. However, the original version of Bachmann's ψ is allowed.
In my decision, I partly agree to the whole proposal.
For proposal 1, I agree to include the well-defined notations in the preliminary list, but I disagree to the statement "Gwiki administrators will decide whether a notation is well-founded or not as well as the limit of its well-foundedness if the notation continues beyond its well-founded limit" because this will just give more work to the admins. Also I disagree to include the Catching function in the list since it is ill-defined even at the very first level.
For proposal 2, I agree to include the sufficiently notable ill-defined notations in the preliminary list iff their analysis have either "(intended)" next to the name of the notation or "(debatable)" next to the expression to show that they are ill-defined, but I disagree to the statement "Gwiki administrators will decide whether an ill-defined notation is sufficiently notable and a list shall be put on the policy on which ill-defined notations are sufficiently notable to be used in approximations" because this will just give more work to the admins, just like the statement in proposal 1.
For proposals 3 and 3.1, I agree that using FGH HH or SGH in analyses is allowed iff one specifies the FS (or OCF) for f_{α}(n), H_{α}(n) and g_{α}(n) when α > ω. However, I recommend to rewrite proposal 3.1 as follows:
Wainer hierarchy/CNF is assumed when the user puts a valid Wainer/CNF expression in α where ω < α < ε0. For example, ω, ω+1, ω2, ω^2, ω^ω, etc.
Veblen hierarchy is assumed when the user puts a valid Veblen function expression in α, such as φ(1, 0), φ(1, 0, 0), φ(1, 0 ,0 ,0), etc., as well as the following Greek characters used for shortening: ε_α, ζ_α, η_α, and Γ_α. For example: ε0, ζ0, η0, and Γ0.
For proposal 4, I agree that anyone who uses a notation not specified in policy (assuming the proposals above are vetted) in analyses in mainspace pages are liable for a warning, which follows the same three-tier system, as this should be treated the same as the other rules in the policy. We already have the level 1 warning template: {{t|Unnotable}}, but we don't have the level 2 and 3 warning templates of it.
In my decision, I partly agree to the whole proposal.
For proposal 1, I agree to include the well-defined notations in the preliminary list, as all well-defined notations mathematically makes sense. However, the statement "Buchholz's function by Buchholz and Denis" is wrong. It should be "Buchholz's function by Buchholz and Extended Buchholz's function by Denis".
For proposal 2, I changed my opinion. I disagree to include the sufficiently notable ill-defined notations in the preliminary list even if their analysis have either "(intended)" next to the name of the notation or "(debatable)" next to the expression to show that they are ill-defined, because I think adding ill-defined notations may still leads to misunderstanding of other users.
For proposals 3 and 3.1, I agree that using FGH HH or SGH in analyses is allowed iff one specifies the FS (or OCF) for f_{α}(n), H_{α}(n) and g_{α}(n) when α > ω, as this avoids unspecified and/or ill-defined OCFs.
For proposal 4, I agree that anyone who uses a notation not specified in policy (assuming the proposals above are vetted) in analyses in mainspace pages are liable for a warning, which follows the same three-tier system, as explained in alternative proposal 1.
For the first 2 proposals, I propose to ratify proposals 1.2 and 2.1, as I think this is the limit of all well-founded functions for both notations. For proposal 3, I agree to add the H* function to the list of allowed notations in analyses, as it's like the only well-defined and notable notations that can represent -illion numbers.