Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

INFO-MAC Digest V3 #8

1 view
Skip to first unread message

info-mac@uw-beaver

unread,
Jun 12, 1985, 11:04:38 PM6/12/85
to
From: Moderator John Mark Agosta <INFO-MAC...@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%dartmou...@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: PIE...@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...@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 <mal...@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-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: ma...@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: ma...@harvard.arpa BITNET: MA...@HARVUNXH.BITNET UUCP:
{seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!mazur

------------------------------

Date: Wed 12 Jun 85 08:06:15-PDT
From: Steve Dennett <DEN...@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) <rye...@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
**********************

info-mac@uw-beaver

unread,
Jun 13, 1985, 1:31:54 AM6/13/85
to
0 new messages