Re: [julia-users] Re: Design patterns for an API

[Mike Innes]

Fair point. I timed this in a loop and it seems to be about an order of 
magnitude slower, which (considering that you're redefining the function 
every time it runs) is actually surprisingly good – it seems that doing so 
only takes a microsecond.

On Saturday, 17 May 2014 21:20:34 UTC+1, Tim Holy wrote:
>
> Right, but there are still issues with this approach. Are you planning on 
> always executing this "function" as a macro? If so, then you'll have to 
> pay 
> the compilation price each time you use it. You might not care if xs is 
> huge, 
> but if xs has 10 items then you won't be very happy. 
>
> The performance of the dict-based method cache is not ideal in such 
> circumstances either, but it's about three orders of magnitude faster: 
>
> julia> y = rand(10); 
>
> julia> @time @sumf exp y 
> elapsed time: 0.01007613 seconds (131500 bytes allocated) 
> 19.427283165919906 
>
> julia> @time @sumf exp y 
> elapsed time: 0.011217276 seconds (131500 bytes allocated) 
> 19.427283165919906 
>
> In contrast, 
>
> julia> @time sumf(:exp, y) 
> elapsed time: 0.014134811 seconds (94888 bytes allocated) 
> 19.427283165919906 
>
> julia> @time sumf(:exp, y) 
> elapsed time: 1.0356e-5 seconds (64 bytes allocated) 
> 19.427283165919906 
>
> Three orders of magnitude is enough of a speed difference to notice :). 
>
> --Tim 
>
>
> On Saturday, May 17, 2014 09:31:29 AM Mike Innes wrote: 
> > That macro being slow at the top level isn't really a strike against the 
> > macro technique, because it's easily resolved: 
> > 
> > (Although oddly enough, a let binding doesn't really help here – anyone 
> > know why?) 
> > 
> > macro sumf(f, xs) 
> >   quote 
> > function inner(s = 0.0, x = $(esc(xs))) 
> >   for i = 1:length(x) 
> > s += $(esc(f))(x[i]) 
> >   end 
> >   s 
> > end 
> > inner() 
> >   end 
> > end 
> > 
> > Although you're right that if you call this from a function which itself 
> > takes f as a parameter, you'll lose the speed boost again (technically 
> you 
> > could resolve this by making the calling function a macro in the same 
> way, 
> > but that's equally awful). 
> > 
> > Hopefully this kind of inlining will be automatic soon, so we won't have 
> to 
> > resort to ugly language hacks to make things fast; on the other hand, 
> it's 
> > kinda cool that we *can* resort to ugly language hacks to make things 
> fast 
> > 
> > :) 
> > 
> > On Saturday, 17 May 2014 16:18:15 UTC+1, Tim Holy wrote: 
> > > If you want to make that fast, you need to wrap that inside a 
> function, 
> > > using 
> > > a separate name for each user-supplied f. Example: 
> > > 
> > > function sumf_with_sinc_plus_x(xs) 
> > > 
> > > @sumf(sinc_plus_x, xs) 
> > > 
> > > end 
> > > 
> > > function sumf_with_exp(xs) 
> > > 
> > > @sumf(exp, xs) 
> > > 
> > > end 
> > > 
> > > If you don't wrap it in a function, then it runs in global scope, and 
> > > that's 
> > > horribly slow. 
> > > 
> > > My version allows you to pass a function as an argument, and mimics 
> what 
> > > it 
> > > would be like if we could pass functions-as-arguments without a 
> > > performance 
> > > penalty. 
> > > 
> > > --Tim 
> > > 
> > > On Saturday, May 17, 2014 05:03:07 AM Mike Innes wrote: 
> > > > I may be missing the point here, but wouldn't it be easier to define 
> > > 
> > > sumf 
> > > 
> > > > as a macro? 
> > > > 
> > > > macro sumf(f, xs) 
> > > > 
> > > >   quote 
> > > >   
> > > > s = 0.0 
> > > > x = $(esc(xs)) 
> > > > for i = 1:length(x) 
> > > > 
> > > >   s += $(esc(f))(x[i]) 
> > > > 
> > > > end 
> > > > s 
> > > >   
> > > >   end 
> > > > 
> > > > end 
> > > > 
> > > > @sumf(sinc_plus_x, x) 
> > > > 
> > > > This is just as fast and has the advantage that it will work when f 
> is 
> > > 
> > > only 
> > > 
> > > > in the local scope. 
> > > > 
> > > > On Saturday, 17 May 2014 11:50:56 UTC+1, Tim Holy wrote: 
> > > > > On Friday, May 16, 2014 02:36:03 PM francoi...@gmail.com 
> > > 
> > > wrote: 
> > > > > > - The solver need to be fast and for that, inlining is of 
> paramount 
> > > > > > importance. I know that there is no way to inline F for the time 
> > > 
> > > being. 
> > > 
> > > > > Do 
> > > > > 
> > > > > > we expect inlining on function argument in the near future of 
> Julia 
> > > 
> > > ? 
> > > 
> > > > > I can't speak for when this will happen in a "nice" way, but using 
> > > 
> > > Julia's 
> > > 
> > > > > metaprogramming capabilities there is a (somewhat ugly) way to get 
> > > 
> > > what 
> > > 
> > > > > you 
> > > > > want. Since I'm planning to use this trick myself shortly, I 
> created a 
> > > > > little 
> > > > > demonstration: 
> > > > > 
> > > > > https://gist.github.com/timholy/bdcee95f9b7725214d8b 
> > > > > 
> > > > > If you prefer, you don't have to separate out the definition of 
> the 
> > > 
> > > body 
> > > 
> > > > > from 
> > > > > the eval(quote...end) part, I just did it that way to better 
> > > 
> > > illust

Re: [julia-users] Help Understanding an InexactError() in Code Sample

[zach]

Sorry  I missed a line when transcribing the code snippet in my message. 
 The while loop should read:

while true
k = (i + j) / 2


if h < htab[k]
j = k
else
i = k
end


if j <= i+1
break
end
end



On Saturday, May 17, 2014 7:46:40 PM UTC-7, Jameson wrote:
>
> Where did you define k? I don't see it in you code snippet. It seems 
> likely that it isn't an integer, given the error
>
> On Saturday, May 17, 2014, > wrote:
>
>> I'm trying to understand why I'm getting an InexactError() in the 
>> following bit of code:
>>
>> NTAB = 8
>>
>> htab = [3280.84 * x for x in (0.0, 11.0, 20.0, 32.0, 47.0, 51.0, 71.0, 
>> 84.852)]
>>
>> ttab = [1.8 * x for x in (288.15, 216.65, 216.65, 228.65, 270.65, 270.65, 
>>
>>   214.65, 189.946)] 
>>
>> ptab = [2116.21662 * x for x in  (1.0, 2.233611e-1, 5.403295e-2, 
>> 8.5666784e-3, 
>>
>>   1.0945601e-3, 6.6063531e-4, 
>> 3.9046834e-5, 3.68501e-6)] 
>>
>> gtab = fill(0.0, NTAB) 
>>
>> for i = 1:NTAB-1 
>>
>> gtab[i] = ((ttab[i+1] - ttab[i]) / (htab[i+1] - htab[i]))
>>
>> end 
>>
>> gtab[NTAB] = 0.0
>>  
>> function atmosphere(alt::Float64) 
>>
>> h::Float64 = alt * REARTH / (alt + REARTH)  # convert geometric 
>> to 
>>   
>>   # geopotential altitude 
>> i = 1
>> j = NTAB 
>>
>> while true 
>>
>
>> if h < htab[k]
>> j = k
>> else
>> i = k
>> end
>>
>> if j <= i+1
>>
>> break
>>
>> end
>>
>> end
>>
>> end
>>
>>
>>
>> At the line where I'm making the comparison with h < htab[k], I get an 
>> InexactError() when any value is passed into the function, but I'm not sure 
>> what the reason is as I'm still beginning with Julia.  If anyone would be 
>> kind enough to point out my mistake, then I would appreciate it.
>>
>> Thanks!
>>
>

[julia-users] Re: DataFrames, no method push!

[carlos cinelli]

I have just installed Julia and DataFrames and faced the same problem:

using DataFrames
df = DataFrame()
df[:A] = 1:8

no method push!(Index,Symbol)

On Saturday, May 17, 2014 12:47:57 AM UTC-3, Travis Porco wrote:
>
> This from Julia 0.2.1 on MacOSX 10.7.5, using the DataFrames package, 
> just now updated before the following attemp to execute example code from 
> the manual:
>
> Version 0.2.1 (2014-02-11 06:30 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-apple-darwin12.5.0
>
> julia> using DataFrames
>
> julia> df = DataFrame()
> 0x0 DataFrame:
>
> julia> df[:A] = 1:8
> ERROR: no method push!(Index,Symbol)
>  in insert_single_column! at 
> /Users/travis/.julia/DataFrames/src/dataframe.jl:480
>  in setindex! at /Users/travis/.julia/DataFrames/src/dataframe.jl:525
>
> julia> df[:B] = ["M", "F", "F", "M", "F", "M", "M", "F"]
> ERROR: no method push!(Index,Symbol)
>  in insert_single_column! at 
> /Users/travis/.julia/DataFrames/src/dataframe.jl:480
>  in setindex! at /Users/travis/.julia/DataFrames/src/dataframe.jl:525
>
> But stranger, to me:
>
> julia> push!
> push! (generic function with 12 methods)
>
> Etc. I googled "no method push!" julia
> but I didn't see anything that seemed relevant to my beginner's mind, and 
> I searched 
> this group as well.
>
> Also, the same problem happened just before updating (the update was a 
> failed attempt to fix it).
>
> Is it fixable and worth fixing, or should I just wait for the official 
> 0.3? 
>
> Thanks kindly.
>
>

Re: [julia-users] Help Understanding an InexactError() in Code Sample

[Jameson Nash]

Where did you define k? I don't see it in you code snippet. It seems
likely that it isn't an integer, given the error

On Saturday, May 17, 2014,  wrote:

> I'm trying to understand why I'm getting an InexactError() in the
> following bit of code:
>
> NTAB = 8
>
> htab = [3280.84 * x for x in (0.0, 11.0, 20.0, 32.0, 47.0, 51.0, 71.0,
> 84.852)]
>
> ttab = [1.8 * x for x in (288.15, 216.65, 216.65, 228.65, 270.65, 270.65,
>
>   214.65, 189.946)]
>
> ptab = [2116.21662 * x for x in  (1.0, 2.233611e-1, 5.403295e-2,
> 8.5666784e-3,
>
>   1.0945601e-3, 6.6063531e-4, 3.9046834e-5
> , 3.68501e-6)]
>
> gtab = fill(0.0, NTAB)
>
> for i = 1:NTAB-1
>
> gtab[i] = ((ttab[i+1] - ttab[i]) / (htab[i+1] - htab[i]))
>
> end
>
> gtab[NTAB] = 0.0
>
> function atmosphere(alt::Float64)
>
> h::Float64 = alt * REARTH / (alt + REARTH)  # convert geometric
> to
>
>   # geopotential altitude
> i = 1
> j = NTAB
>
> while true
> if h < htab[k]
> j = k
> else
> i = k
> end
>
> if j <= i+1
>
> break
>
> end
>
> end
>
> end
>
>
>
> At the line where I'm making the comparison with h < htab[k], I get an
> InexactError() when any value is passed into the function, but I'm not sure
> what the reason is as I'm still beginning with Julia.  If anyone would be
> kind enough to point out my mistake, then I would appreciate it.
>
> Thanks!
>

[julia-users] Help Understanding an InexactError() in Code Sample

[zach]

I'm trying to understand why I'm getting an InexactError() in the following 
bit of code:

NTAB = 8

htab = [3280.84 * x for x in (0.0, 11.0, 20.0, 32.0, 47.0, 51.0, 71.0, 
84.852)]

ttab = [1.8 * x for x in (288.15, 216.65, 216.65, 228.65, 270.65, 270.65, 

  214.65, 189.946)] 

ptab = [2116.21662 * x for x in  (1.0, 2.233611e-1, 5.403295e-2, 
8.5666784e-3, 

  1.0945601e-3, 6.6063531e-4, 3.9046834e-5, 
3.68501e-6)] 

gtab = fill(0.0, NTAB) 

for i = 1:NTAB-1 

gtab[i] = ((ttab[i+1] - ttab[i]) / (htab[i+1] - htab[i]))

end 

gtab[NTAB] = 0.0
 
function atmosphere(alt::Float64) 

h::Float64 = alt * REARTH / (alt + REARTH)  # convert geometric to 

# geopotential altitude 
i = 1
j = NTAB 

while true
if h < htab[k]
j = k
else
i = k
end

if j <= i+1

break

end

end

end



At the line where I'm making the comparison with h < htab[k], I get an 
InexactError() when any value is passed into the function, but I'm not sure 
what the reason is as I'm still beginning with Julia.  If anyone would be 
kind enough to point out my mistake, then I would appreciate it.

Thanks!

Re: [julia-users] DataFrame (2 questions)

[Rob J. Goedman]

Thanks John,

On May 17, 2014, at 11:57 AM, John Myles White  wrote:

> In (1), you’re trying to put to insert multiple columns into a single column, 
> which means that you’re effectively inserting a column with 6 entries instead 
> of 3. The error message should probably be changed to note that the size 
> (rather than the length) is wrong. We could change the formula interface at 
> some point to allow “.” as an operator.

Clearly what I was trying to do was wrong and for readability it is probably 
better to be explicit with respect to column names in generating the df and 
model formula.

> Point (2) is intentional. There are a lot of options that control printing of 
> DataFrames and they need to be exposed better in the documentation. They’re 
> documented here for now: 
> https://github.com/JuliaStats/DataFrames.jl/blob/master/spec/show.md
> 
> The printing decision doesn’t depend on the structure of the DataFrame. It 
> only depends on whether or not the DataFrame could be printed to the screen 
> without spillover.

Will study the specs. On my retina display it often times uses less than half 
of terminal window width. But show(..., true) and showall(...) give me exactly 
what I was looking for!

Thanks again, regards,
Rob J. Goedman
goed...@icloud.com

Re: [julia-users] GSOC 3D Visualizations plotting API - Make a wish!

[J Luis]

Hi Simon,

In Earth Sciences, and Geophysics in particular, netCDF is king. There is a 
damn fast and good program called Fledermaus 
(http://www.qps.nl/display/fledermaus) that creates awesome 3D displays of 
grid surfaces (and some 3D solid objects as well). However, it's a 
commercial product that to make it a bit worst, has its own non-public 
format.

However, it has a free viewer that let us visualize and get dizzy with the 
speed at which it renders its scenes. 
The good thing is that I managed to partially crack the format (which is 
half documented) and I'm able to create fledermaus objects that can be seen 
with the free viewer. All that is done with only a couple of mouse clicks 
when using my program, Mirone (w3.ualg.pt/~jluis/mirone)
 
The free viewer is here if you want to try it (the binary needs to be in 
the path)

w3.ualg.pt/~jluis/mirone/win32_iview3d670.exe

it would be fantastic if a Fledermaus type capability would be added to 
your viewer.

Joaquim

Sábado, 17 de Maio de 2014 21:23:49 UTC+1, Tim Holy escreveu:
>
> Maximum intensity projection would be nice to have. 
>
> Also, really fast 2d plotting of large datasets would not be a bad thing. 
> Cairo + Gtk is not bad (and Gtk is quite a lot better than Tk in terms of 
> speed), but it's also not all that impressive either. 
>
> --Tim 
>
> On Saturday, May 17, 2014 09:51:37 AM Simon Danisch wrote: 
> > Hi, 
> > I'm currently in the planning phase for my GSOC 3D Visualization 
> project, 
> > which also means, that I need to define what the most important 
> > visualization forms are. 
> > I must admit, that I haven't done much plotting myself, so I would have 
> to 
> > guess what the really important bits are. 
> > Instead of slavishly  
>
> > imitating Matlabs plot functions with some mix-ins from my side, I 
> thought 
> > we can do better, by getting feedback off the people, that actually plan 
> to 
> > use 3D plotting in Julia! 
> > It would help me a lot, if you could specify what you need exactly in 
> great 
> > detail. 
> > Just tell me what you hate about current solutions, what features you 
> > really like, the format of your data, how you like to work, etc... 
> > Like this, I can find out what needs to be done in order to visualize 
> your 
> > data, rate the importance and difficulty and than decide in which order 
> I 
> > implement the different plotting capabilities. 
> > Any feedback, ideas and comments are welcome! 
> > 
> > Best wishes, 
> > Simon 
>

Re: [julia-users] Re: Downloaded binary startup way slower than when compiled from github

[Elliot Saba]

Yep, we used to do this on purpose, since we didn't have a good way of
restricting the optimizations used by the compiler.  Now we've got a good
baseline set, and the nightlies needed their configurations to be matched.
 New binaries should be up by tonight.
-E


On Sat, May 17, 2014 at 11:34 AM, Tobias Knopp
wrote:

> It seems that the compiled system image is not included in the prerelease
> binaries.
>
> Am Samstag, 17. Mai 2014 20:23:46 UTC+2 schrieb Dom Luna:
>
>> I find it weird that the downloaded one has a drastically slower REPL
>> startup than when compiled from github repo.
>>
>> $ where julia
>> /Applications/Julia-0.3.0-prerelease-0b05b21911.app/
>> Contents/Resources/julia/bin/julia
>> /usr/local/bin/julia
>>
>> I'm symlinking $HOME/julia/julia to /usr/local/bin/julia
>>
>> Here's the startup times
>>
>> Downloaded:
>>
>> time julia -e 'println("Helo")'
>> 5.07s user 0.10s system 98% cpu 5.250 total
>>
>> Source:
>>
>> time /usr/local/bin/julia -e 'println("Helo")'
>> 0.28s user 0.08s system 117% cpu 0.308 total
>>
>> The versions are 1 day old from each other.
>>
>> Downloaded:
>>
>>_
>>_   _ _(_)_ |  A fresh approach to technical computing
>>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>_ _   _| |_  __ _   |  Type "help()" to list help topics
>>   | | | | | | |/ _` |  |
>>   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3053 (2014-05-14 22:03
>> UTC)
>>  _/ |\__'_|_|_|\__'_|  |  Commit 0b05b21* (2 days old master)
>> |__/   |  x86_64-apple-darwin12.5.0
>>
>>
>> Source:
>>
>>   _
>>_   _ _(_)_ |  A fresh approach to technical computing
>>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>_ _   _| |_  __ _   |  Type "help()" to list help topics
>>   | | | | | | |/ _` |  |
>>   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3081 (2014-05-16 15:12
>> UTC)
>>  _/ |\__'_|_|_|\__'_|  |  Commit eb4bfcc (1 day old master)
>> |__/   |  x86_64-apple-darwin13.1.0
>>
>> The main thing I notice is the apple-darwin12.5.0 vs apple-darwin13.1.0.
>> I'm not sure what that means. I'm on OSX 10.9.2.
>>
>> Dom
>>
>>

Re: [julia-users] sizehint for new array

[Andrew Dabrowski]

But is it wrong to use it the way I suggested?


On Saturday, May 17, 2014 4:27:19 PM UTC-4, Tim Holy wrote:
>
> I use it right after creating an array that I'm going to be modifying with 
> push!: 
>
> a = Array(Int, 0) 
> sizehint(a, 10^5) 
>
> Now I'll be able to push! at least 10^5 elements without it having to re- 
> allocate and copy the data I've already added. 
>
> --Tim 
>
> On Saturday, May 17, 2014 09:29:49 AM Andrew Dabrowski wrote: 
> > What's the proper way to use sizehint when defining a new array?  Is it 
> > 
> > newarray = sizehint( f( oldarray ), n ), 
> > 
> > or do you have to already have the new variable defined before using 
> > sizehint? 
>

Re: [julia-users] sizehint for new array

[Tim Holy]

I use it right after creating an array that I'm going to be modifying with 
push!:

a = Array(Int, 0)
sizehint(a, 10^5)

Now I'll be able to push! at least 10^5 elements without it having to re-
allocate and copy the data I've already added.

--Tim

On Saturday, May 17, 2014 09:29:49 AM Andrew Dabrowski wrote:
> What's the proper way to use sizehint when defining a new array?  Is it
> 
> newarray = sizehint( f( oldarray ), n ),
> 
> or do you have to already have the new variable defined before using
> sizehint?

Re: [julia-users] GSOC 3D Visualizations plotting API - Make a wish!

[Tim Holy]

Maximum intensity projection would be nice to have.

Also, really fast 2d plotting of large datasets would not be a bad thing. 
Cairo + Gtk is not bad (and Gtk is quite a lot better than Tk in terms of 
speed), but it's also not all that impressive either.

--Tim

On Saturday, May 17, 2014 09:51:37 AM Simon Danisch wrote:
> Hi,
> I'm currently in the planning phase for my GSOC 3D Visualization project,
> which also means, that I need to define what the most important
> visualization forms are.
> I must admit, that I haven't done much plotting myself, so I would have to
> guess what the really important bits are.
> Instead of slavishly 
> imitating Matlabs plot functions with some mix-ins from my side, I thought
> we can do better, by getting feedback off the people, that actually plan to
> use 3D plotting in Julia!
> It would help me a lot, if you could specify what you need exactly in great
> detail.
> Just tell me what you hate about current solutions, what features you
> really like, the format of your data, how you like to work, etc...
> Like this, I can find out what needs to be done in order to visualize your
> data, rate the importance and difficulty and than decide in which order I
> implement the different plotting capabilities.
> Any feedback, ideas and comments are welcome!
> 
> Best wishes,
> Simon

Re: [julia-users] Re: Design patterns for an API

[Tim Holy]

Right, but there are still issues with this approach. Are you planning on 
always executing this "function" as a macro? If so, then you'll have to pay 
the compilation price each time you use it. You might not care if xs is huge, 
but if xs has 10 items then you won't be very happy.

The performance of the dict-based method cache is not ideal in such 
circumstances either, but it's about three orders of magnitude faster:

julia> y = rand(10);

julia> @time @sumf exp y
elapsed time: 0.01007613 seconds (131500 bytes allocated)
19.427283165919906

julia> @time @sumf exp y
elapsed time: 0.011217276 seconds (131500 bytes allocated)
19.427283165919906

In contrast,

julia> @time sumf(:exp, y)
elapsed time: 0.014134811 seconds (94888 bytes allocated)
19.427283165919906

julia> @time sumf(:exp, y)
elapsed time: 1.0356e-5 seconds (64 bytes allocated)
19.427283165919906

Three orders of magnitude is enough of a speed difference to notice :).

--Tim


On Saturday, May 17, 2014 09:31:29 AM Mike Innes wrote:
> That macro being slow at the top level isn't really a strike against the
> macro technique, because it's easily resolved:
> 
> (Although oddly enough, a let binding doesn't really help here – anyone
> know why?)
> 
> macro sumf(f, xs)
>   quote
> function inner(s = 0.0, x = $(esc(xs)))
>   for i = 1:length(x)
> s += $(esc(f))(x[i])
>   end
>   s
> end
> inner()
>   end
> end
> 
> Although you're right that if you call this from a function which itself
> takes f as a parameter, you'll lose the speed boost again (technically you
> could resolve this by making the calling function a macro in the same way,
> but that's equally awful).
> 
> Hopefully this kind of inlining will be automatic soon, so we won't have to
> resort to ugly language hacks to make things fast; on the other hand, it's
> kinda cool that we *can* resort to ugly language hacks to make things fast
> 
> :)
> 
> On Saturday, 17 May 2014 16:18:15 UTC+1, Tim Holy wrote:
> > If you want to make that fast, you need to wrap that inside a function,
> > using
> > a separate name for each user-supplied f. Example:
> > 
> > function sumf_with_sinc_plus_x(xs)
> > 
> > @sumf(sinc_plus_x, xs)
> > 
> > end
> > 
> > function sumf_with_exp(xs)
> > 
> > @sumf(exp, xs)
> > 
> > end
> > 
> > If you don't wrap it in a function, then it runs in global scope, and
> > that's
> > horribly slow.
> > 
> > My version allows you to pass a function as an argument, and mimics what
> > it
> > would be like if we could pass functions-as-arguments without a
> > performance
> > penalty.
> > 
> > --Tim
> > 
> > On Saturday, May 17, 2014 05:03:07 AM Mike Innes wrote:
> > > I may be missing the point here, but wouldn't it be easier to define
> > 
> > sumf
> > 
> > > as a macro?
> > > 
> > > macro sumf(f, xs)
> > > 
> > >   quote
> > >   
> > > s = 0.0
> > > x = $(esc(xs))
> > > for i = 1:length(x)
> > > 
> > >   s += $(esc(f))(x[i])
> > > 
> > > end
> > > s
> > >   
> > >   end
> > > 
> > > end
> > > 
> > > @sumf(sinc_plus_x, x)
> > > 
> > > This is just as fast and has the advantage that it will work when f is
> > 
> > only
> > 
> > > in the local scope.
> > > 
> > > On Saturday, 17 May 2014 11:50:56 UTC+1, Tim Holy wrote:
> > > > On Friday, May 16, 2014 02:36:03 PM francoi...@gmail.com
> > 
> > wrote:
> > > > > - The solver need to be fast and for that, inlining is of paramount
> > > > > importance. I know that there is no way to inline F for the time
> > 
> > being.
> > 
> > > > Do
> > > > 
> > > > > we expect inlining on function argument in the near future of Julia
> > 
> > ?
> > 
> > > > I can't speak for when this will happen in a "nice" way, but using
> > 
> > Julia's
> > 
> > > > metaprogramming capabilities there is a (somewhat ugly) way to get
> > 
> > what
> > 
> > > > you
> > > > want. Since I'm planning to use this trick myself shortly, I created a
> > > > little
> > > > demonstration:
> > > > 
> > > > https://gist.github.com/timholy/bdcee95f9b7725214d8b
> > > > 
> > > > If you prefer, you don't have to separate out the definition of the
> > 
> > body
> > 
> > > > from
> > > > the eval(quote...end) part, I just did it that way to better
> > 
> > illustrate
> > 
> > > > the
> > > > separate ideas.
> > > > 
> > > > --Tim

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Michael Hatherly]

Hi Simon, as well as the matplotlib API that Mike Innes has already linked 
to you may want to have a look at the racket plotting library [1] for some 
more inspiration (parametric and isosurfaces).

To start with just some basic surface plotting (like matlab's surf 
function) would be excellent to have (with nicely customizable colormaps). 
Rotation and zooming similar to matlab and matplotlib are great to have as 
well.

Perhaps a longer term feature would be the ability to program animation 
sequences that could then be rendered in real time (while a simulation 
progresses) or exported to video files (that would have been nice to have 
for something I was doing recently). Embedding interactive plots into GTK 
applications is also something I'd find useful.

I'd be happy to help testing things out once you get started. Thanks for 
taking on this task since it's one of the last things keeping quite a few 
people I know from trying out Julia for anything except toy examples.

Regards,
Mike

[1] http://docs.racket-lang.org/plot/renderer3d.html

On Saturday, 17 May 2014 18:51:37 UTC+2, Simon Danisch wrote:
>
> Hi, 
> I'm currently in the planning phase for my GSOC 3D Visualization project, 
> which also means, that I need to define what the most important 
> visualization forms are.
> I must admit, that I haven't done much plotting myself, so I would have to 
> guess what the really important bits are.
> Instead of slavishly  
> imitating 
> Matlabs plot functions with some mix-ins from my side, I thought we can do 
> better, by getting feedback off the people, that actually plan to use 3D 
> plotting in Julia!
> It would help me a lot, if you could specify what you need exactly in 
> great detail.
> Just tell me what you hate about current solutions, what features you 
> really like, the format of your data, how you like to work, etc...
> Like this, I can find out what needs to be done in order to visualize your 
> data, rate the importance and difficulty and than decide in which order I 
> implement the different plotting capabilities.
> Any feedback, ideas and comments are welcome!
>
> Best wishes,
> Simon
>

Re: [julia-users] DataFrame (2 questions)

[John Myles White]

In (1), you’re trying to put to insert multiple columns into a single column, 
which means that you’re effectively inserting a column with 6 entries instead 
of 3. The error message should probably be changed to note that the size 
(rather than the length) is wrong. We could change the formula interface at 
some point to allow “.” as an operator.

Point (2) is intentional. There are a lot of options that control printing of 
DataFrames and they need to be exposed better in the documentation. They’re 
documented here for now: 
https://github.com/JuliaStats/DataFrames.jl/blob/master/spec/show.md

The printing decision doesn’t depend on the structure of the DataFrame. It only 
depends on whether or not the DataFrame could be printed to the screen without 
spillover.

 — John

On May 17, 2014, at 11:47 AM, Rob J. Goedman  wrote:

> The DataFrames package still gives me a hard time (coming from R). Two issues 
> I run into most often:
> 
> 1. Below error message, not sure what I'm doing wrong here. Do I need to use 
> join()? Or am I missing a use of comprehension? In ModelFrames the '.' is not 
> allowed, so I would like to be able to say something like lm(Y ~ X, df). But 
> maybe this is to R-ish?
> 
> 2. Printing of a DataFrame. A small DataFrame (< 7 columns?) is printed in 
> the REPL (like df below), but a larger DataFrame seems to give me the 
> structure of the DataFrame. Can I influence that number of 7?
> 
> Rob J. Goedman
> goed...@icloud.com
> 
> julia> versioninfo()
> Julia Version 0.3.0-prerelease+3191
> Commit 03d91ba* (2014-05-16 15:41 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin13.2.0)
>   CPU: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>   LAPACK: libopenblas
>   LIBM: libm
> 
> julia> X1
> 3x2 Array{Int64,2}:
>  1  4
>  2  5
>  3  6
> 
> julia> Y1
> 3-element Array{Int64,1}:
>  1
>  3
>  5
> 
> julia> DataFrame(X=X1[:, 1], Y=Y1)
> 3x2 DataFrame
> |---|---|---|
> | Row # | X | Y |
> | 1 | 1 | 1 |
> | 2 | 2 | 3 |
> | 3 | 3 | 5 |
> 
> julia> df = DataFrame(X=X1[:, 2], Y=Y1)
> 3x2 DataFrame
> |---|---|---|
> | Row # | X | Y |
> | 1 | 4 | 1 |
> | 2 | 5 | 3 |
> | 3 | 6 | 5 |
> 
> julia> DataFrame(X=X1[:, 1:2], Y=Y1)
> ERROR: New columns must have the same length as old columns
>  in insert_single_column! at 
> /Users/rob/.julia/v0.3/DataFrames/src/dataframe/dataframe.jl:383
>  in setindex! at 
> /Users/rob/.julia/v0.3/DataFrames/src/dataframe/dataframe.jl:444
>  in DataFrame at 
> /Users/rob/.julia/v0.3/DataFrames/src/dataframe/dataframe.jl:63
> 
> julia> X1[:, 1:2]
> 3x2 Array{Int64,2}:
>  1  4
>  2  5
>  3  6
> 
> 
> 
> julia> df
> 3x2 DataFrame
> |---|---|---|
> | Row # | X | Y |
> | 1 | 4 | 1 |
> | 2 | 5 | 3 |
> | 3 | 6 | 5 |
> 
> julia> samples_df
> 1000x16 DataFrame
> |---|---|-|-|
> | Col # | Name  | Eltype  | Missing |
> | 1 | lp__  | Float64 | 0   |
> | 2 | accept_stat__ | Float64 | 0   |
> | 3 | stepsize__| Float64 | 0   |
> | 4 | treedepth__   | Int64   | 0   |
> | 5 | n_leapfrog__  | Int64   | 0   |
> | 6 | n_divergent__ | Int64   | 0   |
> | 7 | mu| Float64 | 0   |
> | 8 | theta_1   | Float64 | 0   |
> | 9 | theta_2   | Float64 | 0   |
> | 10| theta_3   | Float64 | 0   |
> | 11| theta_4   | Float64 | 0   |
> | 12| theta_5   | Float64 | 0   |
> | 13| theta_6   | Float64 | 0   |
> | 14| theta_7   | Float64 | 0   |
> | 15| theta_8   | Float64 | 0   |
> | 16| tau   | Float64 | 0   |
> 
> julia> samples_df[:, 7:12]
> 1000x6 DataFrame
> |---|--|--|-|--|--|-|
> | Row # | mu   | theta_1  | theta_2 | theta_3  | theta_4  | theta_5 |
> | 1 | 10.4332  | 5.37291  | 19.7482 | 3.56708  | 7.27914  | 5.88818 |
> | 2 | 8.22581  | 14.2675  | 12.141  | 8.32665  | 2.95288  | 5.34375 |
> | 3 | 10.9068  | 7.43814  | 10.1394 | 7.34402  | 6.14595  | 6.53342 |
> | 4 | 10.9068  | 7.43814  | 10.1394 | 7.34402  | 6.14595  | 6.53342 |
> | 5 | 9.61714  | 8.90304  | 10.2919 | 8.40993  | 7.06141  | 6.35706 |
> | 6 | 7.46585  | 12.2761  | 7.64693 | 4.87427  | 8.23898  | 6.50898 |
> | 7 | 12.3858  | 6.32497  | 8.23373 | 12.6327  | 11.2788  | 5.70445 |
> | 8 | 8.66217  | 10.2486  | 7.02425 | 15.3532  | 15.0876  | 5.2819  |
> | 9 | 13.2488  | 21.4967  | 9.04809 | 3.62114  | -5.58207 | 6.72995 |
> ⋮
> | 991   | 6.44634  | -7.45131 | 13.8173 | 0.726336 | 5.32585  | 7.74152 |
> | 992   | -1.84407 | 5.74692  | 3.77242 | 7.83245  | 11.0352  | 2.81801 |
> | 993   | 3.54546  | 7.49026  | 11.8291 | 5.5823   | 11.2318  | 5.04784 |
> | 994   | 21.6616  | 23.7753  | 1.0125  | 8.47316  | 0.786987 | 7.47116 |
> | 995   | 10.0226  | 12.4223  | 11.7201 | 16.0979  | 33.8617  | 2.

[julia-users] DataFrame (2 questions)

[Rob J. Goedman]

The DataFrames package still gives me a hard time (coming from R). Two issues I 
run into most often:

1. Below error message, not sure what I'm doing wrong here. Do I need to use 
join()? Or am I missing a use of comprehension? In ModelFrames the '.' is not 
allowed, so I would like to be able to say something like lm(Y ~ X, df). But 
maybe this is to R-ish?

2. Printing of a DataFrame. A small DataFrame (< 7 columns?) is printed in the 
REPL (like df below), but a larger DataFrame seems to give me the structure of 
the DataFrame. Can I influence that number of 7?

Rob J. Goedman
goed...@icloud.com

julia> versioninfo()
Julia Version 0.3.0-prerelease+3191
Commit 03d91ba* (2014-05-16 15:41 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.2.0)
  CPU: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libm

julia> X1
3x2 Array{Int64,2}:
 1  4
 2  5
 3  6

julia> Y1
3-element Array{Int64,1}:
 1
 3
 5

julia> DataFrame(X=X1[:, 1], Y=Y1)
3x2 DataFrame
|---|---|---|
| Row # | X | Y |
| 1 | 1 | 1 |
| 2 | 2 | 3 |
| 3 | 3 | 5 |

julia> df = DataFrame(X=X1[:, 2], Y=Y1)
3x2 DataFrame
|---|---|---|
| Row # | X | Y |
| 1 | 4 | 1 |
| 2 | 5 | 3 |
| 3 | 6 | 5 |

julia> DataFrame(X=X1[:, 1:2], Y=Y1)
ERROR: New columns must have the same length as old columns
 in insert_single_column! at 
/Users/rob/.julia/v0.3/DataFrames/src/dataframe/dataframe.jl:383
 in setindex! at 
/Users/rob/.julia/v0.3/DataFrames/src/dataframe/dataframe.jl:444
 in DataFrame at /Users/rob/.julia/v0.3/DataFrames/src/dataframe/dataframe.jl:63

julia> X1[:, 1:2]
3x2 Array{Int64,2}:
 1  4
 2  5
 3  6



julia> df
3x2 DataFrame
|---|---|---|
| Row # | X | Y |
| 1 | 4 | 1 |
| 2 | 5 | 3 |
| 3 | 6 | 5 |

julia> samples_df
1000x16 DataFrame
|---|---|-|-|
| Col # | Name  | Eltype  | Missing |
| 1 | lp__  | Float64 | 0   |
| 2 | accept_stat__ | Float64 | 0   |
| 3 | stepsize__| Float64 | 0   |
| 4 | treedepth__   | Int64   | 0   |
| 5 | n_leapfrog__  | Int64   | 0   |
| 6 | n_divergent__ | Int64   | 0   |
| 7 | mu| Float64 | 0   |
| 8 | theta_1   | Float64 | 0   |
| 9 | theta_2   | Float64 | 0   |
| 10| theta_3   | Float64 | 0   |
| 11| theta_4   | Float64 | 0   |
| 12| theta_5   | Float64 | 0   |
| 13| theta_6   | Float64 | 0   |
| 14| theta_7   | Float64 | 0   |
| 15| theta_8   | Float64 | 0   |
| 16| tau   | Float64 | 0   |

julia> samples_df[:, 7:12]
1000x6 DataFrame
|---|--|--|-|--|--|-|
| Row # | mu   | theta_1  | theta_2 | theta_3  | theta_4  | theta_5 |
| 1 | 10.4332  | 5.37291  | 19.7482 | 3.56708  | 7.27914  | 5.88818 |
| 2 | 8.22581  | 14.2675  | 12.141  | 8.32665  | 2.95288  | 5.34375 |
| 3 | 10.9068  | 7.43814  | 10.1394 | 7.34402  | 6.14595  | 6.53342 |
| 4 | 10.9068  | 7.43814  | 10.1394 | 7.34402  | 6.14595  | 6.53342 |
| 5 | 9.61714  | 8.90304  | 10.2919 | 8.40993  | 7.06141  | 6.35706 |
| 6 | 7.46585  | 12.2761  | 7.64693 | 4.87427  | 8.23898  | 6.50898 |
| 7 | 12.3858  | 6.32497  | 8.23373 | 12.6327  | 11.2788  | 5.70445 |
| 8 | 8.66217  | 10.2486  | 7.02425 | 15.3532  | 15.0876  | 5.2819  |
| 9 | 13.2488  | 21.4967  | 9.04809 | 3.62114  | -5.58207 | 6.72995 |
⋮
| 991   | 6.44634  | -7.45131 | 13.8173 | 0.726336 | 5.32585  | 7.74152 |
| 992   | -1.84407 | 5.74692  | 3.77242 | 7.83245  | 11.0352  | 2.81801 |
| 993   | 3.54546  | 7.49026  | 11.8291 | 5.5823   | 11.2318  | 5.04784 |
| 994   | 21.6616  | 23.7753  | 1.0125  | 8.47316  | 0.786987 | 7.47116 |
| 995   | 10.0226  | 12.4223  | 11.7201 | 16.0979  | 33.8617  | 2.83627 |
| 996   | 15.299   | 17.4176  | 13.2271 | 11.5311  | -2.48596 | 8.27366 |
| 997   | 16.3412  | 20.98| 15.723  | 2.40238  | 29.9986  | 8.09409 |
| 998   | 8.42056  | 7.86757  | 11.8463 | 13.2561  | 10.2436  | 7.41587 |
| 999   | 8.52441  | 10.568   | 16.061  | 11.2477  | 12.1242  | 9.03829 |
| 1000  | 11.2382  | 9.76319  | 12.3402 | 3.54328  | 10.975   | 5.75154 |

julia> samples_df[:, 7:13]
1000x7 DataFrame
|---|-|-|-|
| Col # | Name| Eltype  | Missing |
| 1 | mu  | Float64 | 0   |
| 2 | theta_1 | Float64 | 0   |
| 3 | theta_2 | Float64 | 0   |
| 4 | theta_3 | Float64 | 0   |
| 5 | theta_4 | Float64 | 0   |
| 6 | theta_5 | Float64 | 0   |
| 7 | theta_6 | Float64 | 0   |

[julia-users] Re: Downloaded binary startup way slower than when compiled from github

[Tobias Knopp]

It seems that the compiled system image is not included in the prerelease 
binaries.

Am Samstag, 17. Mai 2014 20:23:46 UTC+2 schrieb Dom Luna:
>
> I find it weird that the downloaded one has a drastically slower REPL 
> startup than when compiled from github repo.
>
> $ where julia
>
> /Applications/Julia-0.3.0-prerelease-0b05b21911.app/Contents/Resources/julia/bin/julia
> /usr/local/bin/julia
>
> I'm symlinking $HOME/julia/julia to /usr/local/bin/julia
>
> Here's the startup times
>
> Downloaded:
>
> time julia -e 'println("Helo")'
> 5.07s user 0.10s system 98% cpu 5.250 total
>
> Source:
>
> time /usr/local/bin/julia -e 'println("Helo")'
> 0.28s user 0.08s system 117% cpu 0.308 total
>
> The versions are 1 day old from each other.
>
> Downloaded:
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" to list help topics
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3053 (2014-05-14 22:03 
> UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit 0b05b21* (2 days old master)
> |__/   |  x86_64-apple-darwin12.5.0
>
>
> Source:
>
>   _
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" to list help topics
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3081 (2014-05-16 15:12 
> UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit eb4bfcc (1 day old master)
> |__/   |  x86_64-apple-darwin13.1.0
>
> The main thing I notice is the apple-darwin12.5.0 vs apple-darwin13.1.0. 
> I'm not sure what that means. I'm on OSX 10.9.2.
>
> Dom
>
>

Re: [julia-users] Downloaded binary startup way slower than when compiled from github

[Isaiah Norton]

The pre-compiled system image must not have been included in the nightly
distribution.
I just pinged the OS X nightly maintainer about this on the issue tracker,
see:
https://github.com/JuliaLang/julia/issues/5459#issuecomment-43418116


On Sat, May 17, 2014 at 2:23 PM, Dom Luna  wrote:

> I find it weird that the downloaded one has a drastically slower REPL
> startup than when compiled from github repo.
>
> $ where julia
>
> /Applications/Julia-0.3.0-prerelease-0b05b21911.app/Contents/Resources/julia/bin/julia
> /usr/local/bin/julia
>
> I'm symlinking $HOME/julia/julia to /usr/local/bin/julia
>
> Here's the startup times
>
> Downloaded:
>
> time julia -e 'println("Helo")'
> 5.07s user 0.10s system 98% cpu 5.250 total
>
> Source:
>
> time /usr/local/bin/julia -e 'println("Helo")'
> 0.28s user 0.08s system 117% cpu 0.308 total
>
> The versions are 1 day old from each other.
>
> Downloaded:
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" to list help topics
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3053 (2014-05-14 22:03
> UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit 0b05b21* (2 days old master)
> |__/   |  x86_64-apple-darwin12.5.0
>
>
> Source:
>
>   _
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" to list help topics
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3081 (2014-05-16 15:12
> UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit eb4bfcc (1 day old master)
> |__/   |  x86_64-apple-darwin13.1.0
>
> The main thing I notice is the apple-darwin12.5.0 vs apple-darwin13.1.0.
> I'm not sure what that means. I'm on OSX 10.9.2.
>
> Dom
>
>

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Mike Innes]

You might want to have a look through matplotlib's 3D API – personally I'd 
be really to see basic 3D plotting working really well.

http://matplotlib.org/1.3.1/mpl_toolkits/mplot3d/tutorial.html

Looking forward to seeing what you come up with!

On Saturday, 17 May 2014 17:51:37 UTC+1, Simon Danisch wrote:
>
> Hi, 
> I'm currently in the planning phase for my GSOC 3D Visualization project, 
> which also means, that I need to define what the most important 
> visualization forms are.
> I must admit, that I haven't done much plotting myself, so I would have to 
> guess what the really important bits are.
> Instead of slavishly  
> imitating 
> Matlabs plot functions with some mix-ins from my side, I thought we can do 
> better, by getting feedback off the people, that actually plan to use 3D 
> plotting in Julia!
> It would help me a lot, if you could specify what you need exactly in 
> great detail.
> Just tell me what you hate about current solutions, what features you 
> really like, the format of your data, how you like to work, etc...
> Like this, I can find out what needs to be done in order to visualize your 
> data, rate the importance and difficulty and than decide in which order I 
> implement the different plotting capabilities.
> Any feedback, ideas and comments are welcome!
>
> Best wishes,
> Simon
>

Re: [julia-users] for loops

[Cameron McBride]

Stefan,

Thank you. Your description really helps clarify things. The issue about
different functionality for "return" in map vs for loops was obviously
something I overlooked here.

And yes, the influence is clearly ruby.

I see how a macro could can duplicate the for loop structure. I guess I'm a
bit surprised that is the only way, and there wasn't a metaprogramming way
to add this functionality to all iterators.

I guess what I was wanting was the ability to use something like "each"
(which functions like a for loop, but looks like map()), and any such
function (enumerate, etc.), which I guess is just more method definitions.

But I probably just have too much baggage from history, so I'll just try
and use natural julia expressions for the time being...  ;)

Cameron





On Fri, May 16, 2014 at 12:58 PM, Stefan Karpinski wrote:

> That form of iteration is common from Ruby, which is where I'm guessing
> this interest is coming from? Ruby has the block/proc/lambda distinction
> that makes the for loop and .each forms behaviorally similar, whereas in
> Julia, there's just the one kind of anonymous function. As a result, if
> this were made to work, enumerate(a) do i,x and for (i,x) in enumerate(a)
> would not behave exactly the same – return in the former would exit the
> current loop iteration whereas return in the latter exits the enclosing
> function. I'm not sure it's a good idea to introduce too many different
> ways to write this. If we were going to implement this, we wouldn't do it
> by adding language features, but by adding methods to iterator-producing
> functions like enumerate. In this case, you could do something like this:
>
> function enumerate(f::Callable, x)
>   for (i,x) in enumerate(x)
> f(i,x)
>   end
> end
>
>
> That pattern could be emitted by a macro, of course.
>

Re: [julia-users] Compile once, run many?

[Isaiah Norton]

If you are on Julia 0.2, the biggest improvement will come from moving to
Julia 0.3-pre (nightly builds) where pre-compilation functionality was
added. This should get startup time down to around 0.5s or so depending on
your computer. You would still need some JIT time for your own code, but
this should be much less than 9s. It is also possible (still potentially a
bit buggy, therefore undocumented) to include custom code in this system
image. To do this you will need to compile Julia yourself, and create a
file called `base/userimg.jl` containing your code, or `include` statements
to pull in your script. (Search the list for "userimg.jl" for more
information).

For distributed computation you may also want to investigate Julia's
parallelism functionality (allows to start remote worker nodes and
distribute batch computations to them, thereby only requiring a one-time
startup delay).


On Sat, May 17, 2014 at 1:15 AM, Vale Cofer-Shabica <
vale.cofershab...@gmail.com> wrote:

> My apologies if I've missed something fundamental; I'm half a day into
> using Julia. I'm porting a classical mechanics simulation from C to Julia.
> Even in the C case, my potential energy function is FORTRAN "black box".
> I've written a wrapper and am able to call the function easily. This is
> great! I can run my code from the cli, but it's very slow:
>
> % time LD_LIBRARY_PATH=. julia testPotential-julia.jl
> ...
> LD_LIBRARY_PATH=. julia testPotential-julia.jl  9.01s user 0.10s system
> 98% cpu 9.233 total
>
> if I do the same thing in the REPL, it's very fast (after the initial
> compilation):
>  LD_LIBRARY_PATH=. julia -L testPotential-julia.jl
> ...
> julia> @time main()
> ...
> elapsed time: 0.001423427 seconds (12048 bytes allocated)
>
> How do I combine the two? I'd like to be able to be able to repeatably
> execute a binary from the command line---it's fine even if it's julia with
> arguments---and have the kind of speed I get when I repeatedly execute from
> within the REPL.Is this possible? If not, does anyone have a sane way to
> use Julia code on distributed batch queuing systems?
>
> Many thanks,
> vale
>
>

[julia-users] Downloaded binary startup way slower than when compiled from github

[Dom Luna]

I find it weird that the downloaded one has a drastically slower REPL 
startup than when compiled from github repo.

$ where julia
/Applications/Julia-0.3.0-prerelease-0b05b21911.app/Contents/Resources/julia/bin/julia
/usr/local/bin/julia

I'm symlinking $HOME/julia/julia to /usr/local/bin/julia

Here's the startup times

Downloaded:

time julia -e 'println("Helo")'
5.07s user 0.10s system 98% cpu 5.250 total

Source:

time /usr/local/bin/julia -e 'println("Helo")'
0.28s user 0.08s system 117% cpu 0.308 total

The versions are 1 day old from each other.

Downloaded:

   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" to list help topics
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3053 (2014-05-14 22:03 
UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 0b05b21* (2 days old master)
|__/   |  x86_64-apple-darwin12.5.0


Source:

  _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" to list help topics
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.3.0-prerelease+3081 (2014-05-16 15:12 
UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit eb4bfcc (1 day old master)
|__/   |  x86_64-apple-darwin13.1.0

The main thing I notice is the apple-darwin12.5.0 vs apple-darwin13.1.0. 
I'm not sure what that means. I'm on OSX 10.9.2.

Dom

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Tobias Knopp]

Hi Simon,

it is a great idea to ask for community feedback on what people want from 
3D graphics.

Here are some ideas from me:
- In general I think it is really useful to have interactive graphics. But 
for publications there will a need to export the data to an image. This 
could be done by rendering into an offscreen buffer and mapping this into a 
cairo surface which will give us various export formats for free.

- Visualization of 3D data (i.e. an Array{Real,3})
  a) Show 3 orthogonal slices, whereas the slice position should be 
configurable
  b) Volume rendering using the raytracing method.
  c) as b) but with a clip plane that can be use to scroll through the 
volume.

- For the visualization of real data one needs to convert the data to ARGB. 
This is something a shader is perfectly suited for. The user will want to 
chose different colormaps (like gray, spring, ...) and the window width and 
window level for mapping from real to colored data. The data itself can be 
uploaded to the graphics card using PBOs.

Cheers,

Tobias


Am Samstag, 17. Mai 2014 18:51:37 UTC+2 schrieb Simon Danisch:
>
> Hi, 
> I'm currently in the planning phase for my GSOC 3D Visualization project, 
> which also means, that I need to define what the most important 
> visualization forms are.
> I must admit, that I haven't done much plotting myself, so I would have to 
> guess what the really important bits are.
> Instead of slavishly  
> imitating 
> Matlabs plot functions with some mix-ins from my side, I thought we can do 
> better, by getting feedback off the people, that actually plan to use 3D 
> plotting in Julia!
> It would help me a lot, if you could specify what you need exactly in 
> great detail.
> Just tell me what you hate about current solutions, what features you 
> really like, the format of your data, how you like to work, etc...
> Like this, I can find out what needs to be done in order to visualize your 
> data, rate the importance and difficulty and than decide in which order I 
> implement the different plotting capabilities.
> Any feedback, ideas and comments are welcome!
>
> Best wishes,
> Simon
>

[julia-users] Compile once, run many?

[Vale Cofer-Shabica]

My apologies if I've missed something fundamental; I'm half a day into 
using Julia. I'm porting a classical mechanics simulation from C to Julia. 
Even in the C case, my potential energy function is FORTRAN "black box". 
I've written a wrapper and am able to call the function easily. This is 
great! I can run my code from the cli, but it's very slow:

% time LD_LIBRARY_PATH=. julia testPotential-julia.jl
...
LD_LIBRARY_PATH=. julia testPotential-julia.jl  9.01s user 0.10s system 98% 
cpu 9.233 total

if I do the same thing in the REPL, it's very fast (after the initial 
compilation):
 LD_LIBRARY_PATH=. julia -L testPotential-julia.jl
...
julia> @time main()
...
elapsed time: 0.001423427 seconds (12048 bytes allocated)

How do I combine the two? I'd like to be able to be able to repeatably 
execute a binary from the command line---it's fine even if it's julia with 
arguments---and have the kind of speed I get when I repeatedly execute from 
within the REPL.Is this possible? If not, does anyone have a sane way to 
use Julia code on distributed batch queuing systems?

Many thanks,
vale

[julia-users] GSOC 3D Visualizations plotting API - Make a wish!

[Simon Danisch]

Hi, 
I'm currently in the planning phase for my GSOC 3D Visualization project, 
which also means, that I need to define what the most important 
visualization forms are.
I must admit, that I haven't done much plotting myself, so I would have to 
guess what the really important bits are.
Instead of slavishly  
imitating 
Matlabs plot functions with some mix-ins from my side, I thought we can do 
better, by getting feedback off the people, that actually plan to use 3D 
plotting in Julia!
It would help me a lot, if you could specify what you need exactly in great 
detail.
Just tell me what you hate about current solutions, what features you 
really like, the format of your data, how you like to work, etc...
Like this, I can find out what needs to be done in order to visualize your 
data, rate the importance and difficulty and than decide in which order I 
implement the different plotting capabilities.
Any feedback, ideas and comments are welcome!

Best wishes,
Simon

Re: [julia-users] Re: Design patterns for an API

[Mike Innes]

That macro being slow at the top level isn't really a strike against the 
macro technique, because it's easily resolved:

(Although oddly enough, a let binding doesn't really help here – anyone 
know why?)

macro sumf(f, xs)
  quote
function inner(s = 0.0, x = $(esc(xs)))
  for i = 1:length(x)
s += $(esc(f))(x[i])
  end
  s
end
inner()
  end
end

Although you're right that if you call this from a function which itself 
takes f as a parameter, you'll lose the speed boost again (technically you 
could resolve this by making the calling function a macro in the same way, 
but that's equally awful).

Hopefully this kind of inlining will be automatic soon, so we won't have to 
resort to ugly language hacks to make things fast; on the other hand, it's 
kinda cool that we *can* resort to ugly language hacks to make things fast 
:)


On Saturday, 17 May 2014 16:18:15 UTC+1, Tim Holy wrote:
>
> If you want to make that fast, you need to wrap that inside a function, 
> using 
> a separate name for each user-supplied f. Example: 
>
> function sumf_with_sinc_plus_x(xs) 
> @sumf(sinc_plus_x, xs) 
> end 
>
> function sumf_with_exp(xs) 
> @sumf(exp, xs) 
> end 
>
> If you don't wrap it in a function, then it runs in global scope, and 
> that's 
> horribly slow. 
>
> My version allows you to pass a function as an argument, and mimics what 
> it 
> would be like if we could pass functions-as-arguments without a 
> performance 
> penalty. 
>
> --Tim 
>
> On Saturday, May 17, 2014 05:03:07 AM Mike Innes wrote: 
> > I may be missing the point here, but wouldn't it be easier to define 
> sumf 
> > as a macro? 
> > 
> > macro sumf(f, xs) 
> >   quote 
> > s = 0.0 
> > x = $(esc(xs)) 
> > for i = 1:length(x) 
> >   s += $(esc(f))(x[i]) 
> > end 
> > s 
> >   end 
> > end 
> > 
> > @sumf(sinc_plus_x, x) 
> > 
> > This is just as fast and has the advantage that it will work when f is 
> only 
> > in the local scope. 
> > 
> > On Saturday, 17 May 2014 11:50:56 UTC+1, Tim Holy wrote: 
> > > On Friday, May 16, 2014 02:36:03 PM francoi...@gmail.com 
> wrote: 
> > > > - The solver need to be fast and for that, inlining is of paramount 
> > > > importance. I know that there is no way to inline F for the time 
> being. 
> > > 
> > > Do 
> > > 
> > > > we expect inlining on function argument in the near future of Julia 
> ? 
> > > 
> > > I can't speak for when this will happen in a "nice" way, but using 
> Julia's 
> > > metaprogramming capabilities there is a (somewhat ugly) way to get 
> what 
> > > you 
> > > want. Since I'm planning to use this trick myself shortly, I created a 
> > > little 
> > > demonstration: 
> > > 
> > > https://gist.github.com/timholy/bdcee95f9b7725214d8b 
> > > 
> > > If you prefer, you don't have to separate out the definition of the 
> body 
> > > from 
> > > the eval(quote...end) part, I just did it that way to better 
> illustrate 
> > > the 
> > > separate ideas. 
> > > 
> > > --Tim 
>

[julia-users] sizehint for new array

[Andrew Dabrowski]

What's the proper way to use sizehint when defining a new array?  Is it

newarray = sizehint( f( oldarray ), n ),

or do you have to already have the new variable defined before using 
sizehint?

[julia-users] Algebra, Eigen, Varimax. Precision of calculations.

[paul analyst]

Varimax rotation loadings matrix sizes of about 3000x3000, unless as a 
result of errors of machine completely loses ortogonality. 
Please help with the rotation of large matrices.
Paul

Re: [julia-users] Re: Design patterns for an API

[Tim Holy]

If you want to make that fast, you need to wrap that inside a function, using 
a separate name for each user-supplied f. Example:

function sumf_with_sinc_plus_x(xs)
@sumf(sinc_plus_x, xs)
end

function sumf_with_exp(xs)
@sumf(exp, xs)
end

If you don't wrap it in a function, then it runs in global scope, and that's 
horribly slow.

My version allows you to pass a function as an argument, and mimics what it 
would be like if we could pass functions-as-arguments without a performance 
penalty.

--Tim

On Saturday, May 17, 2014 05:03:07 AM Mike Innes wrote:
> I may be missing the point here, but wouldn't it be easier to define sumf
> as a macro?
> 
> macro sumf(f, xs)
>   quote
> s = 0.0
> x = $(esc(xs))
> for i = 1:length(x)
>   s += $(esc(f))(x[i])
> end
> s
>   end
> end
> 
> @sumf(sinc_plus_x, x)
> 
> This is just as fast and has the advantage that it will work when f is only
> in the local scope.
> 
> On Saturday, 17 May 2014 11:50:56 UTC+1, Tim Holy wrote:
> > On Friday, May 16, 2014 02:36:03 PM francoi...@gmail.com 
wrote:
> > > - The solver need to be fast and for that, inlining is of paramount
> > > importance. I know that there is no way to inline F for the time being.
> > 
> > Do
> > 
> > > we expect inlining on function argument in the near future of Julia ?
> > 
> > I can't speak for when this will happen in a "nice" way, but using Julia's
> > metaprogramming capabilities there is a (somewhat ugly) way to get what
> > you
> > want. Since I'm planning to use this trick myself shortly, I created a
> > little
> > demonstration:
> > 
> > https://gist.github.com/timholy/bdcee95f9b7725214d8b
> > 
> > If you prefer, you don't have to separate out the definition of the body
> > from
> > the eval(quote...end) part, I just did it that way to better illustrate
> > the
> > separate ideas.
> > 
> > --Tim

Re: [julia-users] Accessing the loop variable (and pi as float)

[Chris Foster]

On Sat, May 17, 2014 at 11:14 PM, Hans W Borchers  wrote:
> and it took me some time before I realized that the answer came from outside
> the function.
> That behavior can really lead to very difficult testing situations.

Fair enough.  I suspect there can be some subtle bugs which occur with
the more relaxed scoping as well, though I can't think of a good
example right now.

> I don't know whether something like this can happen in C/C++.

It can, though this particular case is not at all common if you avoid
globals with short names.  A more insidious problem which does happen
occasionally is something like the following:

int i = 0;
for (int j = 0; j < 10; ++j)
{
if (x[j] = 0)
{
int i = j; // Oops.  Should have been "i = j"
break;
}
}

Here a separate variable i is declared inside the inner loop, so the
one outside doesn't get modified.  In a real case there would
obviously be more code around the problem making it hard to find, and
the error would probably creep in after carelessly copying some code
between scopes.

~Chris

Re: [julia-users] Accessing the loop variable (and pi as float)

[Hans W Borchers]

> It's true that the looser scoping rules of langauges like matlab and 
python 
> can be convenient.  On the whole I prefer tighter scoping rules like C++ 
> though: they make code easier to reason about by making the data 
> flow more local. 

The situation I met was not as clear as you describe it here.
For some testing purposes I had defined i before defining the function:

julia> i = 10;

julia> function testfun1(x::Vector{Float64})
   for i = 1:length(x)
   if x[i] == 0.0
   break
   end
   end
   return i-1
   end;

julia> testfun1([1.0, 2.0, 3.0, 0.0, 1.0])
9

and it took me some time before I realized that the answer came from 
outside the function.
That behavior can really lead to very difficult testing situations.

I don't know whether something like this can happen in C/C++.


On Saturday, May 17, 2014 2:37:13 PM UTC+2, Chris Foster wrote:
>
> On Sat, May 17, 2014 at 9:59 PM, Hans W Borchers 
> > 
> wrote: 
> > Yesterday I implemented a function calculating arc length of curves (to 
> the 
> > last digit) when I came across the following stumbling blocks. Image the 
> > following function where I leave a for-loop with a 'break' statement: 
> > 
> > function testfun1(x::Vector{Float64}) 
> > for i = 1:length(x) 
> > if x[i] == 0.0 
> > break 
> > end 
> > end 
> > return i-1 
> > end 
>
> For this particular example, I'd suggest you just return i-1 directly 
> inside the loop: 
>
> function testfun1(x::Vector{Float64}) 
> for i = 1:length(x) 
> if x[i] == 0.0 
> return i-1 
> end 
> end 
> return length(x)-1 # Or other special case for when 0 isn't found 
> end 
>
> Using an early return like this is really quite powerful, especially when 
> you have a deeply nested set of loops.  I use it all the time in C++. 
>
> > I understand that the scope of the loop variable is restricted to the 
> loop 
> > itself. What is the best way to "export"  i  to the outside? For the 
> moment 
> > I settled with defining i before the loop. 
>
> Yes, if you want i accessible outside a loop, you'll just have to declare 
> it in the outer scope.  AFAIK you've done the right thing there, though 
> initializing i to a default would be more concise and wouldn't fail if the 
> input array is empty (unless that's intentional). 
>
> > This works, but I must admit it runs against my gut feeling and 
> > experience with other scientific programming languages. 
>
> It's true that the looser scoping rules of langauges like matlab and 
> python 
> can be convenient.  On the whole I prefer tighter scoping rules like C++ 
> though: they make code easier to reason about by making the data 
> flow more local. 
>
> ~Chris 
>

Re: [julia-users] Re: Accessing the loop variable (and pi as float)

[Mike Innes]

Well, you could do this by defining another method on the (more specific)
Integer type:

test(x::Real) = x*x
test(x::Integer) = error()

There's also the FloatingPoint type, but that excludes pi.

I have to say, though, that it seems odd that you'd want to do this, seeing
as integers are effectively a special case of floating point numbers.


On 17 May 2014 13:40, Hans W Borchers  wrote:

> Thanks, Mike, for the prompt answer.
> But what if i want to explicitly exclude integers.
> I think with Real I would allow them.
>
>
> On Saturday, May 17, 2014 2:13:09 PM UTC+2, Mike Innes wrote:
>>
>> I think your first example is right, although someone may well correct me
>> on that. That's how I've done similar things, anyway.
>>
>> As for your second example, this is happening because your type parameter
>> is overly restrictive – if you use ::Real it works as you would expect.
>>
>> Conversions like this will certainly take place where they make sense,
>> but they don't really make sense here – it has to be assumed that you've
>> asked for a Float64 because you specifically need one.
>>
>> – Mike
>>
>> On Saturday, 17 May 2014 12:59:02 UTC+1, Hans W Borchers wrote:
>>>
>>> Yesterday I implemented a function calculating arc length of curves (to
>>> the last digit) when I came across the following stumbling blocks. Image
>>> the following function where I leave a for-loop with a 'break' statement:
>>>
>>> function testfun1(x::Vector{Float64})
>>> for i = 1:length(x)
>>> if x[i] == 0.0
>>> break
>>> end
>>> end
>>> return i-1
>>> end
>>>
>>> julia> testfun([1.0, 2.0, 3.0, 0.0, 1.0])
>>> ERROR: i not defined
>>>  in testfun at none:7
>>>
>>> I understand that the scope of the loop variable is restricted to the
>>> loop itself. What is the best way to "export"  i  to the outside? For
>>> the moment I settled with defining i before the loop.
>>>
>>> function testfun2(x::Vector{Float64})
>>> local i::Int
>>> for i = 1:length(x)
>>> if x[i] == 0.0
>>> break
>>> end
>>> end
>>> return i-1
>>> end
>>>
>>> This works, but I must admit it runs against my gut feeling and
>>> experience with other scientific programming languages.
>>>
>>>
>>> The next shock was the following:
>>>
>>> function testfun(x::Float64)
>>> return x^2
>>> end
>>>
>>> julia> testfun(pi)
>>> ERROR: no method testfun(MathConst{:π})
>>>
>>> Again, I learned that I can use testfun(float(pi) , but my feeling
>>> would be that pi should be converted to float automatically whenever
>>> the context requires it. On the mailing list I think I have seen other
>>> complaints about this. I would prefer that  pi  and MathConst{:π} (or
>>> even better π alone) were different objects.
>>>
>>>

[julia-users] Re: Accessing the loop variable (and pi as float)

[Hans W Borchers]

Thanks, Mike, for the prompt answer.
But what if i want to explicitly exclude integers.
I think with Real I would allow them.


On Saturday, May 17, 2014 2:13:09 PM UTC+2, Mike Innes wrote:
>
> I think your first example is right, although someone may well correct me 
> on that. That's how I've done similar things, anyway.
>
> As for your second example, this is happening because your type parameter 
> is overly restrictive – if you use ::Real it works as you would expect.
>
> Conversions like this will certainly take place where they make sense, but 
> they don't really make sense here – it has to be assumed that you've asked 
> for a Float64 because you specifically need one.
>
> – Mike
>
> On Saturday, 17 May 2014 12:59:02 UTC+1, Hans W Borchers wrote:
>>
>> Yesterday I implemented a function calculating arc length of curves (to 
>> the last digit) when I came across the following stumbling blocks. Image 
>> the following function where I leave a for-loop with a 'break' statement:
>>
>> function testfun1(x::Vector{Float64})
>> for i = 1:length(x)
>> if x[i] == 0.0
>> break
>> end
>> end
>> return i-1
>> end
>>
>> julia> testfun([1.0, 2.0, 3.0, 0.0, 1.0])
>> ERROR: i not defined
>>  in testfun at none:7
>>
>> I understand that the scope of the loop variable is restricted to the 
>> loop itself. What is the best way to "export"  i  to the outside? For 
>> the moment I settled with defining i before the loop.
>>
>> function testfun2(x::Vector{Float64})
>> local i::Int
>> for i = 1:length(x)
>> if x[i] == 0.0
>> break
>> end
>> end
>> return i-1
>> end
>>
>> This works, but I must admit it runs against my gut feeling and 
>> experience with other scientific programming languages.
>>
>>
>> The next shock was the following:
>>
>> function testfun(x::Float64)
>> return x^2
>> end
>>
>> julia> testfun(pi)
>> ERROR: no method testfun(MathConst{:π})
>>
>> Again, I learned that I can use testfun(float(pi) , but my feeling would 
>> be that pi should be converted to float automatically whenever the 
>> context requires it. On the mailing list I think I have seen other 
>> complaints about this. I would prefer that  pi  and MathConst{:π} (or 
>> even better π alone) were different objects.
>>
>>

Re: [julia-users] Accessing the loop variable (and pi as float)

[Chris Foster]

On Sat, May 17, 2014 at 9:59 PM, Hans W Borchers  wrote:
> Yesterday I implemented a function calculating arc length of curves (to the
> last digit) when I came across the following stumbling blocks. Image the
> following function where I leave a for-loop with a 'break' statement:
>
> function testfun1(x::Vector{Float64})
> for i = 1:length(x)
> if x[i] == 0.0
> break
> end
> end
> return i-1
> end

For this particular example, I'd suggest you just return i-1 directly
inside the loop:

function testfun1(x::Vector{Float64})
for i = 1:length(x)
if x[i] == 0.0
return i-1
end
end
return length(x)-1 # Or other special case for when 0 isn't found
end

Using an early return like this is really quite powerful, especially when
you have a deeply nested set of loops.  I use it all the time in C++.

> I understand that the scope of the loop variable is restricted to the loop
> itself. What is the best way to "export"  i  to the outside? For the moment
> I settled with defining i before the loop.

Yes, if you want i accessible outside a loop, you'll just have to declare
it in the outer scope.  AFAIK you've done the right thing there, though
initializing i to a default would be more concise and wouldn't fail if the
input array is empty (unless that's intentional).

> This works, but I must admit it runs against my gut feeling and
> experience with other scientific programming languages.

It's true that the looser scoping rules of langauges like matlab and python
can be convenient.  On the whole I prefer tighter scoping rules like C++
though: they make code easier to reason about by making the data
flow more local.

~Chris

[julia-users] Re: Accessing the loop variable (and pi as float)

[Mike Innes]

I think your first example is right, although someone may well correct me 
on that. That's how I've done similar things, anyway.

As for your second example, this is happening because your type parameter 
is overly restrictive – if you use ::Real it works as you would expect.

Conversions like this will certainly take place where they make sense, but 
they don't really make sense here – it has to be assumed that you've asked 
for a Float64 because you specifically need one.

– Mike

On Saturday, 17 May 2014 12:59:02 UTC+1, Hans W Borchers wrote:
>
> Yesterday I implemented a function calculating arc length of curves (to 
> the last digit) when I came across the following stumbling blocks. Image 
> the following function where I leave a for-loop with a 'break' statement:
>
> function testfun1(x::Vector{Float64})
> for i = 1:length(x)
> if x[i] == 0.0
> break
> end
> end
> return i-1
> end
>
> julia> testfun([1.0, 2.0, 3.0, 0.0, 1.0])
> ERROR: i not defined
>  in testfun at none:7
>
> I understand that the scope of the loop variable is restricted to the loop 
> itself. What is the best way to "export"  i  to the outside? For the 
> moment I settled with defining i before the loop.
>
> function testfun2(x::Vector{Float64})
> local i::Int
> for i = 1:length(x)
> if x[i] == 0.0
> break
> end
> end
> return i-1
> end
>
> This works, but I must admit it runs against my gut feeling and experience 
> with other scientific programming languages.
>
>
> The next shock was the following:
>
> function testfun(x::Float64)
> return x^2
> end
>
> julia> testfun(pi)
> ERROR: no method testfun(MathConst{:π})
>
> Again, I learned that I can use testfun(float(pi) , but my feeling would 
> be that pi should be converted to float automatically whenever the 
> context requires it. On the mailing list I think I have seen other 
> complaints about this. I would prefer that  pi  and MathConst{:π} (or 
> even better π alone) were different objects.
>
>

Re: [julia-users] Re: Design patterns for an API

[Mike Innes]

I may be missing the point here, but wouldn't it be easier to define sumf 
as a macro?

macro sumf(f, xs)
  quote
s = 0.0
x = $(esc(xs))
for i = 1:length(x)
  s += $(esc(f))(x[i])
end
s
  end
end

@sumf(sinc_plus_x, x)

This is just as fast and has the advantage that it will work when f is only 
in the local scope.


On Saturday, 17 May 2014 11:50:56 UTC+1, Tim Holy wrote:
>
> On Friday, May 16, 2014 02:36:03 PM francoi...@gmail.com wrote: 
> > - The solver need to be fast and for that, inlining is of paramount 
> > importance. I know that there is no way to inline F for the time being. 
> Do 
> > we expect inlining on function argument in the near future of Julia ? 
>
> I can't speak for when this will happen in a "nice" way, but using Julia's 
> metaprogramming capabilities there is a (somewhat ugly) way to get what 
> you 
> want. Since I'm planning to use this trick myself shortly, I created a 
> little 
> demonstration: 
>
> https://gist.github.com/timholy/bdcee95f9b7725214d8b 
>
> If you prefer, you don't have to separate out the definition of the body 
> from 
> the eval(quote...end) part, I just did it that way to better illustrate 
> the 
> separate ideas. 
>
> --Tim 
>
>

[julia-users] Accessing the loop variable (and pi as float)

[Hans W Borchers]

Yesterday I implemented a function calculating arc length of curves (to the 
last digit) when I came across the following stumbling blocks. Image the 
following function where I leave a for-loop with a 'break' statement:

function testfun1(x::Vector{Float64})
for i = 1:length(x)
if x[i] == 0.0
break
end
end
return i-1
end

julia> testfun([1.0, 2.0, 3.0, 0.0, 1.0])
ERROR: i not defined
 in testfun at none:7

I understand that the scope of the loop variable is restricted to the loop 
itself. What is the best way to "export"  i  to the outside? For the moment 
I settled with defining i before the loop.

function testfun2(x::Vector{Float64})
local i::Int
for i = 1:length(x)
if x[i] == 0.0
break
end
end
return i-1
end

This works, but I must admit it runs against my gut feeling and experience 
with other scientific programming languages.


The next shock was the following:

function testfun(x::Float64)
return x^2
end

julia> testfun(pi)
ERROR: no method testfun(MathConst{:π})

Again, I learned that I can use testfun(float(pi) , but my feeling would be 
that pi should be converted to float automatically whenever the context 
requires it. On the mailing list I think I have seen other complaints about 
this. I would prefer that  pi  and MathConst{:π} (or even better π alone) 
were different objects.

Re: [julia-users] Re: Design patterns for an API

[Tim Holy]

On Friday, May 16, 2014 02:36:03 PM francois.fay...@gmail.com wrote:
> - The solver need to be fast and for that, inlining is of paramount 
> importance. I know that there is no way to inline F for the time being. Do 
> we expect inlining on function argument in the near future of Julia ?

I can't speak for when this will happen in a "nice" way, but using Julia's 
metaprogramming capabilities there is a (somewhat ugly) way to get what you 
want. Since I'm planning to use this trick myself shortly, I created a little 
demonstration:

https://gist.github.com/timholy/bdcee95f9b7725214d8b

If you prefer, you don't have to separate out the definition of the body from 
the eval(quote...end) part, I just did it that way to better illustrate the 
separate ideas.

--Tim