winio@

Supposedly, in the winio@ language, one is supposed to be able to output a floating point number in a window as follows:

i=winio@('%14.4wf VARIABLE &'), where: 14.4 outputs the floating point number VARIABLE is the variable name & leaves the window open for future activity

I have this sequence in my subroutine, after I have specified the window, size, etc.

However, even though I set the Variable to a value, it always comes out zero in the window??? Totally perplexed why, any advise? Sid kraft

double precision var var = 1.2345d0 i=winio@('%14.4wf',var) end

Paul: I changed the variables as you had requested, made them all DOUBLE PRECISION. Ran the example, they were output to the window and all values were 0.0000. I tried to find an example in the winio@ pictorial that was put together by the Salford people and could not find an actual program segment sample that showed the 'i=winio@('%wf14.4, Var &')' use. I believe that there is a very simple problem in using this winio@ feature that I am overlooking, should not be that hard. Is it possible to find an actual example of this structure being used in a Fortran program? Let me know, Sid Kraft

Sid

If you can post some sample code to show what you are doing then someone will probably be able to help you..

Here it is: SUBROUTINE OPENGL(ROT,XX,YY,ZZ) IMPLICIT REAL8 (A-H,O-Z)
COMMON PLTX(110), PLTY(110), PLTZ(110), ICIRCL, SGSIZE, INOW C COMMON ROT,XX,YY,ZZ
INCLUDE <clearwin.ins>,nolist INCLUDE <opengl.ins>,nolist INTEGER4 ctrl, INDX, INDXSV, IPLCDE, IPEN(110),IPENI,ISTRSG, II CHARACTER ABUFF(80) CHARACTER*1 A49(49)
DIMENSION X(110), Y(110), Z(110), II(110),JJ(110),KK(110)
C SET THE WINDOW HEADER
i=winio@('%es%ca[Simple OpenGL Example]&') C SET THE WINDOW SIZE
i=winio@('%sp%ww[no_border]%og[static]%lw',0,0,1500,1500,ctrl) C OUTPUT THE VARIABLES ROT, XX, YY, ZZ i=winio@('%14.4wf ROT &') i=winio@('%14.4wf XX &') i=winio@('%14.4wf yy &') i=winio@('%14.4wf ZZ &')

In the above example, when I output the variables ROT, XX, YY, ZZ as shown from winio@, they all are displayed as 0.0000?? Even though I declared the output to be equivalent to the Fortran directed output to be f14.4, i.e. theoretically as 14 characters long with 4 characters after the decimal point, totally confused why the variables are 0.0000. The variables are utilized in the OpenGL software to rotate 20 degrees around the ZZ axis, i.e. again, ROT=20., XX=0., YY=0., ZZ=1. Any ideas will be appreciated, Sid Kraft

Answer from winio@ 0.0000ROT, 0.0000XX, 0.0000YY, 0.0000ZZ when the variables are output to the window in the previous example, Sid Kraft

Sid

It looks like you have displayed the initial values of these variables before the process to change them has been applied.

You might find it helpful to use the debugger and to step through the process that is generating the output.

%lw means 'leave window open' so what follows it happens immediately.

Paul: I did process using the debugger, the variables were set from a calling machine and passed to the shown routine as arguments. Thus, should have been initialized before being sent. In actuality, when using the debugger, I displayed the variables just before the winio@ output and they were set to the values that I want. I still think that it is the way that I am calling for the variables to be output from winio, that is why an example of the application would be so helpful, Sid Kraft

i=winio@('%14.4wf ROT')

should be:

i=winio@('%14.4wf', ROT)

etc.

Thanks, that worked, Sid Kraft

In general %wf is only used to display values that are known when the window is created. It creates a Microsoft Windows 'Static' control.

It is usually more appropriate to use %rf to output results generated at runtime. This creates a Microsoft Windows 'Edit' control.

The display for %rf can be made to look like that for %wf by using a grave accent %`rf, whilst formatting can be applied via the %rf[fmt=...] option.

Also it is usually necessary to synconise the display to match the result variable by, for example, calling window_update@(xx).

Another issue, when I call the GL command in SilverFrost Fortran and have the rotate transformation command CALL glRotatef(ROT,XX,YY,ZZ) from the above program segment with ROT=60., XX=0., YY=0., ZZ=1. the GL command is supposed to rotate the geometrical elements by 60 degrees about the ZZ axis. It does not, leaves the substituted parameters at 0., 0., 0., 0. I would think that the programing would allow the substituting of the values in the parameters into the command but does not seem to work. Any suggestions? Sid kraft

Per the above samples and statements, being that the OpenGL system and the requirement in the command glRotatef(ROT,XX,YY,ZZ) that the parameters be of the highest significance, what is the difference in the declarations IMPLICITE REAL*8 (A-H,O-Z) and DOUBLE PRECISION ROT, XX, YY, ZZ. This may be why the parameters submitted have actual values but when the command is executed, the variables turn out to be zero, Sid Kraft

Both forms declare ROT, XX, YY and ZZ as double precision.

Very Interesting: The reason why the arguments to the glRotatef function in the OpenGL language did not work is that the variables were declared double precision and the code above includes the command with 'f'. should be used with the 'd' to denote double precision arguments, i.e. glRotated(ROT,XX,YY,ZZ). Not at all specific in my test book on the OpenGL language, problem solved, at least this one, Sid Kraft

Sid,

To complement Paul's answer, you can also use the OPTIONS compiler directive to set the default REAL to be DOUBLE PRECISION or REAL*8, and something similar to make all INTEGERs 4 byte:

OPTIONS (INTL, DREAL)

Although REAL4 is good enough precision in many cases, there are also many cases where it isn't. The option DREAL makes it appear as though the computer only has REAL8 - unless you declare something specifically to a lower precision.

Eddie

Is the extended precision going to be available in FTN95? It seems to have been added in the 2008 'iso_fortran_env'.

Ian,

By 'extended precision' do you mean REAL*10 ? I remember Paul saying that it's there in 32 bit, but not in 64 bit FTN95.

Eddie

Eddie, You are correct, there is a Real10 option available in 32-bit as the intel 8086 co-processor supported this resolution directly. It was not ported to the 64-bit version. I was really talking about the Real16 data type that we had in VAX Fortran-77 all those years ago. In that there was the option to compile with the 'Grand' and 'Huge' precision allowing either a very high precision but a lower range than the other option which allowed for larger values but with a lower precision. Obviously, they were for sending spacecraft to the moon and further. They also had uses in transfer matrix type of vibration analysis where the determinant of the final matrix involved subtracting the multiple of two large numbers from the multiple of two other large numbers and adjusting a frequency so that they would result in a zero value, thus identifying a natural frequency. This is something our company used for the analysis of the whirling of ship's propeller shafts. I had just hoped that it would appear in FTN95, although it appears that it is only in the later Fortran standards.

We are currently working towards implementing extended precision for the x64 platform but it seems unlikely that this will be finished in time for the next full release.

Initially it could be real10 with real16 coming later.

The extension may require the use of third party redistributables that would need to be downloaded by the user.