Skip to content

make check and postscript output in R 1.7.1

4 messages · Brian Ripley, Don MacQueen, Peter Dalgaard

Don MacQueen
# 
I think this might be telling us that reg-plot.ps.save needs to be 
updated for the new version of postscript().

comparing 'reg-plot.ps' to '../../source/tests/reg-plot.ps.save' ...100c100
< 663.53 0 l
---
104c104
< 0 -7.20 l
---
-Don
Brian Ripley
# 
It's telling us that your machine gives different output from *all* the 
other machines that were checked in the beta-test period.   So what 
machine is this that no one beta tested?   (In future please do 
participate in the beta test so your unusual system gets tested.)

As Rob G has reported this from FreeBSD earlier today it is probably 
already fixed in R-devel (it is for him).  Fortunately the difference is 
in this case negligible.
On Tue, 17 Jun 2003, Don MacQueen wrote:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Don MacQueen
    

    

      
      #
    

  


  

      
I'm sorry, I neglected to provide version information.

In fact, I see the same result from make check on two different 
systems: Solaris 2.7 and OS X 10.2.6.

The "-0.00" values in reg-plot.ps.save are the kinds of values I saw 
in postscript files generated by R 1.7.0, i.e., prior to the fix of 
PR#3132.

In particular, in his r-help message on 2003-5-29 on the topic 
"Postscript query: plotting long vectors", Peter Dalgaard noted "If 
you want to use rlineto, you need to round *before* differencing." 
Values like "-0.00" could result from rounding *after* differencing, 
could they not?

My earlier message was from the OS X build. This is from make check on Solaris:
comparing 'reg-plot.ps' to '../../source/tests/reg-plot.ps.save' ...100c100
< 663.53 0 l
---

            

      
      
      
    

        
104c104
< 0 -7.20 l
---

            

      
      
      
    

        
On the OS X system:
configure --prefix=/Users/macq/R/R-1.7.1 \
    --enable-R-shlib --with-blas="-framework vecLib" --with-lapack \
    CPPFLAGS="-I/sw/include" LDFLAGS="-L/sw/lib"

On the Solaris system
source/configure --prefix=/erd/statistic/apps/R/R-1.7.1\
    --with-tcl-config=/erd/statistic/apps/R/tcltk/tcl8.3.3/unix/tclConfig.sh\
    --with-tk-config=/erd/statistic/apps/R/tcltk/tk8.3.3/unix/tkConfig.sh\
    --enable-R-shlib PERL=/apps/gnu/perl5/perl5.8.0/bin/perl

-Don

        
At 7:13 PM +0100 6/17/03, Prof Brian Ripley wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Don MacQueen <macq at llnl.gov> writes:

            

      
      
      
    

        
No, I don't think so. However, differencing after rounding (to two
digits) plus slightly odd formatting routines might do it. You have
the source... The logic is this:

static void PostScriptRLineTo(FILE *fp, double x0, double y0,
                              double x1, double y1)
{
    double x = rround(x1, 2) - rround(x0, 2),
        y = rround(y1, 2) - rround(y0, 2);

    if(x == 0) fprintf(fp, "0"); else fprintf(fp, "%.2f", x);
    if(y == 0) fprintf(fp, " 0"); else fprintf(fp, " %.2f", y);
    fprintf(fp, " l\n");
}

and it would seem that on some machines, rround(.,2) is not a perfect
step function, in that you can have two numbers rounded to slightly
different values.

(I see the same effect on Solaris 9, gcc 2.95.3 BTW. So you're not the
only one forgetting to platform test. It's just that our Sun is so
terribly slooooow...)