Programmatic Mathematica XVII: The Collatz Conjecture

There has been a lot of interest recently in the Collatz Conjecture. A lot of video blogs are going into it, particularly Numberphile, a vlog present on YouTube. It might have something to do with the fact that this year is the 70th anniversary of the conjecture. It is a simple idea, easy enough for a child to understand. Yet, it has been difficult enough that no one has been able to either prove or disprove it to this day.

The Collatz Conjecture is the hunch, or guess, or idea, that performing a certain recursive operation on any positive integer leads to the inevitable result that repeated operations on all successors will lead to the number 1. After that, the sequence of {1, 4, 2, …} occurs in an infinite repetition.

This problem was first posed by Lothar Collatz in 1937. The reason it is only a conjecture is that no one has been able to prove it for all positive integers. It is only conjectured to work as such. Over the past seventy years, no one has been able to furnish a counterexample where the number 1 is not reached. So by now, we’re “pretty sure” Collatz is correct for all positive integers.

I thought of some Mathematica code to write for this. The algorithm would go something like:

  1. Precondition: n > 0; n \in Z
  2. If n is 1, return 1 and exit
  3. If n is even, return n/2
  4. If n is odd, return 3n + 1
  5. Go back to line 2.

Like Fermat’s Last Theorem, which has been proved once and for all in 1995 by Professor Andrew Wiles, and aided by Richard Taylor, the Collatz Conjecture is simple enough to describe to any lay person (as I just did), but its proof has eluded us.

The application of the above algorithm to Mathematica code involves some new syntax. Sow[n] acts as a kind of array for anyone who doesn’t want to declare and implement an array. I would suppose that the programmers of the Mathematica language didn’t see the need for an array for many implementations, such as sequences of numbers. If you want to generate a sequence, you want the numbers in order from some lower bound, up to some upper bound. If you want to list them, you want to do the same thing. It is not often that you want to access only one particular value inside the sequence. This is for those people who just want the whole sequence uninterrupted.

I guess what Sow[n] does is leave the members of the sequence lying around in some pre-defined region in computer memory. That memory is likely to be freed once the Reap[n] function is called, which lists all the members of the stored sequence in the order generated.

EvenQ[] and OddQ[] are employed to check if n if odd or even before executing the rest of the line. If false, control passes through the next line. The testing is inefficient here, since each statement is tested all the time. So, if we already know the number is even, OddQ[] is executed anyway.

ClearAll[Co];
Co[1] = 1;
Co[n_ /; EvenQ[n]] := (Sow[n]; Co[n/2])
Co[n_ /; OddQ[n]] := (Sow[n]; Co[3*n + 1])
Collatz[n_] := Reap[Co[n]]

But Reap[n] by itself gives a nested array (or more accurately, a “ragged” array) with the final “1” outside of the innermost nesting, where the other numbers are.

In[10]:= Collatz[7]
Out[10]= {1, {{7, 22, 11, 34, 17, 52, 26, 13,
    40, 20, 10, 5, 16, 8, 4, 2}}}

Nested arrays are un-necessary, but the remedy to this gets rid of the number “1” which is the number the Collatz function is supposed to always land on. So we then rely on the presence of the number “2”, the number arrived at before going to “1”, at the end of the sequence. Getting rid of the nested array relies on using Flatten[Reap[Co[n]]]. But when you do that, this happens:

In[11]:= Collatz[7]
Out[11]= {1, 7, 22, 11, 34, 17, 52, 26, 13,
    40, 20, 10, 5, 16, 8, 4, 2}

Flattening has the effect of placing the ending 1 at the beginning of the array. If we can live with this minor inconvenience, then we are able to test the Collatz Conjecture on wide ranges of positive integers. So, this is the code we ended up with:

ClearAll[Co];
Co[1] = 1;
Co[n_ /; EvenQ[n]] := (Sow[n]; Co[n/2])
Co[n_ /; OddQ[n]] := (Sow[n]; Co[3*n + 1])
Collatz[n_] := Flatten[Reap[Co[n]]]

The sequences generated by the Collatz conjecture have the well-documented property of having common endings. Using the Table[] command, we can observe the uncanny phenomena that most of these sequences end in “8, 4, 2” (or, to be more precise, “8, 4, 2, 1”). Here are the sequences generated for the numbers from 1 to 10:

In[38]:= Table[Collatz[i], {i, 10}]

Out[38]= {{1}, 
          {1, 2}, 
          {1, 3, 10, 5, 16, 8, 4, 2}, 
          {1, 4, 2}, 
          {1, 5, 16, 8, 4, 2}, 
          {1, 6, 3, 10, 5, 16, 8, 4, 2}, 
          {1, 7, 22, 11, 34, 17, 52, 26, 13, 40, 20, 10, 5, 16, 8, 4, 2},
          {1, 8, 4, 2}, 
{1, 9, 28, 14, 7, 22, 11, 34, 17, 52, 26, 13, 40, 20, 10, 5, 16, 8, 4, 2},    
          {1, 10, 5, 16, 8, 4, 2}}

Because even numbers are to be divided by 2, somewhere along the meanderings of the sequence, a power of 2 is encountered, and from there it’s a one-way trip to the number “1”.

BoUoW: Bash on Ubuntu on Windows

bash_tuxsay_uobow_sysinfo
Tux is telling you the most current Ubuntu running for Windows for BoUoW.

I am not proud of possibly inventing the ugly acronym “BOUOW”, but “BASH on Ubuntu on Windows” appears to compel it. Maybe we can pronounce it “bow-wow” — not sure if that’s complementary. Just did a Google search, and, no, as predicted I couldn’t have invented it: It is variously acronymed: B.O.U.O.W., or BoUoW. It has been around since at least March of 2016, giving end users, computer geeks, and developers plenty of time to come up with something of a nickname or acronym.

But I actually mean to praise BoUoW, and to give it considerably high praise. This is a brave move on Microsoft’s part, and a long time coming. MS has made *NIX access available in its kernel for some time now, thus making *NIX conventions possible on the command line like certain commands in the Power Shell. The user has to enable the capability in the Windows 10 settings (“Windows Subsystem for Linux” (WSL)), and as Admin, the kernel has to be set to “Developer mode”, and follow the instructions on the MSDN website to download binaries and to enable a bash shell on either the command line or PowerShell.

BoUoW takes advantage of the WSL to do impressive things like use the same network stack as Windows 10 itself. This is because with WSL enabled, a UNIX command such as SSH can now make calls directly to the Windows 10 kernel to access the network stack.

This is, by Microsoft’s admission, a work in progress. It would worry me if they would not have said that. But lots of things do work. vi works and is symlinked (or somehow aliased) to vim. The bash shell comes with some other common aliases like “ll” for “ls -l”, for instance, and apparently, as part of the installation, you actually have a miniature version of Ubuntu, complete with a C compiler, and an image of Ruby, Perl, Python, and if it isn’t installed, you can always use “apt-get” to install it.

One of the security features has the disadvantage of conducting an install of BoUoW separately for each user. If a user types “bash” in a cmd window, and if BoUoW is not installed for that user, the install happens all over again, and the image goes under each user’s AppData directory requesting a BoUoW install. If you are using an SSD for C: drive like me, then you might find that limiting due to a shortage of space.

There are many things not recommended yet. If you are a serious web developer, for example, you would find many of the things you want, such as mySQL, are not currently working the right way. If you are a systems programmer, then you’ll find that ps and top only work for unix-like commands, so I wouldn’t use BoUoW for any serious process management. That being said, it does contain the old standbys: grep, sed, and awk.

gcc_output_uobow
The compiling and output of my “Hello, world!” program, also showing the source code.

gcc had to be installed separately. The binary it created for my “Hello, world!” program lacks the Microsoft .exe extension. And as it is for Unix binaries, it lacks any default extension. It is using gcc version 4.8.4. The current version is 6.3. This older gcc usually won’t pose a problem for most users.

The current stable Ubuntu is 16.04. BoUoW uses the previous stable version, 14.04, and thus has slightly older versions of Perl (5.18), Python (2.7.6), bash (4.3.11), Ruby (1.8) (available using apt-get), vim (7.4), and other software. Vim, however, appears to be the “large” version, which is expandable, using plugins like Vundle, which is good news. I don’t suspect that these slightly older versions would cause anyone problems, except possibly for Python, which has gone all the way up to version 3.5.2 since. You are warned also that it is possible that under Python or Perl, you might run into problems due to not all of their libraries running correctly under BoUoW. Not surprising, since Python has hundreds of installable libraries and Perl has thousands of them. Could take a while.

 

Cygwin has come a long way … A story in animated GIFs

cygwin_setup
Search is handy for adding new packages to your installation.

First of all, let me say that there is some currency to what the title and pictures imply.

Cygwin/X really has come a long way.  10 years ago, the only viable way to run Cygwin was through a DOS-style UNIX shell. The windows system Cygwin/X provided, such as it was, was  mostly TWM, a primitive window manager which  I used to use, which ran the core programs in the X-Windows distribution. Most  of what came with Cygwin,  such as Gnome or KDE, never worked for me, making me an FVWM2 fan for a long time. Along the way, I appreciated  that while FVWM2 was very stripped-down, it made up for it in flexibility and configurability. Even now, FVWM2 is quite liveable.

cygwin_wait
Postinstall scripts can be a bit of a wait.

I decided yesterday to upgrade Cygwin on one of my older computers,  and after working past some glitches in installation, found that:

  1. If you have your guard down, you may still install packages you hadn’t intended, particularly the TeX language packs for languages and alphabet systems that you know you will never use. Minutes can turn to hours with postinstall scripts running trying to configure these redundant packages.
  2. hacking_keys
    I had this idea of moving my old Cygwin installation to another drive; and it was then I discovered a thicket of permission problems that I had to untangle. This took a lot of work.

    Mate is recent addition to Cygwin, and actually works on my slow system in 2016. In fact, I am using the Midori web browser to edit this blog under Mate in Cygwin/X.

  3. GIMP was once a graphics program you had to compile; now it is intallable for Cygwin as its own package.
  4. When moving my old
    vim_install_github
    Github is the place for a lot of things to round out Cygwin. I was using it to clone source code remotely, then compile and install.

    distribution to another drive, I found a ton of permision problems which were caused by compiling the source for various downloaded code  as another user – not the owner of the directory.

  5. I now have a good system, with much more functionality than ever before. Cygwin has gone from a system that was “mostly broken” to “mostly working” in the space of 10 or so years.green_ninja

Programmatic Mathematica XVI: Patterns in Highly Composite Numbers

This article was inspired by a vlog from Numberphile, on the discussion of “5040: an anti-prime number”, or some title like that.

A contributor to the OEIS named Jean-François Alcover came up with a short bit of Mathematica code that I modified slightly:

Reap[
   For[
      record = 0; n = 1, n <= 110880, n = If[n < 60, n + 1, n + 60], tau = DivisorSigma[0, n]; 
      If[tau > record, record = tau; Print[n, "\t\t", tau];
      Sow[tau]]]][[2, 1]]

This generates a list of a set of numbers with an unusually high amount of factors called “highly composite numbers” up to 110,880. The second column of the output are the number of factors.

1      1
2       2
4       3
6       4
12      6
24      8
36      9
48      10
60      12
120     16
180     18
240     20
360     24
720     30
840     32
1260        36
1680        40
2520        48
5040        60
7560        64
10080       72
15120       80
20160       84
25200       90
27720       96
45360       100
50400       108
55440       120
83160       128
110880      144

For a number like 110,880, there is no number before it that has more than 144 factors.

Highly composite numbers (HCNs) are loosely defined as a natural number which has more factors than any others that came before it. 12 is such a number, with 6 factors, as is 6 itself with 4. The number 5040 has 60 factors, and is also considered highly composite.

5040=24×32×5×7
This works out to 60, because with 24, for example, we get the factors 2, 4, 8, and 16. With 24×32, we get 2, 3, 4, 6, 8, 9, 16, 18, 36, 72, and 144, all which evenly divide 5040. The total number of factors including 1 and 5040 itself can be had from adding 1 to each exponent and multiplying: (4+1)(2+1)(1+1)(1+1)=5×3×2×2=60.

Initially, facotorization of HCNs was done in Maple using the “ifactor()” command. But there is a publication circulating the Internet referring to a table created by Ramanujan that has these factors. A partial list of these are summarized in a table below. The top row headers are the prime numbers that can be the prime factors, from 2 to 17. The first column is the number to factorize. The numbers in the same columns below these prime numbers are the exponents on the primes, such as: 10,080=25×32×51×71. The last column are the total number of factors on these HCNs. So, by adding 1 to each exponent in the row and multiplying, we find that 10,080 has 6×3×2×2=72 factors.

NUMBER PATTERNS OBSERVED

As a number of factors (underneath the “# facotrs” column), We get overlapping patterns starting from 60. One of them would be the sequence: 120, 240, 360, 480, 600, and 720. But the lack of an 840 breaks that pattern. But then we get 960, then 1080 is skipped, but then we get 1200.

For numbers of factors that are powers of 2, it seems to go right off the end of the table and beyond: 64, 128, 256, 512, 1024, 2048, 4096, 8192, … . Before 5040, the pattern is completed, since 2 has 2 factors, 6 has 4 factors, 24 has 8 factors, 120 has 16 factors, and 840 has 32 factors. The HCN with 8192 factors is 3,212,537,328,000. We have to go beyond that to see if there is a number with 16,384 factors.

Multiples of 12 make their appearance as numbers of factors: 12, 24, 36, 48, 60 (which are the numbers of factors of 5040), 72, 84, 96, 108, 120, but a lack of a 132 breaks that pattern. But then we see: 144, 288, 432, 576, 720, 864, 1008, 1152, and the pattern ends with the lack of a 1296.

We also observe short runs of numbers of factors in the sequence 100, 200, 400, 800, until we reach the end of this table. But the pattern continues with the number 2,095,133,040, which has 1600 factors. Then, 3200 is skipped.

There are also multiples of 200: 200, 400, 600, 800, but the lack of a 1000 breaks that pattern. But when seen as multiples of 400, we get: 400, 800, 1200, 1600, but then 2000 is skipped.

There are also peculiarities in the HCNs themselves. Going from 5040 to as high as 41,902,660,800, only 4 of the 60 HCNs were not multiples of 5040. The rest had the remainder 2520, which is one-half of 5040.

Also beginning from the HCN 720,720, we observe a run of numbers containing 3-digit repeats: 1081080, 1441440, 2162160, 2882880, 3603600, 4324320, 6486480, 7207200, 8648640, 10810800, and 14414400.

Number 2   3   5   7   11  13  17  # of
                                factors
-----------------------------------------------------------------------
5040    4   2   1   1               60  
7560    3   3   1   1               64  
10080   5   2   1   1               72  
15120   4   3   1   1               80  
20160   6   2   1   1               84  
25200   4   2   2   1               90  
27720   3   2   1   1   1           96  
45360   4   4   1   1               100 
50400   5   2   2   1               108 
55440   4   2   1   1   1           120 
83160   3   3   1   1   1           128 
110880  5   2   1   1   1           144 
166320  4   3   1   1   1           160 
221760  6   2   1   1   1           168 
332640  5   3   1   1   1           192 
498960  4   4   1   1   1           200 
554400  5   2   2   1   1           216 
665280  6   3   1   1   1           224 
720720  4   2   1   1   1   1       240 
1081080 3   3   1   1   1   1       256 
1441440 5   2   1   1   1   1       288 
2162160 4   3   1   1   1   1       320 
2882880 6   2   1   1   1   1       336 
3603600 4   2   2   1   1   1       360 
4324320 5   3   1   1   1   1       384 
6486480 4   4   1   1   1   1       400 
7207200 5   2   2   1   1   1       432 
8648640 6   3   1   1   1   1       448 
10810800    4   3   2   1   1   1       480 
14414400    6   2   2   1   1   1       504 
17297280    7   3   1   1   1   1       512 
21621600    5   3   2   1   1   1       576 
32432400    4   4   2   1   1   1       600 
61261200    4   2   2   1   1   1   1   720 
73513440    5   3   1   1   1   1   1   768 
110270160   4   4   1   1   1   1   1   800 
122522400   5   2   2   1   1   1   1   864 
147026880   6   3   1   1   1   1   1   896 
183783600   4   3   2   1   1   1   1   960 
245044800   6   2   2   1   1   1   1   1008    
294053760   7   3   1   1   1   1   1   1024    
367567200   5   3   2   1   1   1   1   1152    
551350800   4   4   2   1   1   1   1   1200    

After that run, we see a 4-digit overlapping repeat. The digits of the HCN 17297280 could be thought of as an overlap of 1728 and 1728 to make 1729728 as part of that number. The 3-digit run continues with: 21621600, 32432400, 61261200, and after that the pattern is broken.

Programmatic Mathematica XV: Lucas Numbers

The Lucas sequence follows the same rules for its generation as the Fibonacci sequence, except that the Lucas sequence begins with t1 = 2 and t2 =1.

Lucas numbers are found in the petal counts of flowing plants and pinecone spirals much the same as the Fibonnaci numbers. Also, like the Fibonacci numbers, successive pairs of Lucas numbers can be divided to make the Golden Ratio, \phi. The Mathematica version (10) which I am using has a way of  highlighting certain numbers that meet certain conditions. One of them is the Framed[] function, which draws a box around numbers. Framed[] can be placed into If[] statements so that an array of numbers can be fed into it (using a Table[] command).

For example, let’s frame all Lucas numbers that are prime:

In[1]:= If[PrimeQ[#], Framed[#], #] & /@ Table[L[n], {n, 0, 30}]

The If[] statement is best described as:

If[Condition[#], do_if_true[#], do_if_false[#]]

The crosshatch # is a positional parameter upon which some condition is placed by some function we are calling Condition[]. This boolean function returns True or False. In the statement we are using above, the function PrimeQ will return true if the number in the positional parameter is prime; false if 1 or composite.

The positional parameters require a source of numbers by which to make computations, so for this source, we shall look to a sequence of Lucas numbers generated by the Table command. The function which generates the numbers is a user-defined function L[n_]:

In[2]:= L[0] := 2
In[3]:= L[1] := 1
In[4]:= L[n_] := L[n-2] + L[n-1]

With that, I can generate an array with the Table[] command to get the first 31 Lucas numbers:

In[5]:= Table[L[n], {n, 0, 30}]
{2, 1, 3, 4, 7, 11, 18, 29, 47, 76, 123, 199, 322, 521, 843, 1364, \
2207, 3571, 5778, 9349, 15127, 24476, 39603, 64079, 103682, 167761, \
271443, 439204, 710647, 1149851, 1860498}

This list (or “table”) of numbers is passed through the If[] statement thusly:

In[6]:= If[PrimeQ[#], Framed[#], #] & /@ Table[L[n], {n, 0, 30}]

to produce the following output:

In[7]:=Array_Frame_Lucas_Prime

Note that this one was an actual screenshot, to get the effect of the boxes. So, these are the first 31 Lucas numbers, with boxes around the prime numbers. The Table[] command appears to feed the Lucas numbers into the positional parameters represented by #.

There was a sequence I created. Maybe it’s already famous; I have no idea. On the other hand, maybe no one cares. But I wanted to show that with any made-up sequence that is recursive in the same way Fibonacci and Lucas numbers were, that I could show, for example, that as the numbers grow, neighbouring numbers can get closer to the Golden Ratio. The Golden Ratio is \phi = \frac{1 + \sqrt{5}}{2}. I want to show that this is not really anything special that would be attributed to Fibonacci or François Lucas. It can be shown that, for any recursive sequence involving the next term being the sum of the previous two terms, sooner or later, you will always approach the Golden Ratio in the same way. It doesn’t matter what your starting numbers are. In Lucas’s sequence, the numbers don’t even have to begin in order. So let’s say I have:

K[0] := 2
K[1] := 5

K[n_] := K[n-2] + K[n-1]

So, just for kicks, I’ll show the first 31 terms:

Table[K[n], {n, 0, 30}]
{2, 5, 7, 12, 19, 31, 50, 81, 131, 212, 343, 555, 898, 1453, 2351, \
3804, 6155, 9959, 16114, 26073, 42187, 68260, 110447, 178707, 289154, \
467861, 757015, 1224876, 1981891, 3206767, 5188658}

Now, let’s output the Golden Ratio to 15 decimals as a reference:

N[GoldenRatio, 15]
1.61803398874989

Now, let’s take the ratio of the last two numbers in my 31-member sequence:

N[K[30]/K[29], 15]
1.61803398874942

You may say that the last two digits are off, but trying against the Fibonacci sequence, the ratio of the 30th and 31st numbers yields merely: 1.61803398874820, off by 3 digits.

For Lucas: 1.61803398875159, off by 4 digits — even worse.

So, my made-up sequence is more accurate for \phi than either Lucas or Fibonacci. I have tried other made-up sequences. Some are more, and some are less accurate. If it depends on the starting numbers, I think some combinations work better, and you won’t necessarily get greater accuracy by starting and ending with larger numbers.

The HP 35s Calculator: a revised review

hp35s
The HP 35s Programmable Calculator

A while ago, I wrote a blog article on a different blog regarding the HP 35s programmable calculator. Depending on where you buy it, it could cost anywhere from $55 to $98 to buy.

I have heard in other places about the plastic used to make this calculator. It is indeed cheap plastic. It certainly feels hollow when you hold it. It belies the amount of memory and the increased calculating power that lies inside. The calculator has two calculation modes: ALG mode (algebraic mode) to resemble conventional calculators, and RPN mode (reverse-Polish notation), which, for those who do long calculations, provides a way to avoid parentheses, but requires getting used to stacks.

As far as RPN mode goes, only four numbers can be pushed on to the stack at maximum for this calculator. I have read other reviews for other HP calculators where the stack can be much larger. The numbers push to the bottom of the stack as you enter new numbers, and as you enter them, the “bottom” of the stack actually moves “up” on the display. It makes it difficult to discuss how it implements this data structure because the numbers scroll in the opposite direction. The theory goes that you “push” data to the top of the stack, and you “pop” data off the top of the stack. This is a LIFO data structure (LIFO = “last in, first out”). To see the HP25s implementation, you apparently “push” data to the bottom of the stack, numbers “above” it move upward, and then you “pop” data off the bottom of the stack. It actually amounts to the same thing in the end. It is still a LIFO data structure. Pushing a fifth number on to the stack will cause the first number to disappear, so you can only work with four numbers at a time.

So, let’s say that you have the following stack:

a: 8
b: 7
c: 6
d: 5

The last two numbers entered are the numbers “6” and “5” in memory locations “c” and “d” respectively. Operations will be done on the last two numbers entered. So, if I now press the operator “+”, it will add 6 to 5 and pop both of these numbers off of the stack.

a: 0 (empty)
b: 8
c: 7
d: 11

The stack rotates down, the “bottom” (location “a”) of the stack becomes empty, and the “11”, the result of the calculation replaces both 6 and 5.

Some operators are unary, so pressing the square root will perform an operation on only the last number (location “d”), and replace the result back into location “d”, eliminating the number 11.

a: 0 (empty)
b: 8
c: 7
d: 3.31662479036

Well, there is also the programmability of the calculator. There are many commands available, and one pet peeve is how you are only allowed to assign a single letter to name a program.

Latex editors: a comparison

latex_lamport
If you are using Lyx or Texmacs, this book is still an absolute must. It is THE bible for this language.

Latex is a math typesetting markup language which has been around for about 30 years. It is about as old as HTML, and runs on pretty much any kind of computer that can support a Latex compiler. I have written many term papers in it, and continue to use it to write documents. Its best feature is its ability to handle mathematical and scientific notation. It is also the official typesetting language of the American Mathematical Society. A Stanford professor named Dr. Donald Knuth invented a lower-level markup language called Tex as far back as 1976, and Latex, designed in 1985 by Leslie Lamport, was and is just a bunch of Tex macros, sophisticated enough in itself to amount to a higher-level language. You can edit complete documents and even entire books with only a background in Latex. Latex is therefore robust enough that that is all I ever use for math and science documents.

Latex documents are known for their distinctive roman font, and its clean presentation of even the most complicated formulae. The WordPress editor used in making this blog article can show formulae using the distinctive Latex fonts: m = \frac{m_0}{\sqrt{1-\frac{v^2}{c^2}}} is the way Einstein’s relative mass formula is presented on my editor. This is identical to how it would appear in a Latex paper document. Unfortunately, this editor only displays inline math, so I can’t show you how it would display “presentation-style” math, where the fonts would be larger.

Over the decades, there have been editors in existence that mimic Latex in presentation of fonts and formulae. Two that I have encountered are Lyx and Texmacs.

Both Lyx and Texmacs try to distance themselves from being just WYSIWYG wrappers for the Tex/Latex language. While the metafonts displayed are the distinctive fonts known to exist in Latex are those displayed by default in these editors, saving the files saves to the format native to these separate editors. If you want Latex, you have to export your work into Latex format.

texmacs
Examples of output from Texmacs. Not bad for math, (especially if you know the Latex math codes) but not so easy to use when not in math mode.

First I’ll discuss Texmacs, since my experience with it is the most recent. I discovered Texmacs by surprise when browsing through my Cygwin menus on my laptop. While one would think that going by the name, Texmacs must have some combination of Tex and Emacs, it has dependence on neither. The editor has no resemblance to Emacs (neither in the user interface nor the keystrokes), and a selection of document options appear on the toolbar and in the menus that appear to be in line with Latex document and font options. Texmacs produces its own Texmacs code by default, and while Latex can be exported, the document in Latex may not end up looking the same. I have found that many font changes were lost, for instance.

For one who has worked with Latex for close to 30 years, I can say that nearly all of the resemblance to Latex as well as its ease of use lie in the editor’s use of math commands, although there is more dependence on the GUI. One finds that you can’t enter “\frac{3}{4}” to get \frac{3}{4}, but there is a Texmacs icon you can click that handles that.  Its weakness lay in its handling of the rest of the document. Tables were not well implemented. It appears incapable of inserting gridlines forming the borders for the table cells, for instance, even though the command for it appears to be there in the GUI. I found I needed to export the Latex code, bail out of Texmacs and edit the Latex code directly in a text editor. Another drawback of Texmacs is that while the icons cover nearly anything you would like to do in math, the fact remains that your choices of math expressions are largely limited to the buttons provided. If you are going to do something more complicated, you are going to find reason to edit the Latex code directly by hand again in a text editor. And once you do, importing the *.tex file back into Texmacs to continue editing will not guarantee that your new Latex code will be understood the way you want it. One thing that Texmacs does rather well is change fonts. Latex/Tex has ways of changing fonts internal to its language, but you are limited to only a small number of standard Tex fonts, unless you know your way around the preamble, or header part of the code. Texmacs leaves you more open to alternative installed fonts, allowing you to take advantage of the diversity of Tex fonts of which there are hundreds, created over the last 10 or more years. In fact Texmacs is the only way I know of to take advantage of alternative fonts outside of the Roman/Helvetica/monospace fonts that are at the core of Tex in a way that is even remotely as easy as a word processor. Texmacs documents will have a Latex look and feel, with greater flexibility in font choices, but as said earlier, all this is great as long as you are sticking largely to simple math or math in the toolbars, or as long as you avoid typesetting constructs outside of the math markup, such as tables.

lyx
An older version of the Lyx editor.

Lyx is, I believe a much older editor. It claims to use Latex for its typesetting, but my experience with it (although admittedly years ago) was that for serious math applications, you have to export Latex code and edit it by hand if you want to get what you want. Make sure you have Leslie Lamport’s Latex book beside you at the time. After decades of working on and off with Latex, I can never completely get the language and all its nuances in my head, and need the constant assistance of Lamport’s Latex book at my side. This also ends up being the case for Texmacs, since even basic formatting has to be changed under that editor.

In the end, these editors can save a lot of time to get the basic look and feel down for your document, but in the end you need to, at some point, hunker down and edit Latex code directly, using a text editor. I use vi, where I constantly need to bail out and compile the code and run xdvi on the compiled *.dvi file to see what it looks like and what Latex code I need to tweak next.

Both Texmacs and Lyx are on the GPL.
Texmacs source code: http://savannah.gnu.org/svn/?group=texmacs
Lyx source code: http://www.lyx.org/Download

Eterm on Windowmaker

This is Eterm, running under X-Windows in Cygwin. The root desktop image is an image of an Emacs Quick Reference, made for the desktop. Nice reason to have a transparency feature on a terminal window.
This is Eterm, running under X-Windows in Cygwin. The root desktop image is an image of an Emacs Quick Reference, made for the desktop. Nice reason to have a transparency feature on a terminal window.

There is always something to have to consider when bringing an app into Cygwin that is not part of the Cygwin distro. I wish to make note of this here in case anyone else has this problem.

Modern window managers are configurable, but only through windows and dialogs. I prefer to configure a bit closer to the metal, so I prefer to edit scripts. The chosen X-window manager was WindowMaker, which is somewhat “modern” while still being nicely configurable, through scripts you can edit under ~/GNUstep/Library/WindowMaker along with graphics files for things such as background images and border tiles. It was nice that WindowMaker still comes with Cygwin, along with FVWM2, another favourite window manager of mine.

I noticed that Cygwin lacked a transparent terminal. You might be thinking that I forgot “mintty”, but I didn’t, since it actually runs as a process directly under Windows, not under Cygwin. Even if I execute mintty from an xterm, the terminal that comes up is not a child of X-Windows, it is a child of MS-Windows, and thus cannot be managed under X-windows.

So, Eterm at first could not compile under Cygwin, and for hours I was racking my brain as to what the problem might be, and looking through the output of the command “configure --help“, I found what solved my problem. What seemed to stop compilation were references to “utmp” and associated header files. The configure script allowed for compilation without utmp support. Utmp is used for access to system logs. This was considered not a big deal in Cygwin, since MS-Windows still has such logs. So my configure command for Eterm was:

./configure --enable-trans=yes --enable-utmp=no

From then I was able to successfully compile Eterm with the eye candy that one associates with the Enlightenment window manager, but under WindowMaker.

The World Wide Web, as it once was seen

line-mode.cern.ch
Tim-Berners-Lee’s 1989 vision of the World-Wide Web, as seen through a green-screen terminal such as a Cybernex XL-87.

You can see the first version of the World-Wide Web at the CERN website. They simulate the experience as if you were looking at the pages through a green-screen terminal such as one of the old Cybernex XL87s. Illustrated is part of a screenshot, but clicking on the graphic will actually bring you there.

CERN is a research facility in Europe having more to do with physics than with computers. They set up web pages back then to communicate with other physicists and provide links to their graphics files, which they had to download and view some other way, often through an 8-bit color screen if they had one available. In the late 1980s, graphical user interfaces (GUIs) were just emerging, with the first X-Windows installations available on university machines such as a Sun Microsystems computer. Apple soon came up with the first GUI for mass market, soon followed by Microsoft Windows.

In those days, the World-Wide Web ran alongside Gopher, which also ran on a text-based terminal. Gopher is pretty dead these days, having been bested by the promise of the hypertext protocol. What passed for search engines were called Archie, Jughead and Veronica. Archie was an FTP search service, while Jughead did searches within a single server. Veronica allowed you to search nearly any link available on the Gopher network.

And what was Gopher? Gopher was a text-only system of what can be best called links, which led to text documents, binary files, or other resources.

WAIS, the Wide-Area Information Servers, were also available and allowed for text searches for widely distributed documents on many servers, similar to Gopher and Veronica. All of these protocols gave way to HTTP and the world-wide web in the early 1990s.

BASH prompts: Box-drawing characters

xterm_shot2
An xterm session with BASH prompts containing box-drawing characters. The rest of the screen is the output of repeated fortune commands.

I used to be a big user of xterm’s box drawing characters. I hadn’t been aware that they could be used in prompts.

But I recently heard a (probably dated) discussion on how box drawing characters could be used in a command prompt.

I think that’s a great idea, however, the big problem I found was to do it in a way that correctly turn off the drawing so that you could display text again. Otherwise a lot of text ends up looking garbled.

First, let me say that I used a “twtty” example code at Giles Orr’s BASH prompt website which I modified to allow actual box prompts. A clue was provided in the HOWTO here, where they showed, in a very brief way, the entire “catalogue” of “high-bit” ANSI characters, which I pasted into an xterm:

echo -e "�33(0abcdefghijklmnopqrstuvwxyz�33(B"

The high-bit characters are whatever you type in lowercase after you output the ANSI escape sequence “�33(0“, I needed the echo command (echo -e) to get that to work. The output of echo -e can be stored in a string like this:

local box1=`echo -e "�33(0qqqqqqqqqqqqqqqq�33(B"

�33(0 turns on ANSI escapes, while �33(B turns it off. The string “qqqq”… are the characters used to draw a horizontal line. There were some other tweaks I did to his code to become more complete in box characters for a two-line prompt, but it had the side effect of not going all the way across the screen like the original. Adding six characters fixed it, albeit in a kludgy kind of way:

ESC_IN=`echo -e "�33(0"`  # turn on box-drawing
ESC_OUT=`echo -e "�33(B"` # turn off box-drawing

function prompt_command {
    #   Find the width of the prompt:
    TERMWIDTH=${COLUMNS}

    #   Add all the accessories below ...
    local l="${ESC_IN}l${ESC_OUT}"
    local m="${ESC_IN}m${ESC_OUT}"
    local temp="${l}-(${usernam}@${hostnam}:${cur_tty})---(${PWD})--"

    let fillsize=${TERMWIDTH}-${#temp}+6

What I mean by “kludgy” is that I simply added a “6” on the last line above which controls the number of characters required for the first line of the prompt to go across the screen. It’s unlikely that the terminal width will ever need to be less than 6.

I added two variables which are occasionally useful: $ESC_IN for turning on the ANSI feature, and $ESC_OUT for turning it off. Inside the function prompt_command, I added variables $l and $m since his code uses dashes and I wanted the ANSI horizontal lines instead. $l is for the ANSI output for the letter “l”; while $m is for the letter “m” in ANSI. These generate two corners of the box which occur on the far left of the prompt. And they do join up. The $l is used in the next statement below in the form of ${l} to begin making the string $temp. I could have done something with the dashes in this string such as use “${ESC_IN}qqq${ESC_OUT}” in place of “—“, but there were problems if I was too overzealous, so some dashes were left as is.

The main problem was to get a horizontal line in place of the string “——————————————————” which went on indefinitely. Those were replaced by lowercase “q” letters without the ANSI escapes. These were better placed in a statement nearby:

if [ "$fillsize" -gt "0" ]
then
    fill="qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq"
    #   It's theoretically possible someone could need more 
    #   dashes than above, but very unlikely!  HOWTO users, 
    #   the above should be ONE LINE, it may not cut and
    #   paste properly
    fill="$ESC_IN${fill:0:${fillsize}}$ESC_OUT"
    newPWD="${PWD}"
fi

where $ESC_IN and $ESC_OUT were used in the next statement below the comments. You can’t put them inside the first $fill assignment, because the second assignment cuts off the end including $ESC_OUT should you attempt to do it that way.