Talk:Word wrap: Difference between revisions
Content added Content deleted
Walterpachl (talk | contribs) (→REXX Timings: please take Regina measurements or let's leave it at that.) |
(→REXX Timings: seperated versions into different sections, added comments. -- ~~~~) |
||
Line 61: | Line 61: | ||
versions 0 and 1 adapted as usual: @->a, $->d, = -> ="" |
versions 0 and 1 adapted as usual: @->a, $->d, = -> ="" |
||
<strike> |
|||
version 0 has a minor flaw: The output has a leading blank. Otherwise outputs are identical. --[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 09:55, 21 August 2013 (UTC) |
version 0 has a minor flaw: The output has a leading blank. Otherwise outputs are identical. --[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 09:55, 21 August 2013 (UTC) |
||
</strike> |
|||
::::: fixed the flow. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:01, 21 August 2013 (UTC) |
|||
: Since you didn't post a version of the program (version 2) that actually reads a file, I suspect that a factor is reading the (one million bytes) text file. Also, console (terminal) I/O (at least on Windows/XP systems and such [using Regina]) is very unkind to timings (elapsed time), especially when causing the output to scroll. The REXX version 2 doesn't write it's output to the terminal. It's hard to compare apples to oranges when one program writes to the terminal, another writes to a file. I frequently time REXX programs, and timing large amounts of data being written to the screen (even as an artifact) really effects the elapsed time (which is, I suspect, what you are measuring, not CPU time). When displaying a million bytes of characters to a DOS window uses a fair amount of wall clock time, and the same can be said for reading a file that large. Also, please note, this is the (Classic) REXX section, not ooRexx. Also note that the task asks to wrap a paragraph of text, not a book. The input file (LAWS.TXT) exceeded that by a bit, but using a million bytes of text stresses the REXXes variable accessing mechanism quite a bit, and what is being measured (besides the reading and displaying) is the accessing of the text, in this case, the WORD BIF. If speed is what is wanted, a stemmed array could've been used instead of a flat representation (one REXX variable), but that would obfuscate somewhat the REXX program during the reading of the file. The idea was to show how to re-format a paragraph, and for that amount of text, it wasn't worth the added complexity to make the REXX program faster. One million bytes of text was a design consideration. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 15:49, 21 August 2013 (UTC) |
: Since you didn't post a version of the program (version 2) that actually reads a file, I suspect that a factor is reading the (one million bytes) text file. Also, console (terminal) I/O (at least on Windows/XP systems and such [using Regina]) is very unkind to timings (elapsed time), especially when causing the output to scroll. The REXX version 2 doesn't write it's output to the terminal. It's hard to compare apples to oranges when one program writes to the terminal, another writes to a file. I frequently time REXX programs, and timing large amounts of data being written to the screen (even as an artifact) really effects the elapsed time (which is, I suspect, what you are measuring, not CPU time). When displaying a million bytes of characters to a DOS window uses a fair amount of wall clock time, and the same can be said for reading a file that large. Also, please note, this is the (Classic) REXX section, not ooRexx. Also note that the task asks to wrap a paragraph of text, not a book. The input file (LAWS.TXT) exceeded that by a bit, but using a million bytes of text stresses the REXXes variable accessing mechanism quite a bit, and what is being measured (besides the reading and displaying) is the accessing of the text, in this case, the WORD BIF. If speed is what is wanted, a stemmed array could've been used instead of a flat representation (one REXX variable), but that would obfuscate somewhat the REXX program during the reading of the file. The idea was to show how to re-format a paragraph, and for that amount of text, it wasn't worth the added complexity to make the REXX program faster. One million bytes of text was a design consideration. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 15:49, 21 August 2013 (UTC) |
||
Line 91: | Line 94: | ||
Say right(r,3) right(cnt.r,5) |
Say right(r,3) right(cnt.r,5) |
||
End |
End |
||
</lang> |
|||
⚫ | |||
⚫ | |||
Call time 'R' |
Call time 'R' |
||
parse arg iFID width /*get optional arguments from CL.*/ |
parse arg iFID width /*get optional arguments from CL.*/ |
||
Line 115: | Line 117: | ||
Call lineout ifid |
Call lineout ifid |
||
Exit |
Exit |
||
o: Return lineout(oid,arg(1)) |
o: Return lineout(oid,arg(1))</lang> |
||
⚫ | |||
⚫ | |||
Call time 'R' |
Call time 'R' |
||
parse arg iFID width justify _ . /*get optional CL args.*/ |
parse arg iFID width justify _ . /*get optional CL args.*/ |
||
Line 168: | Line 169: | ||
return /*go back and keep truckin'. */ |
return /*go back and keep truckin'. */ |
||
⚫ | |||
<lang rexx> |
|||
⚫ | |||
/* REXX *************************************************************** |
/* REXX *************************************************************** |
||
* 20.08.2013 Walter Pachl "my way" |
* 20.08.2013 Walter Pachl "my way" |
||
Line 202: | Line 204: | ||
</lang> |
</lang> |
||
⚫ | |||
The last shown REXX program has a problem with classic REXX: '''fn''' is an unknown function. Also, that REXX program only reads the first record of the file (does exactly one read) instead of doing a loop until done. It would make more sense to exclude the time to read the file as well as bypassing the writing of the records to the file, as the I/O would be unvarying and slightly dependant on other I/O activity in the system, not to mention caching. Whoever does the first reading pays for all the I/O, the 2nd reading would be from cache. I would benchmark for a paragraph of text as the task says, not a million bytes. Scale up the number of executions to make the timings meaningful. Also, I took the liberty of breaking up the listing of the REXX programs into separate sections, perhaps it would be a good idea to label/identify them, not to mention to bring version 0 and 1 up to date. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:01, 21 August 2013 (UTC) |
|||
⚫ |