Input clarification

Input clarification

The .PDF filerules state the line termination character is semicolon (;) and makes no reference as to what constitutes an inputline, in particularis it CR, LF, CRLF or the aformentioned are considered whitespace. Meaning

---------------------
var x=50;var y=10
; var z = 9;
---------------------

is valid input. I will have to assume since this is not mentioned that this is left as an implementation detail
Note, in your "Valid keywords and functions" table, section "var", lines 3 and 4, column Examples has

var decimal =
345.212312321;

Using this from the "published" rules would indicate that text line termination characters and extraneous white space is to be ignored.

Note, the above statement could be false (please state so) and if so, then would this mean program comments can follow the line termination? e.g.

var decimal = 345.212312321; This is a decimal variable

Some clarification has to be made regarding this.

Second input question:

You state string variables have a max length of 256 characters. Are we supposed to produce an error message if this length is exceeded even if our implimentation supports longer length character variables?

Third input question:

Is there an inputline length limit?

Will you provide a representative range for the size of the input file (e.g. byte size or number of statements). It makes little sense to write a parallel interpreter for a one statement program.

Lack of clarification on these and other users queries will have to be assumed "and implementation detail".

Jim Dempsey

www.quickthreadprogramming.com
publicaciones de 13 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Hi,
Thanks for bringing these aspects to our notice and raising the questions. Please find below my response:

1.To answer the 1st question, note that you cannot carry a statement across 2 or more lines of source code. That is, the semicolon and source statement should be placed in the same source line. Sorry, inthe problem description table we have given "var decimal" definition split across 2 lines. This happened because of word text wrapping which didn't correct. Support for CR or LF or CRLF must be provided to indicate end of line and beginning on new source statements in the next line.

2. Yes, if the characters input to the string variable is more than 256, an error "Cannot assign more than 256 characters" should be reportedin the output file and parsing stops.

3. There isn't any input length limit. Since we are doing benchmarking, we will want to have a large number of statements to exercise the parsers submitted. So, I don't have an estimate of the input size yet.

Hope this clarifies. Please let me if you want more details or have queries.

Thanks
-Rama

Quoting Rama Kishan Malladi (Intel)
Hi,
Thanks for bringing these aspects to our notice and raising the questions. Please find below my response:

1.To answer the 1st question, note that you cannot carry a statement across 2 or more lines of source code. That is, the semicolon and source statement should be placed in the same source line. Sorry, inthe problem description table we have given "var decimal" definition split across 2 lines. This happened because of word text wrapping which didn't correct. Support for CR or LF or CRLF must be provided to indicate end of line and beginning on new source statements in the next line.

2. Yes, if the characters input to the string variable is more than 256, an error "Cannot assign more than 256 characters" should be reportedin the output file and parsing stops.

3. There isn't any input length limit. Since we are doing benchmarking, we will want to have a large number of statements to exercise the parsers submitted. So, I don't have an estimate of the input size yet.

Hope this clarifies. Please let me if you want more details or have queries.

Thanks
-Rama

#1: Rama, are you saying that the input files provided will not contain statements split across lines, or that CR / LF in the middle of a statement must, necessarily, be treated as an error and cause execution to stop?

Just that this adds one more error state to check for...

Hi,
From my understanding, not having multiple-line split of statements will make it easier for you to implement the parser. Otherwise, you will have to use a statement continuation symbol or assume that statements flow across multiple source lines but that has its own complexities. So, to keep it simple, a statement can span only 1 source line. However, multiple source statements can be placed on 1 source line.

Does this help answer your query?

Thanks
-Rama

Rama,

--------------
My interpretation of your replies, and please confirm or correct,is:

1) Input data (interpreter source) will consist of one or more text lines terminated by customary line termination character(s) (i.e. CR, LF, CRLF, ??other).
2) text is ASCII character set.
3) zero or more code statements may appear in each text line
4) code statement is terminated with semicolon (;)

The above is subset of rules.

What about End of File? Is that equivalent to line termination?
--------------------
--------------------
Should CR and LF and TABbe equivilent to the Space character?

If so then this would permit multi-line statement

x =
y
+ z;

In C such treatment is standard.
--------------------
--------------------
Is there operator precedence? (*,/ higher than +,-)
-------------------
-------------------
In some languages I've use (and written) you are permitted to write an expression that serves as an inline function.

Exampleusing your script:

x = 123 + (var y = 456; var z = 789; y*z + (free(y); free(z); 0));

The above isn't as screwy as it first appears. In MS Word (and other editors) you can maintain lists of frequently used paste buffers. These paste buffers can then contain the equivilent to a C function complete with local variables.
There is nothing in your contest rules to state if "inline functons" are valid syntax or not.

Note, even though your proposed test programs will not use "inline functions" you may include parsing checker test program in which the test program contains a valid "inline function" (should inline functions be supported).
------------------
------------------
Your rules stated "For example, output(50.323467) should send 50.3234670000 to the output."

Does this statement mean the internal numeric data type has to be decimal (text)as opposed to IEEE 754 double?

If decimal text is to be used internally then is the max length for the numeric value256 characters (including possible ".")?
Are the values, if stored in characters, packed (0-9, ., +, -). Thus permitting numberic values to span up to 510/512 digits?
-----------------
Does output(expressionHere) succeed or fail when theresultant line islonger than 256 characters?

Sorry for asking so may questions.

Jim Dempsey

www.quickthreadprogramming.com

Quoting Rama Kishan Malladi (Intel)
Hi,
From my understanding, not having multiple-line split of statements will make it easier for you to implement the parser. Otherwise, you will have to use a statement continuation symbol or assume that statements flow across multiple source lines but that has its own complexities. So, to keep it simple, a statement can span only 1 source line. However, multiple source statements can be placed on 1 source line.

Does this help answer your query?

Thanks
-Rama

I understand that one statement can occupy only one newline-terminated line. But, there can be multiple statements per newline-terminated line.

Maintaining statement continuation symbols becomes relevant if an implementation processes the input one newline-terminated line at a time. However, if I process the input file one byte at a time and simply treat space, CR, LF (, tab?) as whitespace characters, CR/LF will be ignored just like spaces. The only end-of-source-line I would need to look for is a semi-colon.

Let me re-phrase my question.

Consider the following code snippet:
averageOfValues = totalOfValues /
numberOfValues;

Again, I understand that one statement can occupy only one newline-terminated line. But, should the above statement produce an error?

In other words, will there be test cases, designed specifically to test this particular condition?

Hi Jim,
Thanks for asking questions and clarifying. To reiterate, we are looking for a parallel implementation of a simple parser and formula interpreter. So, we would like to keep the problem statement and implementation scope fairly small and exclude some of the advanced features supported in many of the modern languages.

Please find below my response to your queries. Let me know if these clarifications help.

1. Your subset of rules is a correct interpretation.

2. EOF will be determined when you reach the end of the input text file. There is no explicit EOF symbol or indicator.

3. TAB can be treated equivalent to space character. CR and LF aren't treated as space character. So, multi-line split statements are not allowed in this parser implementation. This simplifies things.

4. Operator precedence: We haven't defined one. Good point. There isn't any operator precedence. Please evaluate expressions from right to left in the RHS of the mathematical expression.

5. There is inline functions support in the parser.

6. We are not looking for IEEE support in the mathematical expressions. Output correctness is required but precision of the output will be relaxed to keep it simple.

7. Values are not stored in packed form. So, a string can have only 256 digits.

8. output(expression) where expression could result in >256 characters: It will not succeed as we have defined that the result of the expression will be converted to string and then sent to output file.

Thanks
-Rama

Hi,
I agree with your description. But we will not have test-cases that will spawn the source statements across multiple lines. If the source statements spawn multiple source lines, the parser should flag an error and stop.

Thanks
-Rama

Quoting Rama Kishan Malladi (Intel)

4. Operator precedence: We haven't defined one. Good point. There isn't any operator precedence. Please evaluate expressions from right to left in the RHS of the mathematical expression.

8. output(expression) where expression could result in >256 characters: It will not succeed as we have defined that the result of the expression will be converted to string and then sent to output file.

The spec says that parentheses are used to control order evaluation, so operator precedence isn't necessary.My interpretation of that was that "a = 1 + 2 + 3" would be a syntax error, and that compound expressions would have the execution order made explicit by parenthes: "a = 1 + (2 + 3)".It is isn't a big deal to add right-to-left evaluation, so that the first example is implicitly treated as the second, but given that the present spec already deals with this (parentheses are mandatory for compound expressions) then why change it?

Hi,
I agree that we have given parentheses usage to control order of execution. But in case they aren't used, we can either flag an error or execute them to an operator precendence or execute from right-to-left or left-to-right. So, in this case, instead of flagging an error,I think it would be better to evaluate expression from right-to-left. Hope this clarifies.

Thanks
-Rama

>>2. EOF will be determined when you reach the end of the input text file. There is no explicit EOF symbol or indicator

Yes, but I asked about something like

free(foo);{EOF}

as opposed to

free(foo);{CRLF}
{EOF}

Is the former in errro or not in error?

>>5. There is inline functions support in the parser.

I want to make this clear. I am not talking about functions in line such as sqrt(expr) I am talking about inline functions that would otherwise appear to be mismatched parens "()'s"

vecMag = 0+(X + (Y + (Z + ( {function here} ;

and {function here}, your handy dandy piece of generic code to perform vector magnitude with arbitrary argument names that you paste in from your "ide" containing:

var _Z=);var _Y=);var _X=);_X=_X*_X;_Y=_Y*_Y;_Z=_Z*_Z;sqrt(_X+_Y+_Z)+(free(_X);free(_Y);free(_Z);0));

Note seamingly mismatched parens with "var _Z=);var _Y=);var _X=);" and statement with no variable "0));"

To make this simple

{numeric value or expression}op(

means push value/expression together with operatoronto evaluation stack and clear current value

)

means pop top value and operatoroff stack an perform operation.

So, are inline functions supported?

Jim

www.quickthreadprogramming.com

Jim, I think you're trying to make up a different language ;-)

Jim,The kind of inline functions you mention aren't supported.The parser should support expressions as parameters, as explained in the problem description:output(25
+ 32);output(string(20)
+ string(70));output((30
+ 20) + 10);var
str4 = "result: " + string(50 / 2);output("First
result: " + string(result));var
powRes = pow(20 + 5, (6 / res));output("srq:
" + string(sqrt(30)));

output("Value for a: " +
string(a));

output("Value for b: " +
string(b));

message = message + string(a / b);

Hope it clarifies.Cheers,Gaston

Gastón C. Hillar

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya