Re: small numerical differences in floating point result between

"James Giles" <jamesgiles@worldnet.att.net> writes:

> James Van Buskirk wrote: 
>
> I wouldn't even expect that to work, much less yield predictable
> results.

I'm afraid your expectations differ from those of others then.
Issues like that are *EXACTLY* why actual implementation of
TRANSFER is complicated, slow, and often full of bugs.

For example, a TRANSFER of one dummy argument to another *IS*
supposed to work (the standard has no hint of an exception for
this), even when one or both dummy arguments are assumed-shape,
which means they might be discontiguous with incommensurable
holes.  Yes, there *IS* code like this.  I used to have code of
my own like this long ago... before I figured out how slow and
buggy TRANSFER implementations tended to be.

I was shocked the first time I looked under the covers at the
code generated by a TRANSFER because I though this would be the
most trivial of operations.  It wasn't... by quite a long shot.
Even though my case was a simple one, the code was obviously
generated to handle far more general and complicated cases, with
little attention to optimizing the simple cases.  That was a
long time ago, but I don't think things have changed all that
much.  Most of the compilers have fewer bugs with TRANSFER,
but bugs in it still crop up.  And I don't think any compilers
bother with much optimization of it.

> I mean, what I use it for (and rarely at that) is [simple things]

I commend you on the wisdom of your style choice.  (No sarcasm
indended). On occasion, one really needs something like
TRANSFER.  When it is what you need, then you need it.  But
as I said in my other post, dragons lie there.  Don't play
with them if you don't need to.  And come well prepared.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain