hagen@modular.UUCP (Jeff Hagen) (01/28/88)
RE: NeWS on Sun Is there a limit to the size NeWS allows on the scale and translate functions? For example, % this draws a 45 degree line gsave -10 -20 translate 10 20 moveto 82 92 lineto stroke grestore % but this doesn't: gsave -100000 -200000 translate 100000 200000 moveto 100144 200144 lineto stroke grestore This doesn't cause an error, but it seems to be ignored. I found that translate on the order of 10000 will work as advertized. The problem can be fixed of course by prescaling the data before plotting, but I don't see any reason ( at least from the NeWS manuals ) why this shouldn't work. Also, has anybody gone to the trouble of writing a key-repeat function in NeWS? I suspect it is possible by waiting for the up-transition a certain time after the down transition... Jeff Hagen arizona!modular!hagen Modular Mining Systems (602) 746-9127 1210 E. Pennsylvania St. Tucson, Az 85714
ronb@natmlab.dms.oz (Ron Baxter) (02/08/88)
In article <539@modular.UUCP> hagen@modular.UUCP (Jeff Hagen) writes:
=RE: NeWS on Sun
=Is there a limit to the size NeWS allows on the scale and translate functions?
=For example,
=% this draws a 45 degree line
=gsave -10 -20 translate 10 20 moveto 82 92 lineto stroke grestore
=% but this doesn't:
=gsave -100000 -200000 translate 100000 200000 moveto 100144 200144 lineto
=stroke grestore
=This doesn't cause an error, but it seems to be ignored.
=I found that translate on the order of 10000 will work as advertized.
I have struck this one -- it goes wrong when the numbers
go over 32000 (presumably 2^15). A translation happens,
but th wrong one so if often disappears off the screen.
Capter 13, under implementation limits quotes this limit
but says that then the vaues are automatically converted
to real. Apparently this is not happening in this case.
--
Ron Baxter, CSIRO Div Maths & Stats, PO Box 218, Lindfield, NSW, Australia.
PHONE: +61 2 467 6059 ACSNET: ronb@natmlab.oz
ARPA: ronb@natmlab.oz.aus radford@calgary.UUCP (Radford Neal) (02/21/88)
In article <2090@natmlab.dms.oz>, ronb@natmlab.dms.oz (Ron Baxter) writes: > I have struck this one -- it goes wrong when the numbers > go over 32000 (presumably 2^15). A translation happens, > but th wrong one so if often disappears off the screen. > > Capter 13, under implementation limits quotes this limit > but says that then the vaues are automatically converted > to real. Apparently this is not happening in this case. Fixed point numbers are automatically converted to reals as required in the SUN-only version of NeWS, but not in the "portable" version. This is because whoever re-wrote the fixed-point arithmetic routines in C rather than 68000 assembler decided that overflow checking wasn't really necesary. The fix is not hard if you've got the source - I'll mail it to you if you're interested. Of course, if you're using the SUN-only version, I've mis-diagnosed your problem. Radford Neal
msc@ramoth.SGI.COM (Mark Callow) (02/27/88)
In article <1369@vaxb.calgary.UUCP>, radford@calgary.UUCP (Radford Neal) writes: > > Fixed point numbers are automatically converted to reals as required > in the SUN-only version of NeWS, but not in the "portable" version. > This is because whoever re-wrote the fixed-point arithmetic routines > in C rather than 68000 assembler decided that overflow checking wasn't > really necesary. The fix is not hard if you've got the source - I'll > mail it to you if you're interested. > > Of course, if you're using the SUN-only version, I've mis-diagnosed > your problem. > > Radford Neal The C routines were only provided as a porting aid. Any vendor who used them in a product should be hung out to dry. In both Release 1.0 and a preliminary version of 1.1 there are many places where the overflow flag simply isn't checked yet needs to be. The inverse delta transform is one such place. So even if your fractional arithmetic routines set the flag you can still get overflows. Just try drawing out the calculator to a large size when the word "calculator" is still showing in the calculators display. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
radford@calgary.UUCP (Radford Neal) (02/28/88)
In article <11753@sgi.SGI.COM>, msc@ramoth.SGI.COM (Mark Callow) writes: > > Fixed point numbers are automatically converted to reals as required > > in the SUN-only version of NeWS, but not in the "portable" version. > > This is because whoever re-wrote the fixed-point arithmetic routines > > in C rather than 68000 assembler decided that overflow checking wasn't > > really necesary... > The C routines were only provided as a porting aid. Any vendor who used > them in a product should be hung out to dry. If I have correctly interpreted the tone of this comment, you think my criticism above was misdirected, overly-picky, pedantic, whatever. I am unable to fathom this view. If the C routines were intended as a "porting aid", surely it is crucial that they perform all the required functions, albeit slowly. This way, the person rewriting them in assembler for their machine will actually know what they are supposed to do... As you appear to be familiar with NeWS source code, you surely aren't going to claim that the function of these routines is obvious from the documentation, are you? Radford Neal
msc@ramoth.SGI.COM (Mark Callow) (02/29/88)
In article <1399@vaxb.calgary.UUCP>, radford@calgary.UUCP (Radford Neal) writes: > In article <11753@sgi.SGI.COM>, msc@ramoth.SGI.COM (Mark Callow) writes: > > > The C routines were only provided as a porting aid. Any vendor who used > > them in a product should be hung out to dry. > > If I have correctly interpreted the tone of this comment, you think my > criticism above was misdirected, overly-picky, pedantic, whatever. > > I am unable to fathom this view. If the C routines were intended as > a "porting aid", surely it is crucial that they perform all the required > functions, albeit slowly. This way, the person rewriting them in > assembler for their machine will actually know what they are supposed > to do... I'm not being overly picky. I simply don't believe the C fract routines should be used in a product. If I remember right the porting guide says this and also warns that they don't check for overflow. They serve as a means to get NeWS up quickly and that is all. I was never in any doubt that they didn't check overflows and I also never had any trouble understanding what they were supposed to do. When I was porting NeWS to the mips, I looked at these C routines and concluded it would be hard to do proper overflow checking in a C language version. I implemented the routines in mips assembler using the 68020 assembler version and the comments in fract.c as a guide. In retrospect, I can see that some judicious comparisons of signs would probably have worked. > > As you appear to be familiar with NeWS source code, you surely aren't > going to claim that the function of these routines is obvious from > the documentation, are you? > The function of the routines is obvious from the function names: frmul, vfrmul, frdiv, vfrdiv etc. The algorithms used are not so obvious but there *are* some helpful comments in fract.c especially in frmul. As I said in my article there are plenty of places that don't check the overflow flag so even when the fract routines are doing the right thing you aren't out of trouble. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
radford@calgary.UUCP (Radford Neal) (03/02/88)
In article <11843@sgi.SGI.COM>, msc@ramoth.SGI.COM (Mark Callow) writes: > In article <1399@vaxb.calgary.UUCP>, radford@calgary.UUCP (Radford Neal) writes: > > If the C routines were intended as > > a "porting aid", surely it is crucial that they perform all the required > > functions, albeit slowly. This way, the person rewriting them in > > assembler for their machine will actually know what they are supposed > > to do... > ... If I remember right the porting > guide says this and also warns that they don't check for overflow. > They serve as a means to get NeWS up quickly and that is all. I was > never in any doubt that they didn't check overflows and I also never > had any trouble understanding what they were supposed to do. My copy of the porting guide says nothing about this. I discovered the problem when my test program failed in windows larger than about an inch on a side. From there it took about two or three hours to track down the difficulty. I think this is doing quite well; I can easily imagine someone taking days to find the problem. > The function of the routines is obvious from the function names: frmul, > vfrmul, frdiv, vfrdiv etc. The algorithms used are not so obvious but > there *are* some helpful comments in fract.c especially in frmul. Nothing in that module indicates that overflow checking was omitted. Nothing indicates how overflows should be reported if they are checked for. The comments in frmul don't say anything that everyone doesn't already know. I figured out how to report overflows by looking at the PostScript interpreter and the 68000 version of the fract routines (which do check). It then took me about a half hour to add the overflow checks. > As I said in my article there are plenty of places that don't check the > overflow flag so even when the fract routines are doing the right thing > you aren't out of trouble. I'm not sure what you mean to imply by this comment. Are you saying that SUN was right not to bother with overflow checking in fract.c? The fact that there are problems elsewhere in the code doesn't seem to me to be a justification. I am puzzled by the tone of this discussion. I think it is only reasonable for customers to bitch a bit when software is written poorly. After all, this problem took up several hours of my time, but took me only half an hour to fix myself, once the problem was understood. Wouldn't it have been better if SUN had taken the extra half hour? Now, I understand that the people working on NeWS are under pressure to get the product out the door. There's obviously a tradeoff between quality and release date. I just don't think leaving the overflow checks out of fract.c is a good tradeoff. Radford Neal
msc@ramoth.SGI.COM (Mark Callow) (03/05/88)
In article <1419@vaxb.calgary.UUCP>, radford@calgary.UUCP (Radford Neal) writes: > Now, I understand that the people working on NeWS are under pressure to > get the product out the door. There's obviously a tradeoff between > quality and release date. I just don't think leaving the overflow checks out > of fract.c is a good tradeoff. > > Radford Neal How you got the impression I was advocating leaving out the overflow checks I don't know. I was warning you that fixing fract.c isn't sufficient to cure the overflow problems. Many places that should call vfrmul, and then check the overflow flag, don't. The checks are important. In fact I've just been talking to Sun about some of the places that don't check. Incidentally, when I saw that vfrmul in fract.c simply called frmul I realised immediately that no overflow checking was happening. Possibly I had an advantage in that I had first dealt with a 68020 port using the fract.s routines. I knew the distinction between frmul and vfrmul and about fract_overflows. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."