I also assume AI here. There is no visible scientific connection, no references and it all sounds nonsense. I have a PHD in fluid dynamics but cannot relate.
OP here. this has been a valuable learning experience for me. i was so excited to share what i was working on and i blew it. i will rewrite the blog post and readme later. let me at least briefly explain what i did as a reply to your comment
starting with 3=1+2 we have (1+x)P(x)=3P(x) when x=2. so we lift the problem from n to P(2)=n. this is a known technique of lifting the problem to a polynomial setting. after each itteration of the Collatz map i make sure all coeffients are either 0 or 1 by applying carry operations when a coefficient overflows. since the coefficients are unary strings, this makes it like a fluid dynamics problem (each character in a unary string is analogous to one unit of mass in a list of buckets where the buckets can overflow and spill unary characters over into their left neihgbor)
when x=2, multiplying x by P(x) is a left shift, whereas dividing by x, P(x)/x, is a right shift. (when P(2)=n is even the constant term in P(x) is zero)
the +1 term in 3n+1 effectively induces a non linear carry propoagation.
the new technique i used is based on a realization that the polynomial representation of the Collatz map behaves like an LFSR implementation of a finite field with a missing modulus. in LFSR a finite field is implemented where each element is an array of bits of fixed size corresponding to a polynomial and multiplication of elements is polynomial multiplication taken mod Q(x) where Q(x) is an irreducible polynomial. unlike the finite field LFSR the Collatz map in polynomial form as i have described allows the degree of the polynomial (size of the array of bits) to grow unbounded.
the surprise is when i subtract these two objects the sierpinski gasket appears and this fractal is not destroyed by itterations of the collatz map
this document[1] is a prior result showing a connection between fractals and collatz that i found after posting the OP
Documentation and APIs can be both machine and human readable at the same time. For my impression, MCP is compating symptoms. In a well constructed system, there would be no need to write dedicated documentation or APIs for LLMs.
By the way, I am new to GraphQL and was amazed how it reduced the boilerplate I had to write for REST in my (classical ORM) project. In a single-person team, this allows me to rapidly write frontends. With libraries such as https://gqty.dev/ I basically write no more glue code. These are probably not the needs you have as an enterprise.
Nice article. Some passages have LLM smells (short sentences. No em dash but smells of em dashes). I wonder whether this comes from having an LLM improve the English formulation/typos/etc. I don't like the way how LLMs typically write. One can steer it to certain degree with a longer prompt, that's my impression.
I discovered Perl directly after PHP before Web 2.0 days. Compared with the extreme, Java or (contemporary) Go, Perl codes (can) have a soul. Interestingly, modern ECMAScript (JS) brought in a few of the nice breweties from Perl world which I haven't seen a long time.
I think we can safely steelman the claim to "every Python programmer should know", and even from there, every "serious" Python programmer, writing Python professionally for some "important" reason, not just everyone who picks up Python for some scripting task. Obviously there's not much reason for a C# programmer to go try to memorize all these numbers.
Though IMHO it suffices just to know that "Python is 40-50x slower than C and is bad at using multiple CPUs" is not just some sort of anti-Python propaganda from haters, but a fairly reasonable engineering estimate. If you know that you don't really need that chart. If your task can tolerate that sort of performance, you're fine; if not, figure out early how you are going to solve that problem, be it through the several ways of binding faster code to Python, using PyPy, or by not using Python in the first place, whatever is appropriate for your use case.
Pip is not Linux specific, it's the same on Win/Mac. I prefer AppImages because they are just statically compiled binaries. I prefer Apt&friends because it is good old packaging. But flatpak and snap? Hell no. I see so little advantage there.
reply