pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NIST Autotests


From: John Darrington
Subject: NIST Autotests
Date: Fri, 2 Dec 2011 10:21:32 +0000
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Nov 30, 2011 at 07:59:18AM -0800, Ben Pfaff wrote:

     Unless Selma expresses a preference, I think it would be fine to
     offer your suggestions now.

OK, Well here they are:
     
Selma, you've obviously put a lot of effort into the program and clearly
you have a good understanding of the posix sockets API.  Like you 
said, doing this kind of job in a low level language can be a challange,
and like Ben, I wonder if it would not be better to leave the job of
fetching the NIST files to a program or library designed for the purpose.

There are all sorts of issues which could come up which can affect
downloading from an http server.  For example I tried using your code
at work at lunchtime.  It didn't work, because there, port 80 is closed
and instead all http requests go through a proxy server.  Of course,
you could add code to examine the  http_proxy environnment variable
and if set send a proxy request and handle the response.  But what
about the case when the proxy has a password ?  And what about SSL
connections? and redirects?  Hell, you'll end up writing an entire web
browser!

I suggest that we assume for now, that the relevant NIST files have
been downloaded (we can worry about how later) and are present in a
particular directory.  This will allow you to concentrate on creating
the .at files. and  fixing those issues.  One such issue which I
noticed.  The NIST data presents its decimal results with leading
zeros, whereas PSPP does not (or vici-versa -  I forget which).  Thus,
there were some test failures simply because the test expects "0.1234"
whereas PSPP produces ".1234".  There are a number of possible ways we
can address this.  We just need to decide upon one of them.

Also, rather than generating the .at files themselves,  I think it'll
be a lot easier to have static .at files which fetch the input data
and the expected results from other files.  This will save a lot of
messing about with sewing parts of NIST into .at files.  You will
still have to write a program to cut NIST files into the input data
set and the expected output respectively.  But you will be able to
concentrate on this issue without having to worry about a lot of
side issues.

What do you think?

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]