Trailing zeros required for floats?

Users
1

Hello! I had a question about the need for trailing zeros when initializing floats.

Running Chapel 2.1:

var a: real = 1. ;

Results in a syntax error. I know specifying the type will automatically convert 1 to 1.0, but why should this stylistic choice result in a syntax error? Similar initialization without trailing zeros is supported in C++ and Python.

1 Like
2

Chapel's slightly strict form means that it can support fully consistent hexadecimal and decimal floating point numbers. Unfortunately neither C++ nor Python do to their detriment.

If you want your example leaner and meaner, write it as

var a = 1.0;
2 Likes
3

Thank you!

4

@jmag722 : Tagging onto @damianmoz's response, I think that historically one other reason we took this strict approach was because Chapel supports defining and calling methods on basic types like integers, such that code like the following can be written [ATO]:

writeln(1.return2x());

proc int.return2x() {
  return 2*this;
}

If I recall correctly, I believe it simplified the compiler's lexer/parser for cases like this if 1. was not supported as a floating point literal value.

Also, note that file IO in Chapel is more accepting of such values than the compiler itself is, as demonstrated in this example, which reads the value 3. from stdin.

-Brad

5

One of the nice things that Chapel allows is a declaration of a hexadecimal float like

const x = 0x123.456;

C and C++ would demand a mandatory (but technically redundant) scale factor, i.e.

const double x = 0x123.456p0;

Just an interesting tidbit for the end of the week.

6

Thanks again. I found some additional information on this in the Lexical Structure section of the Chapel docs. Looks like there's lexical ambiguity between this and the range operator too

1 Like