This semester, I—as a teacher—came across two cases of heavily reliance on AI by master students, mostly for coding purposes, to which I had rather surprisingly not been exposed before. (Except for this plagiarised thesis two years ago that essentially rewrote existing papers with synonyms and for which we had to get to the disciplinary committee!) One project made a massive advance within two days, with hundreds of lines of beautiful python code, and reasonable output, but with my student unable to explain the code or the method behind… And anther case homeworks involving coding came back with extremely clean codes as well. Meaning they could not be graded and we had to switch to another type of evaluation. Oh well, welcome ol’me into the new age (just for a few years!)
Archive for debugging
fAIrst contAIct
Posted in Books, Kids, pictures, Statistics, University life with tags ChatGPT, coding, debugging, discipline, master project, plagiarism, Python, R, teaching, Université Paris Dauphine, University of Warwick on November 12, 2025 by xi'anmaking the next meeting more productive
Posted in Kids, R, Statistics, University life with tags best equivariant estimator, Cauchy distribution, debugging, R, R code, student, summer project on August 25, 2023 by xi'anOne of the students’ requests I almost invariably reject is code debugging (and they are warned about it from the start). Here is an illustration why, with an R code sent by a student working this summer on the standard estimators of a Cauchy location parameter, asking for debugging help in order “to make the next meeting more productive”. While I could have pointed them to at least four coding mistakes, this would not have helped them towards an autonomous resolution of the issue and it would have almost surely led to further requests for debugging. As it happened, this student showed up with running codes at the following meeting which proved most productive!
X = rcauchy(n, location = theta, scale = 1)
delta_function<-function(theta_lb, theta_ub, X){
#1. delta = best equivariant
Numerator_function<-function(theta) theta/prod((X-theta)**2 + 1)
Denominator_function <-function(theta) 1/prod((X-theta)**2 + 1)
M = integrate(Numerator_function, theta_lb, theta_ub)
D = integrate(Denominator_function, theta_lb, theta_ub)
delta_BE = M/D
##2. delta = MLE
#delta_MLE = argMin(prod((X-theta)**2 + 1))
return (delta_BE)
}
delta = delta_function(X)
banned from the Linux kernel
Posted in Linux, University life with tags debugging, ethics, Linux, Linux kernel, Minnesota, open source, The Linux Foundation, University of Minnesota on May 8, 2021 by xi'an
the strange occurrence of the one bump
Posted in Books, Kids, R, Statistics with tags accept-reject algorithm, bug, code golf, cross validated, debugging, Gamma generator, mixture of distributions, R, sample on June 8, 2020 by xi'an
When answering an X validated question on running an accept-reject algorithm for the Gamma distribution by using a mixture of Beta and drifted (bt 1) Exponential distributions, I came across the above glitch in the fit of my 10⁷ simulated sample to the target, apparently displaying a wrong proportion of simulations above (or below) one.
a=.9
g<-function(T){
x=rexp(T)
v=rt(T,1)<0
x=c(1+x[v],exp(-x/a)[!v])
x[runif(T)<x^a/x/exp(x)/((x>1)*exp(1-x)+a*(x<1)*x^a/x)*a]}
It took me a while to spot the issue, namely that the output of
z=g(T) while(sum(!!z)<T)z=c(z,g(T)) z[1:T]
was favouring simulations from the drifted exponential by truncating. Permuting the elements of z before returning solved the issue (as shown below for a=½)!
testing R code [book review]
Posted in R, Statistics, Travel with tags CRC Press, debugging, R, R package, RStudio, testing, Testing R Code on March 1, 2017 by xi'an
When I saw this title among the CRC Press novelties, I immediately ordered it as I though it fairly exciting. Now that I have gone through the book, the excitement has died. Maybe faster than need be as I read it while being stuck in a soulless Schipol airport and missing the only ice-climbing opportunity of the year!
Testing R Code was written by Richard Cotton and is quite short: once you take out the appendices and the answers to the exercises, it is about 130 pages long, with a significant proportion of code and output. And it is about some functions developed by Hadley Wickham from RStudio, for testing the coherence of R code in terms of inputs more than outputs. The functions are assertive and testthat. Intended for run-time versus development-time testing. Meaning that the output versus the input are what the author of the code intends them to be. The other chapters contain advices and heuristics about writing maintainable testable code, and incorporating a testing feature in an R package.
While I am definitely a poorly qualified reader for this type of R books, my disappointment stems from my expectation of a book about debugging R code, which is possibly due to a misunderstanding of the term testing. This is an unrealistic expectation, for sure, as testing for a code to produce what it is supposed to do requires some advanced knowledge of what the output should be, at least in some representative situations. Which means using interface like RStudio is capital in spotting unsavoury behaviours of some variables, if not foolproof in any case.
