Notations and Opinions

[andydude]

So until I'm getting used to some slash-notation for IE (T()) and DIE (U()) I should propose the "brk"-function indicating the value of the base, which is needed to get from x to y if h times iterated... (well, I've no use for it so far, but...)

In that case I should re-propose that brk(z, y) = z/^-^y

Andrew Robbins

[bo198214]

In that case I should re-propose that brk(z, y) = z/^-^y

Looks like a japanese smiley ^-^

[andydude]

Yeah, funny how that happened...

[GFR]

Hey, Henryk!

Concerning the proposals for [n]\ (hyper-log) and /[n] (hyper-root) "reducing" operators:

However your idea to put [n]\ instead of \[n] is a better one as you can better memorize the rule
b[n]k /[n] k = b and b [n]\ ( b[n] k ) = k
as "The thing to be reduced is on the (reducing) operation side (i.e. the side with the / or \ attached)"
............

Do you realize, Henryk, that our proposal to use these right (hyper-root) and left (hyper-log) reducing operators practically .... simplify ??

I mean, taking, for instance:

y = b[s]n, with b: base, n: (hyper)exponent and s: rank, we get:

b = nth-[s]hyper-root (y) = y /[s]n = b[s]n /[s]n .... /[s]n simplifies from the right;
n = [s]hlog(base b) (y) = b[s]\ y = b[s]\ b[s]n ........ b[s]\ simplifies from the left.

Divine surprise?

GFR

[bo198214]

Do you realize, Henryk, that our proposal to use these right (hyper-root) and left (hyper-log) reducing operators practically .... simplify ??

Yes, reducing/simplifying, call it as you like, at least it always takes place at the side with the (back)slash. (Did I overlook something in your previous post?)

[GFR]

No, thanks a lot. It's all right. I ... presume. By the way, ... not only "back" are the slashes of the reducer/simplifiers. For the hlogs, they are of the "forward" type. I think. Unless you wish to call "back" just the side of a slash that can be both back or forth. I read this again these lines of mine and I didn't understand completely what I just wrote. Too technical, perhaps ... ! .(

[bo198214]

No, thanks a lot. It's all right. I ... presume. By the way, ... not only "back" are the slashes of the reducer/simplifiers. For the hlogs, they are of the "forward" type. I think. Unless you wish to call "back" just the side of a slash that can be both back or forth. I read this again these lines of mine and I didn't understand completely what I just wrote. Too technical, perhaps ... ! .(

*nudge*
I mean the side, where this thing resides that can be back and forth

[GFR]

OK.

[GFR]

I am sorry to come up again on this, but I think that it is important to draw the attention of the distinguished Participants on the fact that:

y = b[s]x <---> b = y /[s]x <---> x = b[s]\ y.

This is Slashenalgebra and it's just the beginning! The TeX Resellers will be furious, because we shall be able to slash back and forward, without warning.

GFR

[GFR]

Dear Gianfranco (and all) - the proposals are nice.
However .... for iterated exponentiation and decremented iterated exponentiation, with which I'm involved, I always need three parameters ... . So I ... announce:
y = x{4,b}h for iterated exponentiation beginning at x: b^...^b^b^x
(and from earlier discussions)
y = x{3,b}h for iterated multiplication beginning at x: x*b^h
y = x{2,b}h for iterated addition beginning at x: x+b*h

Hi, Gottfried !
As a matter of fact, I promised you to react to some interesting proposals of yours on this matter, that you kindly sent me sometime ago. I am sorry for my delay in answering to you about these important issues. The reason is that I was (... am !) trying to imagine a notation, compatible with the tetrational notation, which we (GFR & KAR) proposed for storing very large numbers, similar to the scientific "floating point" number notation used in physics and in engineering. We need a small change in it, for several reasons, but particularly because that notation is actually based on a ternary operation (base, height, and initial/final exponent) and this may create problems during "manipulations" (if we are not careful).

Keeping aside for a moment this particular problem, I think that your proposals sound good and reasonable. I should only like to examine them in the light of the Slashenquasigroup hyperops notation that pointed out in my recent discussions with Henryk.
In fact, noting that in a general hyperop of rank s, we may write:
y = b[s]n, with s: rank, b: base, n: hyperexponent,
the n-iterated [s] hyperop (on b) could be represented as follows:
y = b[s]<n>b = b[s+1](n+1)

In case of n-iteration of b[s] on a number x >< b, we should have:
y = b[s]<n>x.

The implementation of that, for h iterations of hyperops of ranks 3, 2, 1 , compared with your proposal and using your notations, could be (priority to the right ... whenever necessary) :
y = x{4,b}h = b[3]<h>x = b^...^b^b^x = x@b[4]h = x@b#h, (@ is the "tower extension"),
y = x{3,b}h = b[2]<h>x = b*...b*b*b*x = x*b[3]h = x*b^h,
y = x{2,b}h = b[1]<h>x = b+...b+b+b+x = x+b[2]h = x+b*h,
... (and I stop here, for ... avoiding problems ...)

Obviously:
b[3]<h>b = b[4](h+1)
b[2]<h>b = b[3](h+1)
b[1]<h>b = b[2](h+1).
But this is another story.

Now, your proposal is more compact and my proposal seems more graphically "extended". Nevertheless, my proposal could also be compatible with some other "exponential-type" notations of the iterations (with <h> or °h as exponents of "b[s]").

GFR