Stream question

PROGRAM plumb IMPLICIT NONE INTEGER :: myvalue = 12345 OPEN(10, FILE='myData.txt', ACCESS='STREAM') WRITE(10) 'first' WRITE(10) 'second' WRITE(10) 'myvalue' WRITE(10) myvalue !my question PRINT , 'Done' CLOSE(10) read END PROGRAM plumb

Please explain why at 'my question' '90' is being written, rather than 12345

There is no formatting specified, that's why.

12345 is 0x3039. Since the computer architecture is 'little-endian', it is reported as '90'. This assumes that the integer default is 16 bit. If 32-bit, then two NULL characters would follow the '90' (unless removed by the STREAM driver).

Text is, of course, text.

I suspect you are not seeing and carriage control (CR/LF).

If you wish to replicate printf() statements, remember, that requires formatting of the output as well. And attention to carriage control.

Just consider: Formatted output, while requiring perhaps some additional effort than stream I/O (on occasion) does a lot of 'house-keeping' for you.

The modified code identifies '09' as expected, using FTN95 on a Windows PC.

PROGRAM plumb
IMPLICIT NONE
INTEGER :: myvalue = 12345, i, ic
character ch
do i = 1,4
  ic = mod(myvalue,256)
  ch = char (ic)
  myvalue = myvalue/256
  write (*,*) i,ic,' ',ch
end do
stop
OPEN(10, FILE='myData.txt', ACCESS='STREAM')
WRITE(10) 'first'
WRITE(10) 'second'
WRITE(10) 'myvalue'
WRITE(10) myvalue !my question
PRINT *, 'Done'
CLOSE(10)
read*
END PROGRAM plumb

What computer architecture are you using to get '90' ? integer myvalue is a 4-byte integer so I would expect to get NUL NUL 0 9

Hi Bill,

Not sure what you are asking me. I have an I7 box.

Patrick.

Zach, I didn't ask a question; John did.

BTW, John's code has a STOP in it, and he destroys myvalue in his first processing. And, near the end, there is a READ* that appears to not generate an error when compiling!

He also processes the characters in little-endian order, showing '9' followed by '0', followed by 2 NULL characters, exactly as it should appear in the file.

When writing unformatted, the bytes are presented in the same order as they exist in memory. Thus your example should yield '9','0',NULL,NULL, or as viewed in a capable editor (displays a file in hex): 39 30 00 00.

Here's a link to the image captured from my text editor (hex display) showing what EXACTLY was written to the file (it is exactly as one would expect):

https://www.dropbox.com/s/bm6ggzi8rn44sz5/Screenshot%202023-03-23%20071107.png?dl=0

I did some additional experimenting with the program, and using the '*' as the format or a specific format (i.e. '(A)'), and it generates a run-time error; trying to have formatted data with ACCESS='STREAM' are incompatible.

From the HELP file:

ACCESS=<string> This specifies the type of access for which the file is to be opened. <string> is either DIRECT, SEQUENTIAL or STREAM. As an extension to the Fortran standard <string> can also be TRANSPARENT (see the FORM specifier below). By default the ACCESS is SEQUENTIAL. STREAM is part of the Fortran 2003 Standard and is similar to FTN95 TRANSPARENT access. When compared with DIRECT, STREAM uses POS in place of REC and has a fixed RECL value which for FTN95 is one. The Fortran 2003 intrinsic NEW_ LINE can be used within an WRITE statement. It returns a CHARACTER result which for FTN95 is CHAR(10) and is translated to CHAR(13) then CHAR(10) in the output file.

Note the implied RECL is one! Meaning that trying to use a FORMAT for output will likely result in multiple bytes trying to be written to a one-byte 'record'.

However, also from the HELP file, you might specify the access as TRANSPARENT.

For ACCESS = TRANSPARENT and FORM= FORMATTED, no carriage returns are output at the end of record on output (the user can output carriage returns with the '/' editing descriptor), and on input precisely the field widths specified in the input format are read, with no attempt to align to record boundaries (i.e. after carriage returns).

Your call as to what suits your situation best. The code has to change to work:

	PROGRAM plumb
	IMPLICIT NONE
	INTEGER :: myvalue = 12345, i, ic
	character ch
	do i = 1,4
	  ic = mod(myvalue,256)
	  ch = char (ic)
	  myvalue = myvalue/256
	  write (*,*) i,ic,' ',ch
	end do
        myvalue = 12345
	OPEN(10, FILE='myData.txt',ACCESS='TRANSPARENT',FORM='FORMATTED',status='replace')
	WRITE(10,'(a)') 'first'
	WRITE(10,'(a)') 'second'
	WRITE(10,'(a)') 'myvalue'
	WRITE(10,'(i0)') myvalue !my question
	PRINT *, 'Done'
	CLOSE(10)
	END PROGRAM plumb

Here's the hex of the file: https://www.dropbox.com/s/2r2nff2h96uqeuv/Screenshot%202023-03-23%20081400.png?dl=0

Hi, thank you for your response. Could you please further explain the parameters, 'TRANSPARENT' and 'FORMATTED'. As to 'formatted', I see no formatting.

This is the code that runs okay, about which I have a query

CODE

PROGRAM plumb IMPLICIT NONE INTEGER :: myvalue = 12345 OPEN(10, FILE='myData.txt',ACCESS='TRANSPARENT',FORM='FORMATTED') WRITE(10,'(a)') 'first' WRITE(10,'(a)') 'second' WRITE(10,'(a)') 'myvalue' WRITE(10,'(i0)') myvalue !my question PRINT *, 'Done' CLOSE(10) END PROGRAM plumb

Zach,

There is a HELP file supplied with FTN95. That is where I pulled the descriptions for my comments. Search within that HELP file and you will find the words TRANSPARENT and FORMATTED in the description of the OPEN statement. You can also download the manuals for FTN95 from the Silverfrost website and search them for these references.

You stated your belief that there is no formatting required. If you are wishing to provide human readable output, however, formatting of data is required; most folks can't read the binary codes for a double precision floating point number and immediately discern what value it represents.

I suggest you look back to your printf() or fprintf() knowledge. For human readable output in 'C' and 'C++', there is a format string that must be supplied to printf()/fprintf() that must agree in the data type, and can be used to supply other parameters, such as decimal precision and/or length. It is that formatting that is required if you wish to write a file readable by a human.

If you wish to have the convenience of just doing cout-style output with no regard for the way in which the data are presented, the closest you will get is using '*' for the format. And, in that case, you cannot use ACCESS='STREAM' or ACCESS='TRANSPARENT'.

Bill

Thank you for your comment. I will study your references. In C the world is quite simple, you define a record with the appropriately sized data, and write / read the record. What I usually do is keep the data items in string format as long as possible. That makes life easy.

Would you allow me to use your private email for a question I don't want to ask out in the open?

I have had a superficial glance at the information SilverFrost has on offer. It is truly awesome. One could spend a lifetime studying and experimenting with its information. I am not so young anymore and will have to think of how to make best use of it all. Thank you very much for drawing my attention to it.

You said that I think formatting is not required. I tried to say that if there is the option of creating a record (structure) and writing that 'en bloc' to a file visa versa, that makes life a lot easier, giving a lot of smooth control in a simple way. The data items in the record are of course dimensioned. I keep the data as long as I can in string format. Then do the morphing as required. I am talking about administrative applications, not scientific ones. I am long retired now. Although recently I completed a nice, simple, and efficient in its use, a financial program for my own home use.

Zach,

My application is managing large amounts of character and numeric data. Having developed this SW over the last (almost) 40 years, it has certainly morphed in many ways. I keep data in the format it needs to be in to be (1) the most efficient for the purpose, and (2) the most accurate numeric representation. Decisions made 40 years ago on data typing and precision still haunt me.

You said your data was kept in string form as long as possible, and therefore (I'm assuming here) special formatting of the data is not required. If that is what you meant, I can see now what you were saying.

I use the FORTRAN equivalent of a 'C' struct for much of my data as it transitions to/from files. It is very efficient doing things this way. I think that may be where you are heading.

You can send me a private message on this board system, and I'll get a notice that it is there for me, and I can reply to you via the same method. Click on the link above that reads 'You have no messages' to enter to that part of the system. Use my username to send me a post.

Bill

Quoted from wahorger He also processes the characters in little-endian order, showing '9' followed by '0', followed by 2 NULL characters, exactly as it should appear in the file.

Thanks Bill, I got confused by the mention of endian, when the FTN95 compiler is mostly limited to Windows, except for Dan's recent post.

John,

Depending on what computers he has worked on in the past, the '-endian' issues can be confusing for some.

For example, in Windows computers, bytes are stored in what is termed 'little-endian' meaning the least significant byte is stored first, then the next least significant, etc. For many Apple products, they are stored most significant byte first ('big-endian').

So, if you are looking at how memory is used, 12345 is stored on Windows machines as (in FTN95 syntax) z'39',z'30',z'00',z'00' while on an old Macintosh they would be stored as z'00',z'00',z'30',z'39'.

Most of the time, for programmers, it won't matter, but if you were doing device control, it would be critical to get the bytes being sent in the correct order. I had this problem with a printer driver I wrote where the processor in the printer wanted the bytes in big-endian order!

I was pointing out part of his problem in interpreting what he was seeing, and (ultimately) what was in his file when written as 'UNFORMATTED'. And, he could not 'see' the z'00' (NULL) characters because windows removes them from console outputs. Your code to pull each byte out was showing exactly little-endian order. You code, BTW, would certainly work for big-endian machines. It just would not reflect the ordering of the bytes in memory.

Hope that helps, Bill