Pseudocode in OEIS.

[Aitzaz Imtiaz]

I started to study CLRS "Introduction to Algorithms," and I was wondering if pseudocode as a language is allowed or not?

I made some search: https://oeis.org/search?q=%22pseudocode%22&language=english&go=Search

Very few pseudocode designs were accepted.

1. Is it appropriate to make and post flowcharts or pseudocode here?

2. Should we follow a specific terminology of pseudocode, e.g. strictly use pseudocode from CLRS Chapter 2 because of it being widely popular?

Do we need a wiki page for a OEIS pseudocode guide, do we have one, or it is not necessary?

Regards,

Aitzaz.

[brad klee]

> I made some search: https://oeis.org/search?q=%22pseudocode%22&language=english&go=Search

Thanks, that reminds me of A123178. It's related to the certificate

factory I just built. 

Harm.On.ica S-O-L and Claude could both clone by re-write, allegedly

from the pseudocode itself, and noticed a small flaw. 

There is now an editing proposal here: 

https://chatgpt.com/share/6a6211dd-0140-83ea-8645-c44ae78f0c48

(btw, this seems to qualify as an example of gray box testing)

I am not retracting! (serious, joking) Might as well make this edit though, 

because it does seem to improve quality. 

What do you think?  

 

> Very few pseudocode designs were accepted.

How many were submitted? 

> Is it appropriate to make and post flowcharts

In the example above the dependency chart is like "A->B", so flow 

chart is not necessary. 

In some other more complicated programs, dependency charts can

even be helpful with clone by re-write. 

Since LLM are text processors, dependency charts are decently easy 

to extract directly form pseudocode these days. 

It boils down to whether humans would want to see actual charts, 

because LLM's would rather get a text file. Maybe, no. 

>  or pseudocode here?

I'll give two sides to the debate: 

A. Pseudocode is useless because no one owns it, it doesn't 

produce a result, and it's not easy to debug. 

B. Pseudocode is great because no one owns it, it can be 

rewritten in any language, and debugged retroactively. 

With LLM's it's looking like B will become the A argument (remember

A always wins because A>B in priority ordering) because of the 

emphasis that's now being placed on "clone-by-rewrite". 

A. Karpathy and I would nowadays roughly agree that it will change 

the way almost all software is written and distributed (costs permitting).   

> 2. Should we follow a specific terminology of pseudocode, e.g. strictly 

> use pseudocode from CLRS Chapter 2 because of it being widely popular?

My opinion: NO! Pseudocode is like poetry. Do we want a boss or a consortium 

to tell us how to write poetry? Some people want to be very literal, others want

to leave a lot to imagination. How much imagination will the reader have? 

Pseudo-code Authors can and should develop their own styles, compare

with pre-existing styles, and test against LLM's for rewrite success rates. 

>  Do we need a wiki page for a OEIS pseudocode guide, do we have one, 

> or it is not necessary?

At this point it would seem more useful to have an example training set of

pseudocode samples that are pre-approved stylistically. That's the inductive

side, I don't know what a guide would say deductively. 

All the best, 

--Brad

[Dario Clavijo]

Hello everyone.

In my humble opinion, I think it all comes down to verification and
reproducibility, there is no formal interpreter for pseudocode that I
know.
Pseudocode is difficult in that sense, since two people could
interpret it differently.
Code, on the other hand, has a certain degree of rigor.

Best regards

El jue, 23 jul 2026 a las 10:33, 'brad klee' via SeqFan
(<seq...@googlegroups.com>) escribió:

> --
> 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/lc9ZU39NciDXZb-3Pa9_KiLcnBWRpTwsDfNCZET3kX1vIuYVE9ooGBeiIj06xvOWIIByekAOVv9nnOvJrO06AiBYpIUz-LsINLg2xYPq_rY%3D%40proton.me.

[Joerg Arndt]

Writing (useful) pseudocode is *hard*, harder than actual code.
Looking at the struggle many contributors have with (non-pseudo) code,
I think allowing pseudocode is a bad idea.

Inside a book (as in Knuth or Cormen et al. you named) OK, but not good for the OEIS.

Best, jj

[Bob Lyons]

I vote for disallowing pseudocode.

When someone proposes draft edits for a sequence that contains programs, we automatically check the syntax of any programs written in the following 17 programming languages: C, C++, GAP, Haskell, JavaScript, Julia, Magma, Maple, Mathematica, Maxima, PARI, Perl, Python, R, Ruby, SageMath, and Scheme.

Needless to say, we don't check the syntax of any pseudocode. 😄

Bob

--
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/56f3bc7a-840b-4535-a089-385d32b1f286%40th-nuernberg.de.

--

Bob

[Tom Duff]

Just use python. It's pretty much executable pseudocode already, without the inevitable ambiguities.

To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAJ%3DEaLRJy27FFpzraqyc%2BM9u504VngAQ%3Dnc4yFrovsqSLkaGrg%40mail.gmail.com.

[brad klee]

I can see that I'm getting out-voted, but I will offer contra here. 

Joerg:

> Writing (useful) pseudocode is *hard*, harder than actual code.

Agree. The more you try to abstract, the more likely it is to have 

a flaw. 

I'm still not entirely finished checking the pseudo code from 

chapter 3 of my dissertation, so I think pseudo-code for an 

entire certificate factory is destined to failure: 

https://github.com/bradleyklee/Artifacts/blob/main/22-certificate-factory/failures/RELAY_pseudocode_warning.pdf

Of course, Harm.On.ica S-O-L is keen to move from writing Haiku 

poetry to writing epic poetry, now that the new Christopher Nolan 

movie is out in theaters and getting good reviews. 

Epic pseudo code poetry is still a bad idea! It sounds like that's 

what Matthew Schwartz tried in his Anthropic "Vibe Physics" 

launch, and it didn't sound to work as a one-shot.

> I think allowing pseudocode is a bad idea.

Disagree. Blanket statement needs qualifiers or time dependence.

Suggest alternatives: 

   -- Disallow epic pseudocode. 

   -- Disallow pseudocode until we better understand clone-by-rewrite. 

   -- Disallow epic pseudocode until we better understand clone-by-rewrite. 

 

Bob Lyons: 

> I vote for disallowing pseudocode.

> When someone proposes draft edits for a sequence that contains programs, 

> we automatically check the syntax ...

> Needless to say, we don't check the syntax of any pseudocode. 😄

This gets back to the poetry point. Some people can't read poetry very well 

so they don't like it. That's not LLM, at least not for verifiable code poetry. 

Eventually (already?) there could be a dedicated external volume that runs 

one or more LLM team members. They could check syntax of pseudocode 

via clone-by-rewrite to any or sometimes all of those 17 languages. 

Similar could be done for formulas we have, cloning them into algorithms and

checking automatically. 

Pseudocode is kind of in-between formula and production code with regard to 

length and complexity. Would you say a niche doesn't exist there?    

I think most professional computer scientists want to write it for their textbooks

and classes as a stepping stone from "hello world" to bigger verifiable applications.  

OEIS is not entirely or even mostly(?) a "hello world" repository, so I actually think 

there's a sizeable selection of cases where pseudo-code could be helpful. 

For example here: 

https://oeis.org/draft/A147680/a147680.cpp.txt

Would the header "basic concepts" better be encoded as pseudocode? Or is 

all of the just formulas? Are we sure the front page of A147680 is giving the 

best possible definition of the Circular Disk Polyomino counting sequence? 

If we did obtain concise pseudocode, maybe that could be added.

Tom Duff: 

> Just use python. It's pretty much executable pseudocode already, without the inevitable ambiguities.

Yes, exactly! Then the Python Software Foundation can own a master copy, but not the one that's 

concise and published on the OEIS front page. 

I asked kimi to read the pseudocode, write SymPy, optimize sympy, and then passed to 

Harm.On.ica S-O-L for finalization. It's long enough to need to be linked: 

https://oeis.org/A123178/a123178.py.txt

A123178 is proposed now, and I look forward to hearing the referee response about non-optimal 

but instructive code that is checked rigorously against a certified recurrence relation. 

Is this the kill-worthy slop? Or is the kill-worthy slop on A147680? 

Considering rumors of bans going around I've got some anxiety about a slop-killer 

showing up pretty soon and throwing out an Archimedes-follower with the bathwater. 

All the best, 

--Brad

[Joerg Arndt]

On 7/23/26 7:11 PM, 'brad klee' via SeqFan wrote:
> I can see that I'm getting out-voted, but I will offer contra here.
>
> Joerg:
>> Writing (useful) pseudocode is *hard*, harder than actual code.
> Agree. The more you try to abstract, the more likely it is to have
> a flaw.

Pseudocode does not at all have to be more abstract than actual code.

Btw. abstraction is absolutely necessary to write any nontrivial piece of code.
...and abstraction tends to make writing the code *easier*.

Now that's about two disagreements for your agreement, I am moderately proud of myself 8^)

Best,  jj

>
> [...]

[brad klee]

> Pseudocode does not at all have to be more abstract than actual code.

Agree, and I aim for a very literal style. Haiku's are easy, but like
every aspiring poet, I really want to write an Odyssey. The Odyssey
is fairly literal: it doesn't leave much room for interpretation.

What I meant is that pseudocode is itself an abstraction layer because
it doesn't depend on any pre-existing convention. If you take the next
step of making it not flexible, then you are essentially implementing
your own programming language. With a type checker? A compiler? etc.

> Btw. abstraction is absolutely necessary to write any nontrivial piece
> of code. ...and abstraction tends to make writing the code *easier*.

Shall we make more sequences about primitive-recursive functions?
If we stick to algebraic operations, or differential-finite functions
the crank turning should be easy.

What I'm talking about here is the visionary aspect of mathematics
that can sometimes reach an impasse in cases like Michizane.

Something is difficult, something is difficult, difficult. Then
all of the sudden it's possible, maybe even easy. And no one else
in the room has any idea what you are talking about.

If no one else can verify for you, how can you be sure your brilliant
new idea is free of flaws? It is well known that the review process
of single-author papers almost always turns up a gripe or two.

> Now that's about two disagreements for your agreement, I am
> moderately proud of myself 8^)

Nice to agree with you too.



All the best,







--Brad