From: Rostyslaw J. Lewyckyj on
glen herrmannsfeldt wrote:

> Brooks Moses wrote:
>
> (snip)
>
>> type polar_complex
>> real :: angle, magnitude
>> end type
>
>
>> With arrays, elementwise addition is virtually always the right thing
>> to do for A=B+C. With structs, it's only occasionally the right thing
>> to do, even if it's possible.
>
>
> It would take some study to see what fraction it made sense for,
> and what fraction it didn't. Even in this case, assigning 0 isn't bad.
>
>> I think a reasonable goal for default meanings of operators is that
>> they should generally do no harm. A default to elementwise addition,
>> is, I think, likely to do as much harm as good. For cases where
>> elementwise addition doesn't make semantic sense, I'd much rather have
>> the compiler tell me "you haven't implemented that operator yet" than
>> give me some default that isn't what I expect at all.
>
>
> For mathematicians, elementwise multiplication doesn't make sense,
> but many languages supply it. BASIC is the only one I know that
> supplies matrix multiply but not elementwise multiply.
>
> If you would rather have new operators added instead of reusing
> the existing operators, I won't argue against it. I am only
> suggesting that in some cases structure expressions make sense
> as elementwise expressions, and it is convenient for the language
> to allow for them.
>
> As for generally doing no harm, I think you would have to exclude all
> floating point arithmetic operations, as they tend to do harm more
> often than one would like.
>
> -- glen
>
If my memory hasn't suffered bit rot, then in APL if arrays are
identical in size and shape, + - * / are elementwise and mathematical
matrix multiplication uses a different symbol. Maybe + - * / are
defined elementwise for other collections.

From: glen herrmannsfeldt on
Gary Scott wrote:

(snip on file suffixes)

> Wouldn't work on VM or VOS unless you adopted a very shortened name
> part. VM has a filetype, but the separation character is a space:

For VM you mean CMS. Some programs, such as ftp, accept period
separated filetype,

I don't know about VOS.

> "copyfile filename filetype filemode (space separated list of options"

-- glen

From: glen herrmannsfeldt on
Andrew Swallow wrote:

> glen herrmannsfeldt wrote:
> [snip]

>> As for generally doing no harm, I think you would have to exclude all
>> floating point arithmetic operations, as they tend to do harm more
>> often than one would like.

> Do we still need floating point operations? Could they be replaced
> by say 128 bit fixed point variables - Sign bit, 63 bit integer and 64
> bit fraction?

I don't know about replaced, but many people use floating point where
64 bit (or larger) fixed point would be a better choice.

Floating point is best for quantities with a relative error. Consider
mass. The mass of a proton is known to about 10 decimal digits.
(More or less, I haven't looked recently.) The mass of the earth to
about three digits. The mass of the earth in GeV is very large, but
the uncertainty in the measurement is also large.

In most cases, distance and time measurements will also have a
relative error, though it is less obvious than for mass. With an
interferometer, distance, or at least changes in distance, can be
measured very accurately even as the distance gets large. Very large
distances could be measured to micrometer resolution. In most
cases, though, a computation will have a relative error.

I expect my bank to keep my balance down to the cent, no better
and no worse, independent of how much money I have in the account.
That is an absolute error, so fixed point is more appropriate.

D.E.Knuth recommends fixed point for digital typesetting. He has
an example of a typesetter that supposedly had a 5333 dpi resolution,
but the results didn't look right. When it was found that the
resolution was actually 5333+1/3 dpi everything looked fine.
You might think that the difference should be too small to notice,
but it seems that it wasn't.

-- glen


From: Richard Steiner on
Here in alt.folklore.computers,
Brooks Moses <bmoses-nospam(a)cits1.stanford.edu> spake unto us, saying:

>Richard Steiner wrote:
>
>> Yes, I could see 10 or 12 characters being quite useful, but things get
>> tedious to type quite quickly. :-(
>>
>> Even eight (8) characters would be an improvement, though.
>
> Well, there isn't any need to speak of that in the counterfactual tense.
> Fortran 95 allows up to 31 characters. :)

I'm not aware of a Fortran 95 compiler for the Unisys Cleapath Dorado
(OS2200) environment that I work in, making the new standard moot.

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Mableton, GA USA
Mainframe/Unix bit twiddler by day, OS/2+Linux+DOS hobbyist by night.
WARNING: I've seen FIELDATA FORTRAN V and I know how to use it!
The Theorem Theorem: If If, Then Then.
From: Brooks Moses on
Richard Steiner wrote:
> Here in alt.folklore.computers,
> Brooks Moses <bmoses-nospam(a)cits1.stanford.edu> spake unto us, saying:
>>Richard Steiner wrote:
>>>Yes, I could see 10 or 12 characters being quite useful, but things get
>>>tedious to type quite quickly. :-(
>>>
>>>Even eight (8) characters would be an improvement, though.
>>
>>Well, there isn't any need to speak of that in the counterfactual tense.
>>Fortran 95 allows up to 31 characters. :)
>
> I'm not aware of a Fortran 95 compiler for the Unisys Cleapath Dorado
> (OS2200) environment that I work in, making the new standard moot.

Yeah, well, there's always _someone_ who's doing something weird like
that. Figures you'd be him. :)

- Brooks


--
The "bmoses-nospam" address is valid; no unmunging needed.