On Sun, Oct 17, 1999 at 02:13:33AM +0200, Steinar H. Gunderson wrote:
> On Sat, Oct 16, 1999 at 03:46:30PM +0100, Chris Jefferson wrote:
> >However, proving that they has used the
> >interim file generated by this particular program might be difficult...
>
> Not very. Save files are incompatible from program to program. Or at least
> so I think...
Some time ago I proposed a standard format for save files. It also
had the advantage that it only saved the actual bits used so would
make the save files 1MByte rather than 1.8 MByte for an 8,000,000
exponent in prime95.
> Converting a savefile is also going to be a lot of work :-)
It needs to be done exactly right - hence by the program which
generated it probably.
Here is what I wrote :-
....
Reading in other threads about save files it seems to me that it would be
worth while standardising the format of save files so that they can be ported
across platforms.
At the moment I think both Prime95 and the unix programs write the floating
point values of the FFT array to a file which is inherently non-portable
across machine architectures. It also makes the save files quite a bit
larger than necessary (an important consideration if we ever want to hold a
central repository of these files).
I'd like to propose for discussion a simple cross-platform save file format
as below.
Width Value Description
8 "MersSave" in ASCII as a file identifier
4 int32 version number of file
16 ASCII space filled name of creating program
4 int32 exponent being tested (n)
4 int32 iteration that this residue represents
4 int32 length of platform specific area x words
4x int32 platform specific
len int32 binary data for the residue
len = ((n + 0x1F) & ~ 0x1F) >> 3
4 int32 CCITT CRC-32 of the entire file
All integers should be represented as little-endian in the file (the majority
of the clients are little-endian). The residue should be little endian with
the unused 1-31 bits at the end set to 0.
A file format like this would have the following advantages
1) You could take a save file from one platform/program to another (via a
central repository at primenet maybe)
2) You could take a save file from one FFT size to another (imagine a
software upgrade where the FFT limits have changed)
3) They are much smaller (eg 600k vs 2M)
It would have the disadvantages
1) Slightly slower and more complex to read and write. However this is an
infrequent operation. (That said time to write a save file may be IO
limited in which case a shorter save file will be quicker.)
2) We've all got to agree on it ;-)
Discuss!
--
Nick Craig-Wood
[EMAIL PROTECTED]
http://www.axis.demon.co.uk/
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
