It teaches practical techniques for using the language better.
It teaches how the language works and why. What it teaches is firmly grounded in the ECMAScript specification (which the book explains and refers to).
It covers only the language (ignoring platform-specific features such as browser APIs) but not exhaustively. Instead, it focuses on a selection of important topics.
Last week, I drank my first cup of Rust. I learned concepts that are foreign in the languages I know: ownership, borrowing and lifetimes. This week I want to drink the second cup and see where it leads me.
This is the 2nd post in the Start Rust focus series.Other posts include:
My second cup of Rust (this post)
As CPU cores become both faster and more numerous, the limiting factor for most programs is now, and will be for some time, memory access. Hardware designers have come up with evermore sophisticated memory handling and acceleration techniques–such as CPU caches–but these cannot work optimally without some help from the programmer. Unfortunately, neither the structure nor the cost of using the memory subsystem of a computer or the caches on CPUs is well understood by most programmers. This paper explains the structure of memory sub systems in use on modern commodity hardware, illustrating why CPU caches were developed, how they work, and what programs should do to achieve optimal performance by utilizing them.
In this brief tutorial I’m aiming to make a small game for the ZX Spectrum, written 100% in assembler. I’ve done a bunch of projects for the speccy using SDCC; while I couldn’t completely escape assembly, the C compiler did a lot of heavy lifting for me. In other words, I traded control for convenience.
Now, since I’ve never actually done a 100% assembler project before (ignoring some tiny DOS TSR experiments), this is a learning experience for me as well. A lot of things I’ll do here is likely not going to be optimal, but what I present is what happened to work for me. All the source code is free to use in whatever way you wish, with no warranty whatsoever.
On implementing streaming algorithms, counting of events often occurs, where an event means something like a packet arrival or a connection establishment. Since the number of events is large, the available memory can become a bottleneck: an ordinary n-bit counter allows to take into account no more than 2n−1 events.
One way to handle a larger range of values using the same amount of memory would be approximate counting. This article provides an overview of the well-known Morris algorithm and some generalizations of it.
This guide is intended to help you gain a true understanding of SQL query speeds. It includes research that demonstrates the speed of slow and fast query types. If you work with SQL databases such as PostgreSQL, MySQL, SQLite, or others similar, this knowledge is a must.
Recently, I needed to learn this completely new language Clojure but couldn’t find what I wanted. So, I decided to create one while learning Clojure.
Clojure is a functional programming language and learning functional programming languages is sometimes hard if you’ve only had experiences with imperative languages. I have paid careful attention to make this page easy to understand for people who don’t have experiences with functional programming languages, so please don’t hesitate to read this page even if you don’t know anything about functional programming.
Hopefully, this page helps you learning functional programming and starting to write Clojure!
In this short writeup I’ll give examples of various multiprocessing libraries, how to use them with minimal setup, and what their strengths are.
If you want a TL;DR - I recommend trying out
lokyfor single machine tasks, check out Ray for larger tasks.
A differential equation-solving analog device is a reconfigurable computing platform which leverages the physics of the underlying substrate to implement dynamical system computations. In the last article, we discussed how a programmer would manually configure an analog device to perform computation. In this article, we will discuss how to automatically configure an analog device to run a target dynamical system. We frame this problem of automatically configuring the analog hardware as a compilation problem.
The compiler takes, as input, a specification of the dynamical system and a specification of the analog device. The dynamical system specification provides the differential equations to implement on the hardware. The analog device specification describes the input ports, output ports, programming interface (data fields and modes), and behavior of each block. This specification also defines all of the possible digitally settable connections available on the device. The compiler produces as output an analog circuit specification which describes a circuit made up of configured blocks. The analog circuit specification annotates the signals in the described circuit which implement dynamical system variables.
Working with data from an art museum API and from the Twitter API, this lesson teaches how to use the command-line utility jq to filter and parse complex JSON files into flat CSV files.
This is my own collection of hard-earned knowledge about how integers work in C/C++, and how to use them carefully and correctly. In this article, I try to strike a balance between brevity (easing the reader) and completeness (providing absolute correctness and extensive detail).
Whenever I read or write C/C++ code, I need to recall and apply these rules in many situations, such as: Choosing an appropriate type for a local variable / array element / structure field, converting between types, and doing any kind of arithmetic or comparison. Note that floating-point number types will not be discussed at all, because that mostly deals with how to analyze and handle approximation errors that stem from rounding. By contrast, integer math is a foundation of programming and computer science, and all calculations are always exact in theory (ignoring implementations issues like overflow).
This book is a product of my own endeavour of understanding category theory. It is just that as I am explaining something, I am understanding it better. It is aimed at programmers, as well as anyone else who is interested in this stuff.
The main reason I am interested in Category Theory is that it allows us to formalise some common concepts that we use in our daily (intellectual) lives. Much of our language is based on intuition and rightfully so: relying on intuition is a very easy way to get your point across so it is understood by other human beings. However, that is part of the problem: sometimes intuition makes it too easy to communicate with someone. So easy that he might, in fact, understand things that you haven’t actually said. For example, when I say that two things are equal, it would seem obvious to you what I mean, although it isn’t obvious at all (how are they equal, at what context etc). That is the place when we might want to provide a more rigorous definition of what am I saying (even if I did not have one, to begin with). But providing such definition in natural language, which is designed to use intuition as a means of communication, is no easy task. It is in these situations that people often resort to diagrams to explain their thoughts. Diagrams are ubiquitous in science and mathematics because they are an understandable way to communicate a formal concept clearly. Category theory formalises the concept of a diagram and their components - arrows and objects and creates a language for presenting all kinds of ideas.
In this book, we will visit those formalisms and along the way, we would see all other kinds of mathematical objects, viewed under the primsm of categories.
WebGL2 from the ground up. No magic.
These are a set of articles that teach WebGL2 from basic principles. They are NOT old rehashed out of date OpenGL articles like many others on the net. They are entirely new, discarding the old out of date ideas and bringing you to a full understanding of what WebGL really is and how it really works.
“Formal methods of software design” means using mathematics to write error-free programs. The mathematics needed is not complicated; it’s just basic logic. The word “formal” means the use of a formal language, so that the program logic can be machine checked. Our compilers already tell us if we make a syntax error, or a type error, and they tell us what and where the error is. Formal methods take the next step, telling us if we make a logic error, and they tell us what and where the error is. And they tell us this as we make the error, not after the program is finished. It is good to get any program correct while writing it, rather than waiting for bug reports from users. It is absolutely essential for programs that lives will depend on.
The course begins by introducing (or reviewing) the basic logic that will be used as an aid to programming. Then we look at formal specifications, and how they are refined to become programs. At each refinement step, there is a small theorem to be proven (that the step is correct), so that at the end, the program is correct. Most of the course uses just those programming constructs that are common to most programming languages (assignment statement, if statement, array). We also look at parallel and interacting processes, at probabilistic programming, and functional programming. Along the way, we formally define the language features we use (both execution control and data structures). The emphasis is on program development to meet specifications, and on program modifications that preserve correctness, rather than on verification after a program is finished.
An explanation of how to implement a simple hash table data structure using the C programming language. I briefly demonstrate linear and binary search, and then design and implement a hash table. My goal is to show that hash table internals are not scary, but – within certain constraints – are easy enough to build from scratch.
Cubic Béziers are by far the most common curve representation, used both for design and rendering. One of the fundamental problems when working with curves is curve fitting, or determining the Bézier that’s closest to some source curve. Applications include simplifying existing paths, efficiently representing the parallel curve, and rendering other spline representations such as Euler spiral or hyperbezier. A specific feature where curve fitting will be used in Runebender is deleting a smooth on-curve point. The intent is to merge two Béziers into one, which is another way of saying to find a Bézier which best approximates the curve formed from the two existing Bézier segments.
In spite of the importance of the curve-fitting problem and a literature going back more than thirty years, there has to date been no fully satisfactory solution. Existing approaches either fail to consistently produce the best result, are slow (unsuitable for interactive use), or both.
The main reason the problem is so hard is a basic but little-known fact about cubic Béziers: with C-shaped curves (no inflection point and a small amount of curvature variation) there tend to be three sets of parameters that produce extremely similar shapes. As a result, in general when fitting some arbitrary source curve, there are three local minima. Approaches based on iterative approximation (in addition to being slow) are likely to find just one, potentially missing a closer fit of one of the others.