forums.silverfrost.com

[DanRRight]

Only humanoids can comprehend large output numbers like this done with %rf

59813784709

which is approximately 5.98e10. But there is no Ex.y format in Clearwin. Can this be added?

[PaulLaidler]

I will add this to the wish list.

[LitusSaxonicum]

Dan,

My guess is that it is required on output not input, in which case it can be written to a character variable first.

If you really do need it for input, then you can presumably input the the powers of 10 separately from the decimal part in an %rf and a %rd. That also works better with %il, as each box would have its own 2 limits - an E format box needs 4.

Eddie

[DanRRight]

Thanks you Paul and Eddie, I played further and I think the problem can be more or less satisfactory solved if force %rf to use smaller amount of digits, i.e. use %7rf instead of %rf if this variable intended only for the output. See example below (of course full fledged Ex.y format would be better)

Also I had some problems with %wf, why I use %rf 1000x more often. May be I do something wrong with it. Look at this text sample, the %wf does not react on number of digits

[mecej4]

Add "D0" to the end of the second line.

Without that, or some other way of signifying that the value is double precision, the decimal number is first converted to a 32-bit REAL, which causes some digits to be lost, and then converted to 64-bit REAL on assignment.

[DanRRight]

As to accuracy you are right, Mecej4. Since i am stepping on the same rake already 1000 times i suggest developers to make the following "Warning: such assignment of variable X will lead to the lose of accuracy because by default the values without explicit descriptors are cut to single precision even if declared as double precision. To fix this use double precision descriptor like in 1.23D0" (I like verbose warning and comments, they are less cryptic)

[PaulLaidler]

I have made a note of this.

[PaulLaidler]

A simple assignment like either of the following will now produce a compiler warning...

[DanRRight]

Great, thanks. As to the numbers like 0., 1., 2., 4. etc how about that compiler checks if the number is 0, 1 and the exact multiple of factor of 2 and does not give the warning? Or just makes a comment that for all other numbers here could be a hidden problem which is often hard to find if user forgets adding D specifier to declare the number at the larger precision (in /VERBOSE mode for the errors)

[JohnCampbell]

I don't understand why the F90 standard chose to send us down this path. Why should the following be interpreted differently !!
double precision:: x = 1.83932434324
double precision:: y = 1.83932434324D0

[DanRRight]

Agree, this is an utter absurd of Standard. The intention of the user is clear and was demonstrated two times in stating double precision and giving variable more then 7 digits, yet standard formally push to change that to single precision without even error/warning. Eventually all will more often use double precision numbers and of course omitting D0 will happen more often.

Good this was fixed. But in this case I'd even prefer error message as I never read warnings. When will have time to clean the code I will probably use compiler switch to treat tens of thousands of different warnings as errors.

[LitusSaxonicum]

There is a certain logic to it, because constants are single precision unless stated otherwise, just as REAL is single precision.

OPTIONS (DREAL) helps.

Take for example:

[PaulLaidler]

This has now been fixed so that the warning is not generated for short values.

[DanRRight]

Great. And appeared on Saturday
Scientists and engineers who don't work on Saturdays do not work at all - this phrase my colleagues assign to me but I don't remember when I said this (very possible ... as the very true is that the supercomputers were always less busy at weekends, so you do in two days the job of entire week, and in two holidays weeks the work of next 6 months ). Life shows this is very right though on everything else. This is how I select people to work with.

This compiler now finds so many subtlest potential problems that if someone has some large code written with other compiler, it most probably just produces plain wrong numbers. I said that before, it now is even more true

[JohnCampbell]

Eddie,

Commenting out DREAL shows the problem.
.1234567880630493164E+01

Why should the standard enforce this unfriendly response ?
Lots of new users are tricked by this and produce inaccurate results that are not easy to find.
It is like dealing with the IT dept.