> Martin Maechler
> on Mon, 2 Mar 2020 15:36:51 +0100 writes:
> Duncan Murdoch
> on Mon, 2 Mar 2020 04:43:53 -0500 writes:
>> On 02/03/2020 3:24 a.m., Martin Maechler wrote:
robin hankin
on Sun, 1 Mar 2020 09:26:24 +1300 writes:
>>>
>>> > Thanks guys, I guess I should have referred to FAQ 7.31
>>> > (which I am indeed very familiar with) to avoid
>>> > misunderstanding. I have always used dput() to clarify
>>> > 7.31-type issues.
>>>
>>> > The description in ?dput implies [to me at any rate] that
>>> > there will be no floating-point roundoff in its output. I
>>> > hadn't realised that 'deparsing' as discussed in dput.Rd
>>> > includes precision roundoff issues.
>>>
>>> > I guess the question I should have asked is close to
>>> > Ben's: "How to force dput() to return an exact
>>> > representation of a floating point number?". Duncan's
>>> > reply is the insight I was missing: exact decimal
>>> > representation of a double might not be possible (this had
>>> > not occurred to me). Also, Duncan's suggestion of control
>>> > = c("all", "hexNumeric") looks good and I will experiment
>>> > with this.
>>>
>>> This was not Duncan's suggestion but rather Duncan's *citation* :
>>> Note that he used " " !
>>>
>>> The citation is from ?deparseOpts (to which one is pointed when
reading ?dput),
>>>
>>> but unfortunately many people nowadays have stopped reading texts
>>> that are longer than a tweet... ;-)
>>>
>>> ... and indeed, ?dput and ?deparse use'control = "all"'
>>> instead of c("all", "hexNumeric") when talking about getting
>>> close to an inverse of parse()
>>>
>>> As a matter of fact, within R Core we had discussed this, many
>>> moons ago and actually had more or less decided to make "all"
>>> to *include* "digits17".
>>>
>>> "digits17" is "almost always" (I'm sorry I cannot quantify the
>>> 'almost' here) sufficient ... and is obviously conflicting with
>>> using hexadecimals instead of digits.
>>>
>>> For R 4.0.0, I think we should finally consider doing something
>>> here :
>>>
>>> 1) define "all" to include "digits17"
>>> so new "all" is current c("all", "digits17")
>>> {in a way such that c("all", "hexNumeric") implicitly removes
>>> "digits17" (as it's in contradiction with "hexNumeric").
>>>
>>> 2) add a new option "AllHex" := c("all", "hexNumeric"),
>>> (Note the capital "A": such that match.arg()-like abbreviation
>>> of .deparseOpts() arguments remain possible and notably "all"
>>> does not suddenly become ambiguous)
>>>
>>> Of course, '1)' is well possible without '2)',
>>> but '2)' would allow to use dput(*, control = "All")
>>> which is somewhat easier to readers & writers.
>> I think 1) is a good idea, and adding something with the meaning of
>> AllHex seems useful: but that's not a name I'd choose, since it's not
>> consistent with the other names (which are almost all camelCase). I'd
>> choose something like "exact" (even though it isn't :-).
> Thank you -- you are right;
> all "AllHex" is too non-orthodox and hence a pain for people to
> get right, remember, etc.
> In light of Steven Dirkse's reply (and other much older e-mails
> by others I remember only vaguely), it seems we still need to
> find an example (with numbers) where it is not exact ...
> which makes "exact" even more appropriate.
> Martin
I've now committed these two proposals, using "exact" -- to
R-devel (i.e., for R 4.0.0).
(wanted in one svn commit, but accidentally needed 2: svn r77891 + ...2).
Martin
>>> > On Sun, Mar 1, 2020 at 6:22 AM Duncan Murdoch
>>> > wrote:
>>> >>
>>> >> On 29/02/2020 4:19 a.m., Ben Bolker wrote:
>>> >> >
>>> >> > I think Robin knows about FAQ 7.31/floating point
>>> >> (author of > 'Brobdingnag', among other numerical
>>> >> packages). I agree that this is > surprising (to me).
>>> >> >
>>> >> > To reframe this question: is there way to get an
>>> >> *exact* ASCII > representation of a numeric value (i.e.,
>>> >> guaranteeing the restored value > is identical() to the
>>> >> original) ?
>>> >> >
>>> >> > .deparseOpts has
>>> >> >
>>> >> > ‘"digits17"’: Real and finite complex numbers are
>>> >> output using > format ‘"%.17g"’ which may give more
>>> >> precision than the > default (but the output will depend
>>> >> on the platform and there > may be loss of precision when
>>> >> read back).
>>> >> >
>>> >> > ... but this still doesn't guarantee that all precision
>>> >> is kept.
>>> >>
>>> >> "Using control = c("all", "hexNumeric") comes closest to
>>> >> making deparse() an inverse of parse(), as repres
