developing a notational comma popularity metric

cmloegcmluin
Posts: 769
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

Re: developing a notational comma popularity metric

I read the intro to your SATI paper. I had never heard of async circuits before. I read a bit about quantum computing at some point but this seems totally different.

This boundary algebra notation from Jeffrey James and William Bricken... I know I've seen this before! Even just the general look of these papers – the font and such. It's driving me nuts. Perhaps one of my pen pals emailed it to me at some point. Or one of my nerdy work friends shared it. All I can think of right now is something I saw a while back about a continuum of operations between addition and multiplication. I'll have to go through these again soon.

In the meantime, here's a Smalltalk quine, on my favorite programming chrestomathy site: http://rosettacode.org/wiki/Quine#Smalltalk

------

Okay, back on topic...
Dave Keenan wrote:
Wed Jul 15, 2020 7:30 pm
we can simply change of sum-of-squares to weight them equally, i.e. to use (metric_rank - scala_rank)2. i.e. change z to 1
Do you want me to include the z=1 SoS in the output of my program? It won't make it run much slower.

Every example you give in your table is still sorted the same Can't unsee things as their ranks now. Everything I see is only itself ranked...

------

Not that this should matter much to you, but: while implementing poapfar it quickly became clear to me that it is not exactly a non-operation. It's n*d. And I agree it is not useful to humans, for the reason you said earlier (why not just take the log of everything); I was only introducing it as what I thought would be the least destructive way for my code to recognize that soapfar(n) with ap = lb(p) was a single chunk, since we know soapfar(n) = lb(n). But I had forgotten that I was eliminating the idea of "submetric types" in favor of all defining characteristics of submetrics (whether to use the prime count function, with repetition or not, etc.) being expressed as parameters (such as k, w, a, or whether a is a base or a coefficient, etc.); now that these were both things of the same type, it made it possible to combine the ideas of soapfar and lb as one "chunk". So that was clearly the better way to go.

I can't immediately think of other combinations of parameters/submetrics that can be reduced by humans to single chunks. But if you do think of any, let me know.

------

Okay, back off topic, sort of...

I had another stray thought while working on the code:

As you know, the code currently supports, for just about every numeric parameter, applying it as a coefficient, base (of a logarithm), or exponent (of a power). It occurs to me that we could imagine applying them in a couple other ways: as bases of powers, or exponents of logarithms. I don't have any particular reason to believe they'd be involved in good fits for the Scala data. But perhaps to be exhaustive we should experiment with them.

It also begs the question: what do we call the fourth type of growth in this analogy:

f(x) = exponential c^x : power x^c :: logarithmic log_c(x) : ???? log_x(c)

There's really a 2x2 matrix here: on one axis, whether the parameter is the base or the exponent; on the other, whether we are powering down (logarithmiation) or powering up (exponentiation). I'm less surprised that powering down is non-commutative, since subtraction and division aren't, but it is interesting to me how powering up isn't, since addition and multiplication are.

And it's kind of interesting that the most common of these two operations – "raising to a power" c, and "taking a logarithm" with base c – are on a diagonal of this matrix from each other. I would wager most people consider those two to be opposites.

Dave Keenan
Posts: 1069
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: developing a notational comma popularity metric

cmloegcmluin wrote:
Thu Jul 16, 2020 2:24 am
I read the intro to your SATI paper. I had never heard of async circuits before. I read a bit about quantum computing at some point but this seems totally different.
Yeah. Perfectly classical semiconductor logic circuits. Just wired up differently.
This boundary algebra notation from Jeffrey James and William Bricken... I know I've seen this before! Even just the general look of these papers – the font and such. It's driving me nuts.
I linked you to them way back when we were discussing aligning notations for different levels of the log, linear, exponential hierarchy.
In the meantime, here's a Smalltalk quine, on my favorite programming chrestomathy site: http://rosettacode.org/wiki/Quine#Smalltalk
Cool.
Do you want me to include the z=1 SoS in the output of my program? It won't make it run much slower.
Good idea. You only need to calculate it after you've found your best minimum.
Every example you give in your table is still sorted the same Can't unsee things as their ranks now. Everything I see is only itself ranked...
I don't know what you mean. They would be in a different order if they were sorted on their z=1 SoS. Are you saying I should have done that? Feel free to do it yourself.
It also begs the question: what do we call the fourth type of growth in this analogy:

f(x) = exponential c^x : power x^c :: logarithmic log_c(x) : ???? log_x(c)
We normally call it the "nth-root" although in your example it is the cth root.
"There's really a 2x2 matrix here: on one axis, whether the parameter is the base or the exponent; on the other, whether we are powering down (logarithmiation) or powering up (exponentiation). I'm less surprised that powering down is non-commutative, since subtraction and division aren't, but it is interesting to me how powering up isn't, since addition and multiplication are.
Yes. That is interesting. And the James/Bricken (boundary) notation makes that very clear. And it makes it clear that there is a commutative operation at that level, and it corresponds to what in standard notation is xlog(y), which looks completely like it couldn't possibly be commutative, but it is. So standard notation is stupid in that regard.

The arrow here means "translates from boundary notation into standard notation as".
empty space → 0
juxtaposition is addition, i.e.
x y → x + y
(x) → exp(x), so
() → exp(0) = 1
[x] → log(x)
So
([x][y]) → exp(log(x)+log(y)) = x × y, commutative because x and y at same depth of nesting
(([[x]][y])) → exp(log(x) × y) = xy, not commutative because x and y at different depths of nesting
(([[x]][[y]])) → exp(log(x) × log(y)) = xlog(y), commutative because same depth

You only need these two rules:

([a]) = a = [(a)] → log(exp(a)) = a = exp(log(a)), the law that () and [] are inverses
(a [b]) (a [c]) = (a [b c]) → z×b + z×c = z×(b+c), where z = exp(a), the distributive law
And it's kind of interesting that the most common of these two operations – "raising to a power" c, and "taking a logarithm" with base c – are on a diagonal of this matrix from each other. I would wager most people consider those two to be opposites.
No way. exp and log are the inverse of each other, as are power and root.
clogcx = x
logc(cx) = x
(cth-root(x))c = x
cth-root(xc) = x

cmloegcmluin
Posts: 769
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

Re: developing a notational comma popularity metric

Dave Keenan wrote:
Thu Jul 16, 2020 9:19 pm
I linked you to them way back when we were discussing aligning notations for different levels of the log, linear, exponential hierarchy.
Oh man I’m such an ass! Sorry I forgot it was you.
Do you want me to include the z=1 SoS in the output of my program? It won't make it run much slower.
Good idea. You only need to calculate it after you've found your best minimum.
Okay, so to confirm, you don’t want it to be a new factor in the search for best metrics; you’d only be interested in knowing it as well, after I found best ones by z=-1.
Every example you give in your table is still sorted the same
I don't know what you mean. They would be in a different order if they were sorted on their z=1 SoS. Are you saying I should have done that?
Heh, no, I didn’t mean that. You sure you didn’t switch it up on me? I could have sworn when I looked it over before that both columns, z=1 and z=-1, were monotonic.
It also begs the question: what do we call the fourth type of growth in this analogy:

f(x) = exponential c^x : power x^c :: logarithmic log_c(x) : ???? log_x(c)
We normally call it the "nth-root" although in your example it is the cth root.
Not exactly, though, right? Say x was 9 and c was 3. The answer is 1/2. I know this is a way of expressing that the 2nd root of 9 is 3. But I’ve mapped 9 to 1/2. 2 is not the 2nd root of 9. Maybe we could call this operation the “whichth-root”? I don’t like it because it could apply equally well to logarithms.

Anyway, this conversation could probably go on a while. If you’re interested in pursuing it further, feel free to email me about it.

In the meantime, do you think I should bother implementing parameters including the other corners of this operation matrix?
And it makes it clear that there is a commutative operation at that level, and it corresponds to what in standard notation is xlog(y), which looks completely like it couldn't possibly be commutative, but it is.
Oh that reminds me of a discovery I made when working on the talk I presented at UnTwelve camp last year. You haven’t happened to come across my logharmonic and powharmonic scales yet, have you? The bit I’m referring to is described here: https://en.xen.wiki/w/Powharmonic_serie ... xplanation
And it's kind of interesting that the most common of these two operations – "raising to a power" c, and "taking a logarithm" with base c – are on a diagonal of this matrix from each other. I would wager most people consider those two to be opposites.
No way. exp and log are the inverse of each other, as are power and root.
clogcx = x
logc(cx) = x
(cth-root(x))c = x
cth-root(xc) = x
Ah, yes, you’re totally right.

Dave Keenan
Posts: 1069
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: developing a notational comma popularity metric

cmloegcmluin wrote:
Fri Jul 17, 2020 9:18 am
Oh man I’m such an ass! Sorry I forgot it was you.
Not a problem.
Okay, so to confirm, you don’t want it to be a new factor in the search for best metrics; you’d only be interested in knowing it as well, after I found best ones by z=-1.
Correct.
Heh, no, I didn’t mean that. You sure you didn’t switch it up on me? I could have sworn when I looked it over before that both columns, z=1 and z=-1, were monotonic.
No. Sorry.
Not exactly, though, right? Say x was 9 and c was 3. The answer is 1/2. I know this is a way of expressing that the 2nd root of 9 is 3. But I’ve mapped 9 to 1/2. 2 is not the 2nd root of 9. Maybe we could call this operation the “whichth-root”? I don’t like it because it could apply equally well to logarithms.
You're right. Will discuss further by email.
In the meantime, do you think I should bother implementing parameters including the other corners of this operation matrix?
No.
Oh that reminds me of a discovery I made when working on the talk I presented at UnTwelve camp last year. You haven’t happened to come across my logharmonic and powharmonic scales yet, have you? The bit I’m referring to is described here: https://en.xen.wiki/w/Powharmonic_serie ... xplanation
No, I didn't. I had a quick look now, but I don't understand why they are of musical interest, except that compressed or expanded harmonics (I forget which) sound metallic.

cmloegcmluin
Posts: 769
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

Re: developing a notational comma popularity metric

Dave Keenan wrote:
Sat Jul 18, 2020 1:30 am
I don't understand why they are of musical interest
I get that a lot. I guess my musical interests are pretty different from most folks'!

When I can I've been working on the code for my metric solver. Nothing really to report. A bit of back and forth unfortunately as things which look like great improvements at first turn out to have really ugly surprising effects. Getting the code right is hard. At least it is for me.

cmloegcmluin
Posts: 769
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

Re: developing a notational comma popularity metric

I'm back from my trip. I got a few hours here and there while traveling, during which time I was able to rework the code to handle lb as a single chunk. I also reworked it so that a given parameter can have the same value applied across all the submetrics and count only as a single chunk.

My next plan is to finally dig in and confront the issue of combinations of parameters which lead to blue threads of death. I'm thinking, however, that there may turn out to be a larger large number of deadly combinations; something changed in how my code works which has caused it to no longer be able to complete even a search for the best 3-chunk metric without getting stuck on a combination with one w on one submetric and a different w on another submetric; I'm not sure how it ever got past these types before, but it seems like it shouldn't have, since you should be able to increment one w in ever smaller bits while decrementing the other in ever smaller bits forever. So I'm now thinking that a dumber (in a good way) solution to the problem might be to pull the plug on any investigation which takes longer than a few seconds, since I've already refactored it to run each possibility in a breadth-first style thereby finding the best spots ASAP with extremely diminishing returns the longer it runs.

We're definitely on the home stretch! Sorry to have lost so much momentum. But taking a break was good.

Dave Keenan
Posts: 1069
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: developing a notational comma popularity metric

cmloegcmluin wrote:
Mon Jul 27, 2020 9:07 am
I'm back from my trip. I got a few hours here and there while traveling, during which time I was able to rework the code to handle lb as a single chunk. I also reworked it so that a given parameter can have the same value applied across all the submetrics and count only as a single chunk.
Good work.
My next plan is to finally dig in and confront the issue of combinations of parameters which lead to blue threads of death. I'm thinking, however, that there may turn out to be a larger large number of deadly combinations; something changed in how my code works which has caused it to no longer be able to complete even a search for the best 3-chunk metric without getting stuck on a combination with one w on one submetric and a different w on another submetric; I'm not sure how it ever got past these types before, but it seems like it shouldn't have, since you should be able to increment one w in ever smaller bits while decrementing the other in ever smaller bits forever. So I'm now thinking that a dumber (in a good way) solution to the problem might be to pull the plug on any investigation which takes longer than a few seconds, since I've already refactored it to run each possibility in a breadth-first style thereby finding the best spots ASAP with extremely diminishing returns the longer it runs.
Good plan.

cmloegcmluin
Posts: 769
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

Re: developing a notational comma popularity metric

Argh, I forgot that I meant to say this: I realized while I was traveling that you (and others on this thread) may feel I'm holding it hostage. We probably could pull the trigger on a replacement for SoPF>3 with the info we have now, but I'm being precious about the effort I invested in my own personal solver for this. If you'd like, we can put a timebox on my own efforts, and if I don't come up with something by that deadline, we move on. Let me know how you're feeling.

Dave Keenan
Posts: 1069
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: developing a notational comma popularity metric

I don't want to propose a deadline on your efforts, given that you are conscious of the problem. If we cut them off prematurely, I'd be left wondering if we'd missed something.

But your efforts have already produced several of the metrics in my "best of" table below, and it's possible that further efforts will not produce any new ones. And you're the chunk-counting expert, so could you please add a "Chunk count" column to this table. [Edit: Done.]

MetricLowest SoSSoS chunk
namefound z=-1with z=1count
sopfr0.01420608719845.01
k0.00949124318757.52
j0.00910097118653.52
wyk0.00746044317077.55
cwyk0.00730019516890.57
wyks0.00640663914125.56
hyg0.00637271317867.55
wyb0.00605764915638.55
xwyks0.0055389214309.57
cwyks0.00405952213440.58

These metrics are defined here: viewtopic.php?p=2075#p2075

Are there any others we've mentioned previously that you think should be on this list? [Edit: k and j added, see below.]

cmloegcmluin
Posts: 769
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

Re: developing a notational comma popularity metric

Okay, I've added the chunk counts, as well as two 2-chunk entries:

The "k" entry is text{sopfr} where k = 0.7901235.
The "j" entry is text{sopfr} where j = 1.0954774 and is an exponent.

Doing this task has made me realize that it does not support recognizing text{wyb}
as 7 chunks. It'd consider it an 8-chunk metric. The points of disagreement is this: I think that using one submetric on n and another on d feels like a single chunk of complexity; however, my code can only realize this as the first submetric adding a chunk (k = 0) to zero out its d, and the other adding a chunk (j = 0) to zero out its n. Unfortunately, a "cross-submetric parameter chunk" such as this would add a surprising amount of complexity to the code, which I'm not convinced is worth it. My gut says that using different submetrics on n and d feels psychoacoustically unmotivated.