mtsieve - Page 90

storm5510 · 2023-01-28, 23:59

Quote:

Originally Posted by rogue

...The difference between \n and \r doesn't make any sense. The code is GPU agnostic. But if it works for you, then who am I to complain.

I remember \n from trade school. New line. \r must be more recent. As long as it does its job and you have no suspicions about it working properly, then no problem here.

Mark Rose · 2023-01-29, 22:32

Quote:

Originally Posted by storm5510

I remember \n from trade school. New line. \r must be more recent. As long as it does its job and you have no suspicions about it working properly, then no problem here.

Unix traditionally used the line feed character (ASCII 10 or 0A) for a new line, commonly represented as \n.

Old Mac, before Mac OS X (which is Unix under the hood), used the carriage return character (13 or 0D), \r.

CP/M used both, \r\n. In many ways MS DOS was modelled after CP/M, including the use of both characters for a new line. That has continued on to modern Windows.

Most programming languages discard white space. Most editors are smart enough to work with the existing encoding of a text file.

https://blog.codinghorror.com/the-great-newline-schism/

LaurV · 2023-02-01, 05:51

Real programmers (TM) use \r or CR (carriage return) or ascii code 13 (hex 0x0D) for bringing the cursor at the beginning of the line, without advancing to the new line. This is very useful when you have "counting counters" or other running numbers or info on screen and you want that info to stay on the same line without changing the rest of the screen.
Same way, \n or LF (line feed) or ascii code 10 (hex 0x0A) is used to advance the line without bringing the cursor to the beginning of the line. Like moving the cursor down one row. You have also codes to move the cursor up, or left, right. On former tty (text) monitors (like VT100, etc) you would have to move the cursor here or there to write drop down menus, rewrite the screen under those, when the menu is closed, etc. There is also a FF character (form feed, page skip, you can see all these in an ascii table) which is dated from before terminals, when all the interface was on printer, and the printer would have to go to the next page. In "modern times" they got different uses but a "clever" terminal (like TeraTerm, etc., but also partially for less clever terminals like windows' HT or the command prompt) may have specific settings how these characters (and their combinations are treated). Some "less clever" systems/programs will make no difference and treat all of them like being both CR+LF, i.e. the cursor comes to the beginning of the next like - this is stupid and makes your screen behave like an old typewriter where you had a crowbar to push to return the carriage and advance a line in the same time, Norman style... There you can not (easily) make a running counter on screen, and generally your "grades of liberty" when you design the "text interface" of your program are much restricted.

Andrew Usher · 2023-02-01, 13:18

It would be nice to have the characters always work in that 'logical' way, but that can't be assumed anymore. In that case a newline would consist of both characters (in either order) and there DOS/Windows have it right, and CR+LF was not invented by CP/M but goes back to the ASCII standard, which in turn was based on actual typewriter/teletype use.

Unix is gratuitously incompatible here, and for the sake of saving one byte per line, which seems absurd today (it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).

storm5510 · 2023-02-02, 00:11

Quote:

Originally Posted by Andrew Usher

It would be nice to have the characters always work in that 'logical' way, but that can't be assumed anymore. In that case a newline would consist of both characters (in either order) and there DOS/Windows have it right, and CR+LF was not invented by CP/M but goes back to the ASCII standard, which in turn was based on actual typewriter/teletype use.

Unix is gratuitously incompatible here, and for the sake of saving one byte per line, which seems absurd today (it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).

I would think that, regardless of the programming language, the actual binary values of each would not change. From my days of tinkering with hex editors, I recognized them as 0A 0D.

Andrew Usher · 2023-02-02, 13:49

Actually, 0D 0A in DOS/Windows format (the other order won't generally work), but in a Unix-format text file, it really is just 0A. In any case, the C standard output converts all newlines written to it explicitly or implicitly into both functions, regardless of the system implementation, and the same is true of files opened in text mode (which are treated the same - another Unixism).

There is a way of doing the 'running counter' trick in DOS (don't know if it works the same in modern Windows) using non-standard functions, and it can be done in Unix also, but differently - there is no portable way of moving the cursor using ASCII characters, though there was supposed to be.

storm5510 · 2023-02-03, 04:49

Quote:

Originally Posted by LaurV

Real programmers (TM) use \r or CR (carriage return) or ascii code 13 (hex 0x0D) for bringing the cursor at the beginning of the line, without advancing to the new line...

How does this change in-process from overwriting an existing line to creating a new line below? rogue says he doesn't understand how it can do this in the case of srsieve2cl. My "guess" is that it has something to do with the GPU or its driver package. It does this on one of my GPU's, but not both.

LaurV · 2023-02-03, 09:46

Quote:

Originally Posted by Andrew Usher

(it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).

no, not impossible, there are "escape sequences" for those, I remember the old 0x1B, 0x5B, etc sequences I had to send to my VT52 and VT100 to move the cursor here and there, delete lines, etc. I remember they existed, I mean, and I used them in my Uni projects a lot, but I don't remember what they were. One can easily google those.

And to reply to storm too, I don't use srsieve2cl, but I am sure it can be done, as well as I am sure that the Linux terminal is a lot more clever than the Windoze stuff I use. Those terminals were modeled after the VT52, in fact.

Andrew Usher · 2023-02-03, 13:09

Quote:

Originally Posted by LaurV

no, not impossible, there are "escape sequences" for those, I remember the old 0x1B, 0x5B, etc sequences I had to send to my VT52 and VT100 to move the cursor here and there, delete lines ...

Yes, but that is not standard, which is my point. Although all terminal devices presumably can do this somehow, Unix chose not to support it - and if standard output were redirected to a file (as is always possible), those escape sequences might make it unreadable.

storm5510 · 2023-02-07, 01:40

@rogue:

How does srsieve2[cl] calculate removal rates?

Code:

2 factors found at 1081 sec per factor (last 12 min)

12 minutes is 720 seconds, not 1081. I don't get it!

rogue · 2023-02-07, 04:17

Quote:

Originally Posted by storm5510

@rogue:

How does srsieve2[cl] calculate removal rates?

Code:

2 factors found at 1081 sec per factor (last 12 min)

12 minutes is 720 seconds, not 1081. I don't get it!

CPU utilization is used in the calculation. Short runtimes will skew the calculations too.

2023-02-01, 05:51	#982
LaurV Romulan Interpreter "name field" Jun 2011 Thailand 3·23·149 Posts	Real programmers (TM) use \r or CR (carriage return) or ascii code 13 (hex 0x0D) for bringing the cursor at the beginning of the line, without advancing to the new line. This is very useful when you have "counting counters" or other running numbers or info on screen and you want that info to stay on the same line without changing the rest of the screen. Same way, \n or LF (line feed) or ascii code 10 (hex 0x0A) is used to advance the line without bringing the cursor to the beginning of the line. Like moving the cursor down one row. You have also codes to move the cursor up, or left, right. On former tty (text) monitors (like VT100, etc) you would have to move the cursor here or there to write drop down menus, rewrite the screen under those, when the menu is closed, etc. There is also a FF character (form feed, page skip, you can see all these in an ascii table) which is dated from before terminals, when all the interface was on printer, and the printer would have to go to the next page. In "modern times" they got different uses but a "clever" terminal (like TeraTerm, etc., but also partially for less clever terminals like windows' HT or the command prompt) may have specific settings how these characters (and their combinations are treated). Some "less clever" systems/programs will make no difference and treat all of them like being both CR+LF, i.e. the cursor comes to the beginning of the next like - this is stupid and makes your screen behave like an old typewriter where you had a crowbar to push to return the carriage and advance a line in the same time, Norman style... There you can not (easily) make a running counter on screen, and generally your "grades of liberty" when you design the "text interface" of your program are much restricted. Last fiddled with by LaurV on 2023-02-01 at 05:52

2023-02-07, 01:40	#989
storm5510 Random Account Aug 2009 Not U. + S.A. 5×523 Posts	@rogue: How does srsieve2[cl] calculate removal rates? Code: 2 factors found at 1081 sec per factor (last 12 min) 12 minutes is 720 seconds, not 1081. I don't get it!

2023-02-01, 13:18	#983
Andrew Usher Dec 2022 2²·7·11 Posts	It would be nice to have the characters always work in that 'logical' way, but that can't be assumed anymore. In that case a newline would consist of both characters (in either order) and there DOS/Windows have it right, and CR+LF was not invented by CP/M but goes back to the ASCII standard, which in turn was based on actual typewriter/teletype use. Unix is gratuitously incompatible here, and for the sake of saving one byte per line, which seems absurd today (it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).

2023-02-02, 13:49	#985
Andrew Usher Dec 2022 2²·7·11 Posts	Actually, 0D 0A in DOS/Windows format (the other order won't generally work), but in a Unix-format text file, it really is just 0A. In any case, the C standard output converts all newlines written to it explicitly or implicitly into both functions, regardless of the system implementation, and the same is true of files opened in text mode (which are treated the same - another Unixism). There is a way of doing the 'running counter' trick in DOS (don't know if it works the same in modern Windows) using non-standard functions, and it can be done in Unix also, but differently - there is no portable way of moving the cursor using ASCII characters, though there was supposed to be.