Author Archives: mpdebell

Installing Bergman with CLisp 2.49.93+

Bergman is a noncommutative Groebner basis calculator. I encountered some strange problems while trying to install it and I thought I’d share my solutions in case anyone else has a similar problem.

First, the website that I linked has the software, but the links on the page don’t do anything when clicked. I had to right click on the link, copy it to my clipboard, paste it into my address bar, and hit enter.

I then started following this installation guide (although there area also some instructions that come with the download). I installed CLisp using my normal package manager, dnf (I am on Fedora 39), and it installed “CLisp 2.49.93+”, last updated in 2018. I then navigated to the scripts directory and executed mkbergman -auto. The output was:

Using Common Lisp command line: [/usr/bin/clisp]
Step 1 of 12: Setting the environment
Step 2 of 12: Checking CLISP version
The necessary version of CLISP is at least 2.39
You use version 2.49.93+ (2018-02-18) (built on 6fcfb74db1964280be7b7eea00fd3b5d [127.0.0.2])
*** - READ: input stream # has reached its end

Please upgrade your CLISP version at least to 2.39 (2006-07-16)

After poking around in the install script, I figured out that this error was generated by prelisp.lsp in the directory bergman1.001/auxil/clisp (replace bergman1.001 with whatever it was titled when you unzipped). This script checks the version number, and appears to not be able to deal with sub-version numbers (i.e., it would have worked if my CLisp version number was 2.49 but not if it’s 2.49.93 – I think the + also causes its own issue.) Rather than try to rewrite the regexp that checks version number, I just brute forced around this. Here’s how:

In the file prelisp.lsp, line 8 is version-string ((lisp-implementation-version))). Each time subsequently in the script when version-string is called, (lisp-implementation-version) is executed, so it doesn’t work to just set version-string equal to the string "2.39". Instead, I commented this line out, and found all subsequent calls to version-string throughout the file. These were on lines 11, 13, 24, and 26. I replaced version-string in each of these locations with the example given in the script of a version string produced by 2.39, specifically, I replaced it with this text:
"2.39 (2006-07-16) (built on stnt067 [192.168.0.1])".

After saving the file and rerunning the installation command mkbergman -auto from the scripts directory, everything installed just fine and calling bergman from Macaulay2 also worked fine.

Hope this helps someone!

All Relations are Essential in Roos’s Example of a Non-Koszul Algebra with Arbitrarily Linear Resolution

In the paper “Commutative non-Koszul Algebras having a linear resolution of arbitrarily high order”, Roos gave an example of a family of algebras $S_\alpha$, one for each integer $\alpha\geq 2$, in which the resolution of $k$ (the coefficient ring of characteristic zero) over $S_\alpha$ is linear for for $\alpha$-many steps and non-linear in homological degree $\alpha+1$ (he also gave examples in positive characteristic). The rings are

$$S_\alpha=k[x,y,z,u,v,w]/(x^2,xy,yz,z^2,zu,uv,vw,w^2, xz+azw-uw,zw+xu+(a-2)uw)$$

I find it fascinating that it’s possible to create a family with this homological behavior in which the coefficients of the polynomials depend on the parameter in such a simple way. The relationship between homological behavior and coefficients of the polynomials is usually difficult to so precisely determine.

At first glance, the relations look pretty random and it seems impossible that anyone one could come up with examples like these, but their construction is surprisingly natural, coming from taking the ring $k[x,y]/(x^2,xy)$ (the smallest quadratic non-ci).

I was curious if a smaller example could be constructed by trying the “obvious”: drop each of the relations, one at a time, to see if the quotient by the ten remaining polynomials still exhibited the desired behavior. Here’s the Macaulay2 code (note that I use $\mathbb{Z}/101$ instead of a field of characteristic zero, but this will only affect the resolution of the residue field in higher homological degrees than those we’re interested in):

k=ZZ/101;
alpha = 2;
Q = k[x,y,z,u,v,w];
relSet = {x^2,x*y, y*z, z^2,z*u, u^2, u*v, v*w,w^2, x*z + alpha*z*w - u*w,z*w+ x*u + (alpha - 2)*u*w};
subs = subsets(relSet, 10);
for relset in subs list {
    R = Q/(ideal relset);
    F = res (coker vars R,LengthLimit=>5);
    betti F}

For brevity, I won’t print all the Betti tables here, but the key observation to make is that, as we change $\alpha$ from $2$ to $3$, we still see non-linearity in degree $3$ in every single Betti table. This shows that every relation is essential for this example to work. For example, if we drop $x^2$, we get the following table for $\alpha=2$:

       0 1  2  3   4    5    6     7
total: 1 6 25 96 364 1385 5287 20207
    0: 1 6 25 92 320 1084 3625 12046
    1: . .  .  4  44  301 1646  7905
    2: . .  .  .   .    .   16   256

And the following for $\alpha=3$

       0 1  2  3   4    5    6     7
total: 1 6 25 96 360 1341 4986 18529
    0: 1 6 25 95 349 1266 4570 16465
    1: . .  .  1  11   75  415  2048
    2: . .  .  .   .    .    1    16

Setting up a Monoprice tablet on Linux (Fedora 36)

I’ve been using a monoprice drawing tablet for taking notes and whiteboard-style collaboration with other mathematicians. Like most monoprice products, it is identical to a name brand product marketed under a different name. Mine in particular is equivalent to the Huion H610 Tablet. There is support for this tablet in Linux, but because of this branding issue, Linux doesn’t know to use the Huion driver. In particular, (at least in gnome, my desktop environment), going to the graphical user settings entry for “wacom tablet” gives a frustrating “no tablet detected: please plug in or turn on your wacom tablet” message. Fortunately, this is a pretty easy fix once you know how to do it, so I hope that this post saves someone some hours of frustration.

This stack post was pretty helpful, but it didn’t tell me how to get the right name of the tablet (more on that later). I’ll describe everything that I did below.

Running lsusb in terminal gives a list all devices currently connected via USB. All are clearly identified, except for this mysterious entry:

Bus 001 Device 006: ID 256c:006e  10594

This is the tablet, and the enigmatic information is due to the fact that the device is not recognized currently.

Some more useful troubleshooting commands: libinput list-devices (ran as root) gives a list of input devices, and libwacom-list-local-devices gives a list of tablets. When I run these commands, I get some info about devices being seen by the computer but not recognized.

This can be remedied by adding the appropriate file describing the device. On my machine (Fedora 36), all the files describing tablets are in /usr/share/libwacom. You may need to find a similar folder in another location on your machine by searching for “libwacom”.

In this directory, there is a file titled “huion-h610-pro.tablet”, which is the name brand version of my monoprice tablet. This file contains a number of configuration settings. In particular, “DeviceMatch” is set equal to a list of possible names that the tablet may be found under:

DeviceMatch=usb:256c:006e:HUION PenTablet Pen;usb:256c:006e:HUION PenTablet Pad;usb:256c:006e:Turcom TS-6610 Pen;usb:256c:006e:Turcom TS-6610 Pad;usb:256c:006e:HUION Huion Tablet Pen;usb:256c:006e:HUION Huion Tablet Pad;usb:256c:006e:HUION H610 Pen;usb:256c:006e:HUION H610 Pad

So it would seem that what we need to do is append the name of the tablet to this list, separated by semicolons (and prefaced by “usb:” and postfixed by ” Pen” and ” Pad” to match the formatting of the other names in the list) :

DeviceMatch=usb:256c:006e:HUION PenTablet Pen;usb:256c:006e:HUION PenTablet Pad;usb:256c:006e:Turcom TS-6610 Pen;usb:256c:006e:Turcom TS-6610 Pad;usb:256c:006e:HUION Huion Tablet Pen;usb:256c:006e:HUION Huion Tablet Pad;usb:256c:006e:HUION H610 Pen;usb:256c:006e:HUION H610 Pad;usb:256c:006e: 10594 Pad;usb:256c:006e: 10594 Pen

However, this doesn’t end up working. I’m not exactly sure why, but my guess is that there’s some information about the device that results in particular tablet files being read in the first place, and this information is lacking for my tablet, so this change doesn’t do anything consequential as the file isn’t read at any point. I’m not really sure though because I don’t know much about hardware.

What did end up working for me was to create a new tablet file for my device. At first I tried following the same format as others and naming it something like “monoprice-10594.tablet” but this also didn’t get me anywhere. What did end up working was creating a file named “0x256c-0x6e.tablet” the contents of which are:

# HUION
# H610 Pro
#

[Device]
Name=0x256c 0x6e
ModelName=10594
DeviceMatch=usb:256c:006e  10594
Class=Bamboo
Width=10
Height=6
IntegratedIn=
Layout=huion-h610-pro.svg
Styli=0xffffd;

[Features]
Stylus=true
Reversible=true
Touch=false
Buttons=8

[Buttons]
Left=A;B;C;D;E;F;G;H
EvdevCodes=0x100;0x101;0x102;0x103;0x104;0x105;0x106;0x107

To be honest, I don’t remember where I got the tablet name from. I don’t see it in the output of any of the diagnostic commands that I mentioned above. I figured this out a while back on another machine and tried to reproduce it on a newer computer, failed, and went back to see what I did on the old machine. Maybe someone can tell me what the missing piece is!