[m-rev.] for review: fix float_to_string so that roundtripping works

[Fergus Henderson]

On 19-Nov-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> fjh wrote:
> > > +#ifdef MR_USE_SINGLE_PREC_FLOAT
> > > + const char *format_a = ""%.7g"";
> > > + const char *format_b = ""%.9g"";
> > > + const char *format_r = ""%f"";
> > > + float round;
> > > +#else
> > > + const char *format_a = ""%.15g"";
> > > + const char *format_b = ""%.17g"";
> > > + const char *format_r = ""%lf"";
> > > + double round;
> > > +#endif
> >
> > I'd be tempted to do
> >
> > MR_Float round;
> >
> > outside the #ifdef.
> >
> > The way we actually read floats (string__to_float, etc.)
> > is to scan them in to a double using "%lf", and then
> > assign this double to a value of type MR_Float.
> > In the MR_USE_SINGLE_PREC_FLOAT case, this may produce different results
> > than scanning in directly as a float.  The code here should match
> > the technique used in string__to_float.  (Add comments mentioning this
> > in both places.)
>
> Why not instead change to code in string__to_float to match the behaviour I
> implemented?

That would be fine too.

> What is the advantage of reading it in as a double first?

The original reason was just that it makes the code a little simpler.

> To
> me it seems worse that we use single precision floats everywhere, except for
> reading them in and that could lead to slightly different behaviour.  I
> would prefer to be consistently use single precision floats everywhere.

Agreed.

> > > -:- pragma foreign_proc("MC++",
> > > +:- pragma foreign_proc("C#",
> > >  string__float_to_string(FloatVal::in, FloatString::uo),
> > >  [will_not_call_mercury, promise_pure, thread_safe], "{
> > > - FloatString = System::Convert::ToString(FloatVal);
> > > + FloatString = FloatVal.ToString(""R"");
> > >  }").
> >
> > What's that for?
> >
> > That change was not mentioned in the log message,
> > and is not acceptable without some rationale.
> > Also, it would help to document what the "R" argument to ToString() means.
>
> The R option outputs the float in a format such that it will roundtrip, so
> we don't need to jump through the hoops that we need to for the C backend.
> In fact this is what gave me the idea for how to solve the problem in the
> first place.  I will add a line to the log message and comment the meaning o
> f the R option.

OK.

Now the next problem will be what to do about floats that require 16
digits of precision.  The "R" format will print those to 17 digits of
precision, which is potentially misleading (and which won't match what
the C back-end does, if you adopt my earlier suggestion to try 16
digits of precision before 17).

I'd be satisfied with just an XXX comment for that issue...

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------