info-mac@uw-beaver (05/24/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Friday, 24 May 1985 Volume 2 : Issue 50
Today's Topics:
VMS SYSGEN modification needed in order to use MACGET
Floating point benchmarks on the Mac
C Benchmark
Megamax C floating point
harmonic series benchmark
Re: harmonic series benchmark
Re: Megamax C floating point
SetFile DA vs. new system
Set-File DA
Re: V2 #49 - more on clock, battery, and changing dates.
New Idle and Screensaver DAs
DA terminal query; programs as modes
Simple Database Required
----------------------------------------------------------------------
Date: Thu 23 May 85 12:14:30-PDT
From: John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
I've changed write2troff to handle MacWrite 3.x/4.x documents.
Attached is a "shar" archive of the new version. This version has
been sporadically tested with most versions of MacWrite from 3.96
onwards & seems to work. I've been told that it does strange things
with files produced by MacWrite 3.17 but, lacking my own copy of this
antique, I've been unable to verify or remedy the problems.
As always, please send bug reports, fixes, comments, etc., to me
(van@lbl-rtsg.arpa).
- Van Jacobson, Lawrence Berkeley Lab
[ Please find the archived copy in UNIX-MW4X@TROFF.SHAR -jma ]
------------------------------
Date: 23 May 85 13:35:00 EST
From: JOE WEINSTEIN <weinstein@bbnv1>
Subject: VMS SYSGEN modification needed in order to use MACGET
Reply-to: JOE WEINSTEIN <weinstein@bbnv1>
In order to use MACGET under VAX/VMS, it may be necessary to increase
the type-ahead buffer size specified at SYSGEN time from the default
value of 80 to something around 140-150 in order to be able to
accomodate an entire XMODEM record (128 characters, plus header)
without characters being lost and the transmission hanging
permanently. This is particularly likely to be true if your terminal
lines come into the VAX over a high-speed network connection, to which
the terminal lines are connected by means of a terminal concentrator
of one type or another, rather than over a direct line, because the
characters are then likely to come in much faster than MACGET can read
them. We encountered this problem when trying to use the EUNICE
version of MACGET over terminal lines which come in over an ETHERNET
using the Wollongong Group's terminal driver on the VAX, but I suspect
it is more general.
------------------------------
Date: 22 May 1985 15:58-EST
From: Duane.Williams@CMU-CS-K
Subject: Floating point benchmarks on the Mac
I ran the test described by Harry Lewis, i.e.,
float sum; /* 32 bits */
register int i;
sum = 0.0;
for (i=1; i <= 10000; i++) sum += 1 / (float)i;
using Megamax C on a 128K Mac. It runs in 74 secs. and gets the same
answer as its counterpart on the Vax 11/780, i.e., 9.787613.
If you change "float sum" and "(float)i" to "double sum" and
"(double)i", then the program runs faster, i.e., in 57 secs., and
again gets the same answer as its Vax 11/780 counterpart, i.e.,
9.787606!
------------------------------
Date: Wed, 22 May 85 00:47:15 pdt
From: huxham%ucbcory@Berkeley (Frederick A. Huxham)
Subject: Benchmark
Hi John,
The MacFest was great, especially both nights of speakers...good work.
After running Berkeley's Fest I appreciate all of the hard work
everyone at Stanford must have done to make everything come off so
well.
I've timed the Consulair "Mac C" floating point benchmark
we did this morning:
for (i=1; i < 10001; i++) sum = sum + 1/i;
depending on what type sum was declared to be:
type time
-----------------------
float (32bit) 16-17 sec.
double (64bit) 16-17 sec.
extended (80bit) 8-9 sec.
[ If I recall, this is the time between print statements, one before,
the other after the calculation. -jma ]
I just briefly looked over the new documentation yesterday but I think
I remember it said that in SANE everything is done with extended so if
you declare a type float or double it is converted to extended before
any computation takes place. Thus the times for float and double are
considerably slower.
Looks like Consulair implemented floating point quite a bit better
than either Aztec or Megamax judging by the benchmarks you had this
morning.
See you, Fred huxham@BERKELEY
------------------------------
Date: Wed, 22 May 85 20:25:31 EDT
From: Bob Walsh <walsh@BBN-LABS-B.ARPA>
Subject: Megamax C floating point
I'm not presenting a timed test, but information about Megamax
floating point correctness.
The program:
#include <stdio.h>
main()
{
float f, f2;
double d, d2;
int i;
FILE *fp;
f = (float) 0.0;
f2 = (float) 0.0;
d = (double) 0.0;
d2 = (double) 0.0;
fp = fopen("floatest.dat", "w");
for (i=1; i<=10000; i++){
f += ((float) 1.0) / i;
d += ((double) 1.0) / i;
f2 += ((float) 1.0) / ((float) i);
d2 += ((double) 1.0) / ((double) i);
if ((i < 10) || (i%1000 == 0)){
printf("i = %d f = %f d = %f f2 = %f d2 =
%f\n",
i, f, d, f2, d2);
fprintf(fp, "i = %d f = %f d = %f f2 = %f d2 =
%f\n",
i, f, d, f2, d2);
}
}
printf("f = %f d = %f f2 = %f d2 = %f\n", f, d, f2, d2);
fprintf(fp, "f = %f d = %f f2 = %f d2 = %f\n", f, d, f2, d2);
fclose(fp);
/*
while (! button())
; */
}
Megamax results:
i = 1 f = .007812 d = 1.000000 f2 = .007812 d2 = 1.000000
i = 2 f = .011719 d = 1.500000 f2 = .011719 d2 = 1.500000
i = 3 f = .014323 d = 1.833333 f2 = .014323 d2 = 1.833333
i = 4 f = .016276 d = 2.083333 f2 = .016276 d2 = 2.083333
i = 5 f = .017839 d = 2.283333 f2 = .017839 d2 = 2.283333
i = 6 f = .019141 d = 2.450000 f2 = .019141 d2 = 2.450000
i = 7 f = .020257 d = 2.592857 f2 = .020257 d2 = 2.592857
i = 8 f = .021233 d = 2.717857 f2 = .021233 d2 = 2.717857
i = 9 f = .022101 d = 2.828968 f2 = .022101 d2 = 2.828968
i = 1000 f = .058480 d = 7.485471 f2 = .058480 d2 = 7.485471
i = 2000 f = .063894 d = 8.178368 f2 = .063894 d2 = 8.178368
i = 3000 f = .067061 d = 8.583750 f2 = .067061 d2 = 8.583750
i = 4000 f = .069308 d = 8.871390 f2 = .069308 d2 = 8.871390
i = 5000 f = .071051 d = 9.094509 f2 = .071051 d2 = 9.094509
i = 6000 f = .072475 d = 9.276814 f2 = .072475 d2 = 9.276814
i = 7000 f = .073679 d = 9.430953 f2 = .073679 d2 = 9.430953
i = 8000 f = .074722 d = 9.564475 f2 = .074722 d2 = 9.564475
i = 9000 f = .075643 d = 9.682251 f2 = .075643 d2 = 9.682251
i = 10000 f = .076466 d = 9.787606 f2 = .076466 d2 = 9.787606
f = .076466 d = 9.787606 f2 = .076466 d2 = 9.787606
vax results:
i = 1 f = 1.000000 d = 1.000000 f2 = 1.000000 d2 = 1.000000
i = 2 f = 1.500000 d = 1.500000 f2 = 1.500000 d2 = 1.500000
i = 3 f = 1.833333 d = 1.833333 f2 = 1.833333 d2 = 1.833333
i = 4 f = 2.083333 d = 2.083333 f2 = 2.083333 d2 = 2.083333
i = 5 f = 2.283334 d = 2.283333 f2 = 2.283334 d2 = 2.283333
i = 6 f = 2.450000 d = 2.450000 f2 = 2.450000 d2 = 2.450000
i = 7 f = 2.592857 d = 2.592857 f2 = 2.592857 d2 = 2.592857
i = 8 f = 2.717857 d = 2.717857 f2 = 2.717857 d2 = 2.717857
i = 9 f = 2.828969 d = 2.828968 f2 = 2.828969 d2 = 2.828968
i = 1000 f = 7.485478 d = 7.485471 f2 = 7.485478 d2 = 7.485471
i = 2000 f = 8.178369 d = 8.178368 f2 = 8.178369 d2 = 8.178368
i = 3000 f = 8.583756 d = 8.583750 f2 = 8.583756 d2 = 8.583750
i = 4000 f = 8.871394 d = 8.871390 f2 = 8.871394 d2 = 8.871390
i = 5000 f = 9.094514 d = 9.094509 f2 = 9.094514 d2 = 9.094509
i = 6000 f = 9.276819 d = 9.276814 f2 = 9.276819 d2 = 9.276814
i = 7000 f = 9.430960 d = 9.430953 f2 = 9.430960 d2 = 9.430953
i = 8000 f = 9.564480 d = 9.564475 f2 = 9.564480 d2 = 9.564475
i = 9000 f = 9.682266 d = 9.682251 f2 = 9.682266 d2 = 9.682251
i = 10000 f = 9.787613 d = 9.787606 f2 = 9.787613 d2 = 9.787606
f = 9.787613 d = 9.787606 f2 = 9.787613 d2 = 9.787606
The Megamax documentat ion claims to use Macintosh IEEE 80 bit floating
point numbers. There seems to be a problem converting them to a 32
bit floating point number, but not to a 64 bit floating point number.
Since all floating point (VAX or Macintosh) in C is done with the same
precision (VAX=8 bytes, Mac=10 bytes) and it is only how it is stored
that differs between floats and doubles, one might as well use the
extra 4 bytes of storage and gain accuracy and speed. (The VAX
compiler does a lot of work converting float <--> double for floats).
This is not to say the Megamax compiler is treating floats properly.
I'm glad it was brought up, I might not have discovered this problem
so easily in something more complex.
bob walsh
------------------------------
Date: 22 May 1985 11:21:18 PDT
Subject: harmonic series benchmark
From: Richard Gillmann <GILLMANN@USC-ISIB.ARPA>
I haven't had a chance to try your harmonic series benchmark yet, but
I wanted to ask you whether you added up the series starting with 1/1
or with 1/10,000? If you start with 1/1 then I should think the
result would be dominated by roundoff errors, which after all can
differ from one floating point system to another, depending on the
base for exponents, whether the leading normalized bit is implicit,
etc. Whereas if you start with 1/10,000 and work up, roundoff error
would be less of a problem.
------------------------------
Date: Wed, 22 May 85 16:33:13 EDT
From: lewis@harvard.ARPA (Harry Lewis)
Subject: Re: harmonic series benchmark
Good point. I've been doing it from 1/1 -> 1/10000, but I should go
back and try it the other way.
------------------------------
Date: Thu, 23 May 85 08:30:04 EDT
From: lewis@harvard.ARPA (Harry Lewis)
Subject: Re: Megamax C floating point
Interesting. I didn't know that all C fp was really done with
doubles. Is that well-known (part of a standard, common practice, or
what?
Just out of curiosity, could you run the same program except changing
the loop control to
for (i=10000; i>0; i--) ? It has been suggested that this
might lead to much less accumulation of fp roundoff errors than
starting with the bigger terms.
------------------------------
From: stew%lhasa@harvard.ARPA
Date: 22 May 85 13:12 EDT
Subject: SetFile DA vs. new system
I discovered the same problem when I first installed SetFile some time
ago. The problem is that it MUST be DRVR 19, and its associated
resources must be correctly numbered ($C000 + 19*$32 + i where 0 <= i
<= 31, as per Inside Mac, Resource Manager, page 10). The new system
expects the DA to figure out what its ID is and look for the
corresponding owned resources. All of the others that I have tried
seem to do this, but the authors of SetFile were lazy, and didn't give
us the source so we could fix it.
Workaround: Install whatever DA's you want. Copy SetFile to a new
file in Font/DA mover format. Exit the Font/DA mover and go into the
Resource Editor. Open the DRVRs in System. Note which one is number
19. Go back to Font/DA mover. Delete the DA which you noted. Open
the file in which you stored SetFile. Copy it to System. With any
luck, this will install it as number 19 and renumber all of the
resources appropriately. Now go back and reinstall the DA which used
to be number 19; it will get a new number.
While we're on the topic, here's the definitive list of changes made
to the system file by the update procedure:
New resources:
ALRT -15679
DITL -15679, -15680
DLOG -15680
DRVR 22
ICON -15680, -15679
STR# -15680 These are all part of the "Choose
Printer" DA. Your ID numbers
may
differ depending on what DA's
you
had in your system already.
INIT 4 Patch OpenResFile so that if
curApName == FinderName and a
couple of magic bits are set
and
the file "MiniFinder" exists
on
the default volume, it is
opened
instead.
INIT 13 Left as an exercise to the reader.
Memorize those machine ops!
PAPA -8192 Something to do with printer
selection.
Changed resources:
DRVR 2 ".Print" Quite a bit smaller.
FKEY 4 I guess maybe this is so that
screen dumps go to
LaserWriters OK?
PACK 3 Standard File package. Changes
described in the update info.
PACK 4, 5 Floating pt. and Transcendental
Functions. Guess they fixed
some
bugs.
STR 0 "Version 2.0 08-Apr-85". Everyone
get the same one?
STR -8192 Something else to do with printer
selection, maybe.
That's it. All other resources left unchanged. Anyone know what was
fixed in the floating pt packages?
By the way, I checked the resource files with a program I wrote. It
gives you a sorted list of resources in a specified file, together
with names, lengths and crc's. If there is a clamor for it, I will
upload it. I took these lists and uploaded them to my vax for
diff'ing. Anyone want to write a diff for the Mac? Perhaps the GNU
diff can be ported...
Stew rubenstein@harvard.arpa
{ihnp4,ut-sally,seismo}!harvard!rubenstein
------------------------------
From: David Burnard <burnard@lll-crg.ARPA>
Date: 23 May 1985 0840-PDT (Thursday)
Subject: Set-File DA
It was reported recently that the Set-File Desk Accessory bombs with
the new system release from Apple. The authors of Set File DA, Sam
Roberts and Fred Huxham, rewrote the DA with assistance from Steve
Capps from Apple. There had been a bug in the SFGetFile package in the
old system files. The current version is 2.0, dated sometime in April.
This version checks to see if you are using an old system, and if so
reports that it needs to be updated.
I have used this version now for over a month, without problems. So
check that you are using version 2.0, that you have properly updated
your system, and that the DA Mover didn't muck up the owned resources
that Set File DA requires (if you used the DA Mover). If you still
have problems, let me or Fred know and we will forward the info to
Sam.
The Famous(?) Fred, Sam and Dave Software
Company
Dave Burnard
burnard@lll-crg
or Fred Huxham
huxham@berkeley
------------------------------
Subject: Re: V2 #49 - more on clock, battery, and changing dates.
Date: 22 May 85 12:14:38 EST (Wed)
From: Christopher A Kent <cak@Purdue.ARPA>
Since the Mac's clock is run digitally, instead of by a motor, I
wouldn't expect the speed to change; it would either run or not. And
it would either retain the time or set a random value, which sounds
like what you're getting...
chris
------------------------------
Date: Tue, 21 May 85 20:05:19 edt
From: roy@nlm-vax (Roy Standing)
Subject: New Idle and Screensaver DAs
I find that I would really like to have one DA which combines features
of both New Idle and Screensaver. New Idle has the feature of
blanking the screen but leaving a moving icon. This conserves the Mac
CRT while reminding me that the system is on -- excellent!
Screensaver recognizes that I never know when I'll be called away or
for how long. It features a setable timeout, if no input is received
for the specified time period it turns off the screen. Unfortunately,
it leaves a stationary cursor so that burn-in can still occur at the
cursor location.
A combination of these two great ideas would really answer my desires.
Am I alone in this desire, are the DA authors interested in
suggestions???
While I'm noting wishlist DA items:
1) Diskinfo gives a good directory display. Extras has more
functionality
but requires more mouse manipulation to use. How about putting a
Diskinfo-like directory display in extras and making it the default
display window when Extras is invoked?
2) How about a DA that supports Create, Delete, Move, Copy, Rename,
and Directory? A Rename facility would be VERY nice, it would
allow the user to change scrapbook files from within applications
as an example.
I should note that a) I'd like to see more of the basic OS facilities
placed in DAs, and b) I'd like to see the Mac OS allow the user to
select the scrapbook and notepad filenames. In the same vein, all
fonts beyond the requied system fonts could be in disk files -- the OS
would simply maintain a list of path/filenames and fetch them as
needed.
These are my personal opinions, comments are always welcome. None of
my comments are intended to offend the authors of the DAs or OS.
Their good work speaks for itself.
------------------------------
Subject: DA terminal query; programs as modes
Date: 23 May 85 06:25:49 EDT (Thu)
From: zim@mitre.ARPA
I love MockTerminal, but have become tired of its bad scrolling and
occasional propensity to bomb out ... could anybody give me pointers
to other desk accessory terminals? I really want to have everything I
use a lot as a DA, if possible, so I can open a bunch of them up at
once and move around. After all, "running a program" is really the
same as being stuck in a "mode" ... and at times, it's worse than
being in "insert mode" on a regular editor. Desk accessories are the
closest thing to the "mode-free" Mac philosophy, no? Anybody know of
a DA spreadsheet? -z
------------------------------
Date: Tue, 21 May 85 21:09:16 EDT
From: Joel Malman <malman@BBNH.ARPA>
Subject: Simple Database Required
Is there a simple database program available, in the public domain,
for the Mac? I am looking for something simple, something even a child
could use. A program in MicroSoft Basic, using random access records
would do. Any pointers?
joel
------------------------------
End of INFO-MAC Digest
**********************