Started restoring some old images & posts; changed themes to notepadium

hugo_blag/content/posts/2010-07-04-processing-dla-quadtrees/index.md

@@ -16,7 +16,10 @@ implementation in a slow language for heavy computations
 (i.e. Python), but it worked well enough to create some good results
 like this:
 
+<!--  TODO: Originally:
 [![Don't ask for the source code to this](../images/dla2c.png){width=50%}](../images/dla2c.png)\ 
+-->
+![Diffusion Limited Aggregation](./dla2c.png "Don't ask for the source code to this")
 
 After about 3 or 4 failed attempts to optimize this program to not
 take days to generate images, I finally rewrote it reasonably

hugo_blag/content/posts/2011-02-07-blender-from-a-recovering-pov-ray-user/index.md

@@ -54,9 +54,15 @@ the 2nd image down below) or
 [OpenFrameworks](http://www.openframeworks.cc/) or one of the
 too-many-completely-different-versions of Acidity I wrote.
 
+<!-- TODO: Originals (get alt-text in?)
 [![What I learned Bezier splines on, and didn&#39;t learn enough about texturing.](../images/hive13-bezier03.png){width=100%}](../images/hive13-bezier03.png)
 
 [![This was made directly from some equations. I don't know how I'd do this in Blender.](../images/20110118-sketch_mj2011016e.jpg){width=100%}](../images/20110118-sketch_mj2011016e.jpg)
+-->
+
+![Hive13 bezier splines](./hive13-bezier03.png "What I learned Bezier splines on, and didn't learn enough about texturing.")
+
+![Processing sketch](./20110118-sketch_mj2011016e.jpg "This was made directly from some equations. I don't know how I'd do this in Blender.")
 
 [POV-Ray](http://www.povray.org) was the last program that I
 3D-rendered extensively in (this was mostly 2004-2005, as my
@@ -92,6 +98,6 @@ all the precision that I would have had in POV-Ray, but I built them
 in probably 1/10 the time. That's the case for the two
 work-in-progress Blender images here:
 
-[![This needs a name and a better background.](../images/20110131-mj20110114b.jpg){width=100%}](../images/20110131-mj20110114b.jpg)
+![20110131-mj20110114b](./20110131-mj20110114b.jpg "This needs a name and a better background")
 
-[![This needs a name and a better background.](../images/20110205-mj20110202-starburst2.jpg){width=100%}](../images/20110205-mj20110202-starburst2.jpg)
+![20110205-mj20110202-starburst2](./20110205-mj20110202-starburst2.jpg "This needs a name and a better background.")

hugo_blag/content/posts/2011-11-24-obscure-features-of-jpeg/index.md

@@ -48,9 +48,9 @@ expressing an identical image.
 
 One command I've used pretty frequently before posting a large photo online is:
 
-```bash
+{{<highlight bash>}}
 jpegtran -optimize -progressive -copy all input.jpg > output.jpg
-```
+{{< / highlight >}}
 
 This losslessly converts *input.jpg* to a progressive version and
 optimizes it as well. (*jpegtran* can do some other things losslessly
@@ -108,7 +108,7 @@ Your libjpeg distribution probably contains something called
 **wizard.txt** someplace (say, `/usr/share/docs/libjpeg8a` or
 `/usr/share/doc/libjpeg-progs`); I don't know if an online copy is
 readily available, but mine is
-[here](<../images/obscure_jpeg_features/libjpeg-wizard.txt>). I'll
+[here](<./libjpeg-wizard.txt>). I'll
 leave detailed explanation of a scan script to the "Multiple Scan /
 Progression Control" section of this document, but note that:
 
@@ -124,7 +124,7 @@ Progression Control" section of this document, but note that:
 
 According to that document, the standard script for a progressive JPEG is this:
 
-```bash
+{{<highlight text>}}
 # Initial DC scan for Y,Cb,Cr (lowest bit not sent)
 0,1,2: 0-0,   0, 1 ;
 # First AC scan: send first 5 Y AC coefficients, minus 2 lowest bits:
@@ -146,31 +146,36 @@ According to that document, the standard script for a progressive JPEG is this:
 1:     1-63,  1, 0 ;
 # Y AC lowest bit scan is last; it's usually the largest scan
 0:     1-63,  1, 0 ;</pre>
-```
+{{< / highlight >}}
+
 
 And for standard, sequential JPEG it is:
 
-```bash
+{{<highlight text>}}
 0 1 2: 0 63 0 0;
-```
+{{< / highlight >}}
+
 
 In
-[this image](../images/obscure_jpeg_features/20100713-0107-interleave.jpg)
+[this image](./20100713-0107-interleave.jpg)
 I used a custom scan script that sent all of the Y data, then all Cb,
 then all Cr. Its custom scan script was just this:
 
-```bash
+{{<highlight text>}}
 0;
 1;
 2;
-```
+{{< / highlight >}}
+
 
 While not every browser may do this right, most browsers will render
 the greyscale as its comes in, then add color to it one plane at a
 time. It'll be more obvious over a slower connection; I purposely left
 the image fairly large so that the transfer would be slower.  You'll
 note as well that the greyscale arrives much more slowly than the
-color.
+color.  (2020 note: most browsers will now let you use their
+development tools to simulate a slow connection if you really want to
+see.)
 
 Code & Utilities
 ================
@@ -179,16 +184,18 @@ The **cjpeg** tool from libjpeg will (among other things) create a
 JPEG using a custom scan script. Combined with ImageMagick, I used a
 command like:
 
-```bash
+{{<highlight bash>}}
 convert input.png ppm:- | cjpeg -quality 95 -optimize -scans scan_script > output.jpg
-```
+{{< / highlight >}}
+
 
 Or if the input is already a JPEG, `jpegtran` will do the same
 thing, losslessly (as it's merely reordering coefficients):
 
-```bash
+{{<highlight bash>}}
 jpegtran -scans scan_script input.jpg > output.jpg
-```
+{{< / highlight >}}
+
 
 libjpeg has some interesting features as well. Rather than decoding an
 entire full-resolution JPEG and then scaling it down, for instance (a
@@ -197,7 +204,7 @@ decoding so that it will simply do the reduction for you while
 decoding. This takes less time and uses less memory compared with
 getting the full decompressed version and resampling afterward.
 
-The C code below (or [here](../images/obscure_jpeg_features) or this
+The C code below (or [here](./jpeg_split.c) or this
 [gist](https://gist.github.com/9220146)), based loosely on `example.c`
 from libjpeg, will split up a multi-scan JPEG into a series of
 numbered PPM files, each one containing a scan. Look for
@@ -207,7 +214,7 @@ processes as much input JPEG as it needs for the next scan. (It needs
 nothing special to build besides a functioning libjpeg. `gcc -ljpeg -o
 jpeg_split.o jpeg_split.c` works for me.)
 
-```c
+{{<highlight c>}}
 // jpeg_split.c: Write each scan from a multi-scan/progressive JPEG.
 // This is based loosely on example.c from libjpeg, and should require only
 // libjpeg as a dependency (e.g. gcc -ljpeg -o jpeg_split.o jpeg_split.c).
@@ -342,20 +349,20 @@ void read_scan(struct jpeg_decompress_struct * cinfo,
     jpeg_finish_output(cinfo);
     fclose(outfile);
 }
-```
+{{< / highlight >}}
 
 Examples
 ========
 
 Here are all 10 scans from a standard progressive JPEG, separated out with the example code:
 
-![Scan 1](../images//obscure_jpeg_features/cropphoto1.png)
-![Scan 2](../images//obscure_jpeg_features/cropphoto2.png)
-![Scan 3](../images//obscure_jpeg_features/cropphoto3.png)
-![Scan 4](../images//obscure_jpeg_features/cropphoto4.png)
-![Scan 5](../images//obscure_jpeg_features/cropphoto5.png)
-![Scan 6](../images//obscure_jpeg_features/cropphoto6.png)
-![Scan 7](../images//obscure_jpeg_features/cropphoto7.png)
-![Scan 8](../images//obscure_jpeg_features/cropphoto8.png)
-![Scan 9](../images//obscure_jpeg_features/cropphoto9.png)
-![Scan 10](../images//obscure_jpeg_features/cropphoto10.png)
+![Scan 1](./cropphoto1.png)
+![Scan 2](./cropphoto2.png)
+![Scan 3](./cropphoto3.png)
+![Scan 4](./cropphoto4.png)
+![Scan 5](./cropphoto5.png)
+![Scan 6](./cropphoto6.png)
+![Scan 7](./cropphoto7.png)
+![Scan 8](./cropphoto8.png)
+![Scan 9](./cropphoto9.png)
+![Scan 10](./cropphoto10.png)

hugo_blag/content/posts/2011-11-24-obscure-features-of-jpeg/jpeg_split.c

@@ -0,0 +1,134 @@
+// jpeg_split.c: Write each scan from a multi-scan/progressive JPEG.
+// This is based loosely on example.c from libjpeg, and should require only
+// libjpeg as a dependency (e.g. gcc -ljpeg -o jpeg_split.o jpeg_split.c).
+#include <stdio.h>
+#include <jerror.h>
+#include "jpeglib.h"
+#include <setjmp.h>
+#include <string.h>
+
+void read_scan(struct jpeg_decompress_struct * cinfo,
+               JSAMPARRAY buffer,
+               char * base_output);
+int read_JPEG_file (char * filename, int scanNumber, char * base_output);
+
+int main(int argc, char **argv) {
+    if (argc < 3) {
+        printf("Usage: %s <Input JPEG> <Output base name>\n", argv[0]);
+        printf("This reads in the progressive/multi-scan JPEG given and writes out each scan\n");
+        printf("to a separate PPM file, named with the scan number.\n");
+        return 1;
+    }
+
+    char * fname = argv[1];
+    char * out_base = argv[2];
+    read_JPEG_file(fname, 1, out_base);
+    return 0;
+}
+
+struct error_mgr {
+    struct jpeg_error_mgr pub;
+    jmp_buf setjmp_buffer;
+};
+
+METHODDEF(void) error_exit (j_common_ptr cinfo) {
+    struct error_mgr * err = (struct error_mgr *) cinfo->err;
+    (*cinfo->err->output_message) (cinfo);
+    longjmp(err->setjmp_buffer, 1);
+}
+
+int read_JPEG_file (char * filename, int scanNumber, char * base_output) {
+    struct jpeg_decompress_struct cinfo;
+    struct error_mgr jerr;
+    FILE * infile;      /* source file */
+    JSAMPARRAY buffer;  /* Output row buffer */
+    int row_stride;     /* physical row width in output buffer */
+
+    if ((infile = fopen(filename, "rb")) == NULL) {
+        fprintf(stderr, "can't open %s\n", filename);
+        return 0;
+    }
+
+    // Set up the normal JPEG error routines, then override error_exit.
+    cinfo.err = jpeg_std_error(&jerr.pub);
+    jerr.pub.error_exit = error_exit;
+    // Establish the setjmp return context for error_exit to use:
+    if (setjmp(jerr.setjmp_buffer)) {
+        jpeg_destroy_decompress(&cinfo);
+        fclose(infile);
+        return 0;
+    }
+    jpeg_create_decompress(&cinfo);
+    jpeg_stdio_src(&cinfo, infile);
+    (void) jpeg_read_header(&cinfo, TRUE);
+
+    // Set some decompression parameters
+
+    // Incremental reading requires this flag:
+    cinfo.buffered_image = TRUE;
+    // To perform fast scaling in the output, set these:
+    cinfo.scale_num = 1;
+    cinfo.scale_denom = 1;
+
+    // Decompression begins...
+    (void) jpeg_start_decompress(&cinfo);
+
+    printf("JPEG is %s-scan\n", jpeg_has_multiple_scans(&cinfo) ? "multi" : "single");
+    printf("Outputting %ix%i\n", cinfo.output_width, cinfo.output_height);
+
+    // row_stride = JSAMPLEs per row in output buffer
+    row_stride = cinfo.output_width * cinfo.output_components;
+    // Make a one-row-high sample array that will go away when done with image
+    buffer = (*cinfo.mem->alloc_sarray)
+        ((j_common_ptr) &cinfo, JPOOL_IMAGE, row_stride, 1);
+
+    // Start actually handling image data!
+    while(!jpeg_input_complete(&cinfo)) {
+        read_scan(&cinfo, buffer, base_output);
+    }
+
+    // Clean up.
+    (void) jpeg_finish_decompress(&cinfo);
+    jpeg_destroy_decompress(&cinfo);
+    fclose(infile);
+
+    if (jerr.pub.num_warnings) {
+        printf("libjpeg indicates %i warnings\n", jerr.pub.num_warnings);
+    }
+}
+
+void read_scan(struct jpeg_decompress_struct * cinfo,
+               JSAMPARRAY buffer,
+               char * base_output)
+{
+    char out_name[1024];
+    FILE * outfile = NULL;
+    int scan_num = 0;
+
+    scan_num = cinfo->input_scan_number;
+    jpeg_start_output(cinfo, scan_num);
+
+    // Read up to the next scan.
+    int status;
+    do {
+        status = jpeg_consume_input(cinfo);
+    } while (status != JPEG_REACHED_SOS && status != JPEG_REACHED_EOI);
+
+    // Construct a filename & write PPM image header.
+    snprintf(out_name, 1024, "%s%i.ppm", base_output, scan_num);
+    if ((outfile = fopen(out_name, "wb")) == NULL) {
+        fprintf(stderr, "Can't open %s for writing!\n", out_name);
+        return;
+    }
+    fprintf(outfile, "P6\n%d %d\n255\n", cinfo->output_width, cinfo->output_height);
+
+    // Read each scanline into 'buffer' and write it to the PPM.
+    // (Note that libjpeg updates cinfo->output_scanline automatically)
+    while (cinfo->output_scanline < cinfo->output_height) {
+        jpeg_read_scanlines(cinfo, buffer, 1);
+        fwrite(buffer[0], cinfo->output_components, cinfo->output_width, outfile);
+    }
+
+    jpeg_finish_output(cinfo);
+    fclose(outfile);
+}

hugo_blag/content/posts/2011-11-24-obscure-features-of-jpeg/libjpeg-wizard.txt

@@ -0,0 +1,211 @@
+Advanced usage instructions for the Independent JPEG Group's JPEG software
+==========================================================================
+
+This file describes cjpeg's "switches for wizards".
+
+The "wizard" switches are intended for experimentation with JPEG by persons
+who are reasonably knowledgeable about the JPEG standard.  If you don't know
+what you are doing, DON'T USE THESE SWITCHES.  You'll likely produce files
+with worse image quality and/or poorer compression than you'd get from the
+default settings.  Furthermore, these switches must be used with caution
+when making files intended for general use, because not all JPEG decoders
+will support unusual JPEG parameter settings.
+
+
+Quantization Table Adjustment
+-----------------------------
+
+Ordinarily, cjpeg starts with a default set of tables (the same ones given
+as examples in the JPEG standard) and scales them up or down according to
+the -quality setting.  The details of the scaling algorithm can be found in
+jcparam.c.  At very low quality settings, some quantization table entries
+can get scaled up to values exceeding 255.  Although 2-byte quantization
+values are supported by the IJG software, this feature is not in baseline
+JPEG and is not supported by all implementations.  If you need to ensure
+wide compatibility of low-quality files, you can constrain the scaled
+quantization values to no more than 255 by giving the -baseline switch.
+Note that use of -baseline will result in poorer quality for the same file
+size, since more bits than necessary are expended on higher AC coefficients.
+
+You can substitute a different set of quantization values by using the
+-qtables switch:
+
+	-qtables file	Use the quantization tables given in the named file.
+
+The specified file should be a text file containing decimal quantization
+values.  The file should contain one to four tables, each of 64 elements.
+The tables are implicitly numbered 0,1,etc. in order of appearance.  Table
+entries appear in normal array order (NOT in the zigzag order in which they
+will be stored in the JPEG file).
+
+Quantization table files are free format, in that arbitrary whitespace can
+appear between numbers.  Also, comments can be included: a comment starts
+with '#' and extends to the end of the line.  Here is an example file that
+duplicates the default quantization tables:
+
+	# Quantization tables given in JPEG spec, section K.1
+
+	# This is table 0 (the luminance table):
+	  16  11  10  16  24  40  51  61
+	  12  12  14  19  26  58  60  55
+	  14  13  16  24  40  57  69  56
+	  14  17  22  29  51  87  80  62
+	  18  22  37  56  68 109 103  77
+	  24  35  55  64  81 104 113  92
+	  49  64  78  87 103 121 120 101
+	  72  92  95  98 112 100 103  99
+
+	# This is table 1 (the chrominance table):
+	  17  18  24  47  99  99  99  99
+	  18  21  26  66  99  99  99  99
+	  24  26  56  99  99  99  99  99
+	  47  66  99  99  99  99  99  99
+	  99  99  99  99  99  99  99  99
+	  99  99  99  99  99  99  99  99
+	  99  99  99  99  99  99  99  99
+	  99  99  99  99  99  99  99  99
+
+If the -qtables switch is used without -quality, then the specified tables
+are used exactly as-is.  If both -qtables and -quality are used, then the
+tables taken from the file are scaled in the same fashion that the default
+tables would be scaled for that quality setting.  If -baseline appears, then
+the quantization values are constrained to the range 1-255.
+
+By default, cjpeg will use quantization table 0 for luminance components and
+table 1 for chrominance components.  To override this choice, use the -qslots
+switch:
+
+	-qslots N[,...]		Select which quantization table to use for
+				each color component.
+
+The -qslots switch specifies a quantization table number for each color
+component, in the order in which the components appear in the JPEG SOF marker.
+For example, to create a separate table for each of Y,Cb,Cr, you could
+provide a -qtables file that defines three quantization tables and say
+"-qslots 0,1,2".  If -qslots gives fewer table numbers than there are color
+components, then the last table number is repeated as necessary.
+
+
+Sampling Factor Adjustment
+--------------------------
+
+By default, cjpeg uses 2:1 horizontal and vertical downsampling when
+compressing YCbCr data, and no downsampling for all other color spaces.
+You can override this default with the -sample switch:
+
+	-sample HxV[,...]	Set JPEG sampling factors for each color
+				component.
+
+The -sample switch specifies the JPEG sampling factors for each color
+component, in the order in which they appear in the JPEG SOF marker.
+If you specify fewer HxV pairs than there are components, the remaining
+components are set to 1x1 sampling.  For example, the default YCbCr setting
+is equivalent to "-sample 2x2,1x1,1x1", which can be abbreviated to
+"-sample 2x2".
+
+There are still some JPEG decoders in existence that support only 2x1
+sampling (also called 4:2:2 sampling).  Compatibility with such decoders can
+be achieved by specifying "-sample 2x1".  This is not recommended unless
+really necessary, since it increases file size and encoding/decoding time
+with very little quality gain.
+
+
+Multiple Scan / Progression Control
+-----------------------------------
+
+By default, cjpeg emits a single-scan sequential JPEG file.  The
+-progressive switch generates a progressive JPEG file using a default series
+of progression parameters.  You can create multiple-scan sequential JPEG
+files or progressive JPEG files with custom progression parameters by using
+the -scans switch:
+
+	-scans file	Use the scan sequence given in the named file.
+
+The specified file should be a text file containing a "scan script".
+The script specifies the contents and ordering of the scans to be emitted.
+Each entry in the script defines one scan.  A scan definition specifies
+the components to be included in the scan, and for progressive JPEG it also
+specifies the progression parameters Ss,Se,Ah,Al for the scan.  Scan
+definitions are separated by semicolons (';').  A semicolon after the last
+scan definition is optional.
+
+Each scan definition contains one to four component indexes, optionally
+followed by a colon (':') and the four progressive-JPEG parameters.  The
+component indexes denote which color component(s) are to be transmitted in
+the scan.  Components are numbered in the order in which they appear in the
+JPEG SOF marker, with the first component being numbered 0.  (Note that these
+indexes are not the "component ID" codes assigned to the components, just
+positional indexes.)
+
+The progression parameters for each scan are:
+	Ss	Zigzag index of first coefficient included in scan
+	Se	Zigzag index of last coefficient included in scan
+	Ah	Zero for first scan of a coefficient, else Al of prior scan
+	Al	Successive approximation low bit position for scan
+If the progression parameters are omitted, the values 0,63,0,0 are used,
+producing a sequential JPEG file.  cjpeg automatically determines whether
+the script represents a progressive or sequential file, by observing whether
+Ss and Se values other than 0 and 63 appear.  (The -progressive switch is
+not needed to specify this; in fact, it is ignored when -scans appears.)
+The scan script must meet the JPEG restrictions on progression sequences.
+(cjpeg checks that the spec's requirements are obeyed.)
+
+Scan script files are free format, in that arbitrary whitespace can appear
+between numbers and around punctuation.  Also, comments can be included: a
+comment starts with '#' and extends to the end of the line.  For additional
+legibility, commas or dashes can be placed between values.  (Actually, any
+single punctuation character other than ':' or ';' can be inserted.)  For
+example, the following two scan definitions are equivalent:
+	0 1 2: 0 63 0 0;
+	0,1,2 : 0-63, 0,0 ;
+
+Here is an example of a scan script that generates a partially interleaved
+sequential JPEG file:
+
+	0;			# Y only in first scan
+	1 2;			# Cb and Cr in second scan
+
+Here is an example of a progressive scan script using only spectral selection
+(no successive approximation):
+
+	# Interleaved DC scan for Y,Cb,Cr:
+	0,1,2: 0-0,   0, 0 ;
+	# AC scans:
+	0:     1-2,   0, 0 ;	# First two Y AC coefficients
+	0:     3-5,   0, 0 ;	# Three more
+	1:     1-63,  0, 0 ;	# All AC coefficients for Cb
+	2:     1-63,  0, 0 ;	# All AC coefficients for Cr
+	0:     6-9,   0, 0 ;	# More Y coefficients
+	0:     10-63, 0, 0 ;	# Remaining Y coefficients
+
+Here is an example of a successive-approximation script.  This is equivalent
+to the default script used by "cjpeg -progressive" for YCbCr images:
+
+	# Initial DC scan for Y,Cb,Cr (lowest bit not sent)
+	0,1,2: 0-0,   0, 1 ;
+	# First AC scan: send first 5 Y AC coefficients, minus 2 lowest bits:
+	0:     1-5,   0, 2 ;
+	# Send all Cr,Cb AC coefficients, minus lowest bit:
+	# (chroma data is usually too small to be worth subdividing further;
+	#  but note we send Cr first since eye is least sensitive to Cb)
+	2:     1-63,  0, 1 ;
+	1:     1-63,  0, 1 ;
+	# Send remaining Y AC coefficients, minus 2 lowest bits:
+	0:     6-63,  0, 2 ;
+	# Send next-to-lowest bit of all Y AC coefficients:
+	0:     1-63,  2, 1 ;
+	# At this point we've sent all but the lowest bit of all coefficients.
+	# Send lowest bit of DC coefficients
+	0,1,2: 0-0,   1, 0 ;
+	# Send lowest bit of AC coefficients
+	2:     1-63,  1, 0 ;
+	1:     1-63,  1, 0 ;
+	# Y AC lowest bit scan is last; it's usually the largest scan
+	0:     1-63,  1, 0 ;
+
+It may be worth pointing out that this script is tuned for quality settings
+of around 50 to 75.  For lower quality settings, you'd probably want to use
+a script with fewer stages of successive approximation (otherwise the
+initial scans will be really bad).  For higher quality settings, you might
+want to use more stages of successive approximation (so that the initial
+scans are not too large).

hugo_blag/content/posts/2018-04-08-recommender-systems-1/index.md

@@ -852,7 +852,7 @@ C & =M^\top M \\
 D &= \left(M^\top U - (M^\top U)^\top\right) /\ \textrm{max}(1, M^\top M)
 \end{align}
 $$
-</pre>
+</div>
 
 where $/$ is Hadamard (i.e. elementwise) division, and $\textrm{max}$ is elementwise maximum with 1.  Then, the below gives the prediction for how user $u$ will rate movie $j$:
 
@@ -860,7 +860,7 @@ where $/$ is Hadamard (i.e. elementwise) division, and $\textrm{max}$ is element
 $$
 P(u)_j = \frac{[M_u \odot (C_j > 0)] \cdot (D_j + U_u) - U_{u,j}}{M_u \cdot (C_j > 0)}
 $$
-</pre>
+</div>
 
 $D_j$ and $C_j$ are row $j$ of $D$ and $C$, respectively. $M_u$ and $U_u$ are column $u$ of $M$ and $U$, respectively. $\odot$ is elementwise multiplication.
 
@@ -891,7 +891,7 @@ S_{j,i}(\chi)} u_j - u_i = \frac{1}{card(S_{j,i}(\chi))}\left(\sum_{u
 \in S_{j,i}(\chi)} u_j - \sum_{u \in S_{j,i}(\chi)} u_i\right)
 \end{split}
 $$
-</pre>
+</div>
 
 where:
 
@@ -930,7 +930,7 @@ matrix multiplication:
 
 <div>
 $$C=M^\top M$$
-</pre>
+</div>
 
 since $C\_{i,j}=card(S\_{j,i}(\chi))$ is the dot product of row $i$ of $M^T$ - which is column
 $i$ of $M$ - and column $j$ of $M$.
@@ -940,7 +940,7 @@ We still need the other half:
 
 <div>
 $$\sum_{u \in S_{j,i}(\chi)} u_j - \sum_{u \in S_{j,i}(\chi)} u_i$$
-</pre>
+</div>
 
 We can apply a similar trick here.  Consider first what $\sum\_{u \in
 S\_{j,i}(\chi)} u\_j$ means: It is the sum of only those ratings of
@@ -958,7 +958,7 @@ $M\_j$ (consider the definition of $M\_j$) computes this, and so:
 
 <div>
 $$\sum_{u \in S_{j,i}(\chi)} u_j = M_i \cdot U_j$$
-</pre>
+</div>
 
 and as with $C$, since we want every pairwise dot product, this summation just
 equals element $(i,j)$ of $M^\top U$. The other half of the summation,
@@ -967,13 +967,13 @@ the transpose of this matrix:
 
 <div>
 $$\sum_{u \in S_{j,i}(\chi)} u_j - \sum_{u \in S_{j,i}(\chi)} u_i = M^\top U - (M^\top U)^\top = M^\top U - U^\top M$$
-</pre>
+</div>
 
 So, finally, we can compute an entire deviation matrix at once like:
 
 <div>
 $$D = \left(M^\top U - (M^\top U)^\top\right) /\ M^\top M$$
-</pre>
+</div>
 
 where $/$ is Hadamard (i.e. elementwise) division, and $D\_{j,i} = \textrm{dev}\_{j,i}$.
 
@@ -987,7 +987,7 @@ Finally, the paper gives the formula to predict how user $u$ will rate movie $j$
 $$
 P(u)_j = \frac{1}{card(R_j)}\sum_{i\in R_j} \left(\textrm{dev}_{j,i}+u_i\right) = \frac{1}{card(R_j)}\sum_{i\in R_j} \left(D_{j,i} + U_{u,j} \right)
 $$
-</pre>
+</div>
 
 where $R\_j = \{i | i \in S(u), i \ne j, card(S\_{j,i}(\chi)) > 0\}$, and $S(u)$ is the set of movies that user $u$ has rated. To unpack the paper's somewhat dense notation, the summation is over every movie $i$ that user $u$ rated and that at least one other user rated, except movie $j$.
 
@@ -995,7 +995,7 @@ We can apply the usual trick yet one more time with a little effort. The summati
 
 <div>
 $$P(u)_j = \frac{[M_u \odot (C_j > 0)] \cdot (D_j + U_u) - U_{u,j}}{M_u \cdot (C_j > 0)}$$
-</pre>
+</div>
 
 #### 5.2.2.4. Approximation
 
@@ -1003,7 +1003,7 @@ The paper also gives a formula that is a suitable approximation for larger data
 
 <div>
 $$p^{S1}(u)_j = \bar{u} + \frac{1}{card(R_j)}\sum_{i\in R_j} \textrm{dev}_{j,i}$$
-</pre>
+</div>
 
 where $\bar{u}$ is user $u$'s average rating. This doesn't change the formula much; we can compute $\bar{u}$ simply as column means of $U$.
 
@@ -1169,7 +1169,7 @@ In that sense, $P$ and $Q$ give us a model in which ratings are an interaction b
 
 <div>
 $$\hat{r}_{ui}=q_i^\top p_u$$
-</pre>
+</div>
 
 However, some things aren't really interactions. Some movies are just (per the ratings) overall better or worse. Some users just tend to rate everything higher or lower. We need some sort of bias built into the model to comprehend this.
 
@@ -1177,7 +1177,7 @@ Let's call $b_i$ the bias for movie $i$, $b_u$ the bias for user $u$, and $\mu$
 
 <div>
 $$\hat{r}_{ui}=\mu + b_i + b_u + q_i^\top p_u$$
-</pre>
+</div>
 
 This is the basic model we'll implement, and the same one described in the references at the top.
 
@@ -1187,7 +1187,7 @@ More formally, the prediction model is:
 
 <div>
 $$\hat{r}_{ui}=\mu + b_i + b_u + q_i^\top p_u$$
-</pre>
+</div>
 
 where:
 
@@ -1215,7 +1215,7 @@ $$
 \frac{\partial E}{\partial b_i} &= 2 \sum_{r_{ui}} \left(\lambda b_i + r_{ui} - \hat{r}_{ui}\right)
 \end{split}
 $$
-</pre>
+</div>
 
 Gradient with respect to $p_u$ proceeds similarly:
 
@@ -1229,7 +1229,7 @@ p_u}q_i^\top p_u \right) + 2 \lambda p_u \\
 \frac{\partial E}{\partial p_u} &= 2 \sum_{r_{ui}} \lambda p_u - \left(r_{ui} - \hat{r}_{ui}\right)q_i^\top
 \end{split}
 $$
-</pre>
+</div>
 
 Gradient with respect to $b\_u$ is identical form to $b\_i$, and gradient with respect to $q\_i$ is identical form to $p\_u$, except that the variables switch places.  The full gradients then have the standard form for gradient descent, i.e. a summation of a gradient term for each individual data point, so they turn easily into update rules for each parameter (which match the ones in the Surprise link) after absorbing the leading 2 into learning rate $\gamma$ and separating out the summation over each data point. That's given below, with $e\_{ui}=r\_{ui} - \hat{r}\_{ui}$:
 
@@ -1242,7 +1242,7 @@ $$
 \frac{\partial E}{\partial q_i} &= 2 \sum_{r_{ui}} \lambda q_i - e_{ui}p_u^\top\ \ \ &\longrightarrow q_i' &= q_i - \gamma\frac{\partial E}{\partial q_i} &= q_i + \gamma\left(e_{ui}p_u - \lambda q_i \right) \\
 \end{split}
 $$
-</pre>
+</div>
 
 The code below is a direct implementation of this by simply iteratively applying the above equations for each data point - in other words, stochastic gradient descent.
 

hugo_blag/content/posts/2018-04-13-opinions-go.org

@@ -20,20 +20,21 @@ compilation, namespaces, multiple return values, packages, a mostly
 sane build system, no C preprocessor, *minimal* object-oriented
 support, interfaces, anonymous functions, and closures.  Those aren't
 trivialities; they're all rather great things.  They're all missing in
-C and C++ (for the most part). They're all such common problems that
-nearly every "practical" C/C++ project uses a lot of ad-hoc solutions
-sitting both inside and outside the language - libraries, abuse of
-macros, more extensive code generation, lots of tooling, and a whole
-lot of "best practices" slavishly followed - to try to solve them.
-(No, I don't want to hear about how this lack of very basic features
-is actually a feature.  No, I don't want to hear about how
-painstakingly fucking around with pointers is the hairshirt that we
-all must wear if we wish for our software to achieve a greater state
-of piety than is accessible to high-level languages.  No, I don't want
-to hear about how ~$arbitrary_abstraction_level~ is the level that
-*real* programmers work at, any programmer who works above that level
-is a loser, and any programmer who works below that level might as
-well be building toasters. Shut up.)
+C and C++ (for the most part - excluding that C++11 has started
+incorporating some). They're all such common problems that nearly
+every "practical" C/C++ project uses a lot of ad-hoc solutions sitting
+both inside and outside the language - libraries, abuse of macros,
+more extensive code generation, lots of tooling, and a whole lot of
+"best practices" slavishly followed - to try to solve them.  (No, I
+don't want to hear about how this lack of very basic features is
+actually a feature.  No, I don't want to hear about how painstakingly
+fucking around with pointers is the hairshirt that we all must wear if
+we wish for our software to achieve a greater state of piety than is
+accessible to high-level languages.  No, I don't want to hear about
+how ~$arbitrary_abstraction_level~ is the level that *real*
+programmers work at, any programmer who works above that level is a
+loser, and any programmer who works below that level might as well be
+building toasters. Shut up.)
 
 I'm a functional programming nerd. I just happen to also have a lot of
 experience being knee-deep in C and C++ code.  I'm looking at Go from
@@ -53,13 +54,12 @@ less transparently.
 
 Concurrency was made a central aim in this language.  If you've not
 watched Rob Pike's [[https://blog.golang.org/concurrency-is-not-parallelism][Concurrency is not parallelism]] talk, go do it now.
-While it's perhaps not my favorite approach to concurrency.  While I
-may not be a fan of the style of concurrency that it uses (based on
-[[https://en.wikipedia.org/wiki/Communicating_sequential_processes][CSP]] rather than the more Erlang-ian message passing), this is still a
-far superior style to the very popular concurrency paradigm of
-Concurrency Is Easy, We'll Just Ignore It Now and Duct-Tape the
-Support On Later.  [[http://jordanorelli.com/post/31533769172/why-i-went-from-python-to-go-and-not-nodejs][Why I went from Python to Go (and not node.js)]], in
-my opinion, is spot-on.
+While I may not be a fan of the style of concurrency that it uses
+(based on [[https://en.wikipedia.org/wiki/Communicating_sequential_processes][CSP]] rather than the more Erlang-ian message passing), this
+is still a far superior style to the very popular concurrency paradigm
+of Concurrency Is Easy, We'll Just Ignore It Now and Duct-Tape the
+Support On Later, How Hard Could It Possibly Be.  [[http://jordanorelli.com/post/31533769172/why-i-went-from-python-to-go-and-not-nodejs][Why I went from
+Python to Go (and not node.js)]], in my opinion, is spot-on.
 
 Many packages are available for it, and from all I've seen, they are
 sensible packages - not [[https://www.reddit.com/r/programming/comments/4bjss2/an_11_line_npm_package_called_leftpad_with_only/][leftpad]]-style idiocy.  I'm sure that if I look
@@ -92,7 +92,11 @@ system is also still very limited - particularly, things like the lack
 of any parametric polymorphism.  I'd probably prefer something more
 like in [[https://www.rust-lang.org][Rust]].  I know this was largely intentional as well: Go was
 designed for people who don't want a more powerful type system, but do
-want types.
+want types, and further, to support this kind of polymorphism involves
+tradeoffs it looks like they were avoiding, like those Russ Cox gives
+in [[https://research.swtch.com/generic][The Generic Dilemma]].  (Later note: the [[https://github.com/golang/proposal/blob/master/design/go2draft-contracts.md][Contracts - Draft Design]]
+proposal for Go 2 offers a possible approach for parametric
+polymorphism.)
 
 My objections aren't unique. [[https://www.teamten.com/lawrence/writings/why-i-dont-like-go.html][Ten Reasons Why I Don't Like Golang]] and
 [[http://yager.io/programming/go.html][Why Go Is Not Good]] have criticisms I can't really disagree with.