Re: complex arithmetics

James Giles wrote in message ...
|robin wrote:
|...
|>> z = cmplx(real(z), 1.0, kind(z))
|>>
|>> This doesn't work because there is a spurious reference
|>> to the real part of Z. If the real part of Z is a signalling
|>> NaN, the above will fail with an exception for a reference
|>> that you didn't really even want to make.
|>
|> There is no arithmetic operation here, and there is no
|> reason for NaN being raised.
|> Indeed, the operation can be reduced to the simple
|> transfer of 1.0 after transfomation (if any) to the kind
|> of the imaginary part of Z. There is no need to touch
|> the real part of Z in this case.
|
|Yeah. That's your opinion. That's maybe even my
|opinion of what the rule *should* be. That's not
|necessarily any consolation when the problem arises
|and a vendor states that on the contrary a REAL(Z)
|function call *IS* an operation that they raise
|exceptions for. Probably could get support from
|the comittee for that position too. In any case,
|the following is much more legible, and is a
|superior language design if for only that reason:
|
| z%imag = 1.0
That's not particularly neat, and in any case,
it's an operation that's rarely called for.

|--
|J. Giles


.

Relevant Pages

  • Re: complex arithmetics
    ... This doesn't work because there is a spurious reference ... the above will fail with an exception for a reference ... reason for NaN being raised. ... opinion of what the rule *should* be. ...
    (comp.lang.fortran)
  • Re: Who uses clapack?
    ... > James Giles wrote: ... though they could easily interoperate with each-other. ... sometimes for no discerable reason: ... mangling before ...
    (comp.lang.fortran)
  • Re: Who uses clapack?
    ... > James Giles wrote: ... though they could easily interoperate with each-other. ... sometimes for no discerable reason: ... mangling before ...
    (sci.math.num-analysis)
  • Re: Function PRESENT and logical combinations
    ... "James Giles" writes: ... but I'm quite sure that I have seen reports (probably even here ... I couldn't imagine being any more explicit. ... opinion" should be added... ...
    (comp.lang.fortran)
  • Re: complex arithmetics
    ... >> This doesn't work because there is a spurious reference ... opinion of what the rule *should* be. ... superior language design if for only that reason: ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
Loading