info-mac@uw-beaver (06/13/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.arpa> INFO-MAC Digest Thursday, 13 Jun 1985 Volume 3 : Issue 8 Today's Topics: Floating point Questionnaire RE: Appletalk Cable components Hayes/MacTerminal Info Laserwriter gripes finder 4.1 lament New Finder Bug Re: MacWrite 4.5 BUG MacImp + SCRIBE problems Sheet Feeder for Apple Daisy Wheel Printer? ---------------------------------------------------------------------- Date: 11 June 85 00:50 EDT From: QP2%CORNELLA.BITNET@Berkeley Subject: Floating point Questionnaire To respond to Bruce Cohen's questions about interest in floating point computations: Jerry Lefkowitz and I have written a full-function statistics package for the Mac. Although the program depends heavily on the Mac environment (it is a statistics desktop), we wouldn't have considered the Mac at all were it not for the full IEEE floating point numerics in SANE. The package is in Lisa Pascal and we use SANE extensively. 2) The performance of the floating point routines is, of course, important to us. We have generally found SANE to be fast enough -- about what you'd expect for a software floating point. We do look forward to the improvement that should come when SANE moves into the new ROM. 3) We may have been one of the first shops to convert to Lisa Workshop 3 We did it in part to get the SANE libraries to work on expressions. 5) Floating point hardware would be ideal -- provided it was a Motorola 68881 or something functionally equivalent. One of the beauties of SANE is that it will match the 68881 results so that in the future a one drive 128K Mac (yes, we do run on them) will get the same answers as a turboMac with 68881. 6) Among the IEEE features that we take advantage of are the presence of infinities and NaN's. NaNs provide a convenient tool in handling missing values in statistics operations because they propagate correctly and painlessly. We have been VERY impressed with the quality of numerical results from SANE. We regularly exceed the precision of results from standard mainframe packages, and find that even when we compute a statistic in two very different ways, we get the same value to as many places as we print. IEEE floating point can protect you from a wide range of numerical sins -- possibly even summing a harmonic series in the wrong direction. Note: The 68881 uses 96-bit extended values. For those of you who care, it is probably better to store numbers in double and compute in extended for maximum upwards compatibility. 80-bit extended values are pretty local to the Mac. I have been a bit dismayed at the extent to which the debate has concentrated on the *speed* of floating point calculations rather than the properties of the numerical algorithms behind the floating point. The IEEE standard is so much better than other floating points (especially IBM 370 and relatives) that anyone who really wants good numbers should be willing to pay some speed penalty to use it. I don't want possibly bad results fast when I can have excellent results reasonably fast. The remarkable thing about SANE is that it is not significantly slower than other floating point implemen- tations. Don't be misled by counting the number of digits or bits in floating point numbers. The important aspect of IEEE arithmetic is what it does with the two special bits on the mantissa, not how many digits it carries. In IEEE arithmetic, the result of any binary operation is what you would have gotten on a machine with infinite precision, rounded (or truncated -- your choice) to the available mantissa length. This is about as close to optimal as I can imagine. In addition, there are specific representations for infinities, -0, and Not-a-Number (so Log(-1) can return something). Other floating point methods can be defeated without generating overflow or underflow conditions. Also, don't be mislead by compilers that store numbers "in IEEE format" but don't actually use the IEEE numeric algorithms. This is not a substitute for (or even close to) IEEE arithmetic. -- Paul Velleman Cornell University QP2 @ Cornella ------------------------------ Date: Mon, 10 Jun 85 11:46:12 edt From: Steve Ligett <stevel%dartmouth.csnet@csnet-relay.arpa> Subject: RE: Appletalk Cable components From an article by Jim Damoulakis, in the April/May 1985 issue of AppleView (a publication of the Apple Marlboro Support Center Technical Support Department): "Two outside vendors that can supply AppleTalk cable in bulk are: Montrose Corporation - Telephone 1-800-423-3014 - PVC Cable Part # CBL 6242 - Teflon Cable Part # CBL 6228 - Assembly Plug Part # 815-0878A Belden Corporation - Telephone - 1-800-BELDEN-1 - PVC Cable Part # 9999 - Teflon Cable Part # 89999 - Assembly Plug Part # 815-0878A" Steve Ligett CSNET:stevel@dartmouth or UUCP:(astrovax bedford colby cornell dalcs decvax harvard ihnp4 linus lscvax psc70 research uvm-gen)!dartvax!stevel ------------------------------ Date: Tue 11 Jun 85 08:15:13-PDT From: PIERCE@SRI-KL.ARPA Subject: Hayes/MacTerminal Info At the A32 meeting in San Jose, CA on June 8 there was a presentation by reps from Apple and Hayes on their terminal programs (and Hayes modem). This is a brief review of what I saw. **** Hayes ***** They showed Smartcom II working over a cellular (i.e. Car) phone system. (!) The main feature of Smartcom was extensive "Auto-pilot" (macros) capability. It allows unmonitored dialing (at wierd times), dial different number (if busy), wait for login prompt,etc. It looked like a simple programming language all by itself. It would also allow transfer of graphics for over-the-phone discussions - an interesting feature I would never use unless I had two phones, one for voice and one for Mac. It was really designed for the Hayes Smart Modem 2400 and I don't think it would do much for any other modem (I don't think it could even work with the apple modem) I couldn't tell how good it was at emulating the VT100 or whatever. Probably worth looking into if you need the macro capability. **** MacTerminal 2.0 ***** One of the MacTerminal authors (Mike Boich) showed the old standby. What was interesting was what the enhancements would be to version 2.0. He said they were aiming for completion of the code by end of June and shipment in mid July. (Never trust a programmer. My guess would be end of July - they still have to code up the binary protocol.) What follows is a list of MacTerminal 2.0 enhancements. Some of these were meaningless to me so the transcription may be shakey. 1 - Wait for call with the Apple Modem will be fixed (It really will wait when told to) 2 - Disk will not spin as much (never if not saving past top of screen and less often when saving past top of screen) 3 - Fixed so will work at same time as LaserWriter (AppleBus??) 4 - Serial Port Fix-up (??) 5 - Fix some of the VT100 ESC characters 6 - Fix some of the character sets (and add a bunch of new ones) 7 - Fix copy / paste so it works right 8 - By holding down the option key allow skipping of all confirming requests 9 - MacBinary transfer protocol built in 10 - Work with switcher (but not in background mode) 11 - Add keyboard equivalents to cursor keys (not just in keypad or mouse driven). Probably will be IJKM pattern. There will be no new terminals emulated and no macros added. I think MacTerminal 2.0 will be an correction / upgrade to 1.0 not the product I was hoping for. Pierce@SRI-KL ------------------------------ Date: Mon 10 Jun 85 13:01:57-EDT From: Robert.Berger@CMU-CS-C.ARPA Subject: Laserwriter gripes I'm using MacWrite and the LaserWriter to print a paper I'm publishing. While the output quality is well worth the trouble, there are some annoying "features". The what-you-see-is-what-you-get paradigm goes out the window when using the Laserwriter fonts; I'm always printing test prints, just like I did when using batch-style word processors. For example, the output width is no longer what you specify in the MacWrite rulers. This is a slight annoyance when producing camera-ready output. Also, spaces come out drastically different. This is a MAJOR annoyance when trying to format multi-line math formulas, such as summations and integrals. This worked much better with the Imagewriter. In all, the latest round of software to come out of Apple is not up to their previous standards. My pet peeve in the new finder is that if you type-ahead an eject disk command while a program is exiting, the finder ejects the disk and then immediately asks for it to be re-inserted. The old finder was smart enough to grab what it needed before doing the eject. Robert Berger Berger@cu-cs-c ------------------------------ Date: Mon, 10 Jun 85 20:10:55 EDT From: Joel Malman <malman@BBNH.ARPA> Subject: finder 4.1 lament I can not seem to understand the logic the 'Clean up' command uses to place files and folders on the desktop. Clearly it is not alphabetic. Nor does the command produce eye-pleasing results. Icons frequently end up "half-off" the desktop. If no one can explain the placement -- Can Mr. Capps please improve the algorithm? How about alpha-numeric, left to right, fully dependent on horizontal window size, with the (right hand) scroll bar actived (vertical size), if required. Has anyone noticed that OPTION/Clean-up sometimes produces a different layout than just plain Clean up? Confused, joel ------------------------------ Date: 11 Jun 85 12:08:16-CDT (Tue) From: Canas%ukans.csnet@csnet-relay.arpa Subject: New Finder Bug I don't know if this bug has been reported but I haven't seen it on the Network. Eject the disk from the external drive. Insert another diskette. Before the mouse pointer turns into a watch, trash the icon of the diskette previously ejected. (may have to do this very fast). The system will crash... Daniel canas@ukans ------------------------------ Date: Wed, 12 Jun 85 09:48:47 EDT From: mazur@harvard.ARPA (Eric Mazur) Subject: Re: MacWrite 4.5 BUG About two weeks ago I reported a "bug" in my version 4.5 MacWrite. The problem I was having, was that I was not able to backspace in the line/paragraph just underneath a ruler. Several people replied that they were not able to reproduce this "bug", so I went back to the dealer to make a new copy.... No more problems: I can backspace again! Apparently I had received some kind of bogus MW4.5 the first time. How can that be? Anyway, excuse me if I caused some confusion. Eric Mazur Harvard University ARPA-NET: mazur@harvard.arpa BITNET: MAZUR@HARVUNXH.BITNET UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!mazur ------------------------------ Date: Wed 12 Jun 85 08:06:15-PDT From: Steve Dennett <DENNETT@SRI-NIC.ARPA> Subject: MacImp + SCRIBE problems MacImp does a nice job of turning MacPaint files into Imagen-printable files. But when I try to include these files in Scribed documents [ using @PICTURE ], the result is that the last line of text is trashed and about 3/4 page of blank space is added above and below the image. Has anyone else experimented with this? Does anyone know of a way to cause MacImp to trim white space from around the image and center it on the page? Thanks for your help. Steve Dennett dennett@sri-nic ------------------------------ Date: Tue, 11 Jun 85 7:18:47 EDT From: Robert E. Yellen (MISD-SEAD) <ryellen@Ardc.ARPA> Subject: Sheet Feeder for Apple Daisy Wheel Printer? I'm looking for a sheet feeder for an Apple Daisy Wheel Printer. Can anyone supply a souce and any recommendations? I'd be willing to recap any feedback to info-mac. ryellen@ardc ------------------------------ End of INFO-MAC Digest **********************