forums.silverfrost.com

[Zach]

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

[wahorger]

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.

[JohnCampbell]

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

[Zach]

Hi Bill,

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

Patrick.

[wahorger]

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

[wahorger]

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:

[Zach]

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

[Zach]

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

[wahorger]

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

[Zach]

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.

[Zach]

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

[Zach]

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.

[wahorger]

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

[JohnCampbell]

[wahorger]

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