[Rd] Problem using ofstream in C++ class in package for MacOS X
Dear all,
I am currently learning how to create R packages using C++ classes.
For this purpose I have written a small package MyClass (which I try
to attach since I do not have access to a website).
MyClass has methods WriteFileC() and WriteFileCpp() which implement
C-style and C++-style writing of a table to a file using FILE or
ofstream respectively, and the corresponding R-functions writeFileC.R
and writeFileCpp.R.
While I can compile and execute my package w/o problems on Fedora Core 4,
I can only execute writeFileC.R on my Intel-MacBook Pro, but not
writeFileCpp.R.
Executing my functions I get the following output:
> library(MyClass)
Welcome to MyClass
> writeFileC("myout_fileC.txt")
[1] "outfile = myout_fileC.txt"
Writing file myout_fileC.txt using C style.
---MyClassA::MyClassA()-
---MyClassA::WriteFileC-
<20> records exported.
---MyClassA::~MyClassA()-
[1] "writeFileC finished"
NULL
> writeFileCpp("myout_fileCpp.txt")
[1] "outfile = myout_fileCpp.txt"
Writing file myout_fileCpp.txt using C++ style.
---MyClassA::MyClassA()-
---MyClassA::WriteFileCpp-
*** caught bus error ***
address 0x6, cause 'non-existent physical address'
Traceback:
1: .C("WriteFileCpp", as.character(outfile), PACKAGE = "MyClass")
2: writeFileCpp("myout_fileCpp.txt")
While I understand, that C++ iostreams are best avoided, since there is
no guarantee that the output will appear in the R console (as mentioned
on page 62 of R-exts.pdf), I do not understand why I cannot use ofstream,
which is isolated in a C++ method only.
Is there a way how to use ofstream on MacOS X or is this a limit of the
current Mac implementation?
Thank you in advance.
Best regards
Christian
_._._._._._._._._._._._._._._._
C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
_._._._._._._._._._._._._._._._
MyClass_0.1.2.tar.gz
Description: GNU Zip compressed data
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
On 4 February 2007 at 20:17, cstrato wrote:
| I am currently learning how to create R packages using C++ classes.
Congratulations :)
[ This reminds me to email Oleg (CC'ed). Oleg, your HOWTO is a very useful.
Would you consider adding a section on Dominick's most excellent RcppTemplate
package which makes writing code to go back and forth between R and C++ s
much easier? ]
| For this purpose I have written a small package MyClass (which I try
| to attach since I do not have access to a website).
[...]
| While I can compile and execute my package w/o problems on Fedora Core 4,
Works for me too on Debian.
[...]
| > writeFileCpp("myout_fileCpp.txt")
| [1] "outfile = myout_fileCpp.txt"
| Writing file myout_fileCpp.txt using C++ style.
| ---MyClassA::MyClassA()-
| ---MyClassA::WriteFileCpp-
|
| *** caught bus error ***
| address 0x6, cause 'non-existent physical address'
|
| Traceback:
| 1: .C("WriteFileCpp", as.character(outfile), PACKAGE = "MyClass")
| 2: writeFileCpp("myout_fileCpp.txt")
|
|
| While I understand, that C++ iostreams are best avoided, since there is
| no guarantee that the output will appear in the R console (as mentioned
| on page 62 of R-exts.pdf), I do not understand why I cannot use ofstream,
| which is isolated in a C++ method only.
|
| Is there a way how to use ofstream on MacOS X or is this a limit of the
| current Mac implementation?
Can you get to this in a debugger on MacOS X? Just glancing at your code I
saw nothing obviously sticking out...
Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Dirk Eddelbuettel wrote:
> On 4 February 2007 at 20:17, cstrato wrote:
> | I am currently learning how to create R packages using C++ classes.
>
> Congratulations :)
>
> [ This reminds me to email Oleg (CC'ed). Oleg, your HOWTO is a very useful.
> Would you consider adding a section on Dominick's most excellent RcppTemplate
> package which makes writing code to go back and forth between R and C++ s
> much easier? ]
>
> | For this purpose I have written a small package MyClass (which I try
> | to attach since I do not have access to a website).
> [...]
> | While I can compile and execute my package w/o problems on Fedora Core 4,
>
> Works for me too on Debian.
>
> [...]
> | > writeFileCpp("myout_fileCpp.txt")
> | [1] "outfile = myout_fileCpp.txt"
> | Writing file myout_fileCpp.txt using C++ style.
> | ---MyClassA::MyClassA()-
> | ---MyClassA::WriteFileCpp-
> |
> | *** caught bus error ***
> | address 0x6, cause 'non-existent physical address'
> |
> | Traceback:
> | 1: .C("WriteFileCpp", as.character(outfile), PACKAGE = "MyClass")
> | 2: writeFileCpp("myout_fileCpp.txt")
> |
> |
> | While I understand, that C++ iostreams are best avoided, since there is
> | no guarantee that the output will appear in the R console (as mentioned
> | on page 62 of R-exts.pdf), I do not understand why I cannot use ofstream,
> | which is isolated in a C++ method only.
> |
> | Is there a way how to use ofstream on MacOS X or is this a limit of the
> | current Mac implementation?
>
> Can you get to this in a debugger on MacOS X? Just glancing at your code I
> saw nothing obviously sticking out...
>
> Dirk
>
>
Dear Dirk
Thank you for your fast answer.
Sorrowly, I don´t know how to use a debugger on MacOS X, I am using
old-style print commands.
However, here is the output of the crash log from my Mac. Does it help?
**
Host Name: coeurebooks-computer
Date/Time: 2007-02-04 18:51:50.233 +0100
OS Version: 10.4.8 (Build 8N1051)
Report Version: 4
Command: R
Path:/Library/Frameworks/R.framework/Resources/bin/exec/i386/R
Parent: bash [206]
Version: ??? (???)
PID:1836
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0006
Thread 0 Crashed:
0 libstdc++.6.dylib 0x020fe231 std::basic_ostream >::flush() + 17 (ostream.tcc:395)
1 libstdc++.6.dylib 0x020fe358 std::basic_ostream
>::sentry::sentry[in-charge](std::basic_ostream >&) + 120 (ostream.tcc:56)
2 libstdc++.6.dylib 0x02100b5d std::basic_ostream >& std::operator<<
>(std::basic_ostream >&, char const*) + 29
(ostream.tcc:620)
3 MyClass.so0x0004a30f MyClassA::WriteFileCpp(char const*)
+ 335
4 MyClass.so0x0004a6d0 WriteFileCpp + 80
5 libR.dylib0x0106c701 do_dotCode + 7789 (dotcode.c:1732)
6 libR.dylib0x01096a0f Rf_eval + 1530 (eval.c:445)
7 libR.dylib0x01098b43 do_set + 561 (eval.c:1357)
8 libR.dylib0x010968b4 Rf_eval + 1183 (eval.c:431)
9 libR.dylib0x01098be1 do_begin + 62 (eval.c:1108)
10 libR.dylib0x010968b4 Rf_eval + 1183 (eval.c:431)
11 libR.dylib0x01099fd6 Rf_applyClosure + 688 (eval.c:614)
12 libR.dylib0x01096725 Rf_eval + 784 (eval.c:455)
13 libR.dylib0x010b458c Rf_ReplIteration + 396 (main.c:256)
14 libR.dylib0x010b48f3 R_ReplConsole + 148 (main.c:306)
15 libR.dylib0x010b4c30 run_Rmainloop + 91 (main.c:945)
16 libR.dylib0x010b4c4b Rf_mainloop + 16 (main.c:952)
17 R 0x1f64 main + 54 (Rmain.c:35)
18 R 0x1f12 _start + 216
19 R 0x1e39 start + 41
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x0012ebx: 0x0004a1cb ecx: 0x0214f178 edx: 0x
edi: 0xbfffe568esi: 0x0214f178 ebp: 0xbfffe508 esp: 0xbfffe4f0
ss: 0x001fefl: 0x00010286 eip: 0x020fe231 cs: 0x0017
ds: 0x001f es: 0x001f fs: 0x gs: 0x0037
Binary Images Description:
0x1000 - 0x1fff R
/Library/Frameworks/R.framework/Resources/bin/exec/i386/R
0x5000 - 0x6fff libRblas.dylib
/Library/Frameworks/R.framework/Resources/lib/i386/libRblas.dylib
0xa000 -0x11fff libgcc_s.1.0.dylib
/Library/Frameworks/R.framework/Versions/2.4/Resources/lib/libgcc_s.1.0.dylib
0x49000 -0x4afff MyClass.so
/Users/rabbitus/Library/R/library/MyClass/libs/i386/MyClass.so
0x53000 -0x70fff libreadline.5.1.dylib
/Library/Frameworks/R.framework/Versions/2.4/Resources/lib/libreadline.5.1.dylib
0x582000 - 0x5c libgfortran.0.dylib
/Library/Frameworks/R.framework/Versions/2.4/Resources/lib/libgfortran.0.dylib
0x712000 - 0x716fff methods.so
/Library/Frameworks/R.framework/Resources/library/methods/libs/i386/methods.so
0x1008000 - 0x11f5fff libR.dylib
/Library/Frameworks/R.framework/Resources/lib/i386/libR.dy
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
On 4 February 2007 at 21:20, cstrato wrote: | Thank you for your fast answer. | Sorrowly, I don´t know how to use a debugger on MacOS X, I am using | old-style print commands. | However, here is the output of the crash log from my Mac. Does it help? Not me. I barely know what Mac OS X is, and never used it myself. You may need to talk to the r-sig-mac folks. If everything else fails, Simon tends to come up with answers no matter how hard or esoteric the question :) Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
cstrato <[EMAIL PROTECTED]> writes: > Thank you for your fast answer. > Sorrowly, I don´t know how to use a debugger on MacOS X, I am using > old-style print commands. You should be able to use gdb on OS X (works for me, YMMV). So you could try: R -d gdb run # source a script that causes crash # back in gdb, use backtrace, etc. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Dirk Eddelbuettel wrote: > On 4 February 2007 at 21:20, cstrato wrote: > | Thank you for your fast answer. > | Sorrowly, I don´t know how to use a debugger on MacOS X, I am using > | old-style print commands. > | However, here is the output of the crash log from my Mac. Does it help? > > Not me. I barely know what Mac OS X is, and never used it myself. You may > need to talk to the r-sig-mac folks. If everything else fails, Simon tends to > come up with answers no matter how hard or esoteric the question :) > > Dirk > > Thank you. I have seen that Mac-questions get also answered on this mailing list, so maybe someone has an answer? BTW, I forgot to mention that I downloaded the R-2.4.1.dmg binary since I wanted to create a package for the current version. So I don´t know if the problem disappears when using the new developer version. Is the problem 2.4.1-specific only? Best regards Christian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using ofstream in C++ class in package for MacOS X
Seth Falcon wrote:
> cstrato <[EMAIL PROTECTED]> writes:
>
>> Thank you for your fast answer.
>> Sorrowly, I don´t know how to use a debugger on MacOS X, I am using
>> old-style print commands.
>>
>
> You should be able to use gdb on OS X (works for me, YMMV). So you
> could try:
>
> R -d gdb
> run
> # source a script that causes crash
> # back in gdb, use backtrace, etc.
>
> + seth
>
>
>
Dear Seth
Thank you for this tip, I just tried it and here is the result:
Welcome to MyClass
> writeFileCpp("myout_fileCpp.txt")
[1] "outfile = myout_fileCpp.txt"
Writing file myout_fileCpp.txt using C++ style.
---MyClassA::MyClassA()-
---MyClassA::WriteFileCpp-
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0006
0x020fe231 in std::ostream::flush (this=0x214f178) at
/Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:395
395
/Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:
No such file or directory.
in
/Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc
(gdb)
It seems that it cannot find ostream.tcc, whatever this extension means.
Best regards
Christian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] convolve: request for "usual" behaviour + some improvements + some fixes
Hi Martin,
Thanks for taking the time to read me. Here is a followup,
it's rather long but hopefully not too long (and not too boring) ;-)
Quoting Martin Maechler <[EMAIL PROTECTED]>:
> Thank you, Herve,
>
> > "Herve" == Herve Pages <[EMAIL PROTECTED]>
> > on Fri, 02 Feb 2007 21:30:04 -0800 writes:
>
> Herve> Last but not least: convolve2 can be made 100 times or 1000 times
faster
> Herve> than convolve by choosing a power of 2 for the length of the
fft-buffer
> Herve> (a length of 2^n is the best case for the fft, the worst case
being
when
> Herve> the length is a prime number):
...
> The typical approach here and definitely the idea of the
> original author of convolve() - would be to use nextn() here
> instead of "next_power_of_2()".
The current implementation of convolve uses an fft-buffer of length
nx + ny - 1 for "open" convolution, not nextn().
The fft-based convolution is by nature "circular". However it can be
used for "open" convolutions: the trick is to padd the input sequences
with enough zeros to avoid the overlap inherent to circular convolution.
Then the ouput sequence doesn't "look" circular anymore.
For example, if the input sequences are
X = 2 5 8
Y = 100 1 0
then the "circular" convolution of X and Y is
Z = 205 802 508
To achieve "open" convolution, it's enough to _right_ padd X and
Y with zeros:
X = 2 5 8 0
Y = 100 1 0 0
then the "circular" convolution doesn't look circular anymore (it
looks "open"):
Z = 200 802 508 5
All you need to do is to padd enough zeros to have length X (and Y)
>= nx + ny - 1. But you can add more zeros if you want: this doesn't
change the result (except that you get extra zeros in the output
sequence):
X = 2 5 8 0 0 0
Y = 100 1 0 0 0 0
Z = 200 802 508 5 0 0
The current approach of adding the strict minimum number of necessary
zeros could _at first glance_ seem reasonable since it minimizes
the amount of memory used. But the problem with this approach is that the
fft algorithm is not very good in the general case and very very bad when
the length of the sequence is a prime number: in this case it has to
perform n^2 complex multiplications so it can litterally take days or
weeks when n is a big prime number (>= 10 millions).
>
> convolve() is one of the very old R functions stemming from
> Auckland already seen in the very first R tarball that's still
> available: Dated from June 20, 1995, with most file dates from
> Jun 16/17, i.e. really of even older date, the file src/rrc/fft
> (no 'library', noR extension yet) contains definitions for 'fft', 'nextn'
> and 'convolve' where the latter was (note the ":=" for what now
> would be assignment to the base package)
>
> convolve := function (a, b, conj=F)
> {
> na <- length(a)
> nb <- length(b)
> n <- max(na, nb)
> if (nb < n)
> b <- c(b, rep(0, n - nb))
> else if (na < n)
> a <- c(b, rep(0, n - na))
> da <- fft(a)
> db <- fft(b)
> if(conj) {
> a <- da$x * db$x + da$y * db$y
> b <- - da$x * db$y + db$x * da$y
> }
> else {
> a <- da$x * db$x - da$y * db$y
> b <- da$x * db$y + db$x * da$y
> }
> fft(a, b, inv=T)$x
> }
>
> and just for historical fun here's the help file in that
> cute olde help file format:
>
> TITLE(convolve @ Fast Convolution)
> USAGE(
> convolve(a, b, conj=false)
> )
> ARGUMENTS(
> ARG(a,b @ the sequences to be convolved.)
> ARG(conj @ logical, if true the transform of LANG(b) is conjugated
> before back-transformation.)
> )
> DESCRIPTION(
> LANG(convolve) uses the Fast Fourier Transform to compute the
> convolution of the sequences given as its arguments.
> PARA
> Complex conjugation is useful when computing
> autocovariances and autocorrelations by fast convolution.
> )
> REFERENCES(
> Brillinger, D. R. (1981).
> ITALIC(Time Series: Data Analysis and Theory), Second Edition.
> San Francisco: Holden-Day.
> )
> SEEALSO(
> LANG(LINK(fft)), LANG(LINK(nextn)).
> )
If you ignore the huge bug that 'a' is replaced by 'b' during the 0-padding
operation, this one was better than the current 'convolve'. It already had
the 'conj' argument and the default for it was FALSE so, by default,
the convolve function was doing convolution, not cross-correlation
(more on this below).
But it was doing "circular" convolution only...
>
> Later I had added bits to the docu, convolve got the 'type'
> argument, Brian also fixed code and amplified the description and provided
> the alternative filter() which had hencefor been recommended
> instead of convolve for most applications.
filter() might be OK for users who want filtering but what about people
who want a convolution?
Just FYI, with:
X = 2 5 8
Y = 100 1
filter(X, Y) gives:
Z = 502 805 NA
convolve(X, Y, type="filter") gives:
Z = 208 805
and convolve(x, y, conj=FALSE, ty
