Markus Neteler wrote:
> > I just stumbled upon this while running a large model, and noticed that I
> > couldn't easily find an answer:
> >
> > IIUC r.mapcalc does not support scientific notation of floating point
> > numbers (i.e. 2.540000e-05 instead of 0.0000254). Is that correct ?
> >
> > How difficult would it be to implement the support of such notation ?
>
> We just stumbled over the same issue... would be nice to have.
It works here:
$ r.mapcalc "foo = 2.540000e-05"
$ r.info -r foo
min=2.54e-05
max=2.54e-05
$ g.version -gr
version=7.3.svn
date=2016
revision=r70088
build_date=2017-06-16
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=70829
libgis_date="2017-04-04 08:43:02 +0100 (Tue, 04 Apr 2017) "
mapcalc.l specifically recognises exponential notation:
I [0-9]+
E [eE][-+]?[0-9]+
%%
{I}"."{I}?{E}? |
"."{I}{E}? {
yylval.fval = atof(yytext);
return DOUBLE;
}
atof() is specified as:
7.20.1.1 The atof function
...
[#2] The atof function converts the initial portion of the
string pointed to by nptr to double representation. Except
for the behavior on error, it is equivalent to
strtod(nptr, (char **)NULL)
and strtod() as
7.20.1.3 The strtod, strtof, and strtold functions
...
[#3] The expected form of the subject sequence is an
optional plus or minus sign, then one of the following:
-- a nonempty sequence of decimal digits optionally
containing a decimal-point character, then an optional
exponent part as defined in 6.4.4.2;
I note that any locale-specific varations are supposed to be in
addition to the format used by the "C" locale, so even if LC_NUMERIC
gets set (and it shouldn't), that shouldn't affect it.
Is this issue a wxGUI thing?
--
Glynn Clements <[email protected]>
_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev
