Format for .alq files

[schickel]

As posted in another thread, I've been in touch with Jesper Gerved who was the author of the elf-alq/alq-elf utilities and have the format of the files available.

Originally Posted by Jesper Gerved

The ALQ File Format

16 bit oriented binary format. Only factors larger than 256 stored. The largest prime factor is not stored ! Each factor stored has a header, a 16 bit word. The 12 most significant bits are the index of the term. The 4 least significant bits are the number of 16 bit words of the factor. Then follows the factor with least significant words first (Intel "little endian" byte and word ordering). So to take an example from the start of the 276 sequence:

36 . 1470806764 = 2^2 * 7 * 3301 * 15913
37 . 1471882804 = 2^2 * 7 * 19 * 199 * 13903
38 . 1642613196 = 2^2 * 3 * 7 * 19554919
39 . 2737688884 = 2^2 * 7 * 2389 * 40927

Stores as
0x0241 24(hex) = 36(dec), 1 word
0x0CE5 = 3301(dec)
0x0271
0x0955

Note that nothing is stored for terms 37 and 38.

The augmented format (as of 2006) adds the convention that the 12 bit index
field holds the index modulo 4096. And that if the 4 bit word count is 0 (zero), then an additional 16 bit word is inserted holding the actual word count.

Fundamentally, this is an extension of Paul Zimmerman's fmt format into the binary realm. To expand an alq file, you start with the name to get the starting number, then trial divide by primes <257 to get the start of each line, then use the primes stored for each line, with the remainder after dividing everything out as the last prime. Very elegant.

[schickel]

Also, here is a copy of the latest tool to convert to/from elf/alq. The source is not the most current, however. Jesper was apparently changing some hings for Wolfgang Creyaufmueller and an exe built from it will not work prooperly....

Originally Posted by Jesper Gerved

Using ALQ

>alq
Converts all .elf files in the current directory into .alq files

>alq 276
Converts only 276.elf

>alq 50000 60000
Converts files in this interval

>alq "C:/Documents and Settings/Jesper/Application Data/alq/" Converts all .elf files in directory, the .alq files are put in the same directory

>alq "C:/Documents and Settings/Jesper/Application Data/alq/" "./" ... the resulting .alq files are put in the current directory

>alq fmt 276 1000
Converts all .fmt files in interval into .alq files, directories may be given as above

>alq txt
Text files into .alq

>alq alq
Convert from .alq into .elf. No other text output files are possible at present. Directories and intervals, or single sequences may be specified as above.

The order of parameters is of no importance, but if two directories are given, the first is source and the second is destination. Likewise, if two numbers are given, the first is minimum and the second maximum.

In Windows you may make a shortcut to alq.exe, edit the command line in the properties for the shortcut. I find this to be a convenient way of setting up conversions.


Text Formats

In the attached file 'Text Formats.txt" you will find some examples of text files that can be used as input for 'alq'. Note that Zimmermann's FMT format also stores only minimal information in order to reconstruct the sequence. Being a text format it does take up 2 to 3 times as much memory than ALQ, but this may be acceptable today when we have so much more memory than 20 years ago.

[schickel]

After re-contacting Jesper, he sent me a working alq.exe. This actually can handle the elf for 11280, but, interestingly, alq2elf cannot handle the resulting alq file, so that lends credence to the "something about 11280 is too big" theory.....

[schickel]

And lastly, here is the "Text format" files that shows the layout of several different of the text formats that are used....

[fivemack]

My guess, since it failed at step 2048, is that something's treating the 16-bit header as a signed rather than an unsigned short.

Of course, the header assumes nobody's taking a sequence to more than 4096 steps, which is no longer true ...

[schickel]

Originally Posted by fivemack

My guess, since it failed at step 2048, is that something's treating the 16-bit header as a signed rather than an unsigned short.

Of course, the header assumes nobody's taking a sequence to more than 4096 steps, which is no longer true ...

I think it's size of the numbers combined with the length, not just the length of the sequence. I extended 144984 to over 7000 lines and the old programs have no problem converting in either direction. I think there's something about 11280 that is an extreme corner case. I was thinking about taking a look at some of the sequences on Christophe's page, they're up close to that high too.

It will also be interesting to encounter a sequence with a penultimate prime of >240 bits; we're almost to that point now....