I like that.Ivan Denisov wrote:Doug, you can do something like thisCode: Select all
mat := StrToMat( "1, 0, 0, 0, 0" + 0DX + "1, 1, 0, 0, 0" + 0DX + "1, 0, 1, 0, 0" + 0DX + "1, 0, 0, 1, 0" + 0DX + "1, 0, 0, 0, 1" )
Thanks, Ivan.
I like that.Ivan Denisov wrote:Doug, you can do something like thisCode: Select all
mat := StrToMat( "1, 0, 0, 0, 0" + 0DX + "1, 1, 0, 0, 0" + 0DX + "1, 0, 1, 0, 0" + 0DX + "1, 0, 0, 1, 0" + 0DX + "1, 0, 0, 0, 1" )
Code: Select all
NEW (mat, 4);
mat [0] := IVec.SetStr ('1, 1, 1, 0, 0, 0');
mat [1] := IVec.SetStr ('1, 0, 1, 0, 0 +0');
mat [2] := IVec.SetStr ('1 1 1 0 0 -0');
mat [3] := IVec.SetStr ('0 0 -1 0 +1, 5');
mat := IMat.SetStr (
'1, 1, 1, 0, 0, 0 |' +
'1, 0, 1, 0, 0 +0 |' +
'1 1 1 0 0 -0 |' +
'0 0 -1 0 +1, 5');
Code: Select all
PROCEDURE SetStr* (IN str : ARRAY OF CHAR) : Matrix;
VAR
a, b, r : INTEGER;
chr : CHAR;
txt : ARRAY 128 OF CHAR;
mat : Matrix;
BEGIN
LOOP
a := 0; b := 0; r := 0;
LOOP
chr := str [b]; txt [a] := chr;
IF (chr = '|') OR (chr = 0X) THEN
IF mat # NIL THEN
txt [a] := 0X; mat [r] := IVec.SetStr (txt); a := -1
END;
INC (r);
IF chr = 0X THEN
IF (mat = NIL) & (b > 0) THEN NEW (mat, r); EXIT ELSE RETURN mat END
END
END;
INC (a); INC (b)
END
END
END SetStr;
I have implemented Ivan's suggestion (it took a little more code than I expected)Robert wrote:I sympathise with both of Doug's desires:
- To have a simple way to texturally specify a small matrix
- And to make the corresponding source code easy to read.
I think Helmut pointed out the main reason.DGDanforth wrote:You are probably right.Robert wrote:I'm not sure this is so cumbersome & ugly that it justifies a language change.
So let me shift the discussion to "why did Wirth think it necessary to exclude line breaks?"
Helmut's comment about CR vs CR+ LF may be the reason but each Host would have its
convention that could easily be incorporated into the compiler
Josef Templ wrote: I think Helmut pointed out the main reason.
The compiler doesn't know how to handle line feedsbecause it depends on the intended usage.Doug wrote:why not?When the string is inserted into a BlackBox TextModels.Model it is always a CR,Doug wrote:How so?when output to the console or an ASCII text file it is either a CR, CR-LF or a LF, for example.Doug wrote:When a line is instertedAnother reason is the error reporting in the compiler.Doug wrote:Why 3 different forms?
An unclosed string may lead to skipping parts of the source text and
to strange follow up errors further below and you don't always see where the
erroneous symbol started.Another problem is source code indentation, which leads to leading white space in the lines of the string,Doug wrote:Yes, and how does that affect line breaks in strings? If one forgets to close a string then you simply get, as it is now, a compiler warning.
or if not acceptable, you must give up source code indentation.Note, a constant expression like line1 + CR + line2 is evaluated at compile time.Doug wrote:For the example considered below with matrices white space is consider a delimiter and removed.
There is no runtime overhead.
- Josef
There wouldn't be a compiler warning as it wouldn't know the string wasn't closed if strings can span several lines. It would swallow everything until the opening quote of the beginning of the next string, which it would think was the closing quote of this string. It would then believe that everything in the next string was code etc. etc. Aaargh!!!Josef Templ wrote: Another reason is the error reporting in the compiler.
An unclosed string may lead to skipping parts of the source text and
to strange follow up errors further below and you don't always see where the
erroneous symbol started.Doug wrote:Yes, and how does that affect line breaks in strings? If one forgets to close a string then you simply get, as it is now, a compiler warning.
Chris,cfbsoftware wrote:There wouldn't be a compiler warning as it wouldn't know the string wasn't closed if strings can span several lines. It would swallow everything until the opening quote of the beginning of the next string, which it would think was the closing quote of this string. It would then believe that everything in the next string was code etc. etc. Aaargh!!!Josef Templ wrote: Another reason is the error reporting in the compiler.
An unclosed string may lead to skipping parts of the source text and
to strange follow up errors further below and you don't always see where the
erroneous symbol started.Doug wrote:Yes, and how does that affect line breaks in strings? If one forgets to close a string then you simply get, as it is now, a compiler warning.
A useful reminder.Josef Templ wrote:Note, a constant expression like line1 + CR + line2 is evaluated at compile time.
There is no runtime overhead.
That was never likely!Doug wrote:Final comment.
I don't think we are talking about strings, and whether they can contain line-feeds (they can).DGDanforth wrote:That feels like an "engineering" solution to a theory. What is a "string"?
Code: Select all
int train_X[6][6] = {{1, 1, 1, 0, 0, 0},{1, 0, 1, 0, 0, 0},{1, 1, 1, 0, 0, 0},{0, 0, 1, 1, 1, 0},{0, 0, 1, 0, 1, 0},{0, 0, 1, 1, 1, 0}};