gretl on Slackware 13.0

I had some difficulties getting gretl 1.8.4 installed on Slackware 13. Here is what I did.

The problem was with the LAPACK libraries. After a lot of digging, I found that the problem was twofold: (a) I had built my own LAPACK library using the SlackBuild from slackbuilds.org, and gretl wasn't looking for the library in the right directory. (b) It wasn't finding libblas.a. (You can open config.log for gretl in the /tmp/gretl-1.8.4 directory to find the configuration problems.)

To handle the first problem, I had to edit the SlackBuild script to add the configure option --with-lapack-prefix=/usr to tell it to look for liblapack.a in /usr/lib. It will look in the /lib subdirectory of the directory you give, so if you pass the option --with-lapack-prefix=/usr/lib, it will look in /usr/lib/lib and quit with an error.

The second problem was caused by the fact that I had built my LAPACK library against ACML, AMD's optimized math libraries. I created a symbolic link of that library into /usr/local/lib. (There are probably alternatives, but I know it will be found if I put it there.) I had installed ACML in the default directory, so the symbolic link I created was

ln -s /opt/acml4.3.0/gfortran32/lib/libacml.a /usr/local/lib/libblas.a

The gretl SlackBuild built a package that installed properly and ran, but gave an error when I attempted to plot a graph. I don't know what the error was but it was fixed when I ran gretl from a Slackware 12.1 installation. After that, gretl plotting worked.

Slackware 13 Automount USB Drive

Scratch this: It worked once and now it doesn't work upon reboot!!!
This is so frustrating I may just give up on Slackware altogether.

With Slackware 12.1 and 12.2, USB drives automounted out of the box. Not so for my Slackware 13 installation. The obvious thing was to check which groups I was already a member of, using the command

groups

in Konsole. It said I was a member of cdrom, but not plugdev, so I used the command

gpasswd -a [user] plugdev

and logged out. I logged in again, double checked that I was in plugdev, and tested. Nothing. I didn't know what to do and Google didn't help. I added myself to a bunch of other groups, but none worked.

Some more extensive searching took me here:

http://www.linuxquestions.org/questions/slackware-14/12.0-and-hal-read-this-566862/

Long story short, I had to open the file /etc/login.defs as root and add plugdev to the line referenced in that post. I logged out and back in, and then I could automount USB drives.

Multivariate normal distribution in Python

I could not find a Python function to evaluate the multivariate normal distribution in Python. Here's one that gives equivalent results to the dmvnorm function in the mvtnorm package for R. It's something that works. I've not had time or need yet to fix it up.

b: A vector
mean: The mean of the elements in b (same dimensions as b)
cov: The covariance matrix of the multivariate normal distribution

License: GPL version 2
http://www.gnu.org/licenses/gpl-2.0.html
k = b.shape[0]
part1 = numpy.exp(-0.5*k*numpy.log(2*numpy.pi))
part2 = numpy.power(numpy.linalg.det(cov),-0.5)
dev = b-mean
part3 = numpy.exp(-0.5*numpy.dot(numpy.dot(dev.transpose(),numpy.linalg.inv(cov)),dev))
dmvnorm = part1*part2*part3

Static IP address information in Slackware 12

To find information about a static IP address in Slackware 12:

1. Open /etc/rc.d/rc.inet1.conf
Find the IP address, gateway, and netmask.

2. Open /etc/resolv.conf
There will be information about the nameserver(s).

You can restart the network using the command
/etc/rc.d/rc.inet1 restart

This came in helpful, because I wanted to set up my static IP in Vector 6.0, needed to pull the information from my Slackware installation, but was unable to reboot my computer. I was able to enter the information using Netconf in the Control Center but did not have a way to restart the network.

R packages with ACML

My main production machine has a 64-bit AMD processor and runs Debian Lenny as the primary OS. As I have noticed substantial (often 5x) speed improvements, I always compile R myself against the ACML. For what I do, the difference is important.

I got the following error when trying to install some packages:

/usr/bin/ld: cannot find -lblas
collect2: ld returned 1 exit status

After Google didn't help, and I couldn't find anything explicit in the manuals about this error, I read through "A.3.1.5 Shared BLAS" in the Installation and Administration manual. After a little experimenting, I found that the solution is to make a symbolic link using

ln -s /opt/acml3.6.1/gfortran64_mp/lib/libacml_mp.so /usr/local/lib64/R/lib/libblas.so

AFAICS, the symbolic link needs to go in the same directory as libRlapack.so, if the directory structure happens to be different from my current directory structure. I assume that this will work with any version of ACML provided it has the .so extension.

What is different from anything in the manual is that the symbolic link needs to be a file named libblas.so, not libRblas.so. Note that the error said R could not find -lblas, which means it is looking for a file named libblas.so. Otherwise the error would have said -lRblas was not found.

Using lapply in R

R is generally pretty good, although it has more quirks than other languages, such as automatically dropping dimensions from an array. (You have to specify drop=false every time, there is no way to change the default, apparently the R development team is taking cues from Microsoft.)

Anyway, buried in the documentation is the lapply function, which makes your code run faster when it applies. It can help you avoid having to link in compiled code, i.e., Fortran or C. Here is an example of it in use.

y <- function(x) { z <- x^3 }

x <- 3:5
b <- lapply(x, y)

w <- 1:6
z <- 4
b <- lapply(w, function(x) {
g <- x^3+z
h <- g*2
})

The first example applies the function y to each element in x. The second example applies the values in w to function(x). It shows that you can access global variables inside the function used inside lapply.