> 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:
>>>
> 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
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
> 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
Ben,
I'll edit and split your question just a little.
1) "Is there a way to get an *exact* ASCII representation of a
double-precision value?"
2) "Is there a way to get round-trip behavior, i.e. to make sure that the
value, when converted back to double, is identical() to the original"
The hex
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 ha
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 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 ide
Hi Robin,
In the future, questions like this belong on R-help, not R-devel as it is a
basic usage question not a discussion about development of the R language
itself or similar.
That said, ?dput states a number of times that exact deparsing is not
always possible and that dput is not appropriate
On 2/28/20 11:42 PM, Rui Barradas wrote:
Hello,
FAQ 7.31
See also this StackOverflow post:
https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal
That was going to be my initial response, but then I realized that the
question might be why the dput representation of
Hello,
FAQ 7.31
See also this StackOverflow post:
https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal
Hope this helps,
Rui Barradas
Às 00:08 de 29/02/20, robin hankin escreveu:
My interpretation of dput.Rd is that dput() gives an exact ASCII form
of the internal repr
My interpretation of dput.Rd is that dput() gives an exact ASCII form
of the internal representation of an R object. But:
rhankin@cuttlefish:~ $ R --version
R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-pc-l
Looking at the help file and code for dput does not show any simple
way to do what you want. But the help page makes reference to the
deparse function and deparse does have a width.cutoff argument. So
you could use deparse instead of dput (the use cat or other functions
to display the results sim
Is there some way to control the line width that dput uses?
options(width=...) does not affect dput.
For example, currently
> dput(1:30*2)
c(2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, *line break
here*
34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60)
but on a wider displa
On 3/24/2009 10:02 AM, Stavros Macrakis wrote:
Peter, Duncan,
I understand that the missing value indicator is special and will not
behave like an ordinary value in evaluation. I was only discussing its
handling in the text representation functions dput and dump.
Duncan,
You are absolutely rig
Peter, Duncan,
I understand that the missing value indicator is special and will not
behave like an ordinary value in evaluation. I was only discussing its
handling in the text representation functions dput and dump.
Duncan,
You are absolutely right that "list(x=)" is parseable (though not
evalu
Duncan Murdoch wrote:
On 23/03/2009 7:37 PM, Stavros Macrakis wrote:
It appears to be the
zero-length name:
is.name(ff$x) => TRUE
as.character(ff$x) => ""
This may give you a hint:
> y <- ff$x
> y
Error: argument "y" is missing, with no default
It's a special internal thing th
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
> Sent: Monday, March 23, 2009 5:28 PM
> To: Stavros Macrakis
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] dput(as.list(function...).
On 23/03/2009 7:37 PM, Stavros Macrakis wrote:
Tested in R 2.8.1 Windows
ff <- formals(function(x)1)
ff1 <- as.list(function(x)1)[1]
# ff1 acts the same as ff in the examples below, but is a list rather
than a pairlist
dput( ff , control=c("warnIncomplete"))
list(x = )
This string is not p
Stavros Macrakis wrote:
> Tested in R 2.8.1 Windows
>
>
>> ff <- formals(function(x)1)
>> ff1 <- as.list(function(x)1)[1]
>>
> # ff1 acts the same as ff in the examples below, but is a list rather
> than a pairlist
>
>
>> dput( ff , control=c("warnIncomplete"))
>>
> list(x = )
>
> T
Tested in R 2.8.1 Windows
> ff <- formals(function(x)1)
> ff1 <- as.list(function(x)1)[1]
# ff1 acts the same as ff in the examples below, but is a list rather
than a pairlist
> dput( ff , control=c("warnIncomplete"))
list(x = )
This string is not parsable, but dput does not give a warning as sp
By the way, valgrind finally finished checking
this example and found no problems after adding
the PROTECT(tval). Nor did valgrindless R crash as it
did before on this example.
-Bill
On Thu, 7 Aug 2008, Prof Brian Ripley wrote:
> Bill,
>
> Thanks. Whether or not it is the cause here it should c
Bill,
Thanks. Whether or not it is the cause here it should clearly be
PROTECT-ed (I suspect the original version didn't need to be, but leaving
PROTECTs off is prejudicial to future maintenance), so I've incorporated
this in R-devel/R-patched.
Brian
On Thu, 7 Aug 2008, Bill Dunlap wrote:
On Thu, 7 Aug 2008 [EMAIL PROTECTED] wrote:
> Full_Name: Juan Gea
> Version: R version 2.6.2
> OS: Fedora Core 6
> Submission from: (NULL) (79.153.48.49)
>
> Abort:
>
> objeS <- matrix("AAA",100)
> class(objeS)
> outTxt <- textConnection("vaClob", open = "w", local = FALSE)
> dput(objeS,outTx
Full_Name: Juan Gea
Version: R version 2.6.2
OS: Fedora Core 6
Submission from: (NULL) (79.153.48.49)
Abort:
objeS <- matrix("AAA",100)
class(objeS)
outTxt <- textConnection("vaClob", open = "w", local = FALSE)
dput(objeS,outTxt)
close(outTxt)
R version 2.6.2 (2008-02-08)
Copyright (C)
It is right.
The problem is that dput() does not give a faithful representation, as its
help says. R 2.5.0 does a better job, since the defaults for dput() have
been changed, enough so that your example works there.
On Sun, 22 Apr 2007, [EMAIL PROTECTED] wrote:
> This doesn't seem right; I'm
This doesn't seem right; I'm using R version 2.4.1 (2006-12-18) on Mac OS
and Win XP and find the same issue:
> mydataframe <- data.frame(ppi=c(.5,.5),mmu=c(5,10))
> dput(mydataframe,"mydataframe.txt")
> dget("mydataframe.txt")
Error in attributes(.Data) <- c(attributes(.Data), attrib) :
row n
27 matches
Mail list logo
