Joel's Blog

On Liberty - Introduction

Sat, 27 Feb 2021 00:00:00 -0500

I started reading J.S. Mill's On Liberty today. I thought I would write up my thoughts after each chapter.

In the introduction, Mill states the goal of the essay is:

the nature and limits of the power which can be legitimately excercised by society over the individual.

He then goes on to provide a brief historical overview. It used to be, (he says) that the struggle between Authority and Liberty was the struggle between Ruler and Ruled. When there is a clear division between the ruler and his subjects, the subjects gain Liberty by restricting the power of the ruler. This is a clear pattern that he sees throughout European history. Sometimes the ruler has more constraints and sometimes he has less, but always those who seek liberty seek to restrain his power.

With the rise of constitutional forms of government, things become murkier. Now those who seek liberty will sometimes try to transfer power from the ruler to some other body that represents society as a whole. Once enough power has been transferred to bodies that claim to act in the interests of the people, there is an argument that restrictions on their power reduce the liberty of the people: Liberty consists of the ability of the people to do what they want. One main avenue by which the people (as a whole) exercise their power is through their representatives. Therefore restricting the power of the representatives reduces their ability to achieve the goals of the people, and thus reduces liberty.

Mill raises three objections to this argument.

The interests of the representatives might not coincide with that of the people.
If each person is subject to the will of all the others, each person will have much less liberty.
The "will of the people" often means the will of a particular section of the people (maybe the most numerous or the most vocal), and they may oppress the rest of the people.

He also notes that when society is acting against an individual, it can act through political avenues, but it does not need to.

Protection agains the tyranny of the magistrate is not enough, there needs protection also against the tyranny of the prevailing opinion and feeling; against the tendency of society to impose, by other means than civil penalties, its own ideas and practices as rules of conduct on those who dissent from them; to fetter the development and prevent the formation of any individuality not in harmony with its ways, and compel all characters to fashion themselves upon the model of its own.

This quote brings two things to my mind. First, in today's society it seems that the tyranny of the magistrate is far more constrained than the tyranny of prevailing opinion and feeling. Secondly, (as was pointed out recently in Blake Smith's article on Yan Fu's translation of Mill in Palladium) Mill is concerned with the creation of individuality, not merely allowing people to do as they please.

How then should we determine the ways society may impose upon the individual? Mill rejects custom as merely a way of expressing the interests of the currently dominant class. Instead, society may impose on an individual to prevent harm to another, but may not prevent self-harm.

Finally, he identifies three key liberties that must be protected:

Liberty of Conscience. The thoughts and feelings of one individual cannot harm another, and must be free. He considers the liberty of expressing and publishing opinions to be a key element of this.
Liberty of Tastes and Pursuits. Each should be allowed to plot his own course through life, provided it doesn't harm others.
Liberty of Association. It follows that two or more people should be able to come together for any reason that doesn't harm other.

New Job

Sat, 27 Feb 2021 00:00:00 -0500

I started a new job in September just after the last post. I was hired by Octopuz, a small company that makes offline robot programming software. OLRP is a technique used to streamline the use of the industrial robots used in many factories.

Users start by creating a model of their existing "robot cell." This is one or more six-axis robots, rails that the robots can be repositioned on, rotary tables the work pieces can be mounted on, tools (such as welding torches or cutters) attached to the robot, and obstacles like tables or walls. Our software ships with CAD models of most of the mechanical components our users have, and more can be added easily.

Once the cell has been defined, a CAD model of the part they want to work on is imported. They then create one or more "paths" the robot will follow around the part. The path contains the points to travel between, where to turn the tool on or off, how fast to travel, the angle the tool should be at, &c. A single path is then often duplicated several times to take advantage of translational, rotational or flip symmetries of the part. For instance, there might be a bar held onto a plate by 8 identical brackets on each side. The user would manually lay out the path to weld one bracket, then translate the path to each bracket on that side, and then flip them all to the other side.

We then analyze the paths to find how to best move each robot axis and any external positioners. Users can see a simulation of how the robot will follow the path they defined, and any problems we identified with it.

Finally, we generate an output program that can be provided to the robot to make it follow the paths the user created.

The alternative approach is to use a controller attached to the robot to steer it through the paths to follow, recording the points as you go. OLRP allows a new program to be created for the robot while it is working on a different part, improving utilization. It can also be much faster for complicated paths, as the software can provide shortcuts to quickly visit many points.

Three Stage Iron Casting

Tue, 08 Sep 2020 00:00:00 -0400

(This is the second entry in the series. Part 1)

I mentioned briefly in the intro that more advanced smelting and casting provides higher yields. In this post, I'll walk through a basic iron setup.

The main flow of this setup is iron ore enters at the bottom, then is progressively refined before iron plates come out at the top.

The first processing stage is crushing. This uses Jaw crushers to separate the raw Iron ore into Processed iron ore and Stone. Most of the stone is consumed by the foundries on the second row to create bricks. The bricks are used to create Hot Air to improve the yield farther up.

The processed ore then moves up to the Basic oxygen furnaces. In this chain, the Basic oxygen furnaces seem to play the role of a blast furnace.

(A real-life blast furnace works as follows: iron ore (which is primarily iron oxide) is mixed with coal and a flux (typically limestone). The furnace is loaded with this mixture. Hot oxygen-rich air is blown into the bottom of the furnace, and the coal burns in the oxygen to create heat and carbon monoxide. The carbon monoxide is a strong reducing agent, and will react with the iron oxides to create carbon dioxide and elemental iron. The intense heat from the combustion will also melt the iron, allowing it to flow out the bottom of the furnace. The limestone (CaCO₃) also reacts with the carbon monoxide to form quicklime (CaO) and carbon dioxide. The quicklime then reacts with various impurities in the iron and forms a slag layer near the bottom of the furnace. The molten iron and slag can be drawn out and used for casting or steelmaking.)

In the process I'm currently using, the BOF uses processed ore, oxygen and a borax flux, as well as any combustible fuel. It creates molten iron, which is piped up to the final stage, the casting unit.

The penultimate stage creates sand castings. It uses some of the stone from the crushers to make sand, and that is mixed with creosote made from tar to make the casts.

Finally, the casts, molten iron and more borax flux as well as hot air from the bricks in the second stage are used to cast iron plates.

Introduction to Pyanodon

Tue, 08 Sep 2020 00:00:00 -0400

I recently started a game of Factorio using Pyanodon's mods. This is a set of mods intended to make the production chains in Factorio more complex and realistic. For example, in vanilla Factorio Electronic circuits are made by combining copper wires and iron plates in an assembler. This requires a total of 2 buildings to go from plates to final product. In Pyanodons, Simple circuits (the equivalent item) require Capacitors, Inductors, Resistors, Vacuum Tubes and PCBs. Each of the electronic components requires at least a metal plate or wire as well as Ceramic or Glass that needs to be assembled from simpler ingredients. The PCBs have their own production chain, going from wood -> treated wood -> fiberboard -> formica -> PCB, pulling in at least one other ingredient at each step. By my count, 27 different recipes are used, not including smelting ore into plates.

Someone on Reddit commented that there are lots of posts showing Simple Circuits, but it seems most people give up shortly after. I thought I would chronicle my progress so people interested in the mod can see what's involved.

The aforementioned simple circuit assembly:

Raw coal goes through a two stage coking process to reduce it to coke, as well as creating some tar and coal gas.

Quartz crystals are refined into molten glass before being formed into glass plates or glass beakers for science.

Alien lifeforms are grown to provide urea and methane to create melamine.

Most metals can be smelted in a stone furnace like in vanilla, but this is very expensive, typically using around 10 ore/plate. Here I have a three-stage copper smelter that screens and crushes the ore before casting to improve yield.

Iron Smelting

I'll post more as the factory continues to grow.

Review of Mother of Learning

Sat, 30 May 2020 00:00:00 -0400

Mother of Learning is a story I'd seen recommended on /r/fantasy a few times. In the first chapter, we're introduced to the protagonist, Zorian Kazinski. He's a budding mage who is returning to the mage academy for his third year of schooling. He is a diligent student, but is held back by poor "mana reserves" and a somewhat prickly personality.

Around a month into the school year, the city hosting the school is attacked by a force of monsters and Zorian witnesses a fellow student (Zach) fighting an incredibly powerful lich leading the monsters. Zach makes some cryptic comments and the lich casts a mysterious spell, and then Zorian wakes up in his bed at the beginning of the month.

Zorian quickly figures out he is caught in a Groundhog Day-style time loop, living through the same month over and over, and only he, Zach and a mysterious enemy appear to remember what is happening from month-to-month. He sets out to learn as much magic as he can, both to figure out what is happening with the time loop and to stop the invasion of the city.

This story is an interesting story of Zorian learning to be both a better mage and a better person in general. It is somewhat long-winded (my e-reader app estimates it at 2700 pages), but while I was reading it it always felt like he was progressing towards a goal. It also felt like the setting was designed for Dungeons & Dragons, and in the author's notes at the end he confirmed that the story started out as a way to flesh out a D&D setting.

I enjoyed it, but I'd be hesitant to recommend it given how long it is.

Green peppers stuffed with sausage

Fri, 21 Aug 2015 00:00:00 -0400

This one is fairly self-explanatory.

Heat the oven to 350°F (175°C)

Remove the casings from several sausages. Fry the meat, as well as anything you think goes well with pork. Finely chopped apples work well.

Cut the tops off of some green peppers (one per person) and remove the ribs and seeds. Stuff the peppers with the meat.

Bake for 20 minutes.

Stir-Fried Shrimp

Sat, 04 Jul 2015 00:00:00 -0400

Gwen's dad sent us a recipe for stir-fried shrimp with rice wine, and it turned out quite well.

Shell a pound of shrimp.

Heat ¼ cup of oil in a wok on high. Add 4 thinly sliced scallions and some chopped ginger. Cook until nicely fragrant.

Add the shrimp and cook fully.

Add 1 tablespoon of brown sugar and 2 tablespoons of rice wine. He recommended shàoxīng wine, but the LCBO near us only had saké, which worked fine. Simmer 2 or 3 minutes, then serve.

Seeding the PRNG in a C program

Fri, 20 Feb 2015 00:00:00 -0500

The POSIX specification provides a pseudo-random number generator via the random(3) and srandom(3) functions. srandom() should be called at program start to seed the generator. (If no seed is provided, random() acts as though srandom(1); was called. This provides reproducible behaviour for testing, but an explicit seed might be preferred.) How should we get a random seed for the call to srandom()?

On x86_64 Linux, the loader for ELF files places a collection of values known as the auxilary vector just below the bottom of the stack. These values can be accessed through the getauxval(3) function, found in sys/auxv.h. One of the entries in this vector is AT_RANDOM, a pointer to 16 bytes of random data.

We can therefore seed the generator via

#include <stdlib.h> // random(), srandom()
#include <sys/auxv.h> // getauxval(), AT_RANDOM

void random_seed() {
    int* seed = getauxval(AT_RANDOM);
    srandom(*seed);
}

This should not be used in a situation where the seed must be hidden from the user, as the auxilary vector can be displayed by setting the LD_SHOW_AUXV environment variable prior to calling the program.

Parsec and Left Recursive Grammars

Wed, 04 Feb 2015 00:00:00 -0500

The traditional way to specify the syntax of a programming language is to write a Context Free Grammar (CFG) in Extended Backus-Naur Form (EBNF). Briefly, this form consists of a series of rules, each describing the form of some syntax element. For example, we might have a rule for postfix expression in C:

postfix-expression:
   primary-expression
   | postfix-expression '[' expression ']'
   | postfix-expression '(' argument-expression-list ')'
   | postfix-expression '.' identifier
   ⋮

This says that a postfix expression can be a primary expression (constant, identifier, or expression in parentheses) or it can be a postfix expression followed by some operator. An expression like

rectangle.bottomLeft.x

is thus parsed as

((primary-expression) '.' identifier) '.' identifier

The rule for postfix-expression is known as left recursive because postfix-expression appears as the leftmost symbol in some of the productions. This causes a problem for most left-to-right parsers. When they attempt to parse a postfix expression, they might first attempt to parse it as a primary-expression. If that fails, they might attempt to parse it as an array subscript. To do this, they first need to parse a postfix-expression. This leads to an infinite recursion, where the parser continues to nest deeper and deeper, while never consuming any input.

The traditional solution is to rewrite our rule into a right recursive form. In this case, we notice that every postfix-expression begins with a primary-expression, followed by a (possibly empty) chain of subscripts, member accesses and function calls. We can thus rewrite the grammar as

postfix-expression: primary-expression postfix-expression'

postfix-expression': empty
                   | '[' expression ']' postfix-expression'
                   | '(' argument-expression-list ')' postfix-expression'
                   | '.' identifier postfix-expression'
                   ⋮

Unfortunately, this changes the associativity of the operations. Instead of being left associative, they are now right associative, and our example would be parsed as

primary-expression ('.' identifier ('.' identifier))

The solution to this is somewhat dependent on the particulars of your parser. I have been using Parsec for parsing. The left recursive grammar would be written as

data PostfixExpression = Primary PrimaryExpression
                       | ArraySubscript PostfixExpression Expression
                       | FunctionCall PostfixExpression [ArgumentExpression]
                       | Member PostfixExpression Identifier
                       ⋮
                       
postfixExpression =
    (try $ liftM2 ArraySubscript postfixExpression $ brackets expression)
    <|> (try $ liftM2 FunctionCall postfixExpressioon $ parens $ many argumentExpression)
    <|> (try $ liftM2 Member postfixExpression (dot >> identifier))
    ⋮
    <|> liftM Primary primaryExpression

This builds an abstract syntax tree and nicely matches the structure of the grammar. Unfortunately, it doesn't complete (as we have seen). The advice on most blogs I have seen for dealing with left recursion is to use the chainl1 combinator. This would be a nice solution, but it assumes all the subexpressions have the same type as the result of combining them. chainl1 can be adapted to handle the case of subexpressions of type a and a result of type b. This was useful for handling arithmetic expressions.

chainl1' :: Parser a -> Parser (b -> a -> b) -> (a -> b) -> Parser b
chainl1' parser op baseConstructor = parser >>= (rest . baseConstructor)
    where rest context = do
                             f <- op
                             y <- parser
                             rest $ f context y
                         <|> return context

data AdditiveExpression = MultiplicativeExpression MultiplicativeExpression
                        | Add AdditiveExpression MultiplicativeExpression
                        | Subtract AdditiveExpression MultiplicativeExpression

parsePlusMinus = (reservedOp '+' >> return Add) <|> (reservedOp '-' >> return Subtract)
additiveExpression = chainl1' multiplicativeExpression parsePlusMinus MultiplicativeExpression

This works beautifully for defining the arithmetic of a language, which is often many levels deep and each level has similar structure to all the others. Postfix expressions lack this regular structure, so we need a slightly more involved approach. It might be possible to make an even more general chain combinator, which associates each operator parser with an expression parser, but it would only be used in this location, so it is simpler to just handle this case independently. The structure is similar to chainl1', but with several alternatives

postfixExpression = Primary primaryExpression >>= rest
    where rest context =
                         (brackets expression >>= rest . ArraySubscript context)
                         <|> (parens expression >>= rest . FunctionCall context)
                         <|> (dot >> identifier >>= rest . Member context)
                         <|> context

This runs nicely and still preserves clarity.

Coming up with this solution made showed just how valuable having the source for a solution that does something similar to what you want is, and how valuable having a package management system (Hackage) that can show source is.

Edit: I messed up the final version of postfixExpression. The post was written before I had completed the loop inherent in the C expression type, and consequently couldn't test the parser. This is a case where implicit typing bit me. I knew rest should have been

rest :: PostfixExpression -> ParsecT String u Identity PostfixExpression

but hadn't annotated it. My original version was taking a PasecT as its argument, which lead back to the looping problem.

C Initialization Designators

Tue, 03 Feb 2015 00:00:00 -0500

I have been working on a C parser over the last few days, and because of this I have been reading the section of C99 relating to syntax much more carefully than I have in the past. In particular, §6.7.8 Initialization had a construct I had never seen before.

initializer:
    assignment-expression
    { initializer-list }
    { initializer-list , }

initializer-list:
    designation_opt initializer
    initializer-list , designation_opt initializer

designation:
    designator-list =

designator-list:
    designator
    designator-list designator

designator:
    [ constant-expression ]
    . identifier

It starts very conventionally. If we are initializing a scalar (or copying an aggregate or union), we use an assignment expression. This is the familiar

int x = 5;
struct aggregate_t s = some_function_returning_aggregate();

We can have a list of initializers enclosed in braces. This is the well known construct for initializing arrays:

int arr[] = {1,2,3,4,5};

We can initialize based on the members of a structure (this was added in C99, so anyone using compilers that are based on 25+ year old standards won't have this):

struct {
    int x;
    int y;
} point = { .x=4, .y=7 };

This is all basic stuff, that I see in common use. What caught my eye, largely because I couldn't see how the EBNF translated to C syntax, was the concept of designator-lists and the [ constant-expression ] form of designators. This lets us initialize particular elements of an array, and do precise initialization of nested aggregates.

int arr[4] = { [0]=0*0, [2]=2*2 }

struct {
    struct Point points[4];
    struct Point otherPoints[4];
} s = { .point[2].x=3, .otherPoints[3].y=1 };

Since this could leave a minefield of partially initialized structures, it is easy to understand why the are so infrequently used. I am not sure I have ever seen this syntax in a codebase, and I have certainly never seen it in teaching materials. It also wasn't carried over into C++, so it could prevent a program from being compiled by both C and C++ compilers. Nevertheless, if you want to pick up on interesting (and potentially useful) language features, reading the standard (or your compiler's manual) is invaluable.