antononcube

There is a set of Raku modules that leverage LLMs for different tasks (mostly code generation) using different techniques:

- https://raku.land/zef:antononcube/LLM::Resources : Uses agentic LLM-graphs with asynchronous execution

- https://raku.land/zef:antononcube/ML::FindTextualAnswer : Finds answers to questions over provided texts (e.g. natural language code generation commands)

- https://raku.land/zef:antononcube/ML::NLPTemplateEngine : Fills-in predefined code templates based on natural language code descriptions/commands

- https://raku.land/zef:antononcube/DSL::Examples : Example translations of natural language commands to executable code

That Python package, "NLPTemplateEngine" has Raku and Wolfram Language counterparts:

- Raku, "ML::NLPTemplateEngine"

  - https://raku.land/zef:antononcube/ML::NLPTemplateEngine

  - https://resources.wolframcloud.com/PacletRepository/resources/AntonAntonov/NLPTemplateEngine/

Related Number Theory notebooks / discussions:

- «Numerically 2026 is unremarkable yet happy: semiprime with primitive roots» https://community.wolfram.com/groups/-/m/t/3594686

- «Happy √2²²-22 -- And other ways to calculate 2026» https://community.wolfram.com/groups/-/m/t/3599161

The integer 2026 is semiprime and a happy number, with 365 as one of its primitive roots. Although 2026 may not be particularly noteworthy in number theory, this provides a great excuse to create various elaborate visualizations that reveal some interesting aspects of the number.

Interesting variant. I might program it for some of the «Rock-Paper-Scissors extensions» here:

https://rakuforprediction.wordpress.com/2025/03/03/rock-pape...

Some of the extensions would need polyhedral dices:

https://demonstrations.wolfram.com/OpenDiceRolls/

This document (notebook) shows transformations of a movie dataset into a format more suitable for data analysis and for making a movie recommender system. It is the first of a three-part series of notebooks that showcase Raku packages for doing Data Science (DS).

Yes, Wolfram Language (WL) -- aka Mathematica -- introduced `Tabular` in 2025. It is a new data structure with a constellation of related functions (like `ToTabular`, `PivotToColumns`, etc.) Using it is 10÷100 times faster than using WL's older `Dataset` structure. (In my experience. With both didactic and real life data of 1_000÷100_000 rows and 10÷100 columns.)

This blog post (and related notebook) show how to utilize Large Language Model (LLM) Function Calling with the Raku package "LLM::Functions".

- Package: https://raku.land/zef:antononcube/LLM::Functions

- Notebook: https://github.com/antononcube/RakuForPrediction-blog/blob/m...

Mostly, because Python is not a good a "discovery" and prototyping language. It is like that by design -- Guido Van Rossum decided that TMTOWTDI is counter-productive.

Another point, which could have mentioned in my previous response -- Raku has more elegant and easy to use asynchronous computations framework.

IMO, Python's introspection matches that Raku's introspection.

Some argue that Python's LLM packages are more and better than Raku's. I agree on the "more" part. I am not sure about the "better" part:

- Generally speaking, different people prefer decomposing computations in a different way. - When few years ago I re-implemented Raku's LLM packages in Python, Python did not have equally convenient packages.

Ah, yes, Raku's "LLM::Graph" is heavily inspired by the design of the function LLMGraph of Wolfram Language (aka Mathematica.)

WL's LLMGraph is more developed and productized, but Raku's "LLM::Graph" is catching up.

I would like to say that "LLM::Graph" was relatively easy to program because of Raku's introspection, wrappers, asynchronous features, and pre-existing LLM functionalities packages. As a consequence the code of "LLM::Graph" is short.

Wolfram Language does not have that level introspection, but otherwise is likely a better choice mostly for its far greater scope of functionalities. (Mathematics, graphics, computable data, etc.)

In principle a corresponding Python "LLMGraph" package can be developed, for comparison purposes. Then the "better choice" question can be answered in a more informed manner. (The Raku packages "LLM::Functions" and "LLM::Prompts" have their corresponding Python packages implemented already.)

Specifications for asynchronous LLM computations with Raku's "LLM::Graph" detail how to manage complex, multi-step LLM workflows by representing them as graphs. By defining the workflow as a graph, developers can execute LLM function calls concurrently, enabling higher throughput and lower latency than synchronous, step-by-step processes.

"LLM::Graph" uses a graph structure to manage dependencies between tasks, where each node represents a computation and edges dictate the flow. Asynchronous behavior is a default feature, with specific options available for control.

God to know.

BTW, several years ago the LLM-revolution didn't happen yet. Raku started to have sound LLM packages circa March-May 2023.

What is better in Raku than Python? Did you use any of the dedicated Raku LLM packages?

I think nightcore versions of your pieces would be of interest...

In my opinion the referenced music fragment of that video is fairly "unmemorable", it is "just" a sequence of harmonized textures. And that is precisely what AIs (LLMs) are good at.

(I listened for ≈7 min from the reference point.)

(I am talking about the music, not the live performance itself.)

The creation of music by AI brings to mind a quote from David Bowie:

“Music itself is going to become like running water or electricity. So take advantage of these last few years, because this will never happen again. Get ready for a lot of touring, because that's the only unique experience left.”

While Bowie had different reasoning for making that statement, it's interesting to think that with AI-generated music, his idea of "music like water or electricity" might finally come true.

Wolfram Language (aka Mathematica) notebook.

I assume you mean book's code shown in the Jypyter notebooks in the repository. (Which I think is both simple and messy.)

Dedicated presentation GitHub repository: https://github.com/antononcube/SimplifiedMachineLearningWork...

Thanks for sharing this!

I only "followed" so far the properties given at Wolfram Community:

https://community.wolfram.com/groups/-/m/t/3347182

In this presentation we discuss:

- Two ways of plotting chessboards

- Knight's tour graphs

- Hamiltonian paths

- Animations of knight's tours

Showcasing Raku's tools for exploratory data analysis over programming languages data.

Here is the presentation notebook: https://github.com/antononcube/RakuForPrediction-blog/blob/m...

Here is the corresponding Wolfram Language (aka Mathematica) notebook: https://community.wolfram.com/groups/-/m/t/3180327

The formula is generic; my weights are for measuring engagement.

(And, yes, I am very scared by the future downvotes.)

Insightful!

Do you know of any "large scale" research on this? I.e. analysis of multiple related projects and/or of "real life stories."

(I agree regardless.)

Yes, that is a part of the measure I have in mind. Let me be more concrete.

Terms:

- P: Number of positive votes (of any comment)

- N: Number of negative votes (of any comment)

- V: Number of views of the image album

- C: Number of comments in the thread

Formula:

    w1 * P + w2 * N + w3 * V + w4 * C

   (w1, w2, w3, w4) = (1, 1, 1, 3)

It seems you are describing how functional parsers (aka parser combinators) work.

(BTW, there is a "Parser combinators" section in the featured post/article.)

Very long write-up! If you read it and like the content, you might consider ditching Python and start using Raku a lot and often.

I don't know... It seems to be fairly entertaining, judging by the number of image album views and the number of comments here.

The applications that are WL-units suitable are much more than the WL-units unsuitable ones you refer to.

It is true that I (and others) avoid using Wolfram Language (WL) units. Or try to get the computation expressions units-free as quickly as possible. But that is also a normal procedure when crafting computational workflows.

Yeah! In my opinion, the corresponding "real life" globes I found are pretty ugly when compared to the AI-generated images.

For example, here: https://www.etsy.com/listing/1400131282/chernobyl-snow-globe