No cheating! --Tim
On Friday, December 05, 2014 08:50:36 PM Mike Innes wrote: > I can close that issue for a case of beer, although I can't promise to > actually fix it. > > On 5 December 2014 at 20:49, Tim Holy <[email protected]> wrote: > > Sounds like a bargain...count me in for a bottle. > > > > --Tim > > > > On Friday, December 05, 2014 03:22:18 PM Stefan Karpinski wrote: > > > Make it a bottle of bourbon and we're talking. > > > > > > On Fri, Dec 5, 2014 at 3:21 PM, Jameson Nash <[email protected]> wrote: > > > > I'll buy you a case of beer if you can close that issue > > > > > > > > On Fri, Dec 5, 2014 at 2:58 PM Stefan Karpinski <[email protected]> > > > > > > > > wrote: > > > >> https://github.com/JuliaLang/julia/issues/265 – I'd really like to > > > > fix > > > > > >> this. > > > >> > > > >> On Fri, Dec 5, 2014 at 2:09 PM, Páll Haraldsson < > > > >> > > > >> [email protected]> wrote: > > > >>> On Friday, December 5, 2014 5:25:18 PM UTC, Steven G. Johnson wrote: > > > >>>> There is no runtime overhead in cases where the types are known at > > > >>>> compile time. > > > >>> > > > >>> Be aware of one thing, say you define: > > > >>> > > > >>> f(x, y) = 1 + 2p(x)y; p(x) = 2x^2 + 1; > > > >>> > > > >>> You will get the same code even as if you defined p first. UNLESS > > > >>> you > > > >>> try to run f first by accident (or intentionally as I did). Then at > > > >>> compile time you get complicated assembly code (and an error). > > > >>> > > > >>> Then if you define p then f is already defined and now works and > > > >>> will > > > >>> not get reoptimized. This gives slower result in interactive. > > > >>> > > > >>> Best regards, > > > >>> Palli.
