Christmas Eve Conjecture

[Davide Rotondo]

Hi to all dear seq fans, how are you?

I remain focused on my last conjecture that I posted on the group and I propose that you verify or falsify the following...

Conjecture: Primes q = 2*p+2, where p == 2 (mod 5) is also prime, are primes with primitive root 3.

I checked up to the 1000th prime with primitive root 3 (circa p=67) without finding exceptions.

Davide

[Michel Marcus]

1000th prime with primitive root 3 (circa p=67) : sounds weird ?

and a quick check did not work for me

are you sure ?

when will you learn to program ?

Sans virus.www.avast.com

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/seqfan/4b12ce8b-24ea-4006-b4f0-a98882df425dn%40googlegroups.com.

[Michel Marcus]

aide-toi et le ciel t'aidera ...

Sans virus.www.avast.com

[Md. Rad Sarar Anando]

Dear, 
As written, the conjecture may be false in the sense of generating primes, because 2*p+2> 2 is never prime.

Proof:

Let's factor out 2; q=2*p+2=2*(p+1), then observe parity, p+1 is an integer (since p is an integer). Therefore, q=2*(p+1) is even. For "even primes", the only even prime number is 2. So, if q is prime, we must have q=2. And lastly solve for p as this: 2*p+2=2=>2p=0=>p=0. Thus, p=0 is not prime. So there is no prime p>0 satisfying 2*p+2=prime.

Therefore, for any prime p>0, q=2*p+2 cannot be prime.

Is this correct? Let me know.

Regards, 
Rad

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAFxT7zWrPRaMhNfeM2_z-qwOwgNzX5AZMKo3uPMvXe1CUWWMcA%40mail.gmail.com.

[Davide Rotondo]

Sorry it is my guilty. I meant that if 

 2 + 2 x + 5 x²  

^{Is prime then these primes have primitive root 3.}

^Davide

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CA%2Bx4cjncnS3yUPx1WojjZMvGQohuBBZzHzHLF6O0zG0U_eomSQ%40mail.gmail.com.

[Md. Rad Sarar Anando]

Dear Davide, 
I applaud your effort. That literally killed me! And I have no doubt that this is a great thing you have done. How did you come across this? Well, the most possible part of your conjecture is that it has a great connection with  "Artin’s primitive root conjecture" and some "Chebotarev density theorem". And fortunately being stronger than  Artin’s primitive root conjecture, your conjecture shows more ways to be <<proven>> rather than be false ! But it's hard enough.

I am surprised by this one. And now thinking about this.

Regards,
Rad

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAJu53H_K_bQWm%2B_b-u5KhyMhLw7O_zTGPnTULH7ScgAnAdj7WA%40mail.gmail.com.

[Jonas Karlsson]

Dear Davide,

It took me only a few minutes to write Python code to find that p = 1286261 is a counterexample - we get it for x = 507. 

In your first message you "propose that you verify or falsify" your conjecture. I propose, kindly, that you learn to program.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAJu53H_K_bQWm%2B_b-u5KhyMhLw7O_zTGPnTULH7ScgAnAdj7WA%40mail.gmail.com.

[David desJardins]

You don't need to program, at all. This works fine:

https://chatgpt.com/share/694c2950-4b20-8008-91c1-6b98d0aed1e6

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CABiOuo9phYCpHPNJFzArqjingXpHnX%2B3DXWuQvt3g3WTphuA_A%40mail.gmail.com.

[Davide Rotondo]

Sorry, next year will be better!

Davide

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAP%3DxTqPgTysQRvBw_1JmZbuwnRqW7b609AEojEYFg-iTUjSRfA%40mail.gmail.com.

[Md. Rad Sarar Anando]

Dear Davide, 

Sorry for interrupting. 

Run this code, 

from sympy import isprime, factorint

def is_primitive_root_3(p):
    phi = p - 1
    for r in factorint(phi):
        if pow(3, phi // r, p) == 1:
            return False
    return True

for x in range(1, 2000, 2):  # only odd x give odd q
    q = 5*x*x + 2*x + 2
    if isprime(q):
        if not is_primitive_root_3(q):
            print("Counterexample found")
            print("x =", x)
            print("q =", q)
            break


Concurring with Jonas, I got the same...but your work was interesting as I said. If you show this this way, it should be hardest to prove might be:
  For all x≥1 such that q=5x2+2x+2 is prime, and for every prime r≤log(q), r does not divide the order of 3 modulo q, then 3 is a primitive root modulo q if and only if the Frobenius automorphism of q in K/Q lies in the specified conjugacy class.

 provable by principle, but effectively impossible to verify    

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CABiOuo9phYCpHPNJFzArqjingXpHnX%2B3DXWuQvt3g3WTphuA_A%40mail.gmail.com.

[Ruud H.G. van Tol]

On 2025-12-24 18:56, David desJardins wrote:
> You don't need to program, at all. This works fine:
> https://chatgpt.com/share/694c2950-4b20-8008-91c1-6b98d0aed1e6

Please be aware that independent confirmation is essential.
Next, AI-results are always too weak to accept as is.


PARI:
? { forstep(x=-99, 10^3, 2
    , my(p= 2+2*x+5*x^2);
      if(isprime(p) && znorder(Mod(3, p)) != p-1
      , print(x, " fails")
      )
    );
}

-45 fails
-3 fails
507 fails
537 fails
627 fails
647 fails
687 fails
747 fails
807 fails
857 fails

cpu time = 3 ms, real time = 3 ms.

-- Ruud

[David desJardins]

On Wed, Dec 24, 2025 at 10:34 AM 'Ruud H.G. van Tol' via SeqFan <seq...@googlegroups.com> wrote:

On 2025-12-24 18:56, David desJardins wrote:
> You don't need to program, at all. This works fine:
> https://chatgpt.com/share/694c2950-4b20-8008-91c1-6b98d0aed1e6

Please be aware that independent confirmation is essential.
Next, AI-results are always too weak to accept as is.

That seems like an unreasonable distrust of particular tools but not others. Why should I trust your program? Maybe PARI has a bug. Maybe there's a hardware fault.

[Daniel Mondot]

"independent confirmation is essential"

Yes, absolutely.

As for AI tools, they have been known to hallucinate results. And yes, they are getting better, But I don't think we are at a point where they can be trusted.

But you are right, all tools can have problems. Here is my experience:

I am currently working on a particular sequence.  A simple program worked fine but was slow.

A multi-threaded version of that program worked faster with 8 branches, 1 core per branch, but worked even faster with 4 cores.

That suggested to me that I could rearrange some processes to make it faster.

So I have been experimenting with spreading the load with even more threads. But now, I am getting random errors that suggest that things happen out of order, and I am struggling to explain it.

I am now not only considering that I may have made a few mistakes, but also:

- the compiler may have some issues, That has been known to happen.

- the operating system might not be restoring context correctly when a task moves from one core to another, in some rare cases. OS problems have been known to happen.

- the hardware might not be handling memory caching correctly in some cases where multiple cores repeatedly use the same part of memory. Processor bugs have been documented.

In other words, there are so many reasons why I might not be getting the right answer, so an independent look at the same problem on a different machine, different operating system, different language, different approach must get the same result so that a result can be validated.

Any tool can have a problem, Guaranteeing that a tool works perfectly is virtually impossible,

Daniel.

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAP%3DxTqMEwSWQ8_2pZL-RaF83gxLeFwxCoG0k-ha_24cnhn%3D1sw%40mail.gmail.com.

[Gareth McCaughan]

For a PARI program to say no when the actual answer is yes, there needs to be a bug somewhere -- in the program, in PARI, in the hardware.

For an LLM to say no when the actual answer is yes, there doesn't need to be a bug somewhere. The LLM just needs to get it wrong, as LLMs (like humans) sometimes do. This seems to me like an important difference.

In this case the LLM produced a detailed enough answer that one could check its work. Unfortunately, LLMs produce output that _looks_ plausible but is actually wrong more frequently than humans do, so one would be well advised to check carefully. Perhaps you already did that, but you didn't _say_ you did. So I would be ill advised to trust what the LLM says without doing that careful checking.

The underlying question here is what Davide might do if he chooses to check his conjectures more thoroughly before posting them. Whether asking an LLM is an effective approach depends on whether Davide considers himself sufficiently expert in mathematics to judge answers like the LLM one that you posted. I don't know whether he does, but if I were reading that answer then I would e.g. want to check the assertion near the end that 3^257252 = 1 mod 1286261, and I'd want to use a computer for that. (It might not require _programming_ exactly, though in fact the tool I'd likely reach for would be a programming language.) I'd likewise want to check the claims made in support of applying Pocklington's criterion, which would also need a computer, and personally I'd have to look up what Pocklington's criterion actually says because I am not familiar with it.

So anyone not willing just to assume that what the LLM outputs is reliably correct would have quite a bit of extra work to do to check that answer. Not obviously much less work than it would take to look for counterexamples oneself.

Do you think the LLMs have become reliable enough that one can just assume that what they say is correct? It doesn't seem that way to me; they have definitely improved a lot over, say, the last year, but they do still sometimes say things that are plausible but quite wrong.

--
g

[David desJardins]

On Wed, Dec 24, 2025 at 1:19 PM Gareth McCaughan <gareth.m...@pobox.com> wrote:

Unfortunately, LLMs produce output that _looks_ plausible but is actually wrong more frequently than humans do

That is not my experience. Humans make a lot of mistakes.

Do you think the LLMs have become reliable enough that one can just assume that what they say is correct?

I think it depends on your loss function. I definitely don't trust humans enough that I can just assume that what they say is correct, regardless of the stakes. 

[Jonas Karlsson]

Here are some things LLM have told me in the past few months:

1) If any two vertices in a graph are connected by a unique path, then the graph is a forest.

2) Any two embeddings of a tree in a sphere are isotopic because the tree bounds a disk.

3) The product of two trinomials can never simplify to a binomial.

In all cases the faulty claim was backed up by superficially sound reasoning. So to distrust LLMs more than Pari seems quite reasonable to me. 

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAP%3DxTqOpAC0d72az2oycn-6jtBseSyCPANGzkjS_W-YUeTORNQ%40mail.gmail.com.

[Jonas Karlsson]

Correction: claim 1) was that if any two vertices are connected by a unique *shortest* path, then the graph is a forest, so the claim was actually wrong and not just too weak.

[David desJardins]

Those seem awfully different from the arithmetic calculations we were discussing earlier. I wouldn't trust an unknown-to-me human who told me any of those things, either. That's why we have proofs. And proofs written by humans can definitely be wrong, too.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CABiOuo_XNQTDEsrY%2BiCsUfbd2a%2BgxjkOogykD61EjrczsxzKxA%40mail.gmail.com.

[Jonas Karlsson]

...it seems weird to have to say this, but: Pari does not say anything about shortest paths, or embeddings of graphs in surfaces, or any random thing you might think to ask it. It is a well-tested software package with a small number of well-defined operations. An LLM, by contrast, will happily spin a narrative about anything at all. So I maintain that we should be a lot more skeptical about the latter. 

Fun fact, brought up in an attempt to defuse the developing flame war: Pari is Persian for fairy. I have taken to calling LLMs "gnomes", a word coined by Paracelsus and conjecturally based on "gnosis". In these terms, I trust the fairy but I remain skeptical of gnomes, for the time being. 

Merry Christmas, folks!

J

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAP%3DxTqNFu%3D3iGZW4bXVOEwVJQKYJVuwAqZ8Jcp5UyLEzE-qtuw%40mail.gmail.com.

[David desJardins]

On Wed, Dec 24, 2025 at 2:13 PM Jonas Karlsson <jonas...@gmail.com> wrote:

...it seems weird to have to say this, but: Pari does not say anything about shortest paths, or embeddings of graphs in surfaces, or any random thing you might think to ask it. It is a well-tested software package with a small number of well-defined operations. An LLM, by contrast, will happily spin a narrative about anything at all. So I maintain that we should be a lot more skeptical about the latter. 

Or maybe you should just be judicious about how you use it. You could write code to have Pari output random text if you want.

[Gareth McCaughan]

On 24/12/2025 21:21, David desJardins wrote:

On Wed, Dec 24, 2025 at 1:19 PM Gareth McCaughan <gareth.m...@pobox.com> wrote:

Unfortunately, LLMs produce output that _looks_ plausible but is actually wrong more frequently than humans do

That is not my experience. Humans make a lot of mistakes.

Oh yes, indeed we do. But our mistakes tend to be more visible, relative to their severity, than the LLMs'. So it looks to me, anyway; perhaps I'm wrong.

Do you think the LLMs have become reliable enough that one can just assume that what they say is correct?

I think it depends on your loss function. I definitely don't trust humans enough that I can just assume that what they say is correct, regardless of the stakes.

For sure.

But note that one _can_ pretty reliably just assume that what, say, PARI outputs is correct if what you put into it is correct.

If I say "here is a bit of PARI code that shows that the answer to your question is no", then you can trust that to almost the exact same extent as you trust me; if you (wisely) don't trust me very much you need to check my PARI code but you probably don't feel much need to check that PARI executed it correctly.

If I say "here is the version of your question that I asked ChatGPT and it says the answer is no", then now you need to trust _both_ me (that I asked the right question) _and_ ChatGPT. If you don't trust me, you need to check the input I gave to ChatGPT. If you don't trust ChatGPT, you need to check its output.

In the particular case here, as I observed before, checking ChatGPT's output isn't actually much less work than checking the original question directly, and requires much the same skills.

(For the avoidance of doubt: I am _not_ saying no one should ask an LLM mathematical questions. It will often get them right. I expect that for large classes of questions the LLM will get them right more reliably than, say, I will. I'm just saying that "the LLM said X" is a bit like "my friend with a mathematics PhD said X": LLMs, like humans, are systems that do things fuzzily and unreliably and you can't be confident that as long as you asked the question correctly the answer is right. Which you more or less can with something like PARI.)

--
g

[Antti Karttunen]

Important thing here is transparency or lack of it. With LLM's we have no way of knowing how they hallucinated their answer (even though the answer still might be correct in many cases), in contrast to a case where somebody shows us both a PARI-procedure they wrote and the results it produced. In the latter, by following the basic logic and algorithmic thinking, we can see whether the procedure should give correct answers to our problem, and if we are unsure whether our PARI-implementation is working correctly, we can rewrite it in another programming language and try again, even in a different computer, if we suspect the hardware is deeply flawed.

That being said, it would be nice if the outputs of PARI-functions were specified / documented more exactly, not leaving them such amount of fuzzy leeway as recently was noted with that notorious lindep-function.

Best regards,

Antti

[sven-h...@gmx.de]

Hello together,

the LLMs just need some more experience and usage. The hype is to much and just because of commercial reasons – AI will get control about everything. AI can do a lot in distinct areas (think of folding proteins or GO). Gereral use just has some more needs. I wait for self driving cars – coming soon.  There won’t be much areas where AI is not better than humans and this is a danger. When it is boring for humans they usally get very bad ideas.

A bit lucky having no kids.

Sven

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAB%2B0_%3D%3DH4kOuQ%2BmhKqZPvWy2qAA2-_VQRtAXg%3Dwgj_dVw0US0A%40mail.gmail.com.

[Neil Sloane]

AI will certainly get much better than us at war - think nerve gas,
viruses, poisoned rain, nuclear errors, etc. What could possibly go
wrong? We don't have much time left.
Best regards
Neil

Neil J. A. Sloane, Chairman, OEIS Foundation.
Also Visiting Scientist, Math. Dept., Rutgers University,
Email: njas...@gmail.com

> To view this discussion visit https://groups.google.com/d/msgid/seqfan/000401dc75b8%240ba00160%2422e00420%24%40gmx.de.

[aoife cassidy]

David, Sven,

LLMs have no idea what facts are. so-called "hallucinations" to describe
faulty output are a marketing term for what is (scientifically!)
describe as "bullshit"[1]. they have no concept of truth, or fact, or
correctness. saying that AI errors are comparable to reproducible
computer errors — heck, even to human errors — is a fundamental
misunderstanding of what LLMs are and how they work. they are also, as
discussed in this thread, really good at convincing you that they're
competent.

an LLM is not "malfunctioning" when it tells you the wrong thing: it is
categorically working as intended.

[1]: https://www.scientificamerican.com/article/chatgpt-isnt-hallucinating-its-bullshitting/

[David desJardins]

On Thu, Dec 25, 2025 at 1:55 PM 'aoife cassidy' via SeqFan <seq...@googlegroups.com> wrote:

LLMs have no idea what facts are. so-called "hallucinations" to describe
faulty output are a marketing term for what is (scientifically!)
describe as "bullshit"[1]. they have no concept of truth, or fact, or
correctness. saying that AI errors are comparable to reproducible
computer errors — heck, even to human errors — is a fundamental
misunderstanding of what LLMs are and how they work.

You are wildly out of touch with the current reality. I can only suggest that you collect some evidence for yourself, instead of buying into propaganda that tells you what you want to believe.

[Dave Consiglio]

Yikes. The vitriol! This is a math mailing list people. 

The obvious solution is trust but verify. Use AI to help if you like but back it up with proof and/or additional strategies. 

I have never used AI to help me with a sequence until my most recent submission - and AI was incredibly helpful there. It coded beyond what I could quickly do, but that code produced results that matched the literature and was clear, concise and easy to verify. 

So in the spirit of the holidays, please keep things civil and recognize that humans and LLMs both mistakes, as many have here today. Be kind. Do math. Math doesn't judge. 

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAP%3DxTqNXtJrEisHWLQqvfjT-qtrOtYVwCPcz4W5oC%3D3pF%3DbKug%40mail.gmail.com.

[Dave Consiglio]

I missed a "make". See? We all err. 

[Daniel Mondot]

I hadn't used an AI for some time, and they are getting better, so I wanted to check how good they are now.

So, I asked 5 online AI systems, 3 questions, here are the results (I only copied the summary answer)

Question 1: What are the numbers that, when written in bases 2 to 5, only use the digits 0 and/or 1 ?
Answers:
Gemini: There are only two numbers that satisfy this for all four bases: 0 and 1.
ChatGpt: The only numbers that, when written in bases 2, 3, 4, and 5, use only the digits 0 and/or 1 are: 0 and 1.
Copilot: All powers of integers ≥ 1
Claude AI: After systematic checking, the only numbers that satisfy all these constraints are: 0 and 1
Perplexity AI: The set of all such integers is: { 2^a*3^b*5^c:a,b,c≥0 }, which in increasing order begins 1,2,3,4,5,6,8,9,10,12,15,16,18,20,24,25,27,30,32,36,...
Correct answer: The only known numbers are: 0, 1, 82000. see A146025

Question 2: What planet is on average closest to trappist-1h?
Answers:
Gemini: In the TRAPPIST-1 system, the planet that is on average closest to TRAPPIST-1h is TRAPPIST-1g.
ChatGPT: TRAPPIST-1g is the next planet inward from TRAPPIST-1h in orbital order. So on average, the planet closest to TRAPPIST-1h is TRAPPIST-1g.
Copilot: Since g is the next planet inward, it is the one closest to h on average. Answer: TRAPPIST‑1g
Claude AI: Since TRAPPIST-1h is the farthest planet out, its nearest neighbor is TRAPPIST-1g, TRAPPIST-1g is on average closest to TRAPPIST-1h.
Perplexity AI: On average, the closest planet to TRAPPIST-1h is TRAPPIST-1g.
Correct answer : Trappist-1b

Question 3: What is the smallest number of the form 2^n-1 that, when written in ternary has its lowest zero in position 26?
Answers:
Gemini : 2^33554432-1
ChatGPT: 2*3^25-1
Copilot: 2^351-1
Claude AI: 2^1,694,577,218,886 - 1.
Perplexity AI: Without the ability to perform that modular search or access a database of such precomputed ternary patterns for 2^n−1, the precise smallest n and the corresponding value of 2^n−1 cannot be given here.
Correct answer: 2^143-1  (a well written program should find this is less than a second)

In conclusion, AI systems are still hallucinating answers.

The funny thing about question 2 is that if you ask "What planet is on average closest to Pluto?", they will correctly answer "Mercury" because that answer appears everywhere on the web, but they can't seem to know how to extrapolate that answer to a different system.

Daniel.

On Thu, Dec 25, 2025 at 5:21 PM David desJardins <da...@desjardins.org> wrote:

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAP%3DxTqNXtJrEisHWLQqvfjT-qtrOtYVwCPcz4W5oC%3D3pF%3DbKug%40mail.gmail.com.

[Jeffrey Shallit]

Again, you can't just say "ChatGPT"; there are many versions of ChatGPT, so you need to specify if you are talking about 3.5, 4o, 5.1, 5.2 or what.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAD5iKaiCgEGcpFahArmvgg80sSGB6a_5EqS2LPSjPXm_q1tOkQ%40mail.gmail.com.

[David desJardins]

On Thu, Dec 25, 2025 at 4:15 PM Daniel Mondot <dmo...@gmail.com> wrote:

Question 3: What is the smallest number of the form 2^n-1 that, when written in ternary has its lowest zero in position 26?

Correct answer: 2^143-1  (a well written program should find this is less than a second)

2^143-1 has its lowest zero in position 25. I guess you’re “hallucinating”, now!

Certainly, AI is good at some things and not so good at other things. And in some cases it matters how you ask the question, just as with any tool it matters how you use the tool. If you want to try to make the tool fail, I’m sure you can do that, with pretty much any tool. But you’re doing a terrible job of trying to prove that the tool is not useful.

[Daniel Mondot]

To answer Jeffrey above, apparently it was ChatGPT 5.2.

On Thu, Dec 25, 2025 at 7:42 PM David desJardins <da...@desjardins.org> wrote:

On Thu, Dec 25, 2025 at 4:15 PM Daniel Mondot <dmo...@gmail.com> wrote:

Question 3: What is the smallest number of the form 2^n-1 that, when written in ternary has its lowest zero in position 26?

Correct answer: 2^143-1  (a well written program should find this is less than a second)

2^143-1 has its lowest zero in position 25. I guess you’re “hallucinating”, now!

I'm not hallucinating, I'm just counting from 1 instead of from 0.

Incidentally, one of the AI did asked me that question, if I was counting from 0 or 1. The others didn't bother to ask.

Certainly, AI is good at some things and not so good at other things. And in some cases it matters how you ask the question, just as with any tool it matters how you use the tool. If you want to try to make the tool fail, I’m sure you can do that, with pretty much any tool. But you’re doing a terrible job of trying to prove that the tool is not useful.

--

You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAP%3DxTqOz6CEybrOdQg8cmhO%2BLPGT4soTRWfWxjkk83VvsStiLg%40mail.gmail.com.

[Antti Karttunen]

On Fri, Dec 26, 2025 at 2:54 AM Daniel Mondot <dmo...@gmail.com> wrote:

To answer Jeffrey above, apparently it was ChatGPT 5.2.

Could you ask all those chatbots this question:

If the bitwise-AND of (the binary expansions of) k and 4*k is not zero, what does that imply of bitwise-AND of k and 20*k ? Can you show me why it is so?

 

That is the question that a few days ago almost stymied me (although it has almost a trivial answer, although as usual, I was trying to see it thru some overtly complex formulas, instead of using just pen and paper on a few examples, also the usual sleep deprivation was a culprit for my slow progress). But the solution is still in my draft-edits, so presumably no chatbot has seen it yet.

The problem (imho) with LLM-enthusiasts is that they often seem to give their toys just softball-questions, textbook-problems that are all over the net, or at least easy variants of them.

Best regards,

Antti

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAD5iKagYOs89mT8Fj%2Brgm073KFrZgcnpP27UjaaEmBMCDJjQVA%40mail.gmail.com.

[Gareth McCaughan]

I tried to replicate these, using Claude (Sonnet 4.5; maybe Opus 4.5, which isn't free, is better or maybe it isn't). I worded them a bit differently (but not in a way that gave any particular hints).

For question 1 it tried some small cases and then claimed (without anything that looked even superficially like better reasoning than "I tried these small cases and guessed") that the answer was only 0 and 1. Same as Daniel found.

For question 2 it _correctly_ said that in general the closest planet to any given one is the innermost one in the system. Then it said (I don't know whether this is right or not) that TRAPPIST-1's planets are "unusually close together" and (I don't know whether this is right or not; it seems doubtful) that this could invalidate the general principle. And then it looked up some numbers and said (inter alia) "This puts them only about 1.56 million miles apart in terms of orbital radii, making TRAPPIST-1g the adjacent planet and therefore the closest on average to TRAPPIST-1h." So it got this wrong, by apparently completely forgetting the general principle it had just announced.

For question 3 it wrote some code and invited me to run it in the browser. When I did, it generated the correct answer.

So I get 1/3 rather than Daniel's 0/3. (And maaaaaybe it deserves an extra fraction of a point for question 2, since it did state the correct general principle and its wrong answer was _obviously_ wrong. If I got an answer like that I'd poke it further and very likely get the usual sort of "You're absolutely right!" response. I tried poking it further, doing my best to clarify that I wasn't saying it was wrong, and indeed it did the "You're absolutely right!" thing and ended up at the right answer -- but it could well be that further poking would make it oscillate between right and wrong.)

When I poked it further on Q1 it wrote a script and invited me to run it in my browser -- it checks up to a given limit, and it appears to work correctly at least for numbers of modest size.

When, after those pokings, I invited it to reconsider its answers to all the questions: it (correctly) _didn't_ change its mind about Q1 and (correctly) said that it doesn't know a closed-form answer; it (correctly) said it was confident that the TRAPPIST-1b answer is in fact correct; it (correctly) didn't disavow its script for Q3 but (sensibly) now noticed that there is ambiguity about what "position 26" means and sought clarification.

I asked it for code that tries to answer Q3 for every reasonable interpretation; it chose 2x2 interpretations (0-based or 1-based; counting from the left or from the right) and its code gives n=143 for "1-based from the right", n=106 for "1-based from the left", and "not found in range 1..300" for "0-based from the right" and "0-based from the left". I have not tried to check whether these answers are correct, but my guess is that they are, and that if I wanted to try larger n in pursuit of the 0-based answers it would have no problem making the appropriate tweaks.

In conclusion, AI systems are still hallucinating answers.

For the avoidance of doubt, I don't in any way disagree with that conclusion.

But if I needed the answers to those three questions, asked Claude, and followed up on things it said that were obviously-to-me wrong, then I would have ended up with the right answers: (1) 0, 1, 82000, and not clear whether there are more; (2) TRAPPIST-1b; (3) 143.

As usual, the AI is most useful to those who are able to check its answers at least to some extent.

--
g

[Daniel Mondot]

Antti,

They all got it right, I think

Here are the summary answers from the 5 AIs:

Question 4: If the bitwise-AND of (the binary expansions of) k and 4*k is not zero, what does that imply of bitwise-AND of k and 20*k ? Can you show me why it is so?
Gemini : If the bitwise-AND of k and 4k is non-zero, it implies that the bitwise-AND of k and 20k must also be non-zero.
ChatGPT5.2:if k&4k ≠ 0, then k&20k ≠ 0
Copilot: If (k & 4k)≠0, then it must also be true that k & 20k≠0.
Claude AI: If k & 4k ≠ 0, then k & 20k ≠ 0 is guaranteed.
Perplexity AI: It implies that the bitwise-AND of kk and 20k20k is also nonzero, i.e. (k & 20k)≠0.
Correct answer: The bitwise-AND of k and 20*k is also not zero. (my answer, , I couldn't find a counter-example)

If you want the full answers, email me directly.

Daniel.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAB%2B0_%3DnMV4M%2Bd7Pzv9mo%2Bv-QC_wJj8nt1PVs4DyiY7jujNUbWw%40mail.gmail.com.

[Daniel Mondot]

see below

From the small (6000) list of exoplanets we know of, yes they are somewhat "unusually close together", but again, we only know of very few planets compared to what's out there.. But the real answer to the question is that the most inner planet is always the closest to all the other planets "ON AVERAGE", and how far apart they are is irrelevant.

For question 3 it wrote some code and invited me to run it in the browser. When I did, it generated the correct answer.

So I get 1/3 rather than Daniel's 0/3. (And maaaaaybe it deserves an extra fraction of a point for question 2, since it did state the correct general principle and its wrong answer was _obviously_ wrong. If I got an answer like that I'd poke it further and very likely get the usual sort of "You're absolutely right!" response. I tried poking it further, doing my best to clarify that I wasn't saying it was wrong, and indeed it did the "You're absolutely right!" thing and ended up at the right answer -- but it could well be that further poking would make it oscillate between right and wrong.)

When I poked it further on Q1 it wrote a script and invited me to run it in my browser -- it checks up to a given limit, and it appears to work correctly at least for numbers of modest size.

When, after those pokings, I invited it to reconsider its answers to all the questions: it (correctly) _didn't_ change its mind about Q1 and (correctly) said that it doesn't know a closed-form answer; it (correctly) said it was confident that the TRAPPIST-1b answer is in fact correct; it (correctly) didn't disavow its script for Q3 but (sensibly) now noticed that there is ambiguity about what "position 26" means and sought clarification.

I asked it for code that tries to answer Q3 for every reasonable interpretation; it chose 2x2 interpretations (0-based or 1-based; counting from the left or from the right) and its code gives n=143 for "1-based from the right", n=106 for "1-based from the left", and "not found in range 1..300" for "0-based from the right" and "0-based from the left". I have not tried to check whether these answers are correct, but my guess is that they are, and that if I wanted to try larger n in pursuit of the 0-based answers it would have no problem making the appropriate tweaks.

I haven't tried "from the left", so I don't know either. 

In conclusion, AI systems are still hallucinating answers.

For the avoidance of doubt, I don't in any way disagree with that conclusion.

But if I needed the answers to those three questions, asked Claude, and followed up on things it said that were obviously-to-me wrong, then I would have ended up with the right answers: (1) 0, 1, 82000, and not clear whether there are more; (2) TRAPPIST-1b; (3) 143.

As usual, the AI is most useful to those who are able to check its answers at least to some extent.

Thanks for the follow-up 

--
g

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/d63a1e43-49a2-45f9-9236-b3889b2c4941%40pobox.com.

[Antti Karttunen]

On Fri, Dec 26, 2025 at 4:13 AM Daniel Mondot <dmo...@gmail.com> wrote:

Antti,

They all got it right, I think

Here are the summary answers from the 5 AIs:

Question 4: If the bitwise-AND of (the binary expansions of) k and 4*k is not zero, what does that imply of bitwise-AND of k and 20*k ? Can you show me why it is so?
Gemini : If the bitwise-AND of k and 4k is non-zero, it implies that the bitwise-AND of k and 20k must also be non-zero.
ChatGPT5.2:if k&4k ≠ 0, then k&20k ≠ 0
Copilot: If (k & 4k)≠0, then it must also be true that k & 20k≠0.
Claude AI: If k & 4k ≠ 0, then k & 20k ≠ 0 is guaranteed.
Perplexity AI: It implies that the bitwise-AND of kk and 20k20k is also nonzero, i.e. (k & 20k)≠0.
Correct answer: The bitwise-AND of k and 20*k is also not zero. (my answer, , I couldn't find a counter-example) 

If you want the full answers, email me directly.

Yes, those answers are correct, but without any explanatory reasoning, I would not trust any of them! (or my PARI-program checking it up to 2^30).

So please email me, if they elaborated it any further.

Now here's another question one would expect anybody knowing recent mathematical history to answer correctly:

There is an integer sequence that counts the number of partitions of n into 2 nonnegative cubes. It begins as 1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, ...
There are two almost equivalent formulas for it: One can say that the n-th term is A010057(n) + A025455(n), or that the n-th term is A010057(n) XOR A025455(n), where XOR the bitwise-XOR,
A010057(n) is the characteristic function of cubes, and A025455(n) is the number of partitions of n into 2 positive cubes.
Now is year 1993. Can you say that these formulas are actually equivalent?

Do you know what integer sequence it is in the OEIS?  

(<--- The last question is just for checking whether they have snooped the answer from there).

I'm interested what they might say about this one.

Best,

Antti

 

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAD5iKaj41B05z0yHE0ui6qLqB2BNwMJh%2BVpmCaLHnQSeFZN1hA%40mail.gmail.com.

[Gareth McCaughan]

On 26/12/2025 01:43, Antti Karttunen wrote:

Could you ask all those chatbots this question:

If the bitwise-AND of (the binary expansions of) k and 4*k is not zero, what does that imply of bitwise-AND of k and 20*k ? Can you show me why it is so?

 

That is the question that a few days ago almost stymied me (although it has almost a trivial answer, although as usual, I was trying to see it thru some overtly complex formulas, instead of using just pen and paper on a few examples, also the usual sleep deprivation was a culprit for my slow progress). But the solution is still in my draft-edits, so presumably no chatbot has seen it yet.

I fed this to Claude (Sonnet 4.5). It started trying to prove that if k & 4k is nonzero then so is k & 20k, found that it wasn't as trivial as it hoped because of the existence of carries, and wrote some code to check whether the thing seems empirically to be true. I ran the code for it (Claude can't do that itself, at least not the default free version I'm using), and reported that it found no counterexamples. Claude then had another go at a proof and again found it not so straightforward because of carries. It asked whether I wanted it to keep trying, I said yes, and it floundered for a while longer and again asked me whether I want it to keep on. I said yes and it kept floundering.

(Note that this seems different from what Daniel Mondot reports. Maybe he's using a different version of Claude or maybe it's just doing different things on different occasions. It isn't obvious to me whether in Daniel's run Claude found a correct proof, or handwaved unsoundly and gave the right answer even though it couldn't actually prove it.)

Perhaps I should compare Claude's performance to my own. I found that (late at night and tired) if I just thought about this in my head it didn't seem clear; once I wrote down a couple of lines of bit-patterns I thought it was obvious, but then I noticed I'd made a mistake; so then I thought about it a bit more and after a couple of minutes saw an easy proof. I, like Antti, found that _looking_ at how things fit together was what made the difference between confusion and enlightenment. I think the LLMs have extremely poor "visualization skills". (So do I, relative to other people who are overall about as good at mathematics as me, but apparently Claude's are even worse than mine. :-))

Claude _was_ able to do the job if I asked it the key question: can there be _any_ carries to the right of the rightmost pair of 1s?

--
g

[Antti Karttunen]

I take the liberty of showing the answer of Gemini that Daniel sent to me in a private mail (there were also other ones, but I think this is the clearest, and mirrors my own thinking, although of course it can be compressed into one sentence or paragraph at least):

Gemini:

If the bitwise-AND of k and 4k is non-zero, it implies that the bitwise-AND of k and 20k must also be non-zero.

To understand why, we can break the numbers down into their binary representations and look at how multiplication by a power of 2 affects bit positions.

---

1. Analyzing the first condition (k & 4k=0)

In binary, multiplying a number by 2n is equivalent to shifting its bits to the left by n places.

• 4k is k shifted left by 2 bits.

• The bitwise-AND of k and 4k is non-zero if there is at least one bit position i where both k and 4k have a '1'.

If k has a '1' at position i, then 4k has a '1' at position i+2. For the AND to be non-zero, k must also have a '1' at position i+2. This means k contains a "1-X-1" pattern (two 1s separated by one bit).

2. Analyzing the implication (k & 20k)

We can rewrite 20k as a sum of powers of 2:

20k=(16+4)k=16k+4k

Now consider the bitwise-AND:

k & (16k+4k)

From our first step, we know that if k & 4k=0, there exists at least one bit position j where k has a '1' and 4k has a '1'. Let's look at the bitwise properties of the sum 16k+4k:

• 4k has a '1' at position j.

• 16k is just 4k shifted left by 2 more bits (or k shifted by 4).

• Since k and 4k share a '1' at position j, then k has a '1' at j and k has a '1' at j−2 (because the '1' at j in 4k came from the '1' at j−2 in k).

3. Why it cannot be zero

The bitwise-AND k & (16k+4k) is guaranteed to be non-zero because the "1-X-1" pattern in k that caused k & 4k to be non-zero will interact with the 4k component of 20k.

Specifically: If the bit at position j is the highest bit where both k and 4k have a '1', then in the sum 16k+4k, there is no "carry" coming from lower bits that can flip the bit at position j to a '0'.

• 4k has a '1' at position j.

• 16k has its bits shifted much further left.

• k has a '1' at position j.

Therefore, the bitwise-AND will result in a '1' at least at position j (and potentially others).

Summary of Logic

1. k & 4k=0 means k has two '1's separated by exactly one bit (position i and i+2).

2. 20k=16k+4k.

3. The '1' at position i+2 in k aligns with the '1' at position i+2 in 4k.

4. Because 16k only affects bits at position i+4 and higher (relative to our pattern), it cannot "cancel out" the overlap at position i+2 via addition/carries in a way that results in a zero bitwise-AND with k.

----

 

Yes, I must admit that I'm somewhat impressed!

Best regards,

Antti

--
g

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/603dedca-d2f0-4749-8718-e5f3d0848d30%40pobox.com.

[Gareth McCaughan]

On 26/12/2025 02:58, Antti Karttunen wrote:

I take the liberty of showing the answer of Gemini that Daniel sent to me in a private mail (there were also other ones, but I think this is the clearest, and mirrors my own thinking, although of course it can be compressed into one sentence or paragraph at least):

[...]

The bitwise-AND k & (16k+4k) is guaranteed to be non-zero because the "1-X-1" pattern in k that caused k & 4k to be non-zero will interact with the 4k component of 20k.

Specifically: If the bit at position j is the highest bit where both k and 4k have a '1', then in the sum 16k+4k, there is no "carry" coming from lower bits that can flip the bit at position j to a '0'.

• 4k has a '1' at position j.

• 16k has its bits shifted much further left.

• k has a '1' at position j.

Therefore, the bitwise-AND will result in a '1' at least at position j (and potentially others).

If _highest_ means _leftmost_ (which is what it sounds like, and would be consistent with the numbering elsewhere in the answer) then I don't think I understand this reasoning at all.

If it means _rightmost_ then this feels like the first _wrong_ thing I thought was obvious. Maybe I'm missing something?

Summary of Logic

1. k & 4k=0 means k has two '1's separated by exactly one bit (position i and i+2).

2. 20k=16k+4k.

3. The '1' at position i+2 in k aligns with the '1' at position i+2 in 4k.

4. Because 16k only affects bits at position i+4 and higher (relative to our pattern), it cannot "cancel out" the overlap at position i+2 via addition/carries in a way that results in a zero bitwise-AND with k.

I don't understand claim 4. There can be 1-bits further right than position i in the original number k. To see that these can't lead to any carry into position i+2, unless I'm missing something, you need some further reasoning: if there's a carry that propagates up to position i+2, the chain of carries had to start somewhere, which must have been from adding bits in position t and t+2 for t<i _without_ a carry-in, which could only produce a carry if bits t,t+2 were both 1, which contradicts the choice of i as rightmost.

I don't see anything in the Gemini answer you quoted to indicate that it figured that out.

(Maybe I'm missing something and you actually don't need that further reasoning?)

--
g

[Antti Karttunen]

Here is my reasoning, even before seeing all these AI-answers:

https://oeis.org/history/view?seq=A115422&v=31

 

Is there something in Gemini's point 4 which doesn't fit that?

Best regards,

Antti

g

[Gareth McCaughan]

On 26/12/2025 03:31, Antti Karttunen wrote:

Here is my reasoning, even before seeing all these AI-answers:

https://oeis.org/history/view?seq=A115422&v=31

 

I'm not sure I understand this either.

How do you get from "k AND 4k >0" to "at least one instance of 101"? Why can't it be 111?

When you write "Then it easily follows that these are numbers k such that 5k XOR 16k = 21k", how does it easily follow?

(I expect it's just that I'm not seeing something that should be clear. But I am, for sure, not seeing something.)

--
g

[Antti Karttunen]

On Fri, Dec 26, 2025 at 6:28 AM Gareth McCaughan <gareth.m...@pobox.com> wrote:

On 26/12/2025 03:31, Antti Karttunen wrote:

Here is my reasoning, even before seeing all these AI-answers:

https://oeis.org/history/view?seq=A115422&v=31

 

I'm not sure I understand this either.

How do you get from "k AND 4k >0" to "at least one instance of 101"? Why can't it be 111?

Yes, that just came to my mind a few minutes ago. See:

https://oeis.org/history/view?seq=A115422&v=33

But I guess I need to include an Ascii graphics diagram what happens here.

 

When you write "Then it easily follows that these are numbers k such that 5k XOR 16k = 21k", how does it easily follow?

(I expect it's just that I'm not seeing something that should be clear. But I am, for sure, not seeing something.)

Thanks, good critique. I need to elaborate it further, and how to express it most concisely. One thing of course is that XOR works as a bijective "one-time-pad cryptography function", so that imposes some strict constraints what can happen here.

So now it is like this, still needs editing: https://oeis.org/history/view?seq=A115422&v=33

And I would like to ask Paul Hanna whether we should start this with term 0 included in the beginning.

Regarding my other question about the partitions into nonnegative cubes sequence, Gemini was actually wiser than me, as of course it was already Euler's proof for the specific exponent = 3 of FLT at the end of the eighteenth century that validated the both + and XOR variants of formulas as equal. Gemini also made this sarcastic point:

---

In 1993, the answer to your question is quite interesting because the "OEIS" as we know it today (the On-Line Encyclopedia of Integer Sequences) was just about to be born in its digital form.

At that time, Neil Sloane’s work was primarily known through his books, A Handbook of Integer Sequences (1973) and the then-upcoming The Encyclopedia of Integer Sequences (1995).

---

Best,

Antti

 

--  

g

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/4db700ff-14df-47aa-9f4e-9e3fc2c08c74%40pobox.com.

[Simon Plouffe]

Hello, 
 I have the gemini pro or the one called 3.0 and the answer is 0,011 UA : trappist-1b

the answer is quite elaborate with details of the calculation. 

Here is the answer ; 
################################################################################

Calculating TRAPPIST-1 Distances

I'm currently focused on determining the average distances between planets in the TRAPPIST-1 system. Specifically, I'm working on pinpointing the position of TRAPPIST-1h relative to its neighbouring planets. I'm also actively searching for data on orbital resonances and semi-major axes to validate the order and relative spacing of the planets.

Determining Planetary Orbits

I've just obtained the semi-major axes for the TRAPPIST-1 planets. My current focus is figuring out how to use these values to gain further insights into the system's architecture. This is exciting, as it lays the groundwork for further explorations.

Assessing Average Proximity

I'm now calculating the average distances between TRAPPIST-1h and the other planets, based on the provided semi-major axes. I suspect planet 'g' will be the closest on average, despite the greater distance between 'g' and 'h' relative to some inner planets, given the complex orbital dynamics in multi-planet systems. Using the "point circle method" or a similar approach, I am hoping to get a more accurate evaluation than intuition suggests.

Evaluating Orbital Distance Dynamics

I'm now diving into the nuance of average orbital distances. It turns out, simply subtracting semi-major axes doesn't cut it. I need to consider the integral of distance over time, acknowledging the "Mercury closest to everyone" effect. With the radii of TRAPPIST-1b, g and h in mind, I'm currently figuring out if I can apply a general rule or if I should focus on special insights pertaining to TRAPPIST-1. It seems that g's large opposing-side distance may increase the overall average distance relative to 'b'.

Investigating Neighbourly Proximity

I'm now focusing on identifying the average closest neighbour for the TRAPPIST-1 planets. I've searched for specific research on this but haven't found any directly addressing the "Mercury effect" in this system. Therefore, I'm calculating an approximate average distance based on the known radii. Given the system's architecture, I'll need to consider the large gaps and variations in radii to determine the most average closest neighbor. I have already scaled the radii for easier reading and quick comparison.

Analyzing Orbital Radii

I've confirmed the semi-major axes for the planets, and now I need to determine the average "closest neighbor" to planet h. The counter-intuitive nature of the innermost planet (b) presents an interesting challenge.

Evaluating Proximity Calculations

I'm now assessing the relative proximity of planet h to its inner neighbours, g and b, employing the orbital radius data. It seems, by approximate integration, that the average distance to the smaller orbit is more dependent on the larger orbit. This suggests that the distance calculation may be simpler than first thought. I need to more precisely determine how much the average distance deviates from the larger radius.

Determining Closest Neighbour

I've been analyzing the average distance between planet h and its inner neighbours. My initial intuition about the increasing average distance with increasing inner radius has proven correct. It appears that the planet with the smallest orbital radius, planet b, is indeed the closest neighbour on average. This conclusion is driven by the geometric probability of orbiting bodies being further away (the opposition distance) outweighing proximity during conjunction.

Confirming Average Proximity

I've been working on verifying that TRAPPIST-1b is, on average, the closest neighbour to h. I re-examined the average distance integral and, by letting R=1 and considering values of r, I can see that the average distance indeed increases as the inner orbit grows. With R representing the larger orbital radius and r the smaller, the results support the prior conclusion. This strengthens the case for b being the closest planet to h in terms of average distance. The phrase "en moyenne la plus proche" solidifies the choice of b as the answer.

Finalizing the Explanation

I'm now putting the finishing touches on the explanation. It's a "Mercury paradox" situation, and I'll clearly articulate why b, the innermost planet, is the closest on average to h. The core concept is that, as the inner radius increases, the average distance to h also increases, based on the calculation and the fact that it asks about average distance. I've re-reviewed all the data and confirmed that the question specifically refers to the average distance to h, not the distance to the star. The educational video is a great resource, especially the video discussing the system in the language of the prompt.

Confirming the System's Dynamics

I've been double-checking the YouTube link provided (https://www.youtube.com/watch?v=aHjleE6N8KI) to ensure its relevance. It confirms the system's layout and supports the use of the "Mercury paradox" to analyze proximity. This is critical for the final response, as the video reinforces the planet identification and the "Mercury paradox" explanation for the average distances, which is crucial for answering the prompt. I've noted that the video supports the understanding of the system's layout and orbital dynamics.

########################################################

best regards, 

Simon Plouffe

[David desJardins]

Does anyone want to observe that, on average, Trappist-1h is at distance 0 from Trappist-1h? Hard to get lower than 0.

--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/993d4ba9-328b-4fc6-8d4c-9028afdcaef1%40gmail.com.

[Kevin Ryde]

... k AND 4*k = 0 implies k AND 20*k = 0

Gareth McCaughan <gareth.m...@pobox.com> writes:
>
> Claude ... again asked me whether I want it to keep on.

> I said yes and it kept floundering.

The mechanical approach is to note that bit strings k
for which "k AND 4*k = 0" are a regular language,
and likewise k AND 20*k = 0. Some usual state machine
manipulations shows the 20s are a subset of the 4s.

Less intuition than bits and multiplies, but less work or
chance to go wrong if doing several. Not much to see in the
state machine of the set difference, but all are "reversible"
in the sense that if k makes 0 then so does bitrev(k).

Walnut might answer this kind of question (with certainty)
from the right input syntax. (Which is going to be easier
than explicit state = carry in the multiply :-).

[Jeffrey Shallit]

Hi, Antti, this is an example of the kind of problem Walnut handles easily.  (You can find out more about Walnut here on my web page:  https://cs.uwaterloo.ca/~shallit/walnut.html )

The proof and the intermediate automata  it constructs provides a "reason" why it is true.

first we need some code for the bitwise and of two numbers:

reg bitand msd_2 msd_2 msd_2 "([0,0,0]|[0,1,0]|[1,0,0]|[1,1,1])*":

Next we just assert your claim.  Here A is the universal quantifier:

eval antti "Ak,y,z ($bitand(k,4*k,y) & $bitand(k,20*k,z) & y!=0) => z!=0":

And here is Walnut's output:

[Walnut]$ eval antti "Ak,y,z ($bitand(k,4*k,y) & $bitand(k,20*k,z) & y!=0) => z!=0":

(bitand(k,(4*k),y))&bitand(k,(20*k),z))):79 states - 2ms

computed ~:1 states - 1ms

 y!=0:2 states - 1ms

  ((bitand(k,(4*k),y))&bitand(k,(20*k),z)))&y!=0):115 states - 1ms

   z!=0:2 states - 0ms

    (((bitand(k,(4*k),y))&bitand(k,(20*k),z)))&y!=0)=>z!=0):1 states - 3ms

     (A k , y , z (((bitand(k,(4*k),y))&bitand(k,(20*k),z)))&y!=0)=>z!=0)):1 states - 1ms

Total computation time: 19ms.

____

TRUE

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAB%2B0_%3D%3DzhGyoPMJuAfkaKLcHGqkViwDZzztG_uNiCNPdA_m11w%40mail.gmail.com.

[Jeffrey Shallit]

ChatGPT 5.1 gives the correct answer to question 1, if you know how to use it.   It is designed to default to "fast and dirty" mode in many cases.  If you want a deeper analysis, you have to push it to a deeper mode.

For example, you can do this by following up with "Are you sure there aren't any more?"   If you read the feedback it gives you, you will be surprised at the kinds of things it tries.   Here's the dialogue:

Sorry about the spacing, for some reason subscripts and superscripts are not shown.

I don’t know a slick hand proof that there are only finitely many, but computationally it looks like the answer is “no”.

A number satisfying your condition must in particular have a base-5 expansion using only 0/1, i.e.

n=i≥0∑εi5i,εi∈{0,1}.

So you can enumerate candidates by enumerating all 0/1 base-5 strings and then just test whether the same n also has only 0/1 digits in bases 3 and 4 (base 2 is automatic).

I did exactly that for all base-5 0/1 numbers with up to 26 base-5 digits, i.e. for every

0≤n<526≈1.49×1018.

Among those candidates, the only ones whose base-3 and base-4 expansions also use only 0/1 are:

0, 1, 82000.

And 82000 indeed looks like

82000=101000000010100002=110111110013=1100011004=101110005,

all digits 0/1.

So: no others below 526; if there is another, it’s bigger than about 1.5×1018. Given how restrictive the condition is, I strongly suspect {0,1,82000} is the complete list.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAD5iKaiCgEGcpFahArmvgg80sSGB6a_5EqS2LPSjPXm_q1tOkQ%40mail.gmail.com.

[Michael Branicky]

interesting, jeffrey. compare https://oeis.org/A146025

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CACbCbQqKxDe%2Bn3%3DJAh2p_eiPU1FscGUOfJb%2Bc%2B6pwZ_nNc8fhA%40mail.gmail.com.

[Antti Karttunen]

Thanks Gareth, Daniel, Jeffrey, Kevin and others for the interest in my question regarding https://oeis.org/A115422

I decided to spawn this topic off from the main thread "Christmas Eve Conjecture" and its AI-related topics.

Now, my question rose because I wanted to make sure that A115422 is indeed a subsequence of:

https://oeis.org/A391856 "Numbers k such that 21*k = A048720(m, k) for some m, where A048720 is carryless base-2 multiplication."

which is the row 25 of array:

https://oeis.org/A391925 "A(n, k) is the k-th natural number i that satisfies i*n = A048720(i,m) for some m, where A048720 is carryless base-2 multiplication."

which has the companion array which gives the corresponding m for that i:

https://oeis.org/A391926 "Square array read by descending antidiagonals: find the k-th natural number i that satisfies i*n = A048720(i,m) for some m, then A(n, k) = m."

It seems that there can be only finite kinds of m's here on each row n, and more strictly, it seems that there can be no more of them than A000120(n) [the binary weight of the row number] of them. I haven't yet started checking why, although I suspect there is a simple reason for this, also because in many cases those m's seem to occur quite evenly spaced from each other, like e.g. for n = 57 (111001 in binary), the allowed m seem to be one of [57, 73, 89, 105].

I know that at least both cases m = n and m = A065621(n) always exist. The former is for the cases where the entire ordinary multiplication can be performed carry-free (and thus is then equal to the carryless GF(2)[X] multiplication, A048720), and the other one is also defined for all n, and indeed, I proved this just a few days ago, about twenty years after submitting https://oeis.org/A115873 "The least k >= 1 for which A048720(A065621(n),k) = n*k.", where A065621 is "Reversing binary representation of n. Converting sum of powers of 2 in binary representation of a(n) to alternating sum gives n."

The key here is to note that while A065621 is a bit unwieldy in itself with its originally given formula (n-1 XOR 2n-1) to reason about, we see that actually A065621(n) = A048724(n-1) XOR 1, and the latter is just "carryless multiplication by 3", i.e. = A048720(...,3),  after which all the reasoning can be based on the fact that GF(2)[X] is a ring, so we can apply all the distributivity, associativity, and other tricks here.

Now, I have a dim remembrance that in 1999 or so, I used a simple state-machine illustration (just drawing a few diagrams on my notebook) for one of those A04871* sequences, but can't recall which one, but maybe it indeed was A048716, because all the others are simple variations of Fibbinary numbers, not needing that much reasoning. I realize that it's even for me now hard to read some of those regexp-syntaxes (I used Perl in that time in my work), and specifying them with conditions involving bitwise-AND's are much easier to swallow now. I will be editing these to better shape soon.

So, what questions remain about these: Proving definitely what distinct m can occur for each n in equation i*n = A048720(i,m) for some m, i >= 0. (for the starters, that there is a _finite_ number of such m's).

Then also proving those seeming duplicates (marked with ?'s) in https://oeis.org/A391925

E.g. that A115770 "Numbers k such that 7*k = A048720(11,k)" seems to be also "k such that 5*k = A048720(13,k)." (Here of course, 7-2 = 5 and 11+2 = 13. So probably all these are easy as well).

And there are also several conjectured subsequence-relations, similar to the one that was just proved.

Best regards,

Antti

--

and on Fri, Dec 26, 2025 at 10:41 AM Jeffrey Shallit <j.sh...@gmail.com> wrote:

[Andrei Zabolotskii]

Re. using AI for math: a few days ago the mathematical AI Aristotle proved the alternating sign property of https://oeis.org/A281487 for me. I.e., the problem was: let a(1)=1 and a(n+1) = - Sum_{d|n} a(n); prove that a(n)>=0 of n is odd and a(n)<=0 if n is even. Both my formulation of the problem and its solution involved Lean, the system for formalised proofs, which allows us to be confident that the proof is correct.

Andrei

пятница, 26 декабря 2025 г. в 14:21:11 UTC, bran...@gmail.com: