Tuesday, July 26, 2016

Characters 128 to 255 & Python

Ingredients: Windows 10, Python 2.7.12, Python 3.5.2, integers 128 to 255, various character sets, various fonts.

chr128.py

a = range (128, 256)
v = (min (a), max (a)) * 2
print ("Characters %d to %d (hex %X to %X) via chr() & unichr() ..." % v)
print ("".join (map (   chr, a)))  #    chr: Python 2 or 3
print ("".join (map (unichr, a)))  # unichr: Python 2 only

chr160.py

a = range (160, 256)
v = (min (a), max (a)) * 2
print ("Characters %d to %d (hex %X to %X) via chr() & unichr() ..." % v)
print ("".join (map (   chr, a)))  #    chr: Python 2 or 3
print ("".join (map (unichr, a)))  # unichr: Python 2 only

Snapshots

(01) x 20-7F Character Map -- ASCII.png
(02) x 20-FF Character Map -- DOS 850.png
(03) x 20-FF Character Map -- Windows 1252.png
(04) x 80-FF Console Python 2 chr128.png
(05) x 80-FF Console Python 3 chr128.png
(06) x A0-FF Console Python 2 chr160.png
(07) x A0-FF Console Python 3 chr160.png
(08) IDLE Python 2 results.png
(09) IDLE Python 3 results.png
(10) u 0080-00FF Consolas.png
(11) u 0080-00FF Unifont.png
(12) u FF80-FFFF Unifont.png
(13) u FF80-FFFF Arial Unicode MS.png
(14) u FF80-FFFF Consolas.png

Tuesday, November 24, 2015

Bi-Linear Interpolation

Messing around with bilinear interpolation ...

Suppose that you have a data-set, provided as a rectangular grid of numeric values.

For example, terrain heights [metres above sea level] are given at kilometre intervals (in the east and north dimensions).

The problem is to estimate the value at any "in-between" point.

Bilinear interpolation is quite appealing. Your point lies somewhere within a rectangle whose corner values are known. Through your point, draw parallels to the grid, making 4 sub-rectangles. Consider any one of these sub-rectangles. The larger its area, the smaller the area of the diagonally opposed sub-rectangle. And that other sub-rectangle contains a corner value whose relevance must therefore increase.

That's about it! The relative areas of the 4 sub-rectangles act as weights (or levities) on the 4 corner values. (Weights or levities, depending on your point of view.)

Using the R language environment, I wrote a routine for bilinear interpolation, and soon had the idea of using color values to display its workings.

unit.square.bilinear <- function (x, y, corner.values) {
  X <- c (1 - x, x)
  Y <- c (1 - y, y)
  sum (corner.values * outer (X, Y))
}

interpolation <- function (corner.values) {
  Vectorize (function (x, y) {
    unit.square.bilinear (x, y, corner.values)
  })
}
But how, exactly? Consider a rectangle with corner values < black, red, green, blue >. That seems particularly straight-forward, given that our screens have red, green, and blue pixels.

Using bilinear interpolation, I calculated the red, green, and blue components. Then I began drawing with R's image function. The 3 component bands could be drawn separately (and in any palette), but there was apparently no way of combining them. So I temporarily resorted to writing the bands to an image file ...

Eventually, I found that R's rasterImage function provided the intrinsic means. Here is the raster for the black-red-green-blue rectangle:

     [,1]      [,2]      [,3]      [,4]      [,5]     
[1,] "#00ff00" "#00bf40" "#008080" "#0040bf" "#0000ff"
[2,] "#00aa00" "#15802a" "#2b5555" "#402a80" "#5500aa"
[3,] "#005500" "#2b4015" "#552a2a" "#801540" "#aa0055"
[4,] "#000000" "#400000" "#800000" "#bf0000" "#ff0000"
The rasterImage function even offers to perform its own interpolation — look for smooth = TRUE in the image titles.

Saturday, October 3, 2015

Coin toss program

In the previous post, Coin toss math, I considered a fair coin and sketched demonstrations for some Average Wait problems. The expected values were 2 for H, 4 for HT, and 6 for HH. And using a symmetry or relabelling argument, the average waits would be 2 for T, 4 for TH, and 6 for TT.

The difference between HT (2+2=4) and HH (6) is baffling at first. Toss a coin twice, and the possibilities are {TT, TH, HT, HH}. So why is the expected wait for HH not 4? In various ways, that issue was addressed in the post.

Now look at the sequence TTHTHHHHTHTTH. The waits are <3,2,1,1,1,2,3> for H, <4,5,2,?> for HT, and <6,2,?> for HH. In the images that follow, I display a program that examines a very long sequence of 'coin tosses', then prints a summary and plots graphs.

Image 1: This is an R program. Its first part defines a function named WAITS. I have avoided explicit looping as far as possible. In line 8, the sample function returns a vector of tosses, all at once. Waits for H and HT are then calculated with straight-forward vector manipulations. Calculating HH involves several steps and needs a for-loop to perform re-assignments.

Image 2: The second part of the program uses the WAITS function, prints a summary, and plots histograms that indicate the probability distributions. (The histograms are for discrete data, so should perhaps be called "bar graphs" — whatever.)

Image 3: A view of the R console: the R program is run twice.

Image 4: Histogram for H (average wait = 2.0051)
Image 5: Histogram for HT (average wait = 4.0124)
Image 6: Histogram for HH (average wait = 5.9977)

Sunday, September 27, 2015

Coin toss math

I was reading David Williams' unusual book Weighing the Odds, subtitled A Course in Probability and Statistics (Cambridge University Press, 2001).

Williams is a probability theorist, and so the ultimate in rigour is his game. But this book is "introductory" and teaches in an interesting ("fun") way. Something called measure theory, the foundation of probability, is considered too sophisticated to present, except as results.

Meanwhile, Williams freely acknowledges that there are many wiser minds than his in the field of statistics. The preface opens with this sentence:

Probability and Statistics used to be married; then they separated; then they got divorced; now they hardly ever see each other.

Discussing the use of computers (back in 2001 at the latest), he displays a 1-page C program (not a pretty sight) and a page of its results. The program simulates the "Average Wait for HH for fair coin"; its results indicate that to be very near 6. H is Heads and T is Tails. For example, in the sequence TTHTHH the wait for HH is 6.

So I decided to write a similar program in R ... aiming at the same target, but using R's abundant facilities to deploy a neater method, and to yield a more focussed program text. More on that in a future post (probably) ...

* * *

In the images that follow, I have sketched demonstrations for some Average Wait problems: H, HH, HT. Finding the underlying equational method somewhere on the web, I was duly amazed by its elegance. For this method I have devised diagrams that should make every detail clear. The expected number of tosses is shown as x on the diagrams and in the equations.

Warning: By way of experiment, additional demonstrations are provided for HH and HT, using an auxiliary expected value y. Due to the entanglement of x and y, these are murky. On the HH diagram, at the HT node, what exactly does (2+(1+y)) represent? Suggestion: (1+y) means "do not get T immediately after that given H", while adding 2 means "and now get a new H to replace that wasted H".

Monday, April 20, 2015

Thursday, February 26, 2015