forums.silverfrost.com
Welcome to the Silverfrost forums

 No E format in Clearwin Goto page 1, 2, 3  Next
Author Message
DanRRight

Joined: 10 Mar 2008
Posts: 1963
Location: South Pole, Antarctica

 Posted: Mon Sep 04, 2017 5:39 am    Post subject: No E format in Clearwin 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
Site Admin

Joined: 21 Feb 2005
Posts: 5902
Location: Salford, UK

 Posted: Mon Sep 04, 2017 6:35 am    Post subject: I will add this to the wish list.
LitusSaxonicum

Joined: 23 Aug 2005
Posts: 1983
Location: Yateley, Hants, UK

 Posted: Mon Sep 04, 2017 10:57 am    Post subject: 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

Joined: 10 Mar 2008
Posts: 1963
Location: South Pole, Antarctica

Posted: Mon Sep 04, 2017 12:11 pm    Post subject:

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

 Code: real*8 x    x= 12345678901.123456789    i = winio@('X   rf %ta%rf %ff&', x)    i = winio@('X  7rf %ta%7rf%ff&', x)    i = winio@('X  8rf %ta%8rf%ff&', x)    i = winio@('X  9rf %ta%9rf%ff&', x)    i = winio@('X 10rf %ta%10rf%ff&',x)    i = winio@('X 11rf %ta%11rf%ff&',x)    i = winio@('X 12rf %ta%12rf%ff&',x)    i = winio@('X   wf %ta%wf %ff&', x)    i = winio@('X  7wf %ta%7wf%ff&', x)    i = winio@('X  8wf %ta%8wf%ff&', x)    i = winio@('X  9wf %ta%9wf%ff&', x)    i = winio@('%es') end

Another hopefully small problem is that despite Real*8 declaration for X both %rf and %wf treat X as single precision
mecej4

Joined: 31 Oct 2006
Posts: 1121

 Posted: Mon Sep 04, 2017 7:41 pm    Post subject: 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

Joined: 10 Mar 2008
Posts: 1963
Location: South Pole, Antarctica

 Posted: Tue Sep 05, 2017 6:38 am    Post subject: 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)Last edited by DanRRight on Tue Sep 05, 2017 10:29 am; edited 2 times in total
PaulLaidler
Site Admin

Joined: 21 Feb 2005
Posts: 5902
Location: Salford, UK

 Posted: Tue Sep 05, 2017 6:47 am    Post subject: I have made a note of this.
PaulLaidler
Site Admin

Joined: 21 Feb 2005
Posts: 5902
Location: Salford, UK

Posted: Thu Nov 16, 2017 1:40 pm    Post subject:

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

 Code: double precision:: x = 1.83932434324 x = 1.83932434324

But you will get the same warning with...

 Code: double precision:: x = 1.0 x = 1.0

which could be a little off putting.
DanRRight

Joined: 10 Mar 2008
Posts: 1963
Location: South Pole, Antarctica

 Posted: Fri Nov 17, 2017 12:04 am    Post subject: 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

Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

 Posted: Fri Nov 17, 2017 2:36 am    Post subject: 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

Joined: 10 Mar 2008
Posts: 1963
Location: South Pole, Antarctica

 Posted: Fri Nov 17, 2017 9:22 am    Post subject: 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.Last edited by DanRRight on Sat Nov 18, 2017 4:02 am; edited 4 times in total
LitusSaxonicum

Joined: 23 Aug 2005
Posts: 1983
Location: Yateley, Hants, UK

Posted: Fri Nov 17, 2017 12:58 pm    Post subject:

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:

 Code: OPTIONS (DREAL)       PROGRAM T       DOUBLE PRECISION A       A = 1.234567890123456789       WRITE (*, '(E24.19)') A       END

gives

.1234567890123456690E+01

which seems to me to be the double precision version of the constant, even though it is not exactly as coded, because even the precision of a DOUBLE PRECISION constant (I vaguely remember 15 or so significant figures) has been exceeded.

Eddie
PaulLaidler
Site Admin

Joined: 21 Feb 2005
Posts: 5902
Location: Salford, UK

 Posted: Sat Nov 18, 2017 5:35 pm    Post subject: This has now been fixed so that the warning is not generated for short values.
DanRRight

Joined: 10 Mar 2008
Posts: 1963
Location: South Pole, Antarctica

 Posted: Sat Nov 18, 2017 9:08 pm    Post subject: 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

Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

 Posted: Sun Nov 19, 2017 2:50 am    Post subject: 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.
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First
 All times are GMT + 1 HourGoto page 1, 2, 3  Next Page 1 of 3

 Jump to: Select a forum Admin----------------Announcements FTN95----------------GeneralKBaseSupportSuggestionsClearWin+Plato64-bit FTN77----------------Support
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2005 phpBB Group