As mentioned in the Introduction, AI models alone won't allow us to cram AI features into every corner of our digital life. The primary focus of an AI model is to implement the core mathematical algorithm of an AI system.
But a typical AI system usually contains other components that enable all kinds of software to interact with the AI system in a streamlined way.
Such components are what we are going to discuss in this part of the course.
We will largely focus on the industry standard technique for streamlined interaction between software, called the application programming interface (API).
In Module A.1 we will establish concepts essential for the discussion around APIs. We will also have the chance to play with the API for an existing AI system.
In Module A.2 we will learn how to integrate API interaction in the programming language that you are most familiar with, in this case Python, so you can easily incorporate AI functionalities into your programs.
Download the lecture slides for this module using this link.
What is AI composed of, and how are companies like OpenAI, Anthropic, Google, and Microsoft pushing AI for millions of people around the globe to use, whether people want it or not?
From courses you've taken in previous semesters and the Deep Learning course this semester, you know that one of the essential components of AI is what we call AI models, usually neural network or deep learning models these days, trained on large amounts of data.
AI models are also essentially a type of software, predominantly implemented using the Python programming language and Python libraries like PyTorch and TensorFlow.
An AI model is a neural network in concept and Python code in practice.
However, just the AI models themselves are far from being able to serve people all over the world with different styles and habits for using AI.
To help inflate the AI bubble even more and integrate AI into every piece of our digital life, all kinds of software, such as search engines, messaging apps, text editors, social media apps, and video games, need to interact with AI models.
However, not all software is coded with Python, and even if it is, you cannot expect all software to be Python functions within a giant Python project that can call each other for communication. Therefore, there must be a more standardized, language-agnostic way to enable communication between AI models and other parts of the digital world, but what is it, and can we implement it ourselves?
Selling points of electronic books are off, at least those frequently mentioned by e-book and e-reader vendors.
I recently received this advertisement email from Rakuten Kobo, a Japanese brand that sells electronic books and readers, just like Amazon with their Kindle lineup.
Opening of the advertisement email I received from Rakuten Kobo.
Which translates to:
Do you have these worries while reading books?
Walking around with books is heavy... Battery drain when reading on a smartphone is concerning...
Leave it to the Rakuten Kobo e-reader!
Which are selling points of e-books and e-readers frequently mentioned by most vendors, not limited to Rakuten Kobo.
However, they don't make a lot of sense in most real-world scenarios.
I have been actively moving away from electronic products with built-in lithium batteries, unless I have no practical alternatives.
That means depending on what I need, smartphones and laptops could be the only two electronic devices that I can bear with having built-in lithium batteries.
For all the other devices that need to be portable, I am trying my best to stick to devices with easily replaceable batteries, preferably AA or AAA batteries for bigger devices and CR batteries for smaller devices.
Or for devices that don't necessarily need to have batteries in them, I just stick to wired devices.
My devices that use AA/AAA/CR batteries or are simply battery-free.
In my opinion, AA/AAA/CR batteries are the real "user-replaceable battery" design that I am pursuing.
In recent years, in response to the right-to-repair demand, many companies have started to design the built-in lithium batteries in their products as easier to reach with simple tools and available in their storefronts.
However, as of right now, you probably still need quite a lot of effort getting into the battery compartment of these devices, and you might only be able to purchase the specific model of battery from the specific vendor, with no guarantee that you can always do so.
... or any online collaborative LaTeX editor in general (yeah, I am talking about OpenAI's Prism, or any future platform that might pop up).
I want to demonstrate that with the good old Git and the industry standard CI (continuous integration) pipeline, everything you need from Overleaf can be easily replaced for free, with much better practices for version control and data security.
Why?
I have touched on the general topic of replacing cloud-based tools with local file synchronization in this post.
To repeat the point, I believe pure cloud-based tools like Overleaf are simply unusable and should be avoided at all costs: your data only have one copy on their server, meaning there is zero guarantee that you can always access them or they will never lose them; even the slightest network instability will interrupt your workflow; and why would you trust them to keep your work in progress a secret?
Specific to Overleaf, their price for premium accounts is also absurdly high, and the set of functionalities at free tier is very limited.
Diffusion models, or more broadly, both score-matching and flow-matching models, are the foundational frameworks for building generative models these days.
Compared to previous frameworks including VAEs and GANs, they are actually capable of generating high-quality data, like NSFW images that you might or might not want to jerk off to.
For a more detailed treatment of diffusion models, see this post on shortcut models and this post on discrete diffusion models.
In many scenarios, we would like a generative model to be able to do conditional generation.
For example, when generating images, one might want to generate an image of a dog, rather than any image that is plausible.
Formally, the unconditional probability is $x\sim p_\theta(x)$, where $p_\theta(x)$ is the probability parameterized by the generative model with parameters $\theta$.
Instead of sampling from $p_\theta(x)$, we want to sample from a conditional probability $x\sim p_\theta(x|y)$, where $y$ is the condition.
Steam Deck is a great handheld gaming device and Steam Deck OLED is even better with the beautiful OLED screen, among other hardware improvements.
Its default operating system (SteamOS) is essentially a custom Linux distribution (based on Arch Linux) with KDE Plasma desktop environment and a console-style Steam overlay.
It proves that Linux gaming has became quite mature, and depending on what games you often play, the experience can be better than a Windows machine in many aspects.
It also proves that the "plug and play" experience of traditional consoles and open hardware and software can coexist.
Steam Deck OLED (top) and Nintendo Switch 2 (bottom).
Both with the "Killswitch" line of cases from dbrand.
Given the open nature of the Steam Deck, and also considering some people might not prefer every design choice of SteamOS (e.g., the desktop environment), installing NixOS on Steam Deck can be a good option if you want to customize it while still preserving most of the handheld gaming experience. Thanks to the existence of Jovian-NixOS, a NixOS module built specifically for running NixOS on Steam Deck, the process is actually very straightforward if you are already familiar with NixOS.
