[Rd] as.numeric(levels(factor(x))) may be a decreasing sequence

[Wacek Kusnierczyk]

Petr Savicky wrote:
> On Fri, May 29, 2009 at 03:53:02PM +0200, Martin Maechler wrote:
>   
>> my version of *using* the function was
>>
>> 1 SEXP attribute_hidden StringFromReal(double x, int *warn)
>> 2 {
>> 3   int w, d, e;
>> 4   formatReal(&x, 1, &w, &d, &e, 0);
>> 5   if (ISNA(x)) return NA_STRING;
>> 6   else return mkChar(dropTrailing0(EncodeReal(x, w, d, e, OutDec), OutDec));
>> 7 }
>>
>> where you need to consider that mkChar() expects a 'const char*' 
>> and EncodeReal(.) returns one, and I am pretty sure this was the
>> main reason why Petr had used the two 'const char*' in (the
>> now-named) dropTrailing0() definition. 
>>     
>
> Yes, the goal was to accept the output of EncodeReal() with exactly the
> same type, which EncodeReal() produces. A question is, whether the
> output type of EncodeReal() could be changed to (char *). Then, changing
> the output string could be done without casting const to non-const.
>
>   
exactly.  my suggestion was to modify your function so that no modify a
constant string-cheating is done, by either (a) keeping the const but
returning a *new* string (hence no const-to-nonconst cast would be
needed), or (b) modify your function to accept a non-const string *and*
modify the code that connects to your function via the input and output
strings. 

note, if a solution in which your function serves as a destructive
filter is just fine (martin seems to have accepted it already), then
EncodeReal probably can produce just a string, with no const qualifier,
and analogously for mkChar.  on the other hand, if EncodeReal is
purposefully designed to return a const string (i.e., there is an
important reason for doing so), and analogously for mkChar, then your
function violates the assumptions and can potentially be harmful to the
rest of the code.


> This solution may be in conflict with the structure of the rest of R code,
> so i cannot evaluate, whether this is possible.
>
>   

well, either the rest of the code does *not* need const, and it can be
safely removed, or it *does* rely on const, and your solution ciolates
the expectation.

vQ