Re: complex arithmetics

Hello,

robin wrote:

<snip editorial>

OK, let's suppose we have a processor where there are

32-bit reals and 64-bit doubles,
8-bit, 32-bit and 64-bit integers, and
ascii and 32-bit unicode characters.

Suppose r and d are instances of real and double, respectively
b, i, l are instances of the integers kinds,
a and u are instances of the character kinds

If i = int( r) one gets a 32-bit integer result.
That doesn't imply that l = int( r) is a 64-bit result,
nor does it imply that l = int( d) is a 64-bit result.
This is because int() returns default integers, unless
the kind= is specified.

Now, i = ichar( u) is a 32-bit result, because ichar()
returns default integers.  But i = ichar( a) also
returns a 32-bit integer!  For b = ichar( a), the value
is converted to a different kind *as a result of
the assignment*, not as the function result.

All the type-conversion functions return default kind,
unless a kind= is present, with the *sole* exception
being the real value returned when the argument
is complex.

Thus, Robin, you have it *exactly* backwards:
All type conversion functions return default kind,
except real( complex).  The cmplx() >>> fits
the pattern <<< rather than being the exception.
Your speculation of which is surprising seems ill-informed,
at best.

BTW, I favor a complex() intrinsic, such as was
proposed be James Giles.  I hope someone will make
a Public Comment during the Public Comment period
for f08 suggesting it.  I think it's useful.
But it would also be exceptional among the conversion
intrinsics, and, therefore, perhaps surprising.
I don't know if it would become part of the standard,
as the argument that it's irregular and redundant
could be made against it.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.
.

Relevant Pages
Loading