pretty(.) bug -- fix --> "compatibility" ?

Martin Maechler Martin Maechler <>
Wed, 4 Mar 1998 16:05:06 +0100

In current versions of R,  


gives an infinite loop  
	(due to a silent integer overflow in  src/appl/pretty.c).

I've looked at this problem and also at what S-plus does,
(no code there to inspect, just experiments), and
then I have fixed  pretty.c.

I think that it now behaves much more reasonably 
	(both than before and than S / S-plus).

The only problem:
pretty(.) is not giving the same results any more in quite a few cases,
*and* is used in graphical functions such as
and	contour(.)

Could this be a problem? [non-upward compatibility]
Currently, I plan to have the fixed  pretty(.) even in the upcoming
0.61.2 release which is termed
	"bug fix only"
The new pretty would however (very rarely) change the output of, e.g., hist(.).

Further, S-plus's pretty behaves wierdly in some cases  
which we don't want to emulate anyway.
In other cases pretty(1001.1001), however, it returns 1000 1500 
which is quite different from my improved R version which gives 1000 1002.

Is it okay for you if we do NOT strive for S-plus compatibility here?
Strict S-plus compatibility is not possible, since we don't have S-plus
code; but it is also not desirable in the cases where S's pretty() is
However, with more experiments and thought, it ought to be possible
to come quite close to S's behavior.
But I don't want to spend that extra time if there are no stringent

Martin Maechler <>			<><
Seminar fuer Statistik, ETH-Zentrum SOL G1;	Sonneggstr.33
ETH (Federal Inst. Technology)	8092 Zurich	SWITZERLAND
phone: x-41-1-632-3408		fax: ...-1086

r-devel mailing list -- Read
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: