forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

No E format in Clearwin
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Mon Sep 04, 2017 5:39 am    Post subject: No E format in Clearwin Reply with quote

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?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Sep 04, 2017 6:35 am    Post subject: Reply with quote

I will add this to the wish list.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Mon Sep 04, 2017 10:57 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon Sep 04, 2017 12:11 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 739

PostPosted: Mon Sep 04, 2017 7:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Sep 05, 2017 6:38 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Sep 05, 2017 6:47 am    Post subject: Reply with quote

I have made a note of this.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Nov 16, 2017 1:40 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Nov 17, 2017 12:04 am    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1835
Location: Sydney

PostPosted: Fri Nov 17, 2017 2:36 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Nov 17, 2017 9:22 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Fri Nov 17, 2017 12:58 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Nov 18, 2017 5:35 pm    Post subject: Reply with quote

This has now been fixed so that the warning is not generated for short values.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Nov 18, 2017 9:08 pm    Post subject: Reply with quote

Great. And appeared on Saturday Smile
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
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1835
Location: Sydney

PostPosted: Sun Nov 19, 2017 2:50 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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