Dave Keenan wrote: ↑Sat Oct 24, 2020 1:28 pm
cmloegcmluin wrote: ↑Sat Oct 24, 2020 4:22 am
Whoops. Looks like I never finished up on the sub-topic of pre-calculating sorted numerators to help deepen our list of top 2,3-free classes by N2D3P9. I'll return to that later.
Sure. Forget about that for now. The following is more important.
Well, it was barely any work to queue it up with the corrected max N2D3P9 of 5298.2, so I had already kicked it off last night. It crashed just after I woke up, and for a perfectly foreseeable reason: "Error: This integer 8368831 contains primes which are too big." I had to cut off the code's list of primes somewhere, and I happened to cut it off at 8368819. I suppose I could go up to 10 million. Then I could finish the script, which needs to reach 9765625. Anyway, I can pick up from where it crashed overnight tonight.
By the way, the biggest numerator within the N2D3P9 range it found so far this time was quite similar to
last time. Last time it reported 1953125, which is 5
9. This time it reported 2734375 which is 5
87. It would have reported 2734375 last time had the max N2D3P9 been set properly to 5298.2 rather than 3501. Again, the script will be truly done once it reaches 9765625, which = 5
10. 5
811 = 4296875 won't make the cut with an N2D3P9 of 10257.3, but it's still possible there's a result out there.
Your problem may be that you have transcribed it wrongly as 2^(DATE-ATE) when it was actually 2^(ATE-DATE).
Baaah. Yes that was the problem. Thanks for working it out for me. I'm not sure whether I'm more disappointed in my failure to reason my way out of the transcription error, or the lack of care in the original transcription error
N2D3P9a + t × 2^ATE + s × 2^AAS
or
lb(N2D3P9) + t × ATEb + s × AASc
or
lb(N2D3P9) + t × ATEb + s × 2^AAS
or
N2D3P9a + t × 2^ATE + s × AASc
Okay, got it. I did understand that the numbers in the fns for ATE and AAS were independent, but I didn't quite understand that the operations were independent from each other (one could be a power fn, other could be an exponentiation fn) and independent from the inverse version for the N2D3P9. So: we would never in the same equation raise 2 to the AAS and raise AAS to the c; those are two alternative fns. And it'll always be addition separating the three terms. And here's an exhaustive list of the 2
3 possible forms
lb(N2D3P9) + t × 2^ATE + s × 2^AAS
N2D3P9
a + t × 2^ATE + s × 2^AAS
lb(N2D3P9) + t × ATE
b + s × 2^AAS
N2D3P9
a + t × ATE
b + s × 2^AAS
lb(N2D3P9) + t × 2^ATE + s × AAS
c
N2D3P9
a + t × 2^ATE + s × AAS
c
lb(N2D3P9) + t × ATE
b + s × AAS
c
N2D3P9
a + t × ATE
b + s × AAS
c
And I'll start s and t out in the vicinity of 0.00195 then.
KISS
Maybe start by doing only the Extreme precision.
Word.
That's enough to verify for me that the original plan to go by secondary comma zones should suffice. It's super easy to implement it that way since I already have the secondary comma zones ready to go, because those are the zones I'm searching for competing commas. In fact, now that I articulate it that way, the original plan's logic comes into focus.
Dave Keenan wrote: ↑Sat Oct 24, 2020 3:22 pm
cmloegcmluin wrote: ↑Sat Oct 24, 2020 1:06 pm
Although I was actually going to take it even a step further and suggest we use a colon to indicate that it’s undirected, like this:
{5:7}
(2, 3)
Good point about it being undirected. Would we ever want it directed?
I don't think so, not with the way N2D3P9 was designed to always want n ≥ d.
With the colon, I'd have to write "5:1" or "1:5", and I like to be able to write just "5".
Okay, that's a good counter-point. The code does not currently drop denominators of 1 when formatting for output quotients (ratios) such as ones that appear in 2,3-free classes. But it should drop them, and I've taken a note to make it do that. And I'll keep it how it is with respect to using slashes rather than colons for 2,3-free classes.
And I don't think we need two set of brackets. I think we only need one set (curly), around either the ratio or the list of subscripted primes, not both. We previously agreed to have it only around the subscripts (when it was round brackets). But I don't mind having it around the ratio instead, if that's what you prefer, now that it's curly.
At the time I pushed for round brackets around the subscripted primes, I wasn't thinking of them semantically so much as visually. That is, brackets around the ratio seemed less necessary because everything there was glued together with the vinculum, whereas I found it rather disconcerting to have the list of primes in the subscript glued together by only a comma (you know, the punctuation kind, not the musical kind,
), or worse, floating apart with a space after the comma. That's really all I was thinking about at that time. I don't think these thoughts are important; I think they're kind of silly. But anyway, those were the extent of my thoughts at that time.
Now that we're getting serious and considering the semantics of the punctuation, such as how curlies suggest classes or sets, I think I do prefer it around the ratio, since that's the 2,3-free class. I suppose the subscripted list of primes is a set, but it doesn't feel like it's the primary set or class of interest, you know?
I know you don't want brackets around both the ratio and the subscript. Between the two, I would be more okay with dropping the round brackets in the subscript, especially if we don't include spaces after the commas there. Like this:
{n/d}
p1,p2...
{7/5}
2,3
{5}
2,3
That said, I feel like I should defer to you on this matter. I can barely follow the expanded form I'm making suggestions for the shorthand for, while you can apparently not only read it, but you actually produced it. So clearly you're a lot more familiar with these types of expressions.
Oh yeah, I just remembered how I made it so the code can format them to take advantage of the forum's LaTeX support, like so:
\(\{\frac{n}{d}\}_{\scriptsize{p_{1},p_{2}...}}\)
\(\{\frac{7}{5}\}_{\scriptsize{2,3}}\)
\(\{5\}_{\scriptsize{2,3}}\)