Ah, ye ol' 265. It's funny, I've grown to hardly notice it. But yes, it's an annoyance.
> On Jan 23, 2015, at 7:19 PM, Ben Kuhn <[email protected]> wrote: > > >> On Friday, January 23, 2015 at 3:08:14 PM UTC-8, Stefan Karpinski wrote: >> This kind of thing is a balancing act. All of these behaviors are really >> useful – or at least I find myself using them all the time. We tried for a >> while to disallow `scalar + vector` and require doing `scalar .+ vector` >> instead, but after a few months, everyone agreed that it was really annoying >> so we changed it back. > > Yeah, I totally agree and am happy they exist--sorry if that wasn't clear! > I'd much learn how not to hang myself than not be given the rope. I intended > to ask for mitigation strategies, not complain about the design. > >> I find that one of the most effective ways to make sure your code actually >> does what you think it does is to develop it interactively in the REPL and >> only once you've got a procedure working with intermediate values that make >> sense, worrying about wrapping it all up into a function. All of these >> errors would be obvious if you tried them interactively since the result of >> some step would have the wrong shape. This approach is kind of the inverse >> of writing your code and then walking through it in a debugger. It feels a >> bit odd if you're used to static languages, but it's really very effective >> and once you get used to it, not being able to work that way feels somewhat >> stifling. > > Heh. I'm actually coming from Python, but had stopped using the Julia REPL > because my IPython-adapted habits weren't used to requiring so many restarts. > I will have to break them and find better ones. > >>> On Fri, Jan 23, 2015 at 5:37 PM, Ben Kuhn <[email protected]> wrote: >>> Hi Julia folks, >>> >>> Trying to get a feel for Julia, I decided to write a basic Cox proportional >>> hazards model. While I was implementing the routines to calculate the >>> gradient and Hessian of the model's log-likelihood, I realized that I was >>> making a ton of array "type errors" (dimension errors) that weren't being >>> caught by Julia's type system because the array operations that I was using >>> were too overloaded. Here are some examples of what I mean: >>> >>> - For a 2d array X, trying to get a row with X[i] instead of X[i,:]. This >>> returns a scalar, but if you try to add it to another row vector you'll >>> silently get a different row vector than you expected instead of a failure. >>> - Reversing the order of y * transpose(y) (for y an array) to get the >>> scalar product instead of the outer product (similar silent failure as >>> above). >>> - Doing y .* z when one side is a row vector and the other side is a column >>> vector, and forgetting to transpose them, causing an accidental outer >>> product (via broadcasting) instead of elementwise product. This one is >>> harder to get a silent failure with but I'm pretty sure I managed somehow. >>> >>> I caught them all in testing (I think) and am fairly satisfied my code does >>> the right thing now, but I'd love to know if there are conventions or tools >>> I can use to limit these errors or catch them earlier. I'm sure I'm missing >>> a ton of stuff because I'm a Julia novice (as well as a numerics novice in >>> general). Does anyone have any pointers? If it helps, the code I wrote is >>> here. (It's correct now, or at least agrees with R on a small but >>> nontrivial model; the link is to the function that computes the Hessian of >>> the log-likelihood, which was unsurprisingly the most error-prone part.) >>> >>> Thanks! >>> Ben >>
