Re: [julia-users] Re: Uint8 arrays and deprecations in 0.4

[Michele Zaffalon]

>
> Don't we all understand better the decimal system?
>>
>
> Apparently not: https://www.youtube.com/watch?v=l4bmZ1gRqCc
>
> Wow!

Re: [julia-users] parse() and line numbers

[Isaiah Norton]

Skipping line nodes is straightforward (look at the output of
`dump(expr)`). To hard-code it, you could look at modifying JuliaParser.jl.
Likewise with comments, but that will take more work because they are
simply skipped right now (at least in the main scheme parser code; I
haven't checked in JuliaParser.jl)

On Tue, Mar 17, 2015 at 6:56 AM,  wrote:

> Is there a way to prevent the generation of line numbers:
>
> julia> jt = """for i in 1:10
>println(i)
>end
>"""
> "for i in 1:10\nprintln(i)\nend\n"
>
> julia> parse(jt)
> :(for i = 1:10 # line 2:   <
> println(i)
> end)
>
> julia>
>
> or of retaining any comments that were in the string:
>
> julia> jt = """for i in 1:10
>  # printing now   <-—
>  println(i)
>end
>"""
>  julia> parse(jt) ...
>
> cheers
>
>

[julia-users] Parallel performance test question

[Sheehan Olver]

Hi,

I've created the following to test the performance of parallel processing 
on our departments server.  But the @everywhere isn't working because 
"ERROR: k not defined".   What's wrong?  And any advice on improving the 
test?  (Right now for small n there is little benefit for > 12 processes, 
but this seems expected behaviour to me.  There are many other processes 
maxing out CPU simultaneous with the test.)

Sheehan 



function timemat(n,m,b,p)
rmprocs(procs()[2:end])
tms=Array(Float64,p,b)
for j=1:p
for k=1:b
@everywhere blas_set_num_threads(k)

# following line is just to make sure everything is precompiled
@parallel (+) for k=1:2p
last(randn(n,n)\[1;zeros(n-1)])
 end;

tms[j,k]=@elapsed(@parallel (+) for k=1:m
last(randn(n,n)\[1;zeros(n-1)])
 end)

println("procs=$j blas=$k $(tms[j,k])")
end
addprocs(1)
end
tms
end

Re: [julia-users] Pre-compiling?

[Dallas Morisette]

Ok, thanks. That definitely looks like overkill for what I need. Most of my 
day-to-day work is going to be with IJulia or in REPL, so the overhead 
isn't really a problem. I can load once then try different scenarios 
without restarting the kernel.

On Tuesday, March 17, 2015 at 5:26:58 PM UTC-4, René Donner wrote:
>
> This is in the works, but in the meantime you can get try building your 
> own system image: 
> http://docs.julialang.org/en/release-0.3/devdocs/sysimg/?highlight=userimg 
>
> But this is only handy when the code that gets included there does not 
> change too often, as building this image will take a few minutes. 
>
>
>
> Am 17.03.2015 um 22:24 schrieb Dallas Morisette  >: 
>
> > First, thanks to all those who were patient with me and answered my 
> newbie performance questions! 
> > 
> > I now have my Julia simulation running just as fast as my original 
> Fortran code. Needless to say I'm loving Julia! However, when I run it as a 
> script from the command line, the startup (compilation I assume) takes 
> about 7X longer than my whole simulation! If I run it in an REPL session, 
> after an initial run that takes about 10 sec, I can run additional 
> simulations in just 1.5 sec. 
> > 
> > Is there any way to precompile a Julia script, a la Python's .pyc files 
> to speed up startup of subsequent runs? 
> > 
> > Thanks! 
> > Dallas 
> > 
>
>

Re: [julia-users] Change array of arrays to a one dimensional array

[Christopher Fisher]

Excellent. I was not aware of the use of the ellipsis in Julia. Thanks!

On Tuesday, March 17, 2015 at 9:03:48 PM UTC-4, Andreas Noack wrote:
>
> new_array = vcat(data...)
>
> 2015-03-17 20:59 GMT-04:00 Christopher Fisher  >:
>
>>
>>
>> Hi all-
>>
>> pmap outputs the results as an array of arrays and I am trying to find a 
>> flexible way to change it into a one dimensional array. I can hardcode the 
>> results as new_array = vcat(data[1],data[2],data[3],data[4]). Is there an 
>> easy way to accomplish this without hardcoding each data[] into vcat?
>>
>> Thank you in advance
>>
>
>

Re: [julia-users] Change array of arrays to a one dimensional array

[Andreas Noack]

new_array = vcat(data...)

2015-03-17 20:59 GMT-04:00 Christopher Fisher :

>
>
> Hi all-
>
> pmap outputs the results as an array of arrays and I am trying to find a
> flexible way to change it into a one dimensional array. I can hardcode the
> results as new_array = vcat(data[1],data[2],data[3],data[4]). Is there an
> easy way to accomplish this without hardcoding each data[] into vcat?
>
> Thank you in advance
>

[julia-users] Change array of arrays to a one dimensional array

[Christopher Fisher]

Hi all-

pmap outputs the results as an array of arrays and I am trying to find a 
flexible way to change it into a one dimensional array. I can hardcode the 
results as new_array = vcat(data[1],data[2],data[3],data[4]). Is there an 
easy way to accomplish this without hardcoding each data[] into vcat?

Thank you in advance

Re: [julia-users] Re: Performance - what am I doing wrong?

[Cristóvão Duarte Sousa]

Indeed, x^2 seems to be an optimization case in  NumPy. See, for x^3:

Julia:
julia> @timeit y = x.^3
1000 loops, best of 3: 265.99 µs per loop

Python:
In [1]: %timeit y = x**3
1000 loops, best of 3: 259 µs per loop


On Monday, March 16, 2015 at 4:08:55 PM UTC, Sisyphuss wrote:
>
> Here is my version.
>
> Firstly, the benchmark of Python.
> %timeit x**2
>
> 10 loops, best of 3: 4.43 µs per loop
>
> %timeit [xi**2 for xi in x]
>
> 100 loops, best of 3: 2.28 ms per loop
>
>
> Secondly, the various Julia versions.
> f1 = x -> x.^2
> f2 = x -> x.*x
> f3 = x -> [xi*xi for xi in x]
>
> function f4(x)
> y = x
> for i = 1:length(x) 
> y[i] = x[i]*x[i]
> end
> return y
> end
>
> function f5(x)
> for i = 1:length(x) 
> x[i] *= x[i]
> end
> end
>
> function f6(x)
> @simd for i = 1:length(x) 
> @inbounds x[i] *= x[i]
> end
> end
>
> @timeit f1(x)
>
> 1000 loops, best of 3: 149.74 µs per loop
> @timeit f2(x)
>
> 1000 loops, best of 3: 60.59 µs per loop
> @timeit f3(x)
>
> 10 loops, best of 3: 4.38 ms per loop
> @timeit f4(x)
>
> 10 loops, best of 3: 9.08 µs per loop
>
> @timeit f5(x)
>
> 10 loops, best of 3: 9.18 µs per loop
>
> @timeit f6(x)
>
> 10 loops, best of 3: 2.97 µs per loop
>
>
> The comparison of f1 and f2 shows that .* is faster than .^2
> The comparison of f2 and f3 shows that comprehension is slower
> The high performance of f4 and f5 shows that for higher performance we 
> should write loops ourselves instead of writing vectorization code.
> The higher performance of f6 compared to Python shows that Julia is 
> eventually faster than NumPy.
>
> Furthermore, I find an interesting phenomenon for NumPy:
> %timeit x**2
> %timeit x**4
> %timeit (x**2)**2
>
> 10 loops, best of 3: 4.54 µs per loop
> 1000 loops, best of 3: 774 µs per loop
> 10 loops, best of 3: 9.85 µs per loop
>
> That suggests NumPy only optimized **2, not ** operator itself !
>
>
> On Monday, March 16, 2015 at 3:31:41 PM UTC+1, Sisyphuss wrote:
>>
>> That's interesting!
>>
>> On Sunday, March 15, 2015 at 4:18:34 PM UTC+1, Dallas Morisette wrote:
>>>
>>> Thanks everyone for the suggestions! Here is my updated test:
>>>
>>> using TimeIt
>>> function vec!(x,y)
>>> y = x.*x
>>> end
>>>
>>> function comp!(x,y)
>>> y = [xi*xi for xi in x]
>>> end
>>>
>>> function forloop!(x,y,n)
>>> for i = 1:n 
>>> y[i] = x[i]*x[i]
>>> end
>>> end
>>>
>>> function forloop2!(x,y,n)
>>> @simd for i = 1:n 
>>> @inbounds y[i] = x[i]*x[i] 
>>> end
>>> end
>>> 
>>> function test()
>>> n = 1
>>> x = linspace(0.0,1.0,n)
>>> y = zeros(x)
>>> @timeit vec!(x,y)
>>> @timeit comp!(x,y)
>>> @timeit forloop!(x,y,n)
>>> @timeit forloop2!(x,y,n)
>>> end
>>> test();
>>>
>>> 1 loops, best of 3: 87.82 µs per loop
>>> 1000 loops, best of 3: 62.73 µs per loop
>>> 1 loops, best of 3: 12.66 µs per loop
>>> 10 loops, best of 3: 3.54 µs per loop
>>>
>>>
>>> So the SIMD macros combined with a literal for loop give performance 
>>> essentially equivalent to a call to numpy. I switched to @time so I could 
>>> see the allocations:
>>>
>>> elapsed time: 2.467e-5 seconds (80512 bytes allocated)
>>> elapsed time: 2.1358e-5 seconds (80048 bytes allocated)
>>> elapsed time: 1.5124e-5 seconds (0 bytes allocated)
>>> elapsed time: 6.108e-6 seconds (0 bytes allocated)
>>>
>>>
>>> Looks like one temporary array has to be allocated in both vectorized 
>>> and comprehension forms, which reduced the performance by about 5-7X. I 
>>> suppose this would depend on the exact calculation being done and the size 
>>> of the arrays involved and would have to be tested on a case-by-case basis. 
>>>
>>> Thanks for the help - I'm sure I'll be back with more questions!
>>>
>>> Dallas
>>>
>>

Re: [julia-users] Re: Unable to find were it breaks IUP (0.4 after 0.4.0-dev+3703)

[J Luis]

> I looked up the c definition of this function…
>
> The list is supposed to be a null-terminated list of (name, function) 
> argument pairs. I think you can just go with the following for now though:
>
> function IupSetCallbacks(ih::Ptr{Ihandle}, name::String, func1::Icallback)
> ccall((:IupSetCallbacks, iup), Icallback, (Ptr{Ihandle}, Ptr{Uint8}, 
> Icallback, Ptr{Void}...), ih, name, func1, C_NULL)
> end
>
> Thanks. I remember that I had other functions using varargs so I assume 
that I should do similar for those other functions
 

> Unfortunately (or fortunately), I couldn’t see anything else wrong with 
> your code.
>
> Is the IUP.IupCanvas() call essential, or does just calling gc() there 
> also crash julia?
>
Good catch. Yes `gc()` alone can crash it. 
That's all it takes to do it

julia> using IUP_CD

julia> gc()


Since I don’t see anywhere that you needed to access the fields directly, I 
> suspect you should just declare this type as a typealias to Void. (or 
> perhaps just a thin wrapper type around Ptr{Void}, so that you can add a 
> gc-finalizer, ala 
> https://github.com/stevengj/PyCall.jl/blob/9db730b528d7abb53444f3f89b434bd72a38cc8d/src/PyCall.jl#L82-L90
> )
>
I'm afraid I only half-understand this. The IupCanvas C signature says 
 
Ihandle* IupCanvas(const char **action*);

*action*: Name of the action generated when the canvas needs to be 
redrawn. It can be NULL.

*Returns:* the identifier of the created element, or NULL if an error 
occurs.


so, though not used in any of the examples I ported from the IUP C 
examples, it's supposed to be possible to use with one input argument

>
> It looks like `cdCanvas` might be quite large. Perhaps this is hitting 
> some conflict in the gc?
>
>
> 
>
> # I Don't understand the purpose of this function, which true definition 
> includes a varargs, so I implemented
> # this one only as a guide for the future problems
> function IupSetCallbacks(ih::Ptr{Ihandle}, name::String, func1::Icallback, 
> func2::Icallback)
> ccall((:IupSetCallbacks, iup), Icallback, (Ptr{Ihandle}, Ptr{Uint8}, 
> Icallback, Icallback), ih, name, func1, func2)
> end
>
> note that defining a varargs function without a varargs (...) declaration 
> in julia could corrupt a program, although it seems that only the SysV 
> x86_64 ABI seems to make a distinction (if there are XMM registers in use).
>
> On Mon, Mar 16, 2015 at 12:38 AM J Luis > 
> wrote:
>
> In my machine (Win8 64), 488 is the size limit for that immutable. 
>
> With 489 ==> Kaboomm
>
> segunda-feira, 16 de Março de 2015 às 04:27:38 UTC, J Luis escreveu:
>
> I may have found a very important piece.
>
> If I shrink the immutable Array_1024_Uint8 in
>  https://github.com/joa-quim/IUP.jl/blob/master/src/libcd_h.jl#L154
> to, let say, 4 members than the whole program works again. So apparently 
> it's a size matter!
>
> segunda-feira, 16 de Março de 2015 às 03:06:14 UTC, J Luis escreveu:
>
> The changes referred in https://groups.google.com/foru
> m/?fromgroups=#!topic/julia-users/qi6HpMrAS_A broke IUP.jl in a way that 
> I simply cannot even identify where the breakage occurs.
>
> I managed to reproduce the crash with only one instruction, but even than 
> makes no sense to me. The next two lines crash julia
>
> julia> using im_view_
> julia> a=IUP.IupCanvas()
>
> It can be seen in https://github.com/joa-quim/IU
> P.jl/blob/master/src/libiup.jl#L480 that the wrapper is OK and if fact if 
> I comment the two lines (that leave in another module)
>
> https://github.com/joa-quim/IUP.jl/blob/master/src/IUP_CD.jl#L349
> https://github.com/joa-quim/IUP.jl/blob/master/src/IUP_CD.jl#L350
>
> that are include from the module im_view_ than I get an error of missing 
> function (normal, since I commented its inclusions) but otherwise all seam 
> to work.
> So I'm left with this back trace of which I'm unable to extract any useful 
> information.
>
> (On Win64 with a nightly from 2 days ago)
>
> Please submit a bug report with steps to reproduce this fault, and any 
> error messages that follow (in their entirety). Thanks.
> Exception: EXCEPTION_ACCESS_VIOLATION at 0x6bfb2b56 -- 
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bi

[julia-users] Re: Use Variable in Regex (interpolate)

[David P. Sanders]

El martes, 17 de marzo de 2015, 15:14:35 (UTC-6), Julia User escribió:
>
> How to use a julia variable in a regex string (interpolate).
>
> var = " "
> reg =  r"^$(var)+"   # Something like this
> result = matchall(reg, mystring)
>
>
> Is there a way to make this work?
>

How about the following? I don't know if there's a shorter way.


var = " "
reg_string =  "^$(var)+"   # standard Julia string
reg = Regex(reg_string)  # make a regular expression out of the string
result = matchall(reg, mystring)



Best,
David.

 

>
> Thanks
>
>
>
>

Re: [julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[J Luis]

Unfortunately none of those make a difference. e.g

julia> Pkg.add("Graphics")
INFO: Nothing to be done

julia> using ImageView
ERROR: LoadError: UndefVarError: Graphics not defined
 in include at boot.jl:250
 in include_from_node1 at loading.jl:129
 in reload_path at loading.jl:153
 in _require at loading.jl:68
 in require at loading.jl:51
while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in expression 
starting on line 3




terça-feira, 17 de Março de 2015 às 02:37:34 UTC, Tim Holy escreveu:
>
> Now say Pkg.build("ImageView"). It should now install Graphics.jl for you. 
> If 
> it doesn't, just say Pkg.add("Graphics"). (But adding it to the REQUIRE 
> means 
> you will have fixed it for other users, too.) 
>
> --Tim 
>
> On Monday, March 16, 2015 12:00:32 PM J Luis wrote: 
> > I am sorry but I'm getting nowhere. 
> > - So I added 
> > 
> > Graphics 0.1 
> > 
> > to v0.4\ImageView\REQUIRE and similar in v0.4\ImageView\src\ImageView.jl 
> to 
> > the commit you pointed above, but still 
> > 
> > julia> using ImageView 
> > ERROR: LoadError: UndefVarError: Graphics not defined 
> >  in include at boot.jl:250 
> >  in include_from_node1 at loading.jl:129 
> >  in reload_path at loading.jl:153 
> >  in _require at loading.jl:68 
> >  in require at loading.jl:51 
> > while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in expression 
> > starting on line 3 
> > 
> > 
> > 
> > and 
> > 
> > julia> Pkg.add("Graphics") 
> > INFO: Nothing to be done 
> > 
> > segunda-feira, 16 de Março de 2015 às 00:22:50 UTC, Tim Holy escreveu: 
> > > You likely have to do the same thing to Gtk as in 
> > > 
> > > 
> https://github.com/timholy/Images.jl/commit/68126750d07dec407ed0dbbd8ba01b 
> > > e28ce176d1 
> > > 
> > > --Tim 
> > > 
> > > On Sunday, March 15, 2015 10:32:32 AM J Luis wrote: 
> > > > and bad luck with Gtk too 
> > > > 
> > > > julia> Img = imread( 
> > > 
> > > 
> "C://progs_cygw//GMTdev//gmt5//branches//5.2.0//test//grdimage//gdal//need 
> > > le> 
> > > > .jpg" ); 
> > > > 
> > > > julia> view(Img) 
> > > > (ImageCanvas,ImageSlice2d: zoom = BoundingBox(0.0,430.0,0.0,300.0)) 
> > > > 
> > > > julia> ERROR: `width` has no method matching width(::GtkCanvas) 
> > > > 
> > > >  in setbb! at C:\j\.julia\v0.3\ImageView\src\display.jl:80 
> > > >  in resize at C:\j\.julia\v0.3\ImageView\src\display.jl:582 
> > > >  in anonymous at C:\j\.julia\v0.3\ImageView\src\display.jl:420 
> > > >  in draw at C:\j\.julia\v0.3\Gtk\src\cairo.jl:72 
> > > >  in notify_resize at C:\j\.julia\v0.3\Gtk\src\cairo.jl:52 
> > > > 
> > > > domingo, 15 de Março de 2015 às 16:03:00 UTC, J Luis escreveu: 
> > > > > Bear with me that I'm still very rough with the packaging system 
> but 
> > > 
> > > the 
> > > 
> > > > > fact that I see in my .julia/v0.4/Gtk/REQUIRE 
> > > > > 
> > > > > Cairo 0.2.2 
> > > > > julia 0.2- 
> > > > > Graphics 0.1 
> > > > > BinDeps 
> > > > > @windows WinRPM 
> > > > > @osx Homebrew 
> > > > > 
> > > > > does not mean that the Graphics dependency is already there? 
> > > > > 
> > > > > domingo, 15 de Março de 2015 às 14:26:46 UTC, Tim Holy escreveu: 
> > > > >> Can you add Graphics to the REQUIRE file and submit a pull 
> request 
> > > > >> against the 
> > > > >> gtk branch? 
> > > > >> 
> > > > >> --Tim 
> > > > >> 
> > > > >> On Sunday, March 15, 2015 07:13:02 AM J Luis wrote: 
> > > > >> > Thanks. On v0.3.4 it seams to work (I mean no errors on "using 
> > > > >> 
> > > > >> ImageView") 
> > > > >> 
> > > > >> > but on 0.4 
> > > > >> > 
> > > > >> > julia> Pkg.checkout("ImageView", "gtk") 
> > > > >> > INFO: Checking out ImageView gtk... 
> > > > >> > INFO: Pulling ImageView latest gtk... 
> > > > >> > INFO: No packages to install, update or remove 
> > > > >> > 
> > > > >> > julia> using ImageView 
> > > > >> > ERROR: LoadError: UndefVarError: Graphics not defined 
> > > > >> > while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in 
> > > > >> 
> > > > >> expression 
> > > > >> 
> > > > >> > starting on line 3 
> > > > >> > 
> > > > >> > domingo, 15 de Março de 2015 às 13:27:23 UTC, Tim Holy 
> escreveu: 
> > > > >> > > Pkg.checkout("ImageView", "gtk") 
> > > > >> > > 
> > > > >> > > But I haven't updated that branch in a long time---it's being 
> > > 
> > > held up 
> > > 
> > > > >> > > because 
> > > > >> > > I have an ambitious revamping plan for ImageView, and I just 
> > > 
> > > haven't 
> > > 
> > > > >> > > cleared 
> > > > >> > > the two weeks it will take to implement it. So you may need 
> to be 
> > > > >> 
> > > > >> prepared 
> > > > >> 
> > > > >> > > to 
> > > > >> > > fix up that gtk branch. Pull requests welcome :-). 
> > > > >> > > 
> > > > >> > > --Tim 
> > > > >> > > 
> > > > >> > > On Sunday, March 15, 2015 05:57:35 AM J Luis wrote: 
> > > > >> > > > Hi, 
> > > > >> > > > 
> > > > >> > > > I can't use ImageView because of issue #67 
> > > > >> > > >  (the "Can't 
> > > 
> > > find 
> > > 
> > > > >> usable 
> > > > 

Re: [julia-users] Pre-compiling?

[René Donner]

This is in the works, but in the meantime you can get try building your own 
system image: 
http://docs.julialang.org/en/release-0.3/devdocs/sysimg/?highlight=userimg

But this is only handy when the code that gets included there does not change 
too often, as building this image will take a few minutes.



Am 17.03.2015 um 22:24 schrieb Dallas Morisette :

> First, thanks to all those who were patient with me and answered my newbie 
> performance questions! 
> 
> I now have my Julia simulation running just as fast as my original Fortran 
> code. Needless to say I'm loving Julia! However, when I run it as a script 
> from the command line, the startup (compilation I assume) takes about 7X 
> longer than my whole simulation! If I run it in an REPL session, after an 
> initial run that takes about 10 sec, I can run additional simulations in just 
> 1.5 sec. 
> 
> Is there any way to precompile a Julia script, a la Python's .pyc files to 
> speed up startup of subsequent runs?
> 
> Thanks!
> Dallas
> 

[julia-users] Pre-compiling?

[Dallas Morisette]

First, thanks to all those who were patient with me and answered my newbie 
performance questions! 

I now have my Julia simulation running just as fast as my original Fortran 
code. Needless to say I'm loving Julia! However, when I run it as a script 
from the command line, the startup (compilation I assume) takes about 7X 
longer than my whole simulation! If I run it in an REPL session, after an 
initial run that takes about 10 sec, I can run additional simulations in 
just 1.5 sec. 

Is there any way to precompile a Julia script, a la Python's .pyc files to 
speed up startup of subsequent runs?

Thanks!
Dallas

[julia-users] Use Variable in Regex (interpolate)

[Julia User]

How to use a julia variable in a regex string (interpolate).

var = " "
reg =  r"^$(var)+"   # Something like this
result = matchall(reg, mystring)


Is there a way to make this work?

Thanks

[julia-users] Re: Basic install question

[Novice69]

This is copied from:


   - 
   
   Error evaluating REPL:
   unknown package 
in wait at task.jl:51
in sync_end at 
/Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
in add at pkg/entry.jl:319
in add at pkg/entry.jl:71
in anonymous at pkg/dir.jl:28
in cd at 
/Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
in __cd#227__ at 
/Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
in add at pkg.jl:20
in include_string at loading.jl:97
in include_string at /Users/petar/.julia/v0.3/Jewel/src/eval.jl:36
in anonymous at /Users/petar/.julia/v0.3/Jewel/src/LightTable/eval.jl:68
in handlecmd at 
/Users/petar/.julia/v0.3/Jewel/src/LightTable/LightTable.jl:65
in handlenext at 
/Users/petar/.julia/v0.3/Jewel/src/LightTable/LightTable.jl:81
in server at /Users/petar/.julia/v0.3/Jewel/src/LightTable/LightTable.jl:22
in server at /Users/petar/.julia/v0.3/Jewel/src/Jewel.jl:15
in include at 
/Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
in include_from_node1 at loading.jl:128
in process_options at 
/Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
in _start at 
/Applications/Juno.app/Contents/Resources/app/julia/lib/julia/sys.dylib
   
   

Re: [julia-users] load a Julia dataframe from Microsoft SQL Server table

[Jacob Quinn]

Check out the https://github.com/quinnj/ODBC.jl package for connecting to
DSN defined in your ODBC manager.

On Tue, Mar 17, 2015 at 1:17 PM, Charles Brauer 
wrote:

> Hi,
>
> I'm considering diving into Julia. However, all of my data is in a
> Microsoft SQL Server database.
> I would really appreciate a Julia code example on how to load a Julia
> dataframe from SQL Server table.
>
> Thanks
> Charles
>

Re: [julia-users] Some simple use cases for multi-threading

[Kiran Pamnany]

The threading model is loop parallelism--OpenMP-like parallel blocks and 
for loops with static scheduling only (for now). There are three forms, 
demonstrated in test/threads.jl. I'm working on atomics and locks--there's 
some discussion going on about portable implementations. Given those, 
threadid() and nthreads(), it should be possible to implement any 
concurrent data structure in Julia.

Depending on how well Julia-generated code performs, some important 
concurrent data structures might be better implemented in C and wrapped. We 
do need something like a java.util.concurrent library.

See test/perf/threads/laplace3d for an example threading performance 
benchmark.

The focus of the multi-threading effort is HPC, hence the choice of model. 
I think it is possible to layer other programming models over this, that 
would be better suited for server type applications or GUIs, but we have a 
lot to do on this one yet.

[julia-users] load a Julia dataframe from Microsoft SQL Server table

[Charles Brauer]

Hi,

I'm considering diving into Julia. However, all of my data is in a 
Microsoft SQL Server database.
I would really appreciate a Julia code example on how to load a Julia 
dataframe from SQL Server table.

Thanks
Charles

[julia-users] Make existing Array available to multiple workers as SharedArray?

[Nils Gudat]

I'm wondering what the correct way of achieving the following is:
Say I have a bunch of Arrays, and I need them as input for a function 
inside a loop I want to parallelize. In line with this discussion 
 in the 
user groups, it appears that this is a good situation in which to use 
SharedArrays. Since these Arrays are being initialized in various parts of 
my code (which don't run in parallel), I though I could retroactively make 
them available to all workers in the following way:

function arraycreation()
a = Array(Float64, 100)
b = similar(a)
... some calculations ...
return a, b
end

addprocs(3)

convert(SharedArray, a)
convert(SharedArray, b)


But when I then try to to run @everywhere function2(a), Julia tells me that a 
is not available on workers 2, 3, and 4. 
What is the correct way of making SharedArrays available on all workers?

Re: [julia-users] Reinterpret immutable type as an Array/Matrix.

[Jameson Nash]

getfield already implements array-like (numbered) access to a types fields

Or you could just put the array in your type
On Tue, Mar 17, 2015 at 12:02 PM Erik Schnetter  wrote:

> This is nice. This (unsafe) method could be used to implement array-like
> access functionality (getindex, setindex!, length, etc.) in a safe manner.
>
> -erik
>
> > On Mar 17, 2015, at 11:25 , René Donner  wrote:
> >
> > I believe this might help: https://groups.google.com/d/ms
> g/julia-users/K1BlJW8k2o0/FRfANpsB_XIJ
> >
> > Am Dienstag, 17. März 2015 16:08:09 UTC+1 schrieb Kristoffer Carlsson:
> > Say I have an immutable with only one type.
> >
> > immutable Strain
> > exx::Float64
> > eyy::Float64
> > ezz::Float64
> > gyz::Float64
> > gxz::Float64
> > gxy::Float64
> > end
> >
> > Is there anyway I can reinterpret this as a Vector{Float64} in a fast
> way without copying data. The memory of the Strain type should be exactly
> like the vector.
> >
> > The reason I want to do this is because I want to i.e. be able to
> multiply a strain and a general matrix but I also want to be able to write
> my own functions for Strain.
> >
> > Naively, I tried this:
> >
> > julia> reinterpret(Vector{Float64}, strain)
> > ERROR: reinterpret: expected bits type as first argument
> >  in reinterpret at base.jl:65
> >
> > I saw this comment in one of the issues here
> https://github.com/JuliaLang/julia/issues/5857:
> >
> > "ImmutableArrays has the advantage that Array(Vector4{Int}, 10) it can
> be reinterpreted as a 4x10 matrix with reinterpret and reshape without
> memory movement (e.g. when calling a c function on the data)."
> >
> >
> > Best regards,
> > Kristoffer Carlsson
>
> --
> Erik Schnetter 
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from https://sks-keyservers.net
> .
>
>

Re: [julia-users] Reinterpret immutable type as an Array/Matrix.

[Erik Schnetter]

This is nice. This (unsafe) method could be used to implement array-like access 
functionality (getindex, setindex!, length, etc.) in a safe manner.

-erik

> On Mar 17, 2015, at 11:25 , René Donner  wrote:
> 
> I believe this might help: 
> https://groups.google.com/d/msg/julia-users/K1BlJW8k2o0/FRfANpsB_XIJ
> 
> Am Dienstag, 17. März 2015 16:08:09 UTC+1 schrieb Kristoffer Carlsson:
> Say I have an immutable with only one type.
> 
> immutable Strain
> exx::Float64
> eyy::Float64
> ezz::Float64
> gyz::Float64
> gxz::Float64
> gxy::Float64
> end
> 
> Is there anyway I can reinterpret this as a Vector{Float64} in a fast way 
> without copying data. The memory of the Strain type should be exactly like 
> the vector.
> 
> The reason I want to do this is because I want to i.e. be able to multiply a 
> strain and a general matrix but I also want to be able to write my own 
> functions for Strain.
> 
> Naively, I tried this:
> 
> julia> reinterpret(Vector{Float64}, strain)
> ERROR: reinterpret: expected bits type as first argument
>  in reinterpret at base.jl:65
> 
> I saw this comment in one of the issues here 
> https://github.com/JuliaLang/julia/issues/5857:
> 
> "ImmutableArrays has the advantage that Array(Vector4{Int}, 10) it can be 
> reinterpreted as a 4x10 matrix with reinterpret and reshape without memory 
> movement (e.g. when calling a c function on the data)."
> 
> 
> Best regards,
> Kristoffer Carlsson

--
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from https://sks-keyservers.net.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [julia-users] Re: Reinterpret immutable type as an Array/Matrix.

[Isaiah Norton]

Note that in that thread the immutable is being put in an array first and
then the array is reinterpreted. That is the only way this can work,
because an immutable is not guaranteed to live in the heap.

On Tue, Mar 17, 2015 at 11:25 AM, René Donner  wrote:

> I believe this might help:
> https://groups.google.com/d/msg/julia-users/K1BlJW8k2o0/FRfANpsB_XIJ
>
> Am Dienstag, 17. März 2015 16:08:09 UTC+1 schrieb Kristoffer Carlsson:
>
>> Say I have an immutable with only one type.
>>
>> immutable Strain
>> exx::Float64
>> eyy::Float64
>> ezz::Float64
>> gyz::Float64
>> gxz::Float64
>> gxy::Float64
>> end
>>
>> Is there anyway I can reinterpret this as a Vector{Float64} in a fast way
>> without copying data. The memory of the Strain type should be exactly like
>> the vector.
>>
>> The reason I want to do this is because I want to i.e. be able to
>> multiply a strain and a general matrix but I also want to be able to write
>> my own functions for Strain.
>>
>> Naively, I tried this:
>>
>> julia> reinterpret(Vector{Float64}, strain)
>> ERROR: reinterpret: expected bits type as first argument
>>  in reinterpret at base.jl:65
>>
>> I saw this comment in one of the issues here
>> https://github.com/JuliaLang/julia/issues/5857:
>>
>> "ImmutableArrays has the advantage that Array(Vector4{Int}, 10) it can be
>> reinterpreted as a 4x10 matrix with reinterpret and reshape without memory
>> movement (e.g. when calling a c function on the data)."
>>
>>
>> Best regards,
>> Kristoffer Carlsson
>>
>

[julia-users] Re: Reinterpret immutable type as an Array/Matrix.

[René Donner]

I believe this might help: 
https://groups.google.com/d/msg/julia-users/K1BlJW8k2o0/FRfANpsB_XIJ

Am Dienstag, 17. März 2015 16:08:09 UTC+1 schrieb Kristoffer Carlsson:
>
> Say I have an immutable with only one type.
>
> immutable Strain
> exx::Float64
> eyy::Float64
> ezz::Float64
> gyz::Float64
> gxz::Float64
> gxy::Float64
> end
>
> Is there anyway I can reinterpret this as a Vector{Float64} in a fast way 
> without copying data. The memory of the Strain type should be exactly like 
> the vector.
>
> The reason I want to do this is because I want to i.e. be able to multiply 
> a strain and a general matrix but I also want to be able to write my own 
> functions for Strain.
>
> Naively, I tried this:
>
> julia> reinterpret(Vector{Float64}, strain)
> ERROR: reinterpret: expected bits type as first argument
>  in reinterpret at base.jl:65
>
> I saw this comment in one of the issues here 
> https://github.com/JuliaLang/julia/issues/5857:
>
> "ImmutableArrays has the advantage that Array(Vector4{Int}, 10) it can be 
> reinterpreted as a 4x10 matrix with reinterpret and reshape without memory 
> movement (e.g. when calling a c function on the data)."
>
>
> Best regards,
> Kristoffer Carlsson
>

[julia-users] Re: Looking for incomplete SVD -- need only some of the singular values

[paul analyst]

eigs(A[, B], ; nev=6, which=”LM”, tol=0.0, maxiter=1000, sigma=nothing, 
ritzvec=true, v0=zeros((0, )))
-> (d[, v ], nconv, niter, nmult, resid)
eigs computes eigenvalues d of A using Lanczos or Arnoldi iterations for 
real symmetric or general nonsymmetric matrices

nev= number of eigens...
Paul


W dniu niedziela, 15 marca 2015 21:10:08 UTC+1 użytkownik Erik Schnetter 
napisał:
>
> I am looking for a routine that calculate the SVD (singular value 
> decomposition) of a square, complex, dense, non-symmetric matrix. I am 
> aware of Julia's SVD routine (and the respective LAPACK routines that one 
> could call directly). However, I don't need all of the singular values -- I 
> need only the largest one (or some of the largest ones), as well as the 
> associated entries of U. Is there such a routine? I didn't find one in 
> Julia. 
>
> I've looked for other packages that could be wrapped, but couldn't find 
> any that offers this feature. The only thing I found is a description of 
> the "svds" Matlab routine, which is apparently based on "eigs". 
>
> -erik 
>
> -- 
> Erik Schnetter > 
> http://www.perimeterinstitute.ca/personal/eschnetter/ 
>
> My email is as private as my paper mail. I therefore support encrypting 
> and signing email messages. Get my PGP key from https://sks-keyservers.net. 
>
>
>

Re: [julia-users] Reinterpret immutable type as an Array/Matrix.

[Erik Schnetter]

Yes -- this would be awesome! This functionality be most useful in many physics 
simulation codes, where various user-defined types are implicitly elements of a 
vector space, and being able to treat them as arrays would simplify coding a 
lot.

Several possible implementations come to my mind:

(1) Explicitly define getindex and setindex!, and a few other array operations, 
so that the type behaves like an array from Julia's point of view

(2) Define the type as array or as tuple, and explicitly define functions 
".exx" etc. that offer a syntax identical or similar to accessing field elements

(3) Allow "reinterpret" in this case (immutable types where all fields have the 
same type)

(4) Do one of the above, or something else, and use macros in a clever way to 
simplify the coding overhead

-erik

> On Mar 17, 2015, at 11:08 , Kristoffer Carlsson  wrote:
> 
> Say I have an immutable with only one type.
> 
> immutable Strain
> exx::Float64
> eyy::Float64
> ezz::Float64
> gyz::Float64
> gxz::Float64
> gxy::Float64
> end
> 
> Is there anyway I can reinterpret this as a Vector{Float64} in a fast way 
> without copying data. The memory of the Strain type should be exactly like 
> the vector.
> 
> The reason I want to do this is because I want to i.e. be able to multiply a 
> strain and a general matrix but I also want to be able to write my own 
> functions for Strain.
> 
> Naively, I tried this:
> 
> julia> reinterpret(Vector{Float64}, strain)
> ERROR: reinterpret: expected bits type as first argument
>  in reinterpret at base.jl:65
> 
> I saw this comment in one of the issues here 
> https://github.com/JuliaLang/julia/issues/5857:
> 
> "ImmutableArrays has the advantage that Array(Vector4{Int}, 10) it can be 
> reinterpreted as a 4x10 matrix with reinterpret and reshape without memory 
> movement (e.g. when calling a c function on the data)."
> 
> 
> Best regards,
> Kristoffer Carlsson

--
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from https://sks-keyservers.net.



signature.asc
Description: Message signed with OpenPGP using GPGMail

[julia-users] Re: Reinterpret immutable type as an Array/Matrix.

[Alex]

I think you have to do it like this

reinterpret(Float64, [strain,])

Hope that helps,

Alex.

On Tuesday, 17 March 2015 16:08:09 UTC+1, Kristoffer Carlsson  wrote:
> Say I have an immutable with only one type.
> 
> 
> 
> 
> immutable Strain
>     exx::Float64
>     eyy::Float64
>     ezz::Float64
>     gyz::Float64
>     gxz::Float64
>     gxy::Float64
> end
> Is there anyway I can reinterpret this as a Vector{Float64} in a fast way 
> without copying data. The memory of the Strain type should be exactly like 
> the vector.
> 
> 
> The reason I want to do this is because I want to i.e. be able to multiply a 
> strain and a general matrix but I also want to be able to write my own 
> functions for Strain.
> 
> 
> Naively, I tried this:
> 
> 
> 
> 
> julia> reinterpret(Vector{Float64}, strain)
> ERROR: reinterpret: expected bits type as first argument
>  in reinterpret at base.jl:65
> 
> 
> I saw this comment in one of the issues here 
> https://github.com/JuliaLang/julia/issues/5857:
> 
> "ImmutableArrays has the advantage that Array(Vector4{Int}, 10) it can be 
> reinterpreted as a 4x10 matrix with reinterpret and reshape without memory 
> movement (e.g. when calling a c function on the data)."
> 
> 
> Best regards,
> Kristoffer Carlsson

[julia-users] Reinterpret immutable type as an Array/Matrix.

[Kristoffer Carlsson]

Say I have an immutable with only one type.

immutable Strain
exx::Float64
eyy::Float64
ezz::Float64
gyz::Float64
gxz::Float64
gxy::Float64
end

Is there anyway I can reinterpret this as a Vector{Float64} in a fast way 
without copying data. The memory of the Strain type should be exactly like 
the vector.

The reason I want to do this is because I want to i.e. be able to multiply 
a strain and a general matrix but I also want to be able to write my own 
functions for Strain.

Naively, I tried this:

julia> reinterpret(Vector{Float64}, strain)
ERROR: reinterpret: expected bits type as first argument
 in reinterpret at base.jl:65

I saw this comment in one of the issues here 
https://github.com/JuliaLang/julia/issues/5857:

"ImmutableArrays has the advantage that Array(Vector4{Int}, 10) it can be 
reinterpreted as a 4x10 matrix with reinterpret and reshape without memory 
movement (e.g. when calling a c function on the data)."


Best regards,
Kristoffer Carlsson

Re: [julia-users] Some simple use cases for multi-threading

[Viral Shah]

The multi-threading stuff is on the threading branch. There is a bunch of work 
remaining as captured on github with the multi-threading label. However, if you 
want to take a look at the current api, see the examples in 
test/perf/threads/laplace3d on the threading branch. 

Basically there is the equivalent of @parallel for now - you can annotate a 
loop with `@nthreads all` and see how it speeds up - or crashes :-)

You can control the number of threads with the JULIA_NUM_THREADS environment 
variable at startup to see how things scale with more processors.


-viral



> On 17-Mar-2015, at 2:56 pm, Jame Fairbanks  wrote:
> 
> Are there some docs on what is exposed at the user level in threading?
> Should the benchmarks be implemented in serial with information of how to 
> parallelize them so that as the parallel api develops the benchmark can be 
> parallelized according to the api? Or do you want them implemented with the 
> current processes and remote refs api?
> 
> -james
> 
> On Mar 17, 2015, at 09:49 , Viral Shah  wrote:
> 
>> I don’t know if we have the capabilities exposed at the user level to do 
>> this yet - but it is a good benchmark to have.
>> 
>> -viral
>> 
>> 
>> 
>>> On 16-Mar-2015, at 4:31 pm, James Fairbanks  wrote:
>>> 
>>> Yes I can work on that. The most important piece that I don't know how to 
>>> build in Julia is a parallel queue where many threads can append and pop in 
>>> parallel. In omp that can be implemented with atomics. 
>>> 
>>> I suppose this leads to an even simpler benchmark of the parallel queue 
>>> performance.
>>> 
>>> James
>>> 
>>> On Sun, Mar 15, 2015, 11:18 PM Viral Shah  wrote:
>>> This is a great example. If you are familiar with it, can you submit a PR? 
>>> I think it would be a great addition to our perf suite in general, and an 
>>> excellent candidate for multi-threading.
>>> 
>>> -viral
>>> 
>>> 
>>> 
 On 16-Mar-2015, at 10:22 am, James Fairbanks  wrote:
 
 The graph 500 benchmark was developed to help people benchmark machines 
 and programming environments for graph algorithms which tend to be 
 different from numerical algorithms. There is a reference implementation 
 in octave available. It should be a good example problem.
 
 http://www.graph500.org/specifications
 
 http://www.graph500.org/referencecode
>>> 
>> 
> 

Re: [julia-users] Some simple use cases for multi-threading

[Jame Fairbanks]

Are there some docs on what is exposed at the user level in threading?
Should the benchmarks be implemented in serial with information of how to 
parallelize them so that as the parallel api develops the benchmark can be 
parallelized according to the api? Or do you want them implemented with the 
current processes and remote refs api?

-james

On Mar 17, 2015, at 09:49 , Viral Shah  wrote:

> I don’t know if we have the capabilities exposed at the user level to do this 
> yet - but it is a good benchmark to have.
> 
> -viral
> 
> 
> 
>> On 16-Mar-2015, at 4:31 pm, James Fairbanks  wrote:
>> 
>> Yes I can work on that. The most important piece that I don't know how to 
>> build in Julia is a parallel queue where many threads can append and pop in 
>> parallel. In omp that can be implemented with atomics. 
>> 
>> I suppose this leads to an even simpler benchmark of the parallel queue 
>> performance.
>> 
>> James
>> 
>> On Sun, Mar 15, 2015, 11:18 PM Viral Shah  wrote:
>> This is a great example. If you are familiar with it, can you submit a PR? I 
>> think it would be a great addition to our perf suite in general, and an 
>> excellent candidate for multi-threading.
>> 
>> -viral
>> 
>> 
>> 
>>> On 16-Mar-2015, at 10:22 am, James Fairbanks  wrote:
>>> 
>>> The graph 500 benchmark was developed to help people benchmark machines and 
>>> programming environments for graph algorithms which tend to be different 
>>> from numerical algorithms. There is a reference implementation in octave 
>>> available. It should be a good example problem.
>>> 
>>> http://www.graph500.org/specifications
>>> 
>>> http://www.graph500.org/referencecode
>> 
> 

Re: [julia-users] Some simple use cases for multi-threading

[Viral Shah]

I don’t know if we have the capabilities exposed at the user level to do this 
yet - but it is a good benchmark to have.

-viral



> On 16-Mar-2015, at 4:31 pm, James Fairbanks  wrote:
> 
> Yes I can work on that. The most important piece that I don't know how to 
> build in Julia is a parallel queue where many threads can append and pop in 
> parallel. In omp that can be implemented with atomics. 
> 
> I suppose this leads to an even simpler benchmark of the parallel queue 
> performance.
> 
> James
> 
> On Sun, Mar 15, 2015, 11:18 PM Viral Shah  wrote:
> This is a great example. If you are familiar with it, can you submit a PR? I 
> think it would be a great addition to our perf suite in general, and an 
> excellent candidate for multi-threading.
> 
> -viral
> 
> 
> 
> > On 16-Mar-2015, at 10:22 am, James Fairbanks  wrote:
> >
> > The graph 500 benchmark was developed to help people benchmark machines and 
> > programming environments for graph algorithms which tend to be different 
> > from numerical algorithms. There is a reference implementation in octave 
> > available. It should be a good example problem.
> >
> > http://www.graph500.org/specifications
> >
> > http://www.graph500.org/referencecode
> 

[julia-users] Re: Julia on OpenBSD

[Mike H]

Thanks Antoine,

It's something I might work on in the future when I get some more time. It 
looks like it would take a decent amount of work patching things, but 
possible.

Cheers,
Mike

On Saturday, March 14, 2015 at 5:33:56 AM UTC-7, Antoine Jardin wrote:
>
> Hi, I have thought about it
>
> I'm currently running linux on my day to day laptop workstation but i used 
> to run openbsd.
> I'll try to find the time to run a test build.
>
> llvm is v3.5 in OpenBSD 5.6
> ggc is 4.9
> gmake is 4.0
> gfortran is 4.2
> git is 1.9
> perl is in base
> wget is in ports
> m4 is 1.4.17
> cmake is ok (2.8)
>
> patch I guess is patchutils
>
> so on paper it should work, I'm very interested in the matter
>
>
>
>
>
> Le vendredi 13 mars 2015 07:15:26 UTC+1, Mike H a écrit :
>>
>> Just curiious, has anyone out there tried building Julia on OpenBSD?
>>
>> Cheers,
>> Mike
>>
>

Re: [julia-users] Working with a custom type - questions

[Kristoffer Carlsson]

This is something I thought a lot about recently. Basically, I want to have 
the exact functionality of a concrete type and be able to call all function 
that takes the type but I also want to be able to dispatch differently if I 
want. And I don't want to manually have to copy all the methods.

In summary, dispatch on typealias.

I see this has been discussed before:

https://groups.google.com/forum/#!msg/julia-dev/v8B1tI_NB5E/tk98D0iKopYJ

https://github.com/JuliaLang/julia/pull/3292

I realize this is basically subtyping from a concrete type which seems to 
be a big nono but there would be so much nice things you could do with this.

On Tuesday, March 17, 2015 at 11:02:17 AM UTC+1, Mauro wrote:
>
> >  My thinking being that this would help avoid ambiguity with my code, as 
> I 
> > sometimes work with other units of time (e.g. seconds) that are also 
> > floating point numbers. Of course, this introduced a number of problems 
> in 
> > my existing code, including 
>
> There is also the Units.jl package, which may be of use? 
>
> >1. Arithmetic operators not defined for type JDate. My workaround for 
> >this has thus far been to overload the operators to accept JDate 
> types. 
> >2. My functions not having methods that accept time as a JDate type. 
> My 
> >workaround for this has been to change the function to accept 
> time::FloatingPoint 
> >instead of time::Float64, but this workaround does not work for 
> Arrays. 
>
> This is a only partially solved problem, as far as I know.  How do I 
> wrap a datatype without having to re-implement all its methods. 
> Sometimes this can be done through subtyping, but not always. 
>
> One approach is to use a macro to delegate methods to one of the fields 
> of the datatype: 
>
> https://github.com/JuliaLang/DataStructures.jl/search?utf8=%E2%9C%93&q=delegate
>  
> https://github.com/JuliaLang/julia/pull/3292 
>
> For relatively simple number types, as in your case here, it might be 
> better to manually hook into the "conversion and promotion" framework of 
> Julia: 
> http://docs.julialang.org/en/latest/manual/conversion-and-promotion/ 
>

[julia-users] parse() and line numbers

[cormullion]

Is there a way to prevent the generation of line numbers:

julia> jt = """for i in 1:10
   println(i)
   end
   """
"for i in 1:10\nprintln(i)\nend\n"

julia> parse(jt)
:(for i = 1:10 # line 2:   <
println(i)
end)

julia> 

or of retaining any comments that were in the string:

julia> jt = """for i in 1:10
 # printing now   <-—
 println(i)
   end
   """
 julia> parse(jt) ...

cheers

Re: [julia-users] Concatenating ArrayViews

[Tim Holy]

Not currently, but you can create your own new AbstractArray types. In this 
case, https://github.com/tanmaykm/ChainedVectors.jl
might be a good model for how to proceed.

Best,
--Tim

On Tuesday, March 17, 2015 01:35:03 AM Ján Dolinský wrote:
> Hi,
> 
> Is it possible to create a view which refers to e.g. two different matrices
> ? I am on Julia v0.36.
> 
> X = rand(1000,1000)
> Y = rand(1000,100)
> 
> @time a = view(X, :, :)
> elapsed time: 6.576e-6 seconds (184 bytes allocated)
> 
> @time b = view(Y, :, :)
> elapsed time: 5.83e-6 seconds (168 bytes allocated)
> 
> @time c = [a b]
> elapsed time: 0.080207052 seconds (8802560 bytes allocated)
> 
> a and b are apparently "views" and little memory is allocated. Is it
> possible to create a composite view which refers to X and Y at the same
> time ? Expression "[a b]" seems to create a copy of X and Y.
> 
> My motivation is that I am concatenating two matrices in a loop where the
> first one is usually fixed and the other one may have different number of
> columns at each iteration.
> 
> Thanks,
> Jan

Re: [julia-users] Working with a custom type - questions

[Mauro]

>  My thinking being that this would help avoid ambiguity with my code, as I 
> sometimes work with other units of time (e.g. seconds) that are also 
> floating point numbers. Of course, this introduced a number of problems in 
> my existing code, including

There is also the Units.jl package, which may be of use?

>1. Arithmetic operators not defined for type JDate. My workaround for 
>this has thus far been to overload the operators to accept JDate types.
>2. My functions not having methods that accept time as a JDate type. My 
>workaround for this has been to change the function to accept 
> time::FloatingPoint 
>instead of time::Float64, but this workaround does not work for Arrays.

This is a only partially solved problem, as far as I know.  How do I
wrap a datatype without having to re-implement all its methods.
Sometimes this can be done through subtyping, but not always.

One approach is to use a macro to delegate methods to one of the fields
of the datatype:
https://github.com/JuliaLang/DataStructures.jl/search?utf8=%E2%9C%93&q=delegate
https://github.com/JuliaLang/julia/pull/3292

For relatively simple number types, as in your case here, it might be
better to manually hook into the "conversion and promotion" framework of
Julia:
http://docs.julialang.org/en/latest/manual/conversion-and-promotion/

[julia-users] Concatenating ArrayViews

[Ján Dolinský]

Hi,

Is it possible to create a view which refers to e.g. two different matrices 
? I am on Julia v0.36.

X = rand(1000,1000)
Y = rand(1000,100)

@time a = view(X, :, :)
elapsed time: 6.576e-6 seconds (184 bytes allocated)

@time b = view(Y, :, :)
elapsed time: 5.83e-6 seconds (168 bytes allocated)

@time c = [a b]
elapsed time: 0.080207052 seconds (8802560 bytes allocated)

a and b are apparently "views" and little memory is allocated. Is it 
possible to create a composite view which refers to X and Y at the same 
time ? Expression "[a b]" seems to create a copy of X and Y.

My motivation is that I am concatenating two matrices in a loop where the 
first one is usually fixed and the other one may have different number of 
columns at each iteration.

Thanks,
Jan  

Re: [julia-users] Re: Uint8 arrays and deprecations in 0.4

[Kevin Squire]

On Mon, Mar 16, 2015 at 4:27 PM, J Luis  wrote:

> And another thing, why does it have to print the numbers in hexa?
>
> julia> a = Uint8[1, 255]
> 2-element Array{Uint8,1}:
>  0x01
>  0xff
>
> julia> a[2]
> 0xff
>
>
Note that if you actually *print* the number (but not the array), it will
print in decimal:

julia> println(a[2])
255

Don't we all understand better the decimal system?
>

Apparently not: https://www.youtube.com/watch?v=l4bmZ1gRqCc

Cheers!
   Kevin