| Text output line too short, width = val not working [message #91105] |
Wed, 03 June 2015 17:21  |
laura.hike
Messages: 87
Registered: September 2013
|
Member |
|
|
Hi,
I'm writing an ascii file of data and some of the numbers are wrapping to a second line. On a couple of web pages, I find a suggested solution of adding width = somevalue to the end of my openw statement. I tried several different values, all the way up to 400, and found no change in my output. Any idea why this is? The relevant code and output lines are below. Interestingly, the header line (just text) prints out fine regardless of whether I use a width parameter.
Code lines:
openw, 4, outname + '.txt', width = 400
printf, 4, ' Date DOY Time SZA Lat. Lon. Mask Type CF Height Pressure Temp Tau LWP r_e R_650 R_3.75 T_650 T_3.75'
printf, 4, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 2(1X, F7.2))', year, month, day, doy, time, outdata
Example lines:
Date DOY Time SZA Lat. Lon. Mask Type CF Height Pressure Temp Tau LWP r_e R_650 R_3.75 T_650 T_3.75
2015 2 3 34 2345 -999.00 -999.00 -999.00 -999 -999 -999.000 -999.000 -999.0 -999.0 -999.00 -999.00 -999.0 -999.00 -999.00
-999.00 -999.00
2015 2 4 35 0015 38.54 -121.39 77.95 3 7 0.996 10.000 277.2 224.6 -999.00 -999.00 -999.0 26.75 27.24
282.35 268.82
(If you can't see that properly in this window, only the last two numbers in each of the data "lines" is on a new line.) The crazy format statement comes from me trying to make the line as short as possible.
Thanks,
Laura
|
|
|
|
| Re: Text output line too short, width = val not working [message #91107 is a reply to message #91105] |
Thu, 04 June 2015 02:02  |
vaibhavpant55
Messages: 10
Registered: December 2014
|
Junior Member |
|
|
On Thursday, June 4, 2015 at 5:51:11 AM UTC+5:30, laura...@gmail.com wrote:
> Hi,
>
> I'm writing an ascii file of data and some of the numbers are wrapping to a second line. On a couple of web pages, I find a suggested solution of adding width = somevalue to the end of my openw statement. I tried several different values, all the way up to 400, and found no change in my output. Any idea why this is? The relevant code and output lines are below. Interestingly, the header line (just text) prints out fine regardless of whether I use a width parameter.
>
> Code lines:
>
> openw, 4, outname + '.txt', width = 400
> printf, 4, ' Date DOY Time SZA Lat. Lon. Mask Type CF Height Pressure Temp Tau LWP r_e R_650 R_3.75 T_650 T_3.75'
> printf, 4, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 2(1X, F7.2))', year, month, day, doy, time, outdata
>
>
> Example lines:
>
> Date DOY Time SZA Lat. Lon. Mask Type CF Height Pressure Temp Tau LWP r_e R_650 R_3.75 T_650 T_3.75
>
> 2015 2 3 34 2345 -999.00 -999.00 -999.00 -999 -999 -999.000 -999.000 -999.0 -999.0 -999.00 -999.00 -999.0 -999.00 -999.00
> -999.00 -999.00
>
> 2015 2 4 35 0015 38.54 -121.39 77.95 3 7 0.996 10.000 277.2 224.6 -999.00 -999.00 -999.0 26.75 27.24
> 282.35 268.82
>
>
> (If you can't see that properly in this window, only the last two numbers in each of the data "lines" is on a new line.) The crazy format statement comes from me trying to make the line as short as possible.
>
> Thanks,
>
> Laura
Hi,
I was also facing this problem. For me it is working with width. I am using IDL 8.4. Have you tried increasing width to 1000?
Vaibhav
|
|
|
|
| Re: Text output line too short, width = val not working [message #91108 is a reply to message #91105] |
Thu, 04 June 2015 07:11 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
laura.hike@gmail.com writes:
> I'm writing an ascii file of data and some of the numbers are wrapping to a second line. On a couple of web pages, I find a suggested solution of adding width = somevalue to the end of my openw statement. I tried several different values, all the way up to 400, and found no change in my output. Any idea why this is? The relevant code and output lines are below. Interestingly, the header line (just text) prints out fine regardless of whether I use a width parameter.
Well, you are using a FORMAT statement. So, I wouldn't expect a change
when the WIDTH of the line is changed. If the FORMAT statement doesn't
allow a single line of output, EVEN when the WIDTH of the line is
changed, I would immediately suspect something is up with the FORMAT
statement.
Yours is so complicated, however, that I can't tell what the problem
might be. Try a very simple FORMAT and see if that doesn't shed some
light on this problem, before you retreat to your more complicated
design.
Cheers,
David
P.S. You ARE sure that the wrapping you are seeing is not related to the
configuration of the software you are using to view the output file,
right? For example, I have to turn Word Wrap off in my Notepad
application to view these kinds of text files properly.
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Text output line too short, width = val not working [message #91110 is a reply to message #91108] |
Thu, 04 June 2015 12:07 |
laura.hike
Messages: 87
Registered: September 2013
|
Member |
|
|
Hi David,
Thanks for the reply. I agree that the format statement is the next thing to look at, so I will do that and post the results. In response to your points, though,
1) The format statement only contains data formats (A, F, or I) and spaces (X), no carriage returns or other funky things. (I never use carriage returns.)
2) I read the file in vi. vi wraps the text to the size of the window, breaking at whatever character is at the edge of the screen. If you resize the window, the wrapping changes accordingly. In this case, the header line is longer than the line of data and only wraps when the window is small. The last two values in the data line always appear on a separate line, regardless of the size of the window. In vi, characters have uniform width, so there's no cheating there.
3) According to the Exelis documentation, there is a limit to the number of characters in a line for printf (80), and this can be overcome by using a WIDTH parameter in the openw statement. It's not obvious that this would only apply to lines consisting of a single string variable vs a number of them written one after the other. A punch card is a punch card is a punch card. You hit the end and it's over, if not, then not. I'm baffled by this.
Interestingly, I often run into the problem of a single printf statement printing to multiple lines when I DON'T use a FORMAT statement. Putting in an explicit format usually helps, and allows me to make the line longer than when I rely on IDL standard formatting......
On Thursday, June 4, 2015 at 7:11:42 AM UTC-7, David Fanning wrote:
> Laura H. writes:
>
>> I'm writing an ascii file of data and some of the numbers are wrapping to a second line. On a couple of web pages, I find a suggested solution of adding width = somevalue to the end of my openw statement. I tried several different values, all the way up to 400, and found no change in my output. Any idea why this is? The relevant code and output lines are below. Interestingly, the header line (just text) prints out fine regardless of whether I use a width parameter.
>
> Well, you are using a FORMAT statement. So, I wouldn't expect a change
> when the WIDTH of the line is changed. If the FORMAT statement doesn't
> allow a single line of output, EVEN when the WIDTH of the line is
> changed, I would immediately suspect something is up with the FORMAT
> statement.
>
> Yours is so complicated, however, that I can't tell what the problem
> might be. Try a very simple FORMAT and see if that doesn't shed some
> light on this problem, before you retreat to your more complicated
> design.
>
> Cheers,
>
> David
>
> P.S. You ARE sure that the wrapping you are seeing is not related to the
> configuration of the software you are using to view the output file,
> right? For example, I have to turn Word Wrap off in my Notepad
> application to view these kinds of text files properly.
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
> Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Text output line too short, width = val not working [message #91111 is a reply to message #91110] |
Thu, 04 June 2015 12:46 |
Dick Jackson
Messages: 347
Registered: August 1998
|
Senior Member |
|
|
Hi Laura,
It looks to me like you have more data in 'outdata' than you have formatting elements for, and the Print statement is reusing items from the last available *repeated* segment, being the "2(1X, F7.2)". This might look awful, but here goes:
; This is your original
IDL> print, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 2(1X, F7.2))', findgen(21)
0 1 2 3 5.00 6.00 7.00 8 9 10.000 11.000 12.0 13.0 14.00 15.00 16.0 17.00 18.00
19.00 20.00
; This is the same, but expanding the 2(1X, F7.2)... note how it's different now!
IDL> print, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 1X, F7.2, 1X, F7.2)', findgen(21)
0 1 2 3 5.00 6.00 7.00 8 9 10.000 11.000 12.0 13.0 14.00 15.00 16.0 17.00 18.00
19 20
; Giving more data:
IDL> print, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F7.2, 1X, F7.2)', findgen(21)
0 1 2 3 5.00 6.00 7.00 8 9 10.000 11.000 12.0 13.0 14.00 15.00 16.0 17.00 18.00 19.00 20.00
; Or, even better, perhaps:
IDL> print, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 4(1X, F7.2))', findgen(21)
0 1 2 3 5.00 6.00 7.00 8 9 10.000 11.000 12.0 13.0 14.00 15.00 16.0 17.00 18.00 19.00 20.00
Hope this is helpful!
This behaviour of IDL (going back to reuse only the last repeated segment) can be confusing, but likely helpful in many cases. In IDL Help on "Using Formatted Input and Output", it reads:
Format Reversion
In format reversion, the current record is terminated, a new one is initiated, and format control reverts to the group repeat specification whose opening parenthesis matches the next-to-last closing parenthesis of the format string. If the format does not contain a group repeat specification, format control returns to the initial opening parenthesis of the format string.
Cheers,
-Dick
Dick Jackson Software Consulting Inc.
Victoria, BC, Canada --- http://www.d-jackson.com
On Thursday, 4 June 2015 12:07:07 UTC-7, Laura H. wrote:
> Hi David,
>
> Thanks for the reply. I agree that the format statement is the next thing to look at, so I will do that and post the results. In response to your points, though,
>
> 1) The format statement only contains data formats (A, F, or I) and spaces (X), no carriage returns or other funky things. (I never use carriage returns.)
>
> 2) I read the file in vi. vi wraps the text to the size of the window, breaking at whatever character is at the edge of the screen. If you resize the window, the wrapping changes accordingly. In this case, the header line is longer than the line of data and only wraps when the window is small. The last two values in the data line always appear on a separate line, regardless of the size of the window. In vi, characters have uniform width, so there's no cheating there.
>
> 3) According to the Exelis documentation, there is a limit to the number of characters in a line for printf (80), and this can be overcome by using a WIDTH parameter in the openw statement. It's not obvious that this would only apply to lines consisting of a single string variable vs a number of them written one after the other. A punch card is a punch card is a punch card. You hit the end and it's over, if not, then not. I'm baffled by this.
>
> Interestingly, I often run into the problem of a single printf statement printing to multiple lines when I DON'T use a FORMAT statement. Putting in an explicit format usually helps, and allows me to make the line longer than when I rely on IDL standard formatting......
>
>
>
> On Thursday, June 4, 2015 at 7:11:42 AM UTC-7, David Fanning wrote:
>> Laura H. writes:
>>
>>> I'm writing an ascii file of data and some of the numbers are wrapping to a second line. On a couple of web pages, I find a suggested solution of adding width = somevalue to the end of my openw statement. I tried several different values, all the way up to 400, and found no change in my output. Any idea why this is? The relevant code and output lines are below. Interestingly, the header line (just text) prints out fine regardless of whether I use a width parameter.
>>
>> Well, you are using a FORMAT statement. So, I wouldn't expect a change
>> when the WIDTH of the line is changed. If the FORMAT statement doesn't
>> allow a single line of output, EVEN when the WIDTH of the line is
>> changed, I would immediately suspect something is up with the FORMAT
>> statement.
>>
>> Yours is so complicated, however, that I can't tell what the problem
>> might be. Try a very simple FORMAT and see if that doesn't shed some
>> light on this problem, before you retreat to your more complicated
>> design.
>>
>> Cheers,
>>
>> David
>>
>> P.S. You ARE sure that the wrapping you are seeing is not related to the
>> configuration of the software you are using to view the output file,
>> right? For example, I have to turn Word Wrap off in my Notepad
>> application to view these kinds of text files properly.
>> --
>> David Fanning, Ph.D.
>> Fanning Software Consulting, Inc.
>> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
>> Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Text output line too short, width = val not working [message #91112 is a reply to message #91111] |
Thu, 04 June 2015 13:12 |
laura.hike
Messages: 87
Registered: September 2013
|
Member |
|
|
Drat, you're right. How embarrassing! I should've tried counting before messing with all of the individual formats. I knew about that behavior.
In the meantime, I did some experiments with output from IDL 8.4.1 and found some interesting results. I'll post them below. The 80 character limit only seems to apply in some cases....
Thanks!
Laura
On Thursday, June 4, 2015 at 12:46:46 PM UTC-7, Dick Jackson wrote:
> Hi Laura,
>
> It looks to me like you have more data in 'outdata' than you have formatting elements for, and the Print statement is reusing items from the last available *repeated* segment, being the "2(1X, F7.2)". This might look awful, but here goes:
>
> ; This is your original
> IDL> print, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 2(1X, F7.2))', findgen(21)
> 0 1 2 3 5.00 6.00 7.00 8 9 10.000 11.000 12.0 13.0 14.00 15.00 16.0 17.00 18.00
> 19.00 20.00
>
> ; This is the same, but expanding the 2(1X, F7.2)... note how it's different now!
> IDL> print, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 1X, F7.2, 1X, F7.2)', findgen(21)
> 0 1 2 3 5.00 6.00 7.00 8 9 10.000 11.000 12.0 13.0 14.00 15.00 16.0 17.00 18.00
> 19 20
>
> ; Giving more data:
> IDL> print, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F7.2, 1X, F7.2)', findgen(21)
> 0 1 2 3 5.00 6.00 7.00 8 9 10.000 11.000 12.0 13.0 14.00 15.00 16.0 17.00 18.00 19.00 20.00
>
> ; Or, even better, perhaps:
> IDL> print, format = '(I4, 1X, 2(I3, 1X), I4, 1X, (A4, 1X), 2(F7.2, 1X), F7.2, 1X, 2(I4, 1X), F8.3, 1X, F8.3, 1X, F6.1, 1X, F6.1, 1X, F7.2, 1X, F7.2, 1X, F6.1, 4(1X, F7.2))', findgen(21)
> 0 1 2 3 5.00 6.00 7.00 8 9 10.000 11.000 12.0 13.0 14.00 15.00 16.0 17.00 18.00 19.00 20.00
>
> Hope this is helpful!
>
> This behaviour of IDL (going back to reuse only the last repeated segment) can be confusing, but likely helpful in many cases. In IDL Help on "Using Formatted Input and Output", it reads:
>
> Format Reversion
>
> In format reversion, the current record is terminated, a new one is initiated, and format control reverts to the group repeat specification whose opening parenthesis matches the next-to-last closing parenthesis of the format string. If the format does not contain a group repeat specification, format control returns to the initial opening parenthesis of the format string.
>
> Cheers,
> -Dick
>
> Dick Jackson Software Consulting Inc.
> Victoria, BC, Canada --- http://www.d-jackson.com
>
> On Thursday, 4 June 2015 12:07:07 UTC-7, Laura H. wrote:
>> Hi David,
>>
>> Thanks for the reply. I agree that the format statement is the next thing to look at, so I will do that and post the results. In response to your points, though,
>>
>> 1) The format statement only contains data formats (A, F, or I) and spaces (X), no carriage returns or other funky things. (I never use carriage returns.)
>>
>> 2) I read the file in vi. vi wraps the text to the size of the window, breaking at whatever character is at the edge of the screen. If you resize the window, the wrapping changes accordingly. In this case, the header line is longer than the line of data and only wraps when the window is small. The last two values in the data line always appear on a separate line, regardless of the size of the window. In vi, characters have uniform width, so there's no cheating there.
>>
>> 3) According to the Exelis documentation, there is a limit to the number of characters in a line for printf (80), and this can be overcome by using a WIDTH parameter in the openw statement. It's not obvious that this would only apply to lines consisting of a single string variable vs a number of them written one after the other. A punch card is a punch card is a punch card. You hit the end and it's over, if not, then not. I'm baffled by this.
>>
>> Interestingly, I often run into the problem of a single printf statement printing to multiple lines when I DON'T use a FORMAT statement. Putting in an explicit format usually helps, and allows me to make the line longer than when I rely on IDL standard formatting......
>>
>>
>>
>> On Thursday, June 4, 2015 at 7:11:42 AM UTC-7, David Fanning wrote:
>>> Laura H. writes:
>>>
>>>> I'm writing an ascii file of data and some of the numbers are wrapping to a second line. On a couple of web pages, I find a suggested solution of adding width = somevalue to the end of my openw statement. I tried several different values, all the way up to 400, and found no change in my output. Any idea why this is? The relevant code and output lines are below. Interestingly, the header line (just text) prints out fine regardless of whether I use a width parameter.
>>>
>>> Well, you are using a FORMAT statement. So, I wouldn't expect a change
>>> when the WIDTH of the line is changed. If the FORMAT statement doesn't
>>> allow a single line of output, EVEN when the WIDTH of the line is
>>> changed, I would immediately suspect something is up with the FORMAT
>>> statement.
>>>
>>> Yours is so complicated, however, that I can't tell what the problem
>>> might be. Try a very simple FORMAT and see if that doesn't shed some
>>> light on this problem, before you retreat to your more complicated
>>> design.
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> P.S. You ARE sure that the wrapping you are seeing is not related to the
>>> configuration of the software you are using to view the output file,
>>> right? For example, I have to turn Word Wrap off in my Notepad
>>> application to view these kinds of text files properly.
>>> --
>>> David Fanning, Ph.D.
>>> Fanning Software Consulting, Inc.
>>> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
>>> Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Text output line too short, width = val not working [message #91113 is a reply to message #91110] |
Thu, 04 June 2015 13:18 |
laura.hike
Messages: 87
Registered: September 2013
|
Member |
|
|
The header line, printed as a single string, is 163 characters long. It prints out fine, with or without using a WIDTH specifier, thus defying the 80 character limit.
There is actually a line before this header, printed using the statement
printf, lun, site, sitelat, sitelon, ' ' + systime()
It turns out that this IS split between two lines, where site, sitelat, and sitelon take up 32 spaces on one line and ' ' + systime() takes up 54 spaces on the next line. That's more than 80 characters, but the position of the split makes no sense. If I eliminate some of the spaces so that the total line length is 80 spaces, it does print out to one line. If I make it longer again, but include WIDTH = 120, it prints to a single line. Thus this statement conforms to the 80 character limit and WIDTH adjustment conventions.
In order to try formatting, I replaced systime() with another string of the same length (24 characters) because I don't see a way to use a format statement to get the standard systime output. Keeping the automatic formatting, the behavior is exactly the same. If I add formatting to copy this line, e.g.,
printf, lun, format = '(A6, F13.4, F13.3, A24, A24)', site, sitelat, sitelon, ' ', dummy
I can go beyond an 80 space line. In fact, I tried changing the blanks to numbers, and was able to print out as many as 208 characters on the same line without using a WIDTH parameter before I got tired of adding more characters and trying again.
So now we have two cases that defy the 80 character limit and one that doesn't. It would seem that formatting has precedence over the limit and automatic formatting doesn't -- but printing out a single long string is also fine. Exelis people, can you explain this? I'm running IDL 8.4.1 under Debian linux.
>
> On Thursday, June 4, 2015 at 7:11:42 AM UTC-7, David Fanning wrote:
>> Laura H. writes:
>>
>>> I'm writing an ascii file of data and some of the numbers are wrapping to a second line. On a couple of web pages, I find a suggested solution of adding width = somevalue to the end of my openw statement. I tried several different values, all the way up to 400, and found no change in my output. Any idea why this is? The relevant code and output lines are below. Interestingly, the header line (just text) prints out fine regardless of whether I use a width parameter.
>>
>> Well, you are using a FORMAT statement. So, I wouldn't expect a change
>> when the WIDTH of the line is changed. If the FORMAT statement doesn't
>> allow a single line of output, EVEN when the WIDTH of the line is
>> changed, I would immediately suspect something is up with the FORMAT
>> statement.
>>
>> Yours is so complicated, however, that I can't tell what the problem
>> might be. Try a very simple FORMAT and see if that doesn't shed some
>> light on this problem, before you retreat to your more complicated
>> design.
>>
>> Cheers,
>>
>> David
>>
>> P.S. You ARE sure that the wrapping you are seeing is not related to the
>> configuration of the software you are using to view the output file,
>> right? For example, I have to turn Word Wrap off in my Notepad
>> application to view these kinds of text files properly.
>> --
>> David Fanning, Ph.D.
>> Fanning Software Consulting, Inc.
>> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
>> Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
