Re: [Rd] bug, feature of mistery?
Giuseppe Ragusa wrote: Uwe, - Where is *lexical* scoping involved? Abuse of notation. I intended to say scoping. - Are you really calling you code from a clean workspace? Yes it is clean. - Why don't use pass g through optim() to f? Please do so, because it might be a scoping problem. Tried that. Still no luck. z- does not get assigned even if i pass g through optim - The .C call in psi() should not matter unless you are doing strange things in the part you omitted (...). I do not think is the call to C. And I did not omit, psi() is the last call. And again, same code works fine on the other machine. Can you send me a reproducible example (off list), please (inlcuding example data)? Uwe On Wed, 11 May 2005, Uwe Ligges wrote: Giuseppe Ragusa wrote: I have two machines a linux_amd64_x86 (gentoo_amd64) and a linux_x86. Both run R-2.1.0. I have a very long program (hopefully will become a package) that works perfectly on the linux_amd_x64. Great means no error, no problems and results that, where the analytic solution exists, coincide with it. I have problem making the code run on the x64 machine. I am baffled. The same code on the same version of R, different arch, is behaving differently. After hour of debugging, I traced down what is triggering the error on the x86 machine. the code snippet is the following similar to: R g - h(d) f - function( lambda ) { z - g %*% lambda sum( psi(z) ) ... } optim( init.value, f ) R The function f() is using lexical scoping to get obtain g. The function psi() is a call to a wrapper function that call a (.C) C function doing some simple calculation on z. - Where is *lexical* scoping involved? - Are you really calling you code from a clean workspace? - Why don't use pass g through optim() to f? Please do so, because it might be a scoping problem. - The .C call in psi() should not matter unless you are doing strange things in the part you omitted (...). Uwe Ligges What's the problem? When f() is called, g is there, lambda is there, but the assignment z - g %*% lambda results in a matrix of NaN. This happens from the second time f() is called, i.e. the first time f() is called from optim() after the C call has been made. The error is then that passing a NaN vector to .C results in halted execution. If I debug f() during the call to optim, I can without problem assign z the correct value, but during the execution z is matrix(NaN, nr, 1). At this point I can think of the following: 1) the external C code has errors It is not a programming error, because when called from console it returns the right results. Also, remember, the program work on my other machine (the 64 bit); 2) R error (I do not think so) 3) Compiling error Can be the gcc is messing thing around? on the 32bit machine gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) on the 64-bit machine gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7) Any help, suggestions, thoughts? Thank you. Giuseppe Ragusa __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug, feature of mistery?
Giuseppe Ragusa wrote: I have two machines a linux_amd64_x86 (gentoo_amd64) and a linux_x86. Both run R-2.1.0. I have a very long program (hopefully will become a package) that works perfectly on the linux_amd_x64. Great means no error, no problems and results that, where the analytic solution exists, coincide with it. I have problem making the code run on the x64 machine. I am baffled. The same code on the same version of R, different arch, is behaving differently. After hour of debugging, I traced down what is triggering the error on the x86 machine. the code snippet is the following similar to: R g - h(d) f - function( lambda ) { z - g %*% lambda sum( psi(z) ) ... } optim( init.value, f ) R The function f() is using lexical scoping to get obtain g. The function psi() is a call to a wrapper function that call a (.C) C function doing some simple calculation on z. - Where is *lexical* scoping involved? - Are you really calling you code from a clean workspace? - Why don't use pass g through optim() to f? Please do so, because it might be a scoping problem. - The .C call in psi() should not matter unless you are doing strange things in the part you omitted (...). Uwe Ligges What's the problem? When f() is called, g is there, lambda is there, but the assignment z - g %*% lambda results in a matrix of NaN. This happens from the second time f() is called, i.e. the first time f() is called from optim() after the C call has been made. The error is then that passing a NaN vector to .C results in halted execution. If I debug f() during the call to optim, I can without problem assign z the correct value, but during the execution z is matrix(NaN, nr, 1). At this point I can think of the following: 1) the external C code has errors It is not a programming error, because when called from console it returns the right results. Also, remember, the program work on my other machine (the 64 bit); 2) R error (I do not think so) 3) Compiling error Can be the gcc is messing thing around? on the 32bit machine gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) on the 64-bit machine gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7) Any help, suggestions, thoughts? Thank you. Giuseppe Ragusa __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug, feature of mistery?
Uwe, - Where is *lexical* scoping involved? Abuse of notation. I intended to say scoping. - Are you really calling you code from a clean workspace? Yes it is clean. - Why don't use pass g through optim() to f? Please do so, because it might be a scoping problem. Tried that. Still no luck. z- does not get assigned even if i pass g through optim - The .C call in psi() should not matter unless you are doing strange things in the part you omitted (...). I do not think is the call to C. And I did not omit, psi() is the last call. And again, same code works fine on the other machine. On Wed, 11 May 2005, Uwe Ligges wrote: Giuseppe Ragusa wrote: I have two machines a linux_amd64_x86 (gentoo_amd64) and a linux_x86. Both run R-2.1.0. I have a very long program (hopefully will become a package) that works perfectly on the linux_amd_x64. Great means no error, no problems and results that, where the analytic solution exists, coincide with it. I have problem making the code run on the x64 machine. I am baffled. The same code on the same version of R, different arch, is behaving differently. After hour of debugging, I traced down what is triggering the error on the x86 machine. the code snippet is the following similar to: R g - h(d) f - function( lambda ) { z - g %*% lambda sum( psi(z) ) ... } optim( init.value, f ) R The function f() is using lexical scoping to get obtain g. The function psi() is a call to a wrapper function that call a (.C) C function doing some simple calculation on z. - Where is *lexical* scoping involved? - Are you really calling you code from a clean workspace? - Why don't use pass g through optim() to f? Please do so, because it might be a scoping problem. - The .C call in psi() should not matter unless you are doing strange things in the part you omitted (...). Uwe Ligges What's the problem? When f() is called, g is there, lambda is there, but the assignment z - g %*% lambda results in a matrix of NaN. This happens from the second time f() is called, i.e. the first time f() is called from optim() after the C call has been made. The error is then that passing a NaN vector to .C results in halted execution. If I debug f() during the call to optim, I can without problem assign z the correct value, but during the execution z is matrix(NaN, nr, 1). At this point I can think of the following: 1) the external C code has errors It is not a programming error, because when called from console it returns the right results. Also, remember, the program work on my other machine (the 64 bit); 2) R error (I do not think so) 3) Compiling error Can be the gcc is messing thing around? on the 32bit machine gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) on the 64-bit machine gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7) Any help, suggestions, thoughts? Thank you. Giuseppe Ragusa __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- / |Giuseppe Ragusa |University of California, San Diego |9500 Gilman Dr. 0508 |La Jolla, CA 92093 |http://weber.ucsd.edu/~gragusa \ Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug, feature of mistery?
Giuseppe Ragusa [EMAIL PROTECTED] writes: I have two machines a linux_amd64_x86 (gentoo_amd64) and a linux_x86. You might want to try running valgrind on your code on the 32bit machine. This may turn up a silent coding error that is manifesting on the 64bit platform. I think there is a new R CMD check option to do valgrind. + seth __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel