On 09/10/2014 12:11 PM, Roland Haas wrote:
Hello Ian, all,
range check. Something equivalent to (but with better wording):
"The parameter CoordBase::dx, entered as 40/48, evaluated to 0, which
is not in the range ..."
Possible, requires some change to the interface of CCTKi_SetParameter so
that it takes the original string as input as well as the parsed result
(see ParseFile in ParseFile.c and ProcessParameterDatabase.c) since the
range check happens in there.
It might be enough to have Piraha check the return code and print
out the line being evaluated if there's an error.
BTW looking at line 941 of src/piraha/Call.cc:
--8<--
893 std::string val;
894 smart_ptr<Group> aexpr = gr->group("expr");
895 if(aexpr.valid()) {
896 current_thorn = thorn;
897 smart_ptr<Value> smv = meval(aexpr);
898 val = smv->copy();
899 assert(smv.valid());
900 smv->integerize();
901 if(data != NULL) {
902 if(data->type == PARAMETER_REAL)
903 smv->integerize();
904 if(data->type == PARAMETER_BOOLEAN)
905 smv->booleanize(gr);
906 check_types(thorn.c_str(),aexpr->line(),smv,data->type);
907 }
908 set_function(
909 key.c_str(),
910 val.c_str(),
911 gr->group(0)->line());
912 } else {
--8<--
it seems to me as if set_function (which is CCTKi_SetParameter) is
called with the non-integerized and non-booleanized copy of the
expression result that was copied in line 898.
I understand that the intention is to be as close to C as possible,
and maybe we should do that for consistency. Note that not all
Cactus users are C programmers, and 40/48 == 0 is probably a common
pitfall for newcomers to the language.
I think for parfiles, I'd be happy to be less C like and be more like eg
perl (and python3) and do all arithmetic in floating point and either
required and only cast to int at the point where the parameter is
assigned. An automated cast when the result of the floating point
arithmetic is an integer is probably needed so that "Driver::ncells =
2*42" works as expected but "driver::ncells = 42/5" should require and
"int" cast. This can be made fancier by eg tracking "integerness
destroying" operations (and "integerness restoring" operations) so that
"1/3 * 3" would require a cast as well.
I could just use rational numbers instead of int or double for this
case (it's easy enough with oop)--but I'm skeptical that people
would really want this. I think we want to match the behavior of
a commonly used language in order for things to feel "intuitive."
Since most Cactus people are probably familiar with C or Fortran,
I would expect them to expect integer math.
Cheers,
Steve
Yours,
Roland
_______________________________________________
Users mailing list
[email protected]
http://cactuscode.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://cactuscode.org/mailman/listinfo/users
