Re: [Rd] minus: operator and sign (PR#7908)
[EMAIL PROTECTED] wrote: Full_Name: Allan Sims Version: 2.1.0 OS: WinXP Submission from: (NULL) (193.40.25.254) This should not be correct. It seams that first power is applied and then sign. -2^2 [1] -4 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel So you are telling us in a *bug* report that R works as expected??? The current R Language Definition manual tells us in Section Parser - Expressions - Infox and prefix operators (which is 10.4.2 in the current version) the details on the order of precendence (^ before unary -!). Please read the docs before submitting bug reports! Uwe Ligges __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minus: operator and sign (PR#7908)
Uwe Ligges wrote: [EMAIL PROTECTED] wrote: Full_Name: Allan Sims Version: 2.1.0 OS: WinXP Submission from: (NULL) (193.40.25.254) This should not be correct. It seams that first power is applied and then sign. -2^2 [1] -4 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel So you are telling us in a *bug* report that R works as expected??? The current R Language Definition manual tells us in Section Parser - Expressions - Infox and prefix operators (which is 10.4.2 in the current version) the details on the order of precendence (^ before unary -!). Please read the docs before submitting bug reports! Uwe Ligges BTW: ?Syntax should have told you as well. Uwe Ligges __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] minus: operator and sign (PR#7908)
On 31-May-05 [EMAIL PROTECTED] wrote: Full_Name: Allan Sims Version: 2.1.0 OS: WinXP Submission from: (NULL) (193.40.25.254) This should not be correct. It seams that first power is applied and then sign. -2^2 [1] -4 Rule 1: Know your enemy! ?Syntax -- The following unary and binary operators are defined. They are listed in precedence groups, from highest to lowest. ... '^'exponentiation (right to left) '- +' unary minus and plus ... '+ -' (binary) add, subtract ... So ^ takes precedence over unary -, which takes precedence over binary + and -. But it is always safe (and often prudent) to force precedence with parentheses -- at least you yourself are then absolutely sure of exactly what is going to happen, which is the really important thing (and this is Rule 2, which takes precedence over Rule 1). So if you want to force -2^2 and similar to be the square of -2 then do (-2)^2. And it adds clarity to things like 2 - - - 2^2 Best wishes, Ted. E-Mail: (Ted Harding) [EMAIL PROTECTED] Fax-to-email: +44 (0)870 094 0861 Date: 31-May-05 Time: 11:06:58 -- XFMail -- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] minus: operator and sign (PR#7908)
On 31-May-05 Ted Harding wrote: [...] But it is always safe (and often prudent) to force precedence with parentheses -- at least you yourself are then absolutely sure of exactly what is going to happen, which is the really important thing (and this is Rule 2, which takes precedence over Rule 1). So if you want to force -2^2 and similar to be the square of -2 then do (-2)^2. And it adds clarity to things like 2 - - - 2^2 PS: And will also avoid typopathological events such as x-y when what you really meant was x -y [1] FALSE Ted. E-Mail: (Ted Harding) [EMAIL PROTECTED] Fax-to-email: +44 (0)870 094 0861 Date: 31-May-05 Time: 11:50:07 -- XFMail -- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7899) seek(con, 0, end, rw=r) does not always work
Uwe Ligges wrote:
Tony Plate wrote:
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I've noticed that seek(con, 0, end, rw=r) on a file connection
does not always work correctly after a write (R 2.1.0 on Windows).
[Is a call to fflush() needed inside file_seek() in
main/connections.c?]
If you have an idea where to fflush() precisely and your patch works,
please tell it! I'll happily run some test cases where seeking matters.
I couldn't see why the current code was returning a bad value under
some conditions. (That's why didn't offer anything more than a
suggestion). My suggestion to use an fflush() was a guess (hence the
question mark, but evidence for the guess being correct was that doing
a flush at the R command line made the whole thing work correctly.)
To be safe, I would try to put a flush() right at the beginning of
file_seek(), before the call to f_tell(). I tried this, and with the
modification the test case I gave produced correct output. Here's how
the beginning of my modified file_seek() function (in
main/connections.c) looks:
static double file_seek(Rconnection con, double where, int origin, int
rw)
{
Rfileconn this = con-private;
FILE *fp = this-fp;
#if defined(HAVE_OFF_T) defined(__USE_LARGEFILE)
off_t pos;
#else
#ifdef Win32
off64_t pos;
#else
long pos;
#endif
#endif
int whence = SEEK_SET;
fflush(fp);
pos = f_tell(fp);
/* make sure both positions are set */
Works for your example, but I found another one where it introduces a
worse bug when using origin=current. Hence it's not that easy.
After reviewing this issue more closely, I think writeLines() into a
binary connection might be the real problem and a misuse in this case.
See the last paragrpah in the Details Section of ?writeLines. Hence,
this might also be an issue related to the text mode connection problem
on Windows.
Using simple writeChar and readChar statements works as expected for me
(at least, I was not able to produce anything unexpected). I'm no longer
convinced that this is a bug in R.
I see the same (buggy) behavior when I replace the writeLines()
statements by writeChar() statments (but continue using readLines()). I
also see the same buggy behavior when I explicitly supply a 'sep'
argument to writeLines(). Transcripts of both of these are below.
[Also, in both cases, calling the R function flush() at indicated
position in the transcript results in correct output.]
Regarding the documentation for writeLines, it states:
Normally 'writeLines' is used with a text connection, and the
default separator is converted to the normal separator for that
platform (LF on Unix/Linux, CRLF on Windows, CR on Classic MacOS).
For more control, open a binary connection and specify the
precise value you want written to the file in 'sep'. For even
more control, use 'writeChar' on a binary connection.
The sentence beginning For more control seems to permit the use of
writeLines() for binary connections. What suggested to you that it was
a misuse?
# seek(, rw=r) on a file does not always work a write
# even when sep=\n is supplied to writeLines
f - file(tmp3.txt, w+b)
# Write something earlier in the file
seek(f, 10, rw=w)
[1] 0
writeLines(c(ghi, jkl), f, sep=\n)
seek(f, 20, rw=w)
[1] 18
writeLines(c(abc), f, sep=\n)
seek(f, 0, end, rw=w)
[1] 24
# Try to read at the end of the file
seek(f, 0, end, rw=r)
[1] 0
readLines(f, -1)
character(0)
seek(f, 0, end, rw=w)
[1] 18
# write something at the end of the file
writeLines(c(def), f, sep=\n)
# Try to read at the end of the file
# flush(f) # flushing here makes the seek work correctly
seek(f, 0, end, rw=r)
[1] 24
seek(f, NA, rw=r) # ***WRONG*** (should return 28)
[1] 24
readLines(f, -1) # ***WRONG*** (should return character(0))
[1] def
seek(f, 20, rw=r)
[1] 28
readLines(f, -1)
[1] abc def
seek(f, 0, end, rw=r) # now it works correctly
[1] 28
seek(f, NA, rw=r)
[1] 28
readLines(f, -1)
character(0)
close(f)
# seek(, rw=r) on a file does not always work a write
# even when writeChar is used instead of writeLines
f - file(tmp3.txt, w+b)
# Write something earlier in the file
seek(f, 10, rw=w)
[1] 0
writeChar(c(ghi\n, jkl\n), f, eos=NULL)
seek(f, 20, rw=w)
[1] 18
writeChar(c(abc\n), f, eos=NULL)
seek(f, 0, end, rw=w)
[1] 24
# Try to read at the end of the file
seek(f, 0, end, rw=r)
[1] 0
readLines(f, -1)
character(0)
seek(f, 0, end, rw=w)
[1] 18
# write something at the end of the file
writeChar(c(def\n), f, eos=NULL)
# Try to read at the end of the file
# flush(f) # flushing here makes the seek work correctly
seek(f, 0, end, rw=r)
[1] 24
seek(f, NA, rw=r) # ***WRONG*** (should return 28)
[1] 24
readLines(f, -1) # ***WRONG*** (should return character(0))
[1] def
seek(f, 20, rw=r)
[1] 28
readLines(f, -1)
[1] abc def
[Rd] Problem with fPortfolio
Hello, I hesitate to call this a bug, because I could have forgotten something important, but the MarkowitzPortfolio example in fPortfolio does not work for me. Here's my code: library(fPortfolio) xmpPortfolio(\nStart: Load monthly data set of returns ) data(berndtInvest) # Exclude Date, Market and Interest Rate columns from data frame, # then multiply by 100 for percentual returns ... berndtAssets = berndtInvest[, -c(1, 11, 18)] rownames(berndtAssets) = berndtInvest[, 1] head(berndtAssets) CITCRP CONED CONTIL DATGENDEC DELTA GENMIL GERBERIBM MOBIL PANAM PSNH TANDY TEXACO 1-Jan-78 -0.115 -0.079 -0.129 -0.084 -0.100 -0.028 -0.099 -0.048 -0.029 -0.046 0.025 -0.008 -0.075 -0.054 1-Feb-78 -0.019 -0.003 0.037 -0.097 -0.063 -0.033 0.018 0.160 -0.043 -0.017 -0.073 -0.025 -0.004 -0.010 1-Mar-78 0.059 0.022 0.003 0.063 0.010 0.070 -0.023 -0.036 -0.063 0.049 0.184 0.026 0.124 0.015 1-Apr-78 0.127 -0.005 0.180 0.179 0.165 0.150 0.046 0.004 0.130 0.077 0.089 -0.008 0.055 0.000 1-May-78 0.005 -0.014 0.061 0.052 0.038 -0.031 0.063 0.046 -0.018 -0.011 0.082 0.019 0.176 -0.029 1-Jun-78 0.007 0.034 -0.059 -0.023 -0.021 0.023 0.008 0.028 -0.004 -0.043 0.019 0.032 -0.014 -0.025 WEYER 1-Jan-78 -0.116 1-Feb-78 -0.135 1-Mar-78 0.084 1-Apr-78 0.144 1-May-78 -0.031 1-Jun-78 0.005 ## Markowitz Portfolios: myPortfolio = portfolioMarkowitz(berndtAssets, targetReturn = 20/100/12) Error in portfolioMarkowitz(berndtAssets, targetReturn = 20/100/12) : Object pfolio not found version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Patched major2 minor1.0 year 2005 month05 day 09 language R __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
