🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11421

Re: Hardware Support for Numeric Algorithms

#11421
From: Volker Herminghaus-Shirai
Date: Sun, 22 Nov 1992 19:23
91 lines
5335 bytes
In article <1efg1gINNm6c@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
> akao@.com (Adam Kao) writes:
> : In article <Bxv2t2.4FH@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman  
Rubin) writes:
[lament deleted] 
> Poor ideas or confusing notation in mathematics disappears with the next
> journal issue, but computer software and languages tend to stay around
> for a long time, and so even more so than math, they require substantial
> thought put in their design.

The poorest idea mathematicians had was to use only single characters as
variable names and optimize the multiplication symbol away. This definitely
did not disappear with the next journal issue (there were no journals at
that time). Instead, it led to using all sorts of special characters like
greek or ancient german ones (for matrices) due to name space overcrowding.
BTW I read an article here some time ago by a statistician who complained
about keyboards that couldn't enter these special characters :-)

> Also remember that Usenet, and especially these newsgroups, have a very
> CS-centric view of things, and I think that more people than you expect
> "out there" have feeling similar to mine or Herman's.

Well, usenet runs on real computers, not on mathematical theories.

> I certainly believe us "o'dinry fo'ks" out here have things to learn from
> computer scientists, especially w/r/t the social realities of software
> engineering, and I hope the computer scientists ought to try to learn some
> from us.

Just as much as from any other professional group. The bankers would probably
kick our butts if CS only created languages with mathematical notations,
orphaning their Cobol superprogrammers ;-)

> Incidentally, my favorite computer language, Sather, (a simplified
> speedified Eiffel), was designed by Steve Omohundro, a computer whiz,
> who got a PhD in high-energy physics.  Somehow, it just feels "right".

If it feels "right" for you, use it. I doubt I would like it, though.
If Mathemathics can create demand high enough to support (also
financially) the development of a special language, CS will eventually
do it. Just as for other sciences and professions.

> Back to prof. Rubin's point.  I think it would be nice if language
> designers would recognize that *hardware WILL change*, and that
> they design it in a way such that it becomes natural or easy for
> future implementors to put in new operations that don't interfere with
> old ones.  The idea is not to freeze into a single model of computing,
> and have hardware extensions treated as pariahs, only for use by grungy
> hackers, and so we shouldn't give much though to them, and as a result
> everybody has a different ugly way of doing them.  It's just a change of
> attitude, mostly.

Too bad we never know in advance just *how* hardware will change.

> Scientists, especially in the high-performance world, have a more concrete
> view of computers, that may be sometimes short-sighted, but in other cases
> may be more refreshing.
> 
> As an example, consider a Connection Machine---it's hardware is so fundamentally
> different, and so to even have a chance of writing intelligent programs, it's
> essential to be able to express these fundamentally new methods in software.
> (And yes, they do it.)  Herman's point is that more computers than you think
> may need this, especially as supercomputer-research-type stuff starts coming
> down to earth.  We don't want 87 completely different dialects of C, or tricky
> obscure code that compiles into something simple. We accept the necessity
> of hardware dependence, but we want it tamed, rather than excommunicated.

In the very moment you get hardware dependent you also lose portability. If
you accept loss in portability, do it in assembler. If you need a portable
assembler with elementary type-conversion and safe subroutine calls, symbolic
names for variables and little overhead, use C. That's about as close to
assembler (as hardware dependent) as you can get without resorting to assembler.
I also can hardly imagine what a language would look like that had some special
operators for e.g. "FP division by integer value with remainder saved" on one
architecture but would compile and run on another one.
Other than #define-ing some assembler macros for each machine and inlining the
expansions.

> : Adam
> : "Those French people have a different word for _everything_!!!"

Right, the word for "everything" is "tout" in french, which is indeed
a different word from "everything" :-)

--
Volker Herminghaus-Shirai (vhs@rhein-main.de)

Computer industry: Industry in which the number of units sold of any
given product is inversely proportional to its technical excellence.
See also: MS-DOS, Windows, IBM-PC, X, QWERTY,
          80x86, TrueType, Survival of the shittest.
Technical Details
Message-ID: <1992Nov22.192342.10288@qb.rhein-main.de>
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!Germany.EU.net!incom!orfeo!qb!vhs
References: <1efg1gINNm6c@network.ucsd.edu>

Show Full Headers
Complete Article Headers
Newsgroups: comp.arch
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!Germany.EU.net!incom!orfeo!qb!vhs
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: Hardware Support for Numeric Algorithms
Message-ID: <1992Nov22.192342.10288@qb.rhein-main.de>
Sender: vhs@qb.rhein-main.de (Volker Herminghaus-Shirai)
Reply-To: vhs@rhein-main.de
References: <1efg1gINNm6c@network.ucsd.edu>
Date: Sun, 22 Nov 92 19:23:42 GMT
Lines: 91