Re: [julia-users] Re: Mathematical Computing course in Julia

[Daniel Carrera]

In defense of Python, I don't see why it requires OOP concepts. Python is
happy to work in a very procedural way. I started to like Python when
Python 3 became mature. They really made the language a lot more consistent
and predictable.

I agree with the rest of what you wrote. I don't criticize C; it's just
fundamentally a lower-level language. But Matlab has no excuse. There is no
good reason to require one function per file, or to not have namespaces.
But I always thought Matlab was an employable skill. I'm surprised to learn
that it isn't.

I am a PhD student. I teach a short 3-day (six hour) course on scientific
computing and Matlab for incoming students from several courses so they can
use it to do their homework. I came up with the course idea a few years ago
and it has been a big success. We had a course that required an old
custom-made tool to select stars from a catalogue. Then the students would
import the output into Matlab and make a few simple plots. I had the idea
to drop that tool and instead teach the kids how use slices and masks in
Matlab. The student performance increased dramatically, and the following
year I was asked to teach a few introductory lessons for Matlab. The
following year more teachers sent me their students.

If I was a permanent employee, I would advocate a switch from Matlab to
Julia. But this is my final year, and there is no-one else here who knows
Julia.

Cheers,
Daniel.



On 16 April 2016 at 05:22, Sheehan Olver  wrote:

> I don't think Julia's error message situation is particularly worse than C
> (where memory access bugs trigger crashes randomly)  or Mathematica (where
> many bugs end in infinite loops of symbolic computations that eat up all
> available memory).   I also think teaching in Python would be harder, since
> it requires OOP concepts.  Matlab teaches too many bad programming habits,
> hides what's going on from the students, and is not a particularly
> employable skill  (as we've been told by prospective employers).
>
> So while Julia has its quirks, I don't see another language that is
> clearly better.
>
>
> On Saturday, April 16, 2016 at 12:01:05 PM UTC+10, Peter Kovesi wrote:
>>
>>
>> Sheehan, That's a very nice looking course but I think you are very brave
>> to use Julia at this stage.
>> I love the language but (at this stage of the language's development) the
>> error reporting is highly problematic.  For example this morning I made a
>> classic mistake
>>
>> function foo(a::real) # Should have been:   function foo(a::Real)
>>  ...
>> end
>>
>> The function was defined at line 998, the error was reported at line 433,
>>  565 lines away!  The message was
>> "ERROR: LoadError: TypeError: Tuple: in parameter, expected Type{T}, got
>> Function"
>>
>> Good luck to your students!
>>
>> Working in Julia requires a practice of defensive incremental coding in
>> the extreme.  Every few lines of code that are added need to be tested
>> before carrying on.  That way you know that any errors are in the few lines
>> of code that were just added and not at whatever spurious location was
>> being suggested.
>>
>> Let me say again I love the language.  However the error reporting is a
>> source of extreme frustration to me.
>>
>> A key pathway to getting Julia more widely adopted would be for it to be
>> used for teaching purposes.  However, at the moment I fear that any attempt
>> to do so would surely end in tears.
>>
>> Peter Kovesi
>>
>>
>> On Friday, April 15, 2016 at 10:17:40 AM UTC+8, Sheehan Olver wrote:
>>>
>>>
>>>
>>> I'm currently lecturing the course MATH3076/3976 Mathematical Computing
>>> at U. Sydney in Julia, and thought that others may be interested in the
>>> resources I've provided:
>>>
>>> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>>>
>>> The lecture notes and labs are all Jupyter notebooks.  I've also
>>> included a "cheat sheet" of Julia commands used in the course
>>>
>>>
>>> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>>>
>>> The course is ongoing (it's about half through) and will continue to
>>> take shape, but any feedback is of course welcome!
>>>
>>>
>>> Sheehan Olver
>>>
>>

[julia-users] SIMD multicore

[Jason Eckstein]

I noticed in Julia 4 now if you call A+B where A and B are matrices of 
equal size, the llvm code shows vectorization indicating it is equivalent 
to if I wrote my own function with an @simd tagged for loop.  I still 
notice though that it uses a single core to maximum capacity but never 
spreads an SIMD loop out over multiple cores.  In contrast if I use BLAS 
functions like gemm! or even just A*B it will use every core of the 
processor.  I'm not sure if these linear algebra operations also use simd 
vectorization but I imagine they do since BLAS is very optimized.  Is there 
a way to write an SIMD loop that spreads the data out across all processor 
cores, not just the multiple functional units of a single core?

Re: [julia-users] Re: Mathematical Computing course in Julia

[Daniel Carrera]

On 16 April 2016 at 04:01, Peter Kovesi  wrote:

>
> Working in Julia requires a practice of defensive incremental coding in
> the extreme.  Every few lines of code that are added need to be tested
> before carrying on.  That way you know that any errors are in the few lines
> of code that were just added and not at whatever spurious location was
> being suggested.
>


I have never felt that way about Julia. I think all languages require
incremental coding (I just call this good practice) and all languages have
error messages that students find very difficult to decipher. I think
Julia's error messages are no worse than other languages; in turn, Julia's
clean and simple syntax makes it easier to get code right the first time.
You gave the example of type annotations. I consider that to be a
relatively advanced topic. Julia code works just fine without type
annotations, and only a tiny fraction of my code uses them. The error you
posted also makes for a good teaching opportunity. Yes, it will confuse the
student the first time. But you can explain what it means.



>
> Let me say again I love the language.  However the error reporting is a
> source of extreme frustration to me.
>


:-(

Can you give me an example of a language that you think has good error
reporting? I'm not saying that Julia is fabulous. I think other languages
suck too. I suspect that error reporting is an inherently difficult problem.

Cheers,
Daniel.

Re: [julia-users] Re: Mathematical Computing course in Julia

[Daniel Carrera]

Is there a way to try out your instructions on a computer where I have
previously installed IJulia and PyPlot? Or do I have to remove and re-add
IJulia and PyPlot?

If I follow these instructions, will Julia also keep Jupyter and Python
updated? (i.e. every time I run Pkg.update()). Right now I have an eclectic
mix where Python is updated with apt, Jupyter with pip3, and Julia packages
with Pkg.update().

Cheers,
Daniel.


On 15 April 2016 at 21:29, Steven G. Johnson  wrote:

> For installation, what I recommend (https://github.com/stevengj/julia-mit)
> is:
>
> ENV["PYTHON"]=""
> ENV["JUPYTER"]=""
> Pkg.add("IJulia")
> Pkg.add("PyPlot")
>
>
> That way, it will automatically download and use its own Miniconda
> installation of Python and Jupyter, regardless of what the user has on
> their machine.   Then, run Jupyter via
>
> using IJulianotebook()
>
> at the julia REPL prompt.
>
> Regarding PyPlot documentation, there is a ton of documentation out there
> for Matplotlib.  The trick is just to translate the Python syntax to
> Julia/PyCall syntax.
>

[julia-users] Re: Mathematical Computing course in Julia

[Sheehan Olver]

I don't think Julia's error message situation is particularly worse than C 
(where memory access bugs trigger crashes randomly)  or Mathematica (where 
many bugs end in infinite loops of symbolic computations that eat up all 
available memory).   I also think teaching in Python would be harder, since 
it requires OOP concepts.  Matlab teaches too many bad programming habits, 
hides what's going on from the students, and is not a particularly 
employable skill  (as we've been told by prospective employers).

So while Julia has its quirks, I don't see another language that is clearly 
better.


On Saturday, April 16, 2016 at 12:01:05 PM UTC+10, Peter Kovesi wrote:
>
>
> Sheehan, That's a very nice looking course but I think you are very brave 
> to use Julia at this stage.
> I love the language but (at this stage of the language's development) the 
> error reporting is highly problematic.  For example this morning I made a 
> classic mistake
>
> function foo(a::real) # Should have been:   function foo(a::Real)
>  ...
> end
>
> The function was defined at line 998, the error was reported at line 433, 
>  565 lines away!  The message was
> "ERROR: LoadError: TypeError: Tuple: in parameter, expected Type{T}, got 
> Function"
>
> Good luck to your students!
>
> Working in Julia requires a practice of defensive incremental coding in 
> the extreme.  Every few lines of code that are added need to be tested 
> before carrying on.  That way you know that any errors are in the few lines 
> of code that were just added and not at whatever spurious location was 
> being suggested.
>
> Let me say again I love the language.  However the error reporting is a 
> source of extreme frustration to me.
>
> A key pathway to getting Julia more widely adopted would be for it to be 
> used for teaching purposes.  However, at the moment I fear that any attempt 
> to do so would surely end in tears.
>
> Peter Kovesi
>
>
> On Friday, April 15, 2016 at 10:17:40 AM UTC+8, Sheehan Olver wrote:
>>
>>
>>
>> I'm currently lecturing the course MATH3076/3976 Mathematical Computing 
>> at U. Sydney in Julia, and thought that others may be interested in the 
>> resources I've provided:
>>
>> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>>
>> The lecture notes and labs are all Jupyter notebooks.  I've also included 
>> a "cheat sheet" of Julia commands used in the course
>>
>>
>> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>>
>> The course is ongoing (it's about half through) and will continue to take 
>> shape, but any feedback is of course welcome!
>>
>>
>> Sheehan Olver
>>
>

[julia-users] Re: Mathematical Computing course in Julia

[Peter Kovesi]

Sheehan, That's a very nice looking course but I think you are very brave 
to use Julia at this stage.
I love the language but (at this stage of the language's development) the 
error reporting is highly problematic.  For example this morning I made a 
classic mistake

function foo(a::real) # Should have been:   function foo(a::Real)
 ...
end

The function was defined at line 998, the error was reported at line 433, 
 565 lines away!  The message was
"ERROR: LoadError: TypeError: Tuple: in parameter, expected Type{T}, got 
Function"

Good luck to your students!

Working in Julia requires a practice of defensive incremental coding in the 
extreme.  Every few lines of code that are added need to be tested before 
carrying on.  That way you know that any errors are in the few lines of 
code that were just added and not at whatever spurious location was being 
suggested.

Let me say again I love the language.  However the error reporting is a 
source of extreme frustration to me.

A key pathway to getting Julia more widely adopted would be for it to be 
used for teaching purposes.  However, at the moment I fear that any attempt 
to do so would surely end in tears.

Peter Kovesi


On Friday, April 15, 2016 at 10:17:40 AM UTC+8, Sheehan Olver wrote:
>
>
>
> I'm currently lecturing the course MATH3076/3976 Mathematical Computing at 
> U. Sydney in Julia, and thought that others may be interested in the 
> resources I've provided:
>
> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>
> The lecture notes and labs are all Jupyter notebooks.  I've also included 
> a "cheat sheet" of Julia commands used in the course
>
>
> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>
> The course is ongoing (it's about half through) and will continue to take 
> shape, but any feedback is of course welcome!
>
>
> Sheehan Olver
>

[julia-users] Re: Vectorised usage of Compose

[Cedric St-Jean]

That sucks. I've noticed that one of {Firefox, IJulia, Compose} is leaking 
memory when I do Compose.jl animations, that might be part of the issue as 
well.

On Friday, April 15, 2016 at 5:37:47 PM UTC-4, Christoph Ortner wrote:
>
>
> thanks for the suggestion. Unfortunately, the ... (splat?) operator makes 
> this very slow for larger collections.
>
> Christoph
>
>
> On Friday, 15 April 2016 19:10:12 UTC+1, Cedric St-Jean wrote:
>>
>>
>>
>> On Friday, April 15, 2016 at 12:30:51 PM UTC-4, Christoph Ortner wrote:
>>>
>>> right I mean b) - I have 1000, say, line segments or polygons, each with 
>>> the same number of points. All I can do is loop, yes?
>>>
>>
>> Not a compose expert either, but I used a list comprehension to make a 
>> grid and it worked fine
>>
>> vbars(ncols, nrows) =
>> compose(context(), [compose(context(), line([(x1,0.),(x1,nrows)]))
>> for x1 in 0:1:ncols]...)
>>
>>
>>  
>>
>

Re: [julia-users] Slow eval for arrays of Any

[Yichao Yu]

On Fri, Apr 15, 2016 at 6:22 PM,   wrote:
> This I understand - thank you.
> However, as I have written in my first post eval is only an example showing
> the problem.
> The real use case is when we have some constant reference data, eg. list of
> first names that has 1 entries, and want to store it directly in Julia
> code as an array literal (and not in a separate file from which it is
> loaded).
> Then the problem arises if you include such a file.

Right, and you just shouldn't do it at all.
A programming language parser and interpreter needs to do far more
things than a data storage format and you shouldn't use one as the
other since they are not optimized for the other case.
I'm not sure what takes the most time in this case but for one thing,
you are asking the interpreter to figure out the types of the array
given all the element. This is going to be expensive. Python won't
have this problem since it doesn't have any builtin concept of typed
container (not automatically or using the syntax you have anyway...)

>
> Thank you,
> Bogumil

Re: [julia-users] Re: Mathematical Computing course in Julia

[Daniel Carrera]

On 15 April 2016 at 21:29, Steven G. Johnson  wrote:

> For installation, what I recommend (https://github.com/stevengj/julia-mit)
> is:
>


... That page is really good ... Bookmarked.

Cheers,
Daniel.

Re: [julia-users] Slow eval for arrays of Any

[bogumil . kaminski]

This I understand - thank you.
However, as I have written in my first post eval is only an example showing 
the problem.
The real use case is when we have some constant reference data, eg. list of 
first names that has 1 entries, and want to store it directly in Julia 
code as an array literal (and not in a separate file from which it is 
loaded).
Then the problem arises if you include such a file.

Thank you,
Bogumil

Re: [julia-users] Re: Mathematical Computing course in Julia

[Daniel Carrera]

Hello,

On 15 April 2016 at 21:29, Steven G. Johnson  wrote:

> For installation, what I recommend (https://github.com/stevengj/julia-mit)
> is:
>
> ENV["PYTHON"]=""
> ENV["JUPYTER"]=""
> Pkg.add("IJulia")
> Pkg.add("PyPlot")
>
>
> That way, it will automatically download and use its own Miniconda
> installation of Python and Jupyter, regardless of what the user has on
> their machine.
>


Good to know.



> Regarding PyPlot documentation, there is a ton of documentation out there
> for Matplotlib.  The trick is just to translate the Python syntax to
> Julia/PyCall syntax.
>


Yes, indeed. I usually reply on the API reference which is quite excellent;
and when I have a problem I can't solve, I usually find a ready-made
solution in Stack Overflow. It has taken me a while to learn how to
translate the Python doc to PyPlot. I guess I've been a slow learner. Some
times I entertain the thought of making a copy of the API doc and
converting it to Julia, but then I realize what a big task that would be,
and that soon the doc would be out of sync.


Cheers,
Daniel.

[julia-users] Re: Vectorised usage of Compose

[Christoph Ortner]

thanks for the suggestion. Unfortunately, the ... (splat?) operator makes 
this very slow for larger collections.

Christoph


On Friday, 15 April 2016 19:10:12 UTC+1, Cedric St-Jean wrote:
>
>
>
> On Friday, April 15, 2016 at 12:30:51 PM UTC-4, Christoph Ortner wrote:
>>
>> right I mean b) - I have 1000, say, line segments or polygons, each with 
>> the same number of points. All I can do is loop, yes?
>>
>
> Not a compose expert either, but I used a list comprehension to make a 
> grid and it worked fine
>
> vbars(ncols, nrows) =
> compose(context(), [compose(context(), line([(x1,0.),(x1,nrows)]))
> for x1 in 0:1:ncols]...)
>
>
>  
>

Re: [julia-users] Slow eval for arrays of Any

[Yichao Yu]

On Fri, Apr 15, 2016 at 3:44 PM,   wrote:
> Could someone help me to understand why the following code works slowly and
> how to make it run faster?
>
> function run()
> # this is fast
> s1 = string("x = [0", join([string(", ", i) for i in 1:256]), "]")
> p1 = parse(s1)
> @time eval(p1)
> @time eval(p1)
>
> # here starts the slow part
> s2 = string("x = ['0'", join([string(", ", i) for i in 1:128]), "]")
> p2 = parse(s2)
> @time eval(p2)
> @time eval(p2)
>
> s3 = string("x = ['0'", join([string(", ", i) for i in 1:256]), "]")
> p3 = parse(s3)
> @time eval(p3)
> @time eval(p3)
>
> s4 = string("x = ['0'", join([string(", ", i) for i in 1:192]), "]")
> p4 = parse(s4)
> @time eval(p4)
> @time eval(p4)
> println("done")
> end
>
> run()
>
> I understand that arrays of Any would evaluate slower than arrays of
> specified type but there seems to be a qualitative difference in how they
> are handled. It seems that the problem is with compilation of the code as
> after we run eval(p3) then consecutive run is fast and eval(p4) is also
> fast.
>
> The comparable code in Python:
>
> exec("x = [0"+"".join([", " + str(i) for i in range(1, 513)]) + "]")
> exec("x = ['0'"+"".join([", " + str(i) for i in range(1, 513)]) + "]")
>
> runs fast in both cases.
>
> The problem here is an artificial example. The actual situation occurred
> when I was trying to include code that constructed a long vector of strings
> consisting of ASCIIString and UTF8String entries (some of the string
> literals included code contained only ASCII characters and some did not eg.
> x = ["a", "ą"], the actual vector was much longer).

In either cases, it doesn't seems necessary to use `eval` at all,
especially not by constructing a string and parse it.
You can just push to an array directly and it would be much faster.
Calling `eval` at runtime (i.e. not when you are construction a
module) is always a bad idea especially for performance.

>
> Thank you,
> Bogumił

[julia-users] Re: Slow eval for arrays of Any

[bogumil . kaminski]

I have just found that adding the following type annotation solves the 
problem:

s3 = string("x = Any['0'", join([string(", ", i) for i in 1:256]), "]")

but I do not understand exactly why (it seems that the core reason is how 
Julia handles map on tuples but I am not sure why adding Any annotation 
changes the situation).

Thank you,
Bogumił

On Friday, April 15, 2016 at 9:44:58 PM UTC+2, bogumil@gmail.com wrote:
>
> Could someone help me to understand why the following code works slowly 
> and how to make it run faster?
>
> function run()
> # this is fast
> s1 = string("x = [0", join([string(", ", i) for i in 1:256]), "]")
> p1 = parse(s1)
> @time eval(p1)
> @time eval(p1)
>
> # here starts the slow part
> s2 = string("x = ['0'", join([string(", ", i) for i in 1:128]), "]")
> p2 = parse(s2)
> @time eval(p2)
> @time eval(p2)
>
> s3 = string("x = ['0'", join([string(", ", i) for i in 1:256]), "]")
> p3 = parse(s3)
> @time eval(p3)
> @time eval(p3)
>
> s4 = string("x = ['0'", join([string(", ", i) for i in 1:192]), "]")
> p4 = parse(s4)
> @time eval(p4)
> @time eval(p4)
> println("done")
> end
>
> run()
>
> I understand that arrays of Any would evaluate slower than arrays of 
> specified type but there seems to be a qualitative difference in how they 
> are handled. It seems that the problem is with compilation of the code as 
> after we run eval(p3) then consecutive run is fast and eval(p4) is also 
> fast.
>
> The comparable code in Python:
>
> exec("x = [0"+"".join([", " + str(i) for i in range(1, 513)]) + "]")
> exec("x = ['0'"+"".join([", " + str(i) for i in range(1, 513)]) + "]")
>
> runs fast in both cases.
>
> The problem here is an artificial example. The actual situation occurred 
> when I was trying to include code that constructed a long vector of 
> strings consisting of ASCIIString and UTF8String entries (some of the 
> string literals included code contained only ASCII characters and some did 
> not eg. x = ["a", "ą"], the actual vector was much longer).
>
> Thank you,
> Bogumił
>

[julia-users] Slow eval for arrays of Any

[bogumil . kaminski]

Could someone help me to understand why the following code works slowly and 
how to make it run faster?

function run()
# this is fast
s1 = string("x = [0", join([string(", ", i) for i in 1:256]), "]")
p1 = parse(s1)
@time eval(p1)
@time eval(p1)

# here starts the slow part
s2 = string("x = ['0'", join([string(", ", i) for i in 1:128]), "]")
p2 = parse(s2)
@time eval(p2)
@time eval(p2)

s3 = string("x = ['0'", join([string(", ", i) for i in 1:256]), "]")
p3 = parse(s3)
@time eval(p3)
@time eval(p3)

s4 = string("x = ['0'", join([string(", ", i) for i in 1:192]), "]")
p4 = parse(s4)
@time eval(p4)
@time eval(p4)
println("done")
end

run()

I understand that arrays of Any would evaluate slower than arrays of 
specified type but there seems to be a qualitative difference in how they 
are handled. It seems that the problem is with compilation of the code as 
after we run eval(p3) then consecutive run is fast and eval(p4) is also 
fast.

The comparable code in Python:

exec("x = [0"+"".join([", " + str(i) for i in range(1, 513)]) + "]")
exec("x = ['0'"+"".join([", " + str(i) for i in range(1, 513)]) + "]")

runs fast in both cases.

The problem here is an artificial example. The actual situation occurred 
when I was trying to include code that constructed a long vector of strings 
consisting of ASCIIString and UTF8String entries (some of the string 
literals included code contained only ASCII characters and some did not eg. x 
= ["a", "ą"], the actual vector was much longer).

Thank you,
Bogumił

Re: [julia-users] Re: Mathematical Computing course in Julia

[Steven G. Johnson]

On Friday, April 15, 2016 at 3:27:57 PM UTC-4, Daniel Carrera wrote:
>
> Can you explain that? Is someone going to fund Julia if JuliaBox is used 
> for education?
>

Julia gets donations (via NumFocus) that are used to support JuliaBox and 
other activities (e.g. JuliaCon).   It helps to get funding if you can 
advertise to the sponsors that JuliaBox is enabling exciting new 
educational work. 

Re: [julia-users] Re: Mathematical Computing course in Julia

[Steven G. Johnson]

For installation, what I recommend (https://github.com/stevengj/julia-mit) 
is:

ENV["PYTHON"]=""
ENV["JUPYTER"]=""
Pkg.add("IJulia")
Pkg.add("PyPlot")


That way, it will automatically download and use its own Miniconda 
installation of Python and Jupyter, regardless of what the user has on 
their machine.   Then, run Jupyter via

using IJulianotebook()

at the julia REPL prompt.

Regarding PyPlot documentation, there is a ton of documentation out there 
for Matplotlib.  The trick is just to translate the Python syntax to 
Julia/PyCall syntax.

Re: [julia-users] Re: Mathematical Computing course in Julia

[Daniel Carrera]

Can you explain that? Is someone going to fund Julia if JuliaBox is used
for education?

On 15 April 2016 at 21:09, Zheng Wendell  wrote:

> By the way, if you use JuliaBox for your teaching. Don't forget to
> announce it to the Julia team, so that they can get more funding to
> maintain it.
>
> Disclaimer: I have no relation with the Julia team.
>
>
>
> On Fri, Apr 15, 2016 at 8:50 PM, Daniel Carrera
>

Re: [julia-users] Re: Mathematical Computing course in Julia

[Zheng Wendell]

By the way, if you use JuliaBox for your teaching. Don't forget to announce
it to the Julia team, so that they can get more funding to maintain it.

Disclaimer: I have no relation with the Julia team.



On Fri, Apr 15, 2016 at 8:50 PM, Daniel Carrera

Re: [julia-users] Re: Mathematical Computing course in Julia

[Daniel Carrera]

I haven't tried with students, but I tried to get Jupyter setup on a
Macbook for a researcher who was very keen on using it (he is a strong
advocate of R) and after an hour or two we sort of gave up. We struggled
with online documentation that was often inconsistent, incorrect, or
incomplete. We found several installation tutorials online and we couldn't
any of them to work. He later went back to it and eventually got it
working, but no thanks to me. Sorry I cannot give a detailed report. This
was half a year ago and I don't remember the details.

I had forgotten about JuliaBox. Now that you mention it, that should be a
very good option.

As for jupyterhub, I honestly had not heard of it until you mentioned it
just now. The website says that it's a multi-user server. I definitely
don't want to go down that route. I wouldn't want to be responsible for
running a server where students are supposed to do their work. But I think
JuliaBox is probably a good option. I guess my thoughts of Jupyter were
tainted by the experience with the Macbook and R.

Cheers,
Daniel.

On 15 April 2016 at 17:39, Cedric St-Jean  wrote:

>
>
> On Friday, April 15, 2016 at 9:12:21 AM UTC-4, Daniel Carrera wrote:
>>
>> Cool stuff!
>>
>>  From my point of view, the biggest obstacle is that Jupyter is not easy
>> to install for most people,
>>
>
> I'm surprised to read that. Any issue in particular? Between Anaconda,
> jupyterhub and JuliaBox, there's a lot of possibilities out there. How are
> your students set up?
>
>
>> and PyPlot doesn't have much documentation. I keep telling myself that
>> I'll add documentation for PyPlot but somehow I never seem to find the time.
>>
>> Cheers,
>> Daniel.
>>
>>
>> On Friday, 15 April 2016 04:17:40 UTC+2, Sheehan Olver wrote:
>>>
>>>
>>>
>>> I'm currently lecturing the course MATH3076/3976 Mathematical Computing
>>> at U. Sydney in Julia, and thought that others may be interested in the
>>> resources I've provided:
>>>
>>> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>>>
>>> The lecture notes and labs are all Jupyter notebooks.  I've also
>>> included a "cheat sheet" of Julia commands used in the course
>>>
>>>
>>> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>>>
>>> The course is ongoing (it's about half through) and will continue to
>>> take shape, but any feedback is of course welcome!
>>>
>>>
>>> Sheehan Olver
>>>
>>

[julia-users] asynchronous reading from file

[pevnak]

Hi All,
I would like to implement an asynchronous reading from file.

I am doing stochastic gradient descend and while I am doing the 
optimisation, I would like to load the data on the background. Since 
reading of the data is followed by a quite complicated parsing, it is not 
just simple IO operation that can be done without CPU cycles.

the skeleton of my current implementation looks like this

rr = RemoteChannel()
@async put!(rr, remotecall_fetch(loaddata,2)

  for ii in 1:maxiter
#do some steps of the gradient descend

   #check if the data are ready and schedule next reading
if isready(rr)
  append!(dss[1],take!(rr));
@async put!(rr, remotecall_fetch(loaddata,2)
 end
   end


nevertheless the isready(rr) always returns false, which looks like that 
the data are never loaded.

I start the julia as julia -p 2, therefore I expect there will be a 
processor.

Can anyone explain me please, what am I doing wrong?
Thank you very much.

Tomas

[julia-users] Re: Vectorised usage of Compose

[Cedric St-Jean]

On Friday, April 15, 2016 at 12:30:51 PM UTC-4, Christoph Ortner wrote:
>
> right I mean b) - I have 1000, say, line segments or polygons, each with 
> the same number of points. All I can do is loop, yes?
>

Not a compose expert either, but I used a list comprehension to make a grid 
and it worked fine

vbars(ncols, nrows) =
compose(context(), [compose(context(), line([(x1,0.),(x1,nrows)]))
for x1 in 0:1:ncols]...)


 

>
> Thanks,
>  Christoph
>
>
>
> you are saying this is currently not implemented, I just have to 
>
> On Friday, 15 April 2016 17:12:46 UTC+1, Andreas Lobinger wrote:
>>
>> Hello colleague,
>>
>> On Friday, April 15, 2016 at 5:17:29 PM UTC+2, Christoph Ortner wrote:
>>>
>>> I understand from the example 
>>> how to vectorise drawing of circles. 
>>>
>>> The syntax for a two-point line segment seems to beline( [(x0, y0), 
>>> (x1, y1)] ) I don't see an analogy with `circle`?
>>>
>>> But how do I vectorise lines? 
>>>
>>
>> what is your meaning of 'vectorise lines'? 
>> a) have lines with more points -> 
>> compose(context(),line([(0.4,0.3),(0.6,0.2),(0.6,0.4)])); you just add 
>> tuples in the array
>> b) have more lines in the same primitive -> looks like, you need a new 
>> context for that.
>>
>>

[julia-users] Re: Compose Plotting from REPL

[Andreas Lobinger]

On Friday, April 15, 2016 at 6:35:15 PM UTC+2, Christoph Ortner wrote:
>
> many tanks for this - that looks perfect.
>
>  unfortunately my Gtk installation seems broken, so it will be a while 
> until I can try this out.
>

_
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.4-pre+218 (2016-01-29 21:53 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 386d77b* (76 days old release-0.4)
|__/   |  x86_64-linux-gnu

julia> using Tk

julia> using Compose

julia> w = Tk.Window("a-title",100,200);

julia> c = Tk.Canvas(w, 100,200);

julia> Tk.pack(c, expand = true, fill = "both")
""

julia> function sierpinski(n)
   if n == 0
   compose(context(), polygon([(1,1), (0,1), (1/2, 0)]))
   else
   t = sierpinski(n - 1)
   compose(context(),
   (context(1/4,   0, 1/2, 1/2), t),
   (context(  0, 1/2, 1/2, 1/2), t),
   (context(1/2, 1/2, 1/2, 1/2), t))
   end
   end
sierpinski (generic function with 1 method)

julia> co = sierpinski(3);

julia> Compose.draw(CAIROSURFACE(c.back),co)

julia> Tk.draw(c)

is not self-updating (i'm really no tk expert (anymore)) and you need to do 
all drawing i.e. providing an empty background but at least you get 
something on screen. As Winston ws longer time Tk only, there should be 
signal handling code.

Re: [julia-users] Failed process

[phiroc]

It worked. Than you.

Le vendredi 15 avril 2016 17:39:12 UTC+2, Michele Zaffalon a écrit :
>
> Changing the global git config used to work: 
> https://groups.google.com/d/msg/julia-users/nI7CgwGEd3A/AUZ-10J_04cJ
>
>
> On Fri, Apr 15, 2016 at 9:49 AM,  wrote:
>
>>
>> Hello,
>>
>> I have installed Julia 0.4.5 on Windows 7.
>>
>> When I run *Pkg.init(),* I get the following error message:
>>
>>
>> julia> Pkg.init()
>> INFO: Initializing package repository D:\users\myname\.julia\v0.4
>> INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
>> fatal: unable to connect to github.com:
>> github.com[0: 192.30.252.121]: errno=No error
>>
>> ERROR: failed process: Process(`git clone -q -b metadata-v2 git://
>> github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) [128]
>>  in run at process.jl:531
>>
>>
>>
>> Here's my version info:
>>
>> julia> versioninfo()
>> Julia Version 0.4.5
>> Commit 2ac304d (2016-03-18 00:58 UTC)
>> Platform Info:
>>   System: Windows (x86_64-w64-mingw32)
>>   CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>>   LAPACK: libopenblas64_
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.3
>>
>>
>>
>> Any help would be much appreciated.
>>
>> Philippe
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

[julia-users] Seeking Maintainer for Bokeh.jl

[Bryan Van de ven]

Hi all,

My name is Bryan Van de Ven, I lead the technical effort on the Bokeh 
visualization project:

http://bokeh.pydata.org/en/latest/index.html

https://github.com/bokeh/bokeh

One of the nice aspects of Bokeh is that the browser client library BokehJS 
is driven by a declarative JSON protocol, so that in principle any language 
can drive Bokeh plots and apps in the browser. At Continuum, we have 
invested heavily in the Python 'bindings" for Bokeh, but there is also 
RBokeh (maintained by Ryan Hafen) and bokeh.scala (maintained by Mateusz 
Paprocki) as well as a new TypeScript API. Early on, however, the first new 
language binding for Bokeh was Julia! This was started by Samuel Colvin 
with later work done by Spencer Lyon. However, neither of them have the 
ability to continue maintaining, which is why I am writing this message. 
You can see the last state of Bokeh.jl here:

http://bokeh.github.io/Bokeh.jl/

https://github.com/bokeh/Bokeh.jl

Although this is actually based on a quite old version, I think it is still 
very impressive. But Bokeh has progressed tremendously since then, and I 
think it would be amazing to see Bokeh.jl picked up again. I think with 
some work, it could even be possible to have Julia directly drive the new 
and very much improved Bokeh Server Apps, such as the ones here that are 
driven by Python:

http://demo.bokehplots.com/

I should mention that the main Bokeh project is headed for a 1.0 release 
later this year, with guarantees about compatibility and APIs, etc. so the 
task of maintaining Bokeh.jl should only get simpler (or perhaps even 
automatable to a larger degree) over time. 

If you would like to see its Bokeh's visualization capabilities made 
available in Julia, and are looking for an OSS project to get involved 
with, please don't hesitate to message me directly, or to reach out on the 
main Bokeh mailing list:

https://groups.google.com/a/continuum.io/forum/?pli=1#!forum/bokeh

Best regards, 

Bryan Van de Ven
Continuum Analytics

[julia-users] Re: Vectorised usage of Compose

[Andreas Lobinger]

Hello colleague,

On Friday, April 15, 2016 at 6:30:51 PM UTC+2, Christoph Ortner wrote:
>
> right I mean b) - I have 1000, say, line segments or polygons, each with 
> the same number of points. All I can do is loop, yes?
>
> Thanks,
>  Christoph
>
>
>
> you are saying this is currently not implemented, I just have to 
>

? 

I'm really not an Compose expert, you might look into Gadfly/form.jl how 
e.g. Geom.line plots are build.
If you need 'raw' drawing, looking into Cairo or 
https://github.com/cormullion/Luxor.jl or 
https://github.com/andrewcooke/Drawing.jl

[julia-users] Re: Compose Plotting from REPL

[Christoph Ortner]

many tanks for this - that looks perfect.

 unfortunately my Gtk installation seems broken, so it will be a while 
until I can try this out.

Christoph


On Friday, 15 April 2016 15:42:45 UTC+1, Andreas Lobinger wrote:
>
> Hello colleague,
>
> On Friday, April 15, 2016 at 4:00:34 PM UTC+2, Christoph Ortner wrote:
>>
>>
>> I am trying to use Compose.jl directly instead of going through a 
>> plotting package. From iPython notebooks invoking compose will immediately 
>> create the output. 
>>
>> But when I am in the REPL, how do I plot to a window, similar as in 
>> PyPlot?
>>
>
>  the following works on my REPL with Gtk, and Compose (incl. Cairo):
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.4.4-pre+218 (2016-01-29 21:53 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit 386d77b* (76 days old release-0.4)
> |__/   |  x86_64-linux-gnu
>
> julia> using Gtk
>
> julia> c = Gtk.@GtkCanvas(400,300);
>
> julia> w = Gtk.@GtkWindow(c,"data win");
>
> julia> show(c);
>
> julia> using Compose
> WARNING: using Compose.w in module Main conflicts with an existing 
> identifier.
>
> julia> function sierpinski(n)
>if n == 0
>compose(context(), polygon([(1,1), (0,1), (1/2, 0)]))
>else
>t = sierpinski(n - 1)
>compose(context(),
>(context(1/4,   0, 1/2, 1/2), t),
>(context(  0, 1/2, 1/2, 1/2), t),
>(context(1/2, 1/2, 1/2, 1/2), t))
>end
>end
> sierpinski (generic function with 1 method)
>
> julia> co = sierpinski(3);
>
> julia> Gtk.draw(c) do widget
>Compose.draw(CAIROSURFACE(c.back),co)
>end
>
> julia> co = sierpinski(5);
>
> julia> co = sierpinski(2);
>
> julia> Gtk.draw(c)
>
>
>- I use GtkCanvas and a Window around it.
>- Then the sierpinski demo from the Compose Readme, with the Compose 
>context as output.
>- Then i connect Gtk.draw function for c (=GtkCanvas) with the 
>Compose.draw function drawing to CAIROSURFACE as backend and use the 
> c.back 
>- which is something like a Cairo surface (actually it's a pointer to a 
>Cairo context, but the surface can be reconstructed with that).
>- The drawing (co) is redrawn everytime there is an expose signal from 
>the window to the canvas, usually when you resize or map the window. You 
>can call Gtk.draw(c) manually if you updated the co.
>
> Should work with standard Gtk and Compose (please report if not, i might 
> need some PR then).
>
>
>

[julia-users] Re: Vectorised usage of Compose

[Christoph Ortner]

right I mean b) - I have 1000, say, line segments or polygons, each with 
the same number of points. All I can do is loop, yes?

Thanks,
 Christoph



you are saying this is currently not implemented, I just have to 

On Friday, 15 April 2016 17:12:46 UTC+1, Andreas Lobinger wrote:
>
> Hello colleague,
>
> On Friday, April 15, 2016 at 5:17:29 PM UTC+2, Christoph Ortner wrote:
>>
>> I understand from the example 
>> how to vectorise drawing of circles. 
>>
>> The syntax for a two-point line segment seems to beline( [(x0, y0), 
>> (x1, y1)] ) I don't see an analogy with `circle`?
>>
>> But how do I vectorise lines? 
>>
>
> what is your meaning of 'vectorise lines'? 
> a) have lines with more points -> 
> compose(context(),line([(0.4,0.3),(0.6,0.2),(0.6,0.4)])); you just add 
> tuples in the array
> b) have more lines in the same primitive -> looks like, you need a new 
> context for that.
>
>

Re: [julia-users] Re: PyCall exception.jl's pycheckv - hidden exceptions or is it normal for that to take some time?

[Isaiah Norton]

>
> Aha - it makes complete sense that the Python workload would show up
> somewhere in the profiler. I suppose I wasn't expecting it in exception.jl,
> but if that is where the work happens that is fine.


It's an artifact of macro expansion not tracking where the expanded code
came from (fortunately there are a number of improvements in this area
coming in 0.5).

On Fri, Apr 15, 2016 at 11:47 AM, Tim Wheeler 
wrote:

> Aha - it makes complete sense that the Python workload would show up
> somewhere in the profiler. I suppose I wasn't expecting it in exception.jl,
> but if that is where the work happens that is fine.
> I'm copying the results from TF into my memory - if TF doesn't create new
> ones every time I can just retain handles to those but I haven't checked
> whether that is the case.
> Thank you for your advice!
>
>

[julia-users] Re: Vectorised usage of Compose

[Andreas Lobinger]

Hello colleague,

On Friday, April 15, 2016 at 5:17:29 PM UTC+2, Christoph Ortner wrote:
>
> I understand from the example 
> how to vectorise drawing of circles. 
>
> The syntax for a two-point line segment seems to beline( [(x0, y0), 
> (x1, y1)] ) I don't see an analogy with `circle`?
>
> But how do I vectorise lines? 
>

what is your meaning of 'vectorise lines'? 
a) have lines with more points -> 
compose(context(),line([(0.4,0.3),(0.6,0.2),(0.6,0.4)])); you just add 
tuples in the array
b) have more lines in the same primitive -> looks like, you need a new 
context for that.

Re: [julia-users] How to change REPL mode on startup?

[Keno Fischer]

You can call REPL.setup_inferface yourself and add your own REPL mode. You
can also look at
https://github.com/JuliaLang/julia/blob/master/base/client.jl to see how
the active_repl gets created.

On Fri, Apr 15, 2016 at 9:16 AM,  wrote:

> I have a REPL mode for an application:
> https://github.com/jlapeyre/SJulia.jl/blob/master/src/sjulia_repl.jl
>
> I start julia in a terminal,  load the package with 'using SJulia', and
> then press '=' to enter the alternative mode.  This works fine.
>
> I would like to do this in one step. e.g.  enter 'sjulia' in a terminal
> and then start in the alternative mode. Problems are:
>
> 1. I have to execute a julia function to start the REPL mode 'after' the
> REPL starts and I see the julia prompt. Otherwise there is no active REPL.
> Using .juliarc.jl or julia -e apparently loads and runs code before
> starting the REPL.  I would like the alternative REPL mode to be created
> without entering anything at the julia prompt.
>
> 2. Once I create the alternative REPL, I am still in the standard julia
> REPL mode. To switch to the alternative mode, I enter '='. I would like to
> enter this mode automatically. There is a function Base.LineEdit.transition
> that seems to do this. But, it takes a data structure (of type
> Base.LineEdit.MIState' ) as an argument that I don't know how to get at.  I
> can probably find it buried somewhere in Base.active_repl, but, I have not
> been able to so far.
>
> -John
>

[julia-users] Re: PyCall exception.jl's pycheckv - hidden exceptions or is it normal for that to take some time?

[Tim Wheeler]

Aha - it makes complete sense that the Python workload would show up 
somewhere in the profiler. I suppose I wasn't expecting it in exception.jl, 
but if that is where the work happens that is fine.
I'm copying the results from TF into my memory - if TF doesn't create new 
ones every time I can just retain handles to those but I haven't checked 
whether that is the case.
Thank you for your advice!

Re: [julia-users] Re: Mathematical Computing course in Julia

[Sheehan Olver]

Pkg.add(“IJulia”)

works on a mac, then

using IJulia
@async notebook()


> On 16 Apr 2016, at 1:39 AM, Cedric St-Jean  wrote:
> 
> 
> 
> On Friday, April 15, 2016 at 9:12:21 AM UTC-4, Daniel Carrera wrote:
> Cool stuff!
> 
>  From my point of view, the biggest obstacle is that Jupyter is not easy to 
> install for most people,
> 
> I'm surprised to read that. Any issue in particular? Between Anaconda, 
> jupyterhub and JuliaBox, there's a lot of possibilities out there. How are 
> your students set up?
>  
> and PyPlot doesn't have much documentation. I keep telling myself that I'll 
> add documentation for PyPlot but somehow I never seem to find the time.
> 
> Cheers,
> Daniel.
> 
> 
> On Friday, 15 April 2016 04:17:40 UTC+2, Sheehan Olver wrote:
> 
> 
> I'm currently lecturing the course MATH3076/3976 Mathematical Computing at U. 
> Sydney in Julia, and thought that others may be interested in the resources 
> I've provided:
> 
> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/ 
> 
> 
> The lecture notes and labs are all Jupyter notebooks.  I've also included a 
> "cheat sheet" of Julia commands used in the course
> 
> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>  
> 
> 
> The course is ongoing (it's about half through) and will continue to take 
> shape, but any feedback is of course welcome!
> 
> 
> Sheehan Olver

[julia-users] Re: Mathematical Computing course in Julia

[Cedric St-Jean]

On Friday, April 15, 2016 at 9:12:21 AM UTC-4, Daniel Carrera wrote:
>
> Cool stuff!
>
>  From my point of view, the biggest obstacle is that Jupyter is not easy 
> to install for most people,
>

I'm surprised to read that. Any issue in particular? Between Anaconda, 
jupyterhub and JuliaBox, there's a lot of possibilities out there. How are 
your students set up?
 

> and PyPlot doesn't have much documentation. I keep telling myself that 
> I'll add documentation for PyPlot but somehow I never seem to find the time.
>
> Cheers,
> Daniel.
>
>
> On Friday, 15 April 2016 04:17:40 UTC+2, Sheehan Olver wrote:
>>
>>
>>
>> I'm currently lecturing the course MATH3076/3976 Mathematical Computing 
>> at U. Sydney in Julia, and thought that others may be interested in the 
>> resources I've provided:
>>
>> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>>
>> The lecture notes and labs are all Jupyter notebooks.  I've also included 
>> a "cheat sheet" of Julia commands used in the course
>>
>>
>> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>>
>> The course is ongoing (it's about half through) and will continue to take 
>> shape, but any feedback is of course welcome!
>>
>>
>> Sheehan Olver
>>
>

Re: [julia-users] Failed process

[Michele Zaffalon]

Changing the global git config used to work:
https://groups.google.com/d/msg/julia-users/nI7CgwGEd3A/AUZ-10J_04cJ


On Fri, Apr 15, 2016 at 9:49 AM,  wrote:

>
> Hello,
>
> I have installed Julia 0.4.5 on Windows 7.
>
> When I run *Pkg.init(),* I get the following error message:
>
>
> julia> Pkg.init()
> INFO: Initializing package repository D:\users\myname\.julia\v0.4
> INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
> fatal: unable to connect to github.com:
> github.com[0: 192.30.252.121]: errno=No error
>
> ERROR: failed process: Process(`git clone -q -b metadata-v2 git://
> github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) [128]
>  in run at process.jl:531
>
>
>
> Here's my version info:
>
> julia> versioninfo()
> Julia Version 0.4.5
> Commit 2ac304d (2016-03-18 00:58 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
>
>
> Any help would be much appreciated.
>
> Philippe
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[julia-users] Vectorised usage of Compose

[Christoph Ortner]

I understand from the example 

compose(context(),
circle([0.25, 0.5, 0.75], [0.25, 0.5, 0.75], [0.1]),
fill(LCHab(92, 10, 77)))

how to vectorise drawing of circles. 

The syntax for a two-point line segment seems to beline( [(x0, y0), 
(x1, y1)] ) I don't see an analogy with `circle`?

But how do I vectorise lines? 

Thank you,
Christoph

[julia-users] Re: Compose Plotting from REPL

[Andreas Lobinger]

Hello colleague,

On Friday, April 15, 2016 at 4:00:34 PM UTC+2, Christoph Ortner wrote:
>
>
> I am trying to use Compose.jl directly instead of going through a plotting 
> package. From iPython notebooks invoking compose will immediately create 
> the output. 
>
> But when I am in the REPL, how do I plot to a window, similar as in PyPlot?
>

 the following works on my REPL with Gtk, and Compose (incl. Cairo):

   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.4-pre+218 (2016-01-29 21:53 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 386d77b* (76 days old release-0.4)
|__/   |  x86_64-linux-gnu

julia> using Gtk

julia> c = Gtk.@GtkCanvas(400,300);

julia> w = Gtk.@GtkWindow(c,"data win");

julia> show(c);

julia> using Compose
WARNING: using Compose.w in module Main conflicts with an existing 
identifier.

julia> function sierpinski(n)
   if n == 0
   compose(context(), polygon([(1,1), (0,1), (1/2, 0)]))
   else
   t = sierpinski(n - 1)
   compose(context(),
   (context(1/4,   0, 1/2, 1/2), t),
   (context(  0, 1/2, 1/2, 1/2), t),
   (context(1/2, 1/2, 1/2, 1/2), t))
   end
   end
sierpinski (generic function with 1 method)

julia> co = sierpinski(3);

julia> Gtk.draw(c) do widget
   Compose.draw(CAIROSURFACE(c.back),co)
   end

julia> co = sierpinski(5);

julia> co = sierpinski(2);

julia> Gtk.draw(c)


   - I use GtkCanvas and a Window around it.
   - Then the sierpinski demo from the Compose Readme, with the Compose 
   context as output.
   - Then i connect Gtk.draw function for c (=GtkCanvas) with the 
   Compose.draw function drawing to CAIROSURFACE as backend and use the c.back 
   - which is something like a Cairo surface (actually it's a pointer to a 
   Cairo context, but the surface can be reconstructed with that).
   - The drawing (co) is redrawn everytime there is an expose signal from 
   the window to the canvas, usually when you resize or map the window. You 
   can call Gtk.draw(c) manually if you updated the co.

Should work with standard Gtk and Compose (please report if not, i might 
need some PR then).

Re: [julia-users] Re: Parametric types which add or delete fields.

[Tim Holy]

Your best bet is always to benchmark. Here's how I make such decisions:

# The type-based system:
julia> immutable Container1{T}
   val::T
   end

julia> inc(::Int) = 1
inc (generic function with 1 method)

julia> inc(::Float64) = 2
inc (generic function with 2 methods)

julia> inc(::UInt8) = 3
inc (generic function with 3 methods)

julia> vec = [Container1(1), Container1(1.0), Container1(0x01)]
3-element Array{Container1{T},1}:
 Container1{Int64}(1)
 Container1{Float64}(1.0)
 Container1{UInt8}(0x01) 

julia> function loop_inc1(vec, n)
   s = 0
   for k = 1:n
   for item in vec
   s += inc(item.val)
   end
   end
   s
   end
loop_inc1 (generic function with 1 method)

# The dictionary solution
julia> immutable Container2
   code::Symbol
   end

julia> vec2 = [Container2(:Int), Container2(:Float64), Container2(:UInt8)]
3-element Array{Container2,1}:
 Container2(:Int)
 Container2(:Float64)
 Container2(:UInt8)  

julia> dct = Dict(:Int=>1, :Float64=>2, :UInt8=>3)
Dict(:Int=>1,:UInt8=>3,:Float64=>2)

julia> function loop_inc2(vec, dct, n)
   s = 0
   for k = 1:n
   for item in vec
   s += dct[item.code]
   end
   end
   s
   end
loop_inc2 (generic function with 1 method)

# The switch solution
julia> function loop_inc3(vec, n)
   s = 0
   for k = 1:n
   for item in vec
   if item.code == :Int
   s += 1
   elseif item.code == :Float64
   s += 2
   elseif item.code == :UInt8
   s += 3
   else
   error("Unrecognized code")
   end
   end
   end
   s
   end

loop_inc3 (generic function with 1 method)

julia> loop_inc1(vec, 1)
6

julia> loop_inc2(vec2, dct, 1)
6

julia> loop_inc3(vec2, 1)
6

julia> @time loop_inc1(vec, 10^4)
  0.002274 seconds (10.17 k allocations: 167.025 KB)
6

julia> @time loop_inc1(vec, 10^5)
  0.025834 seconds (100.01 k allocations: 1.526 MB)
60

julia> @time loop_inc2(vec2, dct, 10^5)
  0.010278 seconds (6 allocations: 192 bytes)
60

julia> @time loop_inc3(vec2, 10^5)
  0.001561 seconds (6 allocations: 192 bytes)
60


So in terms of run time, the bottom line is:
- The "switch" version is fastest (by quite a lot), but ugly.
- The dictionary is intermediate. You would likely be able to do even better 
with a "perfect hash" dictionary, see 
http://stackoverflow.com/questions/36385653/return-const-dictionary
- The type-based solution is slowest, but not much worse than the dictionary.

Note that none of this analysis includes compilation time. If you're writing a 
large system, the type-based one in particular will require longer JIT times, 
whereas the first two get by with only a single type and hence will need much 
less compilation.

Of course, if `inc` were a complicated function, it might change the entire 
calculus here. That's really the key: what's the tradeoff between the amount of 
computation per element and the price you pay for dispatch to a type-
specialized method? There is no universal answer to this question.

Best,
--Tim

[julia-users] Re: Help with MXNet AssertionError: get_batch_size(opts.eval_data) == batch_size

[Iain Dunning]

Try filing an issue on the MXNet.jl repository - the developers might not 
(probably don't) read this list.

On Friday, April 15, 2016 at 9:47:46 AM UTC-4, kleinsplash wrote:
>
> still having this issue - any ideas?
>
> On Monday, 11 April 2016 15:58:03 UTC+2, kleinsplash wrote:
>>
>> $ julia G3DB_cnn.jl 
>> (128,128,1,800)
>> (128,128,1,200)
>> INFO: Start training on [GPU0]
>> INFO: Initializing parameters...
>> INFO: Creating KVStore...
>> INFO: Start training...
>> INFO: == Epoch 001 ==
>> INFO: ## Training summary
>> INFO:   accuracy = 0.5638
>> INFO:   time = 1.9078 seconds
>> ERROR: LoadError: AssertionError: get_batch_size(opts.eval_data) == 
>> batch_size
>>  in fit at /home/ashley/.julia/v0.4/MXNet/src/model.jl:482
>>  in include at ./boot.jl:261
>>  in include_from_node1 at ./loading.jl:304
>>  in process_options at ./client.jl:280
>>  in _start at ./client.jl:378
>>
>>
>> Could someone help me understand the above? I dont have many data so my 
>> batch_size is 0. Trying to get to the predicted values.. 
>>
>> Thx
>>
>

[julia-users] Re: Help with MXNet AssertionError: get_batch_size(opts.eval_data) == batch_size

[Iain Dunning]

Try filing an issue on the MXNet.jl repository - the developers might not 
(probably don't) read this list.

On Friday, April 15, 2016 at 9:47:46 AM UTC-4, kleinsplash wrote:
>
> still having this issue - any ideas?
>
> On Monday, 11 April 2016 15:58:03 UTC+2, kleinsplash wrote:
>>
>> $ julia G3DB_cnn.jl 
>> (128,128,1,800)
>> (128,128,1,200)
>> INFO: Start training on [GPU0]
>> INFO: Initializing parameters...
>> INFO: Creating KVStore...
>> INFO: Start training...
>> INFO: == Epoch 001 ==
>> INFO: ## Training summary
>> INFO:   accuracy = 0.5638
>> INFO:   time = 1.9078 seconds
>> ERROR: LoadError: AssertionError: get_batch_size(opts.eval_data) == 
>> batch_size
>>  in fit at /home/ashley/.julia/v0.4/MXNet/src/model.jl:482
>>  in include at ./boot.jl:261
>>  in include_from_node1 at ./loading.jl:304
>>  in process_options at ./client.jl:280
>>  in _start at ./client.jl:378
>>
>>
>> Could someone help me understand the above? I dont have many data so my 
>> batch_size is 0. Trying to get to the predicted values.. 
>>
>> Thx
>>
>

[julia-users] Failed process

[phiroc]

Hello,

I have installed Julia 0.4.5 on Windows 7.

When I run *Pkg.init(),* I get the following error message:


julia> Pkg.init()
INFO: Initializing package repository D:\users\myname\.julia\v0.4
INFO: Cloning METADATA from git://github.com/JuliaLang/METADATA.jl
fatal: unable to connect to github.com:
github.com[0: 192.30.252.121]: errno=No error

ERROR: failed process: Process(`git clone -q -b metadata-v2 
git://github.com/JuliaLang/METADATA.jl METADATA`, ProcessExited(128)) [128]
 in run at process.jl:531



Here's my version info:

julia> versioninfo()
Julia Version 0.4.5
Commit 2ac304d (2016-03-18 00:58 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3



Any help would be much appreciated.

Philippe

[julia-users] Re: Mathematical Computing course in Julia

[John Gibson]

Sheehan: Thanks a million! I am due to teach undergraduate Numerical 
Methods next fall and have been planning to do it in Julia. I have a 
feeling I'm going to be deeply indebted to you for this course material. 

John Gibson
Dept Mathematics & Statistics
University of New Hampshire

On Thursday, April 14, 2016 at 10:17:40 PM UTC-4, Sheehan Olver wrote:
>
>
>
> I'm currently lecturing the course MATH3076/3976 Mathematical Computing at 
> U. Sydney in Julia, and thought that others may be interested in the 
> resources I've provided:
>
> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>
> The lecture notes and labs are all Jupyter notebooks.  I've also included 
> a "cheat sheet" of Julia commands used in the course
>
>
> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>
> The course is ongoing (it's about half through) and will continue to take 
> shape, but any feedback is of course welcome!
>
>
> Sheehan Olver
>

[julia-users] Compose Plotting from REPL

[Christoph Ortner]

I am trying to use Compose.jl directly instead of going through a plotting 
package. From iPython notebooks invoking compose will immediately create 
the output. 

But when I am in the REPL, how do I plot to a window, similar as in PyPlot?

Thanks,
Christoph

[julia-users] Re: Help with MXNet AssertionError: get_batch_size(opts.eval_data) == batch_size

[kleinsplash]

still having this issue - any ideas?

On Monday, 11 April 2016 15:58:03 UTC+2, kleinsplash wrote:
>
> $ julia G3DB_cnn.jl 
> (128,128,1,800)
> (128,128,1,200)
> INFO: Start training on [GPU0]
> INFO: Initializing parameters...
> INFO: Creating KVStore...
> INFO: Start training...
> INFO: == Epoch 001 ==
> INFO: ## Training summary
> INFO:   accuracy = 0.5638
> INFO:   time = 1.9078 seconds
> ERROR: LoadError: AssertionError: get_batch_size(opts.eval_data) == 
> batch_size
>  in fit at /home/ashley/.julia/v0.4/MXNet/src/model.jl:482
>  in include at ./boot.jl:261
>  in include_from_node1 at ./loading.jl:304
>  in process_options at ./client.jl:280
>  in _start at ./client.jl:378
>
>
> Could someone help me understand the above? I dont have many data so my 
> batch_size is 0. Trying to get to the predicted values.. 
>
> Thx
>

Re: [julia-users] Re: PyCall exception.jl's pycheckv - hidden exceptions or is it normal for that to take some time?

[Isaiah Norton]

>
> When passing arrays to Python, the PyCall default is already to use NumPy
> wrappers that pass the data without copying.


Yes, sorry for being unclear. My point was that this wrapper function ('
tfJuliaInterface.pass_image_to_ff') might not be taking advantage of the
existing NumPy-based buffer capability, since it seems to be spending so
much time copying.

On Fri, Apr 15, 2016 at 7:48 AM, Steven G. Johnson 
wrote:

>
>
> On Friday, April 15, 2016 at 12:14:53 AM UTC-4, Isaiah wrote:
>>
>> Your profiling result is not necessarily unreasonable. The listed line
>> number (exception.jl:78) is where the macro-wrapped code is actually
>> executed, and  "pass_image_to_ff" sounds like it could be expensive.
>>
>> Is the Julia-Pycall-TF wrapper copying data in that function? If so, then
>> it may be worth investigating the use of PyCall's buffer support instead,
>> to avoid copying (currently uses NumPy buffers underneath, see
>> https://github.com/stevengj/PyCall.jl/issues/38)
>>
>
> When passing arrays to Python, the PyCall default is already to use NumPy
> wrappers that pass the data without copying.
>

[julia-users] How to change REPL mode on startup?

[lapeyre . math122a]

I have a REPL mode for an application: 
https://github.com/jlapeyre/SJulia.jl/blob/master/src/sjulia_repl.jl

I start julia in a terminal,  load the package with 'using SJulia', and 
then press '=' to enter the alternative mode.  This works fine.

I would like to do this in one step. e.g.  enter 'sjulia' in a terminal and 
then start in the alternative mode. Problems are:

1. I have to execute a julia function to start the REPL mode 'after' the 
REPL starts and I see the julia prompt. Otherwise there is no active REPL. 
Using .juliarc.jl or julia -e apparently loads and runs code before 
starting the REPL.  I would like the alternative REPL mode to be created 
without entering anything at the julia prompt.

2. Once I create the alternative REPL, I am still in the standard julia 
REPL mode. To switch to the alternative mode, I enter '='. I would like to 
enter this mode automatically. There is a function Base.LineEdit.transition 
that seems to do this. But, it takes a data structure (of type 
Base.LineEdit.MIState' ) as an argument that I don't know how to get at.  I 
can probably find it buried somewhere in Base.active_repl, but, I have not 
been able to so far.

-John

[julia-users] Re: Mathematical Computing course in Julia

[Daniel Carrera]

Cool stuff!

I am interested in ways to teach Julia. I currently teach a very short 
MATLAB course and I'd love to teach Julia instead. From my point of view, 
the biggest obstacle is that Jupyter is not easy to install for most 
people, and PyPlot doesn't have much documentation. I keep telling myself 
that I'll add documentation for PyPlot but somehow I never seem to find the 
time.

Cheers,
Daniel.


On Friday, 15 April 2016 04:17:40 UTC+2, Sheehan Olver wrote:
>
>
>
> I'm currently lecturing the course MATH3076/3976 Mathematical Computing at 
> U. Sydney in Julia, and thought that others may be interested in the 
> resources I've provided:
>
> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>
> The lecture notes and labs are all Jupyter notebooks.  I've also included 
> a "cheat sheet" of Julia commands used in the course
>
>
> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>
> The course is ongoing (it's about half through) and will continue to take 
> shape, but any feedback is of course welcome!
>
>
> Sheehan Olver
>

Re: [julia-users] Re: Parametric types which add or delete fields.

[Eric Forgy]

On Friday, April 15, 2016 at 6:40:37 PM UTC+8, Tim Holy wrote:
>
> If in contrast item[i+1] has a different type than item[i], and the amount 
> of 
> processing is quite modest, then it may not be worth it. Because julia 
> can't 
> predict the type at compile-time, it has to look up the type at run-time, 
> search for the appropriate method in method tables, decide (via type 
> intersection) which one matches, determine whether it has been 
> JIT-compiled 
> yet (and do so if not), and then make the call. You're asking the full 
> type- 
> system and JIT-compilation machinery to basically execute the equivalent 
> of a 
> switch statement or dictionary lookup in your own code. Julia can do this, 
> but 
> it's a lot of churn under the hood. If this is the situation you're in, it 
> seems likely to be better to just write that switch statement or to use a 
> dictionary. 
>

Hi Tim, 

Thanks for writing this. I am finally starting to write some serious Julia 
code and I am in exactly the situation you described above. It is kind of 
depressing to read what you wrote, but it makes sense I guess. Now I need 
to rethink my strategy.

It's probably obvious, but could you or someone else help elaborate on 
"just write that switch statement or use a dictionary"?

What is the best way to deal with this situation?

Basically, I have a long list of concrete objects "PriceableType1", 
"PriceableType2", etc, all subtypes of "AbstractPriceableType" and I have a 
different "Price" function for each different concrete time that dispatches 
as I run through the list to come up with the price of the list.

Should I make methods "priceType1", "priceType2", etc and just switch based 
on "typeof" rather than use dispatch? :(

Thanks again and have a great weekend!
Eric

Re: [julia-users] Re: PyCall exception.jl's pycheckv - hidden exceptions or is it normal for that to take some time?

[Steven G. Johnson]

On Friday, April 15, 2016 at 12:14:53 AM UTC-4, Isaiah wrote:
>
> Your profiling result is not necessarily unreasonable. The listed line 
> number (exception.jl:78) is where the macro-wrapped code is actually 
> executed, and  "pass_image_to_ff" sounds like it could be expensive.
>
> Is the Julia-Pycall-TF wrapper copying data in that function? If so, then 
> it may be worth investigating the use of PyCall's buffer support instead, 
> to avoid copying (currently uses NumPy buffers underneath, see 
> https://github.com/stevengj/PyCall.jl/issues/38)
>

When passing arrays to Python, the PyCall default is already to use NumPy 
wrappers that pass the data without copying.

[julia-users] Re: [ANN] Spark.jl - Julia interface to Apache Spark

[Sisyphuss]

Starred it.


On Friday, April 15, 2016 at 12:00:17 AM UTC+2, Andrei Zh wrote:
>
> Spark.jl provides Julia bindings for Apache Spark - by far the most 
> popular computational framework in Hadoop ecosystem. Find it at:
>  
>
> https://github.com/dfdx/Spark.jl
>
>
> There's still *a lot* of work to do (Spark API is *huge*), but Spark.jl 
> already supports: 
>
>- map and reduce functions, as well as map_partitions, 
>map_partitions_with_index, count, collect and others;
>- text files on local disk and HDFS (and theoretically and 
>Hadoop-compatible file system);
>- local, Standalone and Mesos masters (YARN is quite different, though 
>I work hard to add it as well);
>- adding custom JARs and other files
>
> See Roadmap  for detailed 
> status and nearest plans.
>
> Since Spark's API is so wide and it's hard to prioritize, *I heavily 
> encourage users to submit bugs and feature requests*. Fill free to open 
> new issues or add +1 to push a feature. And as usual, bug reports and pull 
> requests are welcome too. 
>
> *Question to the community:* should this package be transferred to some 
> Julia organization (e.g. JuliaParallel) to make it easier to discover? 
>

[julia-users] Re: Mathematical Computing course in Julia

[Sisyphuss]

The doc of Julia is far from helpful.
Most time, you should try it to learn what it actually does.


On Friday, April 15, 2016 at 4:21:41 AM UTC+2, Sheehan Olver wrote:
>
>
> When the course is over I'll give a description of any issues encountered 
> using Julia for teaching.  At the moment there are two big ones: the error 
> messages are hard for students to parse, and the documentation is 
> incomplete.  An example of the latter that came up is 
>
> *help?> **reshape*
>
> search: *reshape* p*r*omot*e*_*shape*
>
>
>   reshape(A, dims)
>
>
>   Create an array with the same data as the given array, but with 
> different dimensions. An
>
>   implementation for a particular type of array may choose whether the 
> data is copied or
>
>   shared.
>
>
>
> It is not clear at all that dims means two (or more) numbers.
>
> On Friday, April 15, 2016 at 12:17:40 PM UTC+10, Sheehan Olver wrote:
>>
>>
>>
>> I'm currently lecturing the course MATH3076/3976 Mathematical Computing 
>> at U. Sydney in Julia, and thought that others may be interested in the 
>> resources I've provided:
>>
>> http://www.maths.usyd.edu.au/u/olver/teaching/MATH3976/
>>
>> The lecture notes and labs are all Jupyter notebooks.  I've also included 
>> a "cheat sheet" of Julia commands used in the course
>>
>>
>> http://nbviewer.jupyter.org/url/www.maths.usyd.edu.au/u/olver/teaching/MATH3976/cheatsheet.ipynb
>>
>> The course is ongoing (it's about half through) and will continue to take 
>> shape, but any feedback is of course welcome!
>>
>>
>> Sheehan Olver
>>
>

Re: [julia-users] Re: Parametric types which add or delete fields.

[Tamas Papp]

On Fri, Apr 15 2016, Tim Holy wrote:

> Julia emphasizes the "real" use for types---being able to make important 
> decisions at compile time---rather than the "window dressing" (glorified 
> switch 
> statements) uses that some OOP paradigms seem to encourage.

When learning Common Lisp, many people go through a "I am gonna write
macros for EVERYTHING" phase. Perhaps the Julia equivalent is
constructing elaborate schemes using the type system. I guess this is
normal, since it is one of the most elaborate features of the language.

Having concocted my fair share of complicated and frequently pointless
computational acrobatics with the type system, now I try to forget that
types exist in Julia until I have a working prototype that I can
profile.

Best,

Tamas

Re: [julia-users] Re: Parametric types which add or delete fields.

[Tim Holy]

Hi Anonymous,

Whether all this is worth it depends on how you're going to use these objects. 
Particularly if you're likely to need to work with long lists of cars of 
different types, the path you're following is probably not worthwhile. The 
issue is this: if you have a container where julia knows the type of each 
element in advance (all objects in the container have the same *concrete* 
type), then julia can emit efficient code for processing the whole list. In 
such 
cases, this path is worthwhile. The other place where it might be worthwhile 
is if you have an enormous amount of computation you're going to do on each 
object, and that processing is greatly sped up by having "sub-functions" that 
know the full type details. (In such cases you'll want a function barrier, 
http://docs.julialang.org/en/stable/manual/performance-tips/#separate-kernel-functions.)

If in contrast item[i+1] has a different type than item[i], and the amount of 
processing is quite modest, then it may not be worth it. Because julia can't 
predict the type at compile-time, it has to look up the type at run-time, 
search for the appropriate method in method tables, decide (via type 
intersection) which one matches, determine whether it has been JIT-compiled 
yet (and do so if not), and then make the call. You're asking the full type-
system and JIT-compilation machinery to basically execute the equivalent of a 
switch statement or dictionary lookup in your own code. Julia can do this, but 
it's a lot of churn under the hood. If this is the situation you're in, it 
seems likely to be better to just write that switch statement or to use a 
dictionary.

Julia emphasizes the "real" use for types---being able to make important 
decisions at compile time---rather than the "window dressing" (glorified switch 
statements) uses that some OOP paradigms seem to encourage.

Best,
--Tim

On Friday, April 15, 2016 11:14:42 AM Mauro wrote:
> On Fri, 2016-04-15 at 09:56, Anonymous  wrote:
> > I need the fields color and year to be Int and ASCIIString, respectively,
> > and I can't just make the types Color and Year type aliases of Int and
> > ASCIIString, since I need these abstract types to distinguish different
> > types of Car for the purposes of multiple dispatch.
> 
> Maybe you need to introduce your Color and Year types.  However if they
> alias to different types then your good.
> 
> typealias MyYear Int
> typealias MyColor ASCIIString
> 
> Car(y::MyYear) = Car{Void, Year}(nothing, y)
> Car(c::MyColor) = Car{Color,Void}(c, nothing)
> Car(c::MyColor, y::MyYear) = Car{Color,Year}(c, y)
> 
> (Note though that this will construct types which have abstract
> field-types.  Those are bad for performance (but only worry about this
> in critical code), have a look at the performance section of the docs)
> 
> > Basically let's say I have 6 possible features and I want to include
> > features 3, 5 and 6.  And let's say those features are ASCIIString, Int
> > and
> > Int, respectively, then I want to be able to write:
> > 
> > Car{Feature3, Feature5, Feature6}(a, b, c)
> 
> Well, outer constructors cannot work like this.
> 
> > where a is a string, and b and c are both integers, and then I want the
> > constructor to return:
> > 
> > Car{Void, Void, Feature3, Void, Feature5, Feature6}(nothing, nothing, a,
> > nothing, b, c)
> > 
> > On Friday, April 15, 2016 at 12:18:56 AM UTC-7, Mauro wrote:
> >> On Fri, 2016-04-15 at 07:28, Anonymous 
> >> 
> >> wrote:
> >> > OP here,
> >> > 
> >> > So it looks like the consensus is to use a single type with un-used
> >> > features set to nothing.  I've actually been playing around with this
> >> > approach since I posted this question.  Here's what I've got:
> >> > 
> >> > abstract AbstractCar
> >> > 
> >> > abstract Color
> >> > abstract Year
> >> > 
> >> > typealias ColorOrVoid Union{Color, Void}
> >> > typealias YearOrVoid Union{Year, Void}
> >> > 
> >> > type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar
> >> > 
> >> >   color::typeMap(C)
> >> >   year::typeMap(Y)
> >> > 
> >> > end
> >> 
> >> This should work:
> >> 
> >> type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar
> >> 
> >>   color::C
> >>   year::Y
> >> 
> >> end
> >> 
> >> (Aside:
> >> I think using a function inside the type definition is only possible if
> >> it can be evaluated at compile time (I might be wrong though).  Consider
> >> this example:
> >> 
> >> julia> g(T) = Vector{T}
> >> g (generic function with 1 method)
> >> 
> >> julia> type B{T}
> >> 
> >>b::g(T)
> >>end
> >> 
> >> julia> B([1,2])
> >> B{Int64}([1,2])
> >> 
> >> julia> h(T) = string(Int.name.name)[1]=="I" ? Int : Float64
> >> h (generic function with 1 method)
> >> 
> >> julia> h(AbstractString)
> >> Float64
> >> 
> >> julia> type C{T}
> >> 
> >>c::h(T)
> >>end
> >> 
> >> WARNING: static parameter T does not occur in signature for call at
> >> none:2.
> >> The method will not be callable.
> >> 
> 

Re: [julia-users] Re: Parametric types which add or delete fields.

[Mauro]

On Fri, 2016-04-15 at 09:56, Anonymous  wrote:
> I need the fields color and year to be Int and ASCIIString, respectively,
> and I can't just make the types Color and Year type aliases of Int and
> ASCIIString, since I need these abstract types to distinguish different
> types of Car for the purposes of multiple dispatch.

Maybe you need to introduce your Color and Year types.  However if they
alias to different types then your good.

typealias MyYear Int
typealias MyColor ASCIIString

Car(y::MyYear) = Car{Void, Year}(nothing, y)
Car(c::MyColor) = Car{Color,Void}(c, nothing)
Car(c::MyColor, y::MyYear) = Car{Color,Year}(c, y)

(Note though that this will construct types which have abstract
field-types.  Those are bad for performance (but only worry about this
in critical code), have a look at the performance section of the docs)

> Basically let's say I have 6 possible features and I want to include
> features 3, 5 and 6.  And let's say those features are ASCIIString, Int and
> Int, respectively, then I want to be able to write:
>
> Car{Feature3, Feature5, Feature6}(a, b, c)

Well, outer constructors cannot work like this.

> where a is a string, and b and c are both integers, and then I want the
> constructor to return:
>
> Car{Void, Void, Feature3, Void, Feature5, Feature6}(nothing, nothing, a,
> nothing, b, c)
>
> On Friday, April 15, 2016 at 12:18:56 AM UTC-7, Mauro wrote:
>>
>>
>> On Fri, 2016-04-15 at 07:28, Anonymous 
>> wrote:
>> > OP here,
>> >
>> > So it looks like the consensus is to use a single type with un-used
>> > features set to nothing.  I've actually been playing around with this
>> > approach since I posted this question.  Here's what I've got:
>> >
>> > abstract AbstractCar
>> >
>> > abstract Color
>> > abstract Year
>> >
>> > typealias ColorOrVoid Union{Color, Void}
>> > typealias YearOrVoid Union{Year, Void}
>> >
>> > type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar
>> >   color::typeMap(C)
>> >   year::typeMap(Y)
>> > end
>>
>> This should work:
>>
>> type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar
>>   color::C
>>   year::Y
>> end
>>
>> (Aside:
>> I think using a function inside the type definition is only possible if
>> it can be evaluated at compile time (I might be wrong though).  Consider
>> this example:
>>
>> julia> g(T) = Vector{T}
>> g (generic function with 1 method)
>>
>> julia> type B{T}
>>b::g(T)
>>end
>>
>> julia> B([1,2])
>> B{Int64}([1,2])
>>
>> julia> h(T) = string(Int.name.name)[1]=="I" ? Int : Float64
>> h (generic function with 1 method)
>>
>> julia> h(AbstractString)
>> Float64
>>
>> julia> type C{T}
>>c::h(T)
>>end
>> WARNING: static parameter T does not occur in signature for call at
>> none:2.
>> The method will not be callable.
>>
>> end-aside)
>>
>> > where the function typeMap will send Void to itself, Color to
>> ASCIIString
>> > and Year to Int.  However I tried doing this and I got an error, I
>> probably
>> > the way to do this is with meta-programming and macros, but I'm not sure
>> > how since I'm a complete novice at meta-programming.
>> >
>> > I would also like to have outer constructors which allow me to avoid
>> having
>> > to enter Void for all the un-used features, so if I'm only interested in
>> > Year, I would have an outer constructor of the form:
>> >
>> > Car{Year}(y::Int) = Car{Void, Year}(nothing, y)
>> >
>> > However this gives me an error saying that *static parameter Year does
>> not
>> > occur in signature for call at none*.
>>
>> Outer constructors are a bit hard to grok because type parameter feature
>> twice, in the same location, but have a completely different
>> meaning:
>>
>> Car{Year}(y::Int) = Car{Void, Year}(nothing, y)
>> ^^
>>  function parameter type parameters
>>
>> Function parameters need to be inferred from the arguments, whereas type
>> parameters are part of the type. (this might get cleared up in the future)
>>
>> Consider that for just an ordinary function, you cannot do this:
>>
>> f{T<:Int}(i::I) = 5
>> # now call it like so
>> f{Int}(4) # error
>>
>> Anyway, the solution is just (assuming Color and Year can be
>> distinguished by type):
>>
>> Car(y::Year) = Car{Void, Year}(nothing, y)
>> Car(c::Color) = Car{Color,Void}(c, nothing)
>> Car(c::Color, y::Year) = Car{Color,Year}(c, y)
>>
>> If you want to explicate specify the type then (like is used in
>> Julia-Base for e.g. array constructors):
>>
>> Car(T::Type{Year}, y) = Car{Void, Year}(nothing, y)
>> ...
>>
>>
>> > On Thursday, April 14, 2016 at 10:08:53 PM UTC-7, Toivo Henningsson
>> wrote:
>> >>
>> >> As you say, it's a lot of types. If you would really need to
>> instantiate
>> >> an exponential number of types then maybe you should reconsider,
>> because
>> >> the jit compiler has to do quite a lot of work for each type that is
>> used.
>> >>
>> >> But if you're not actually going to instantiate such a humongous number
>> of
>> >> them, 

Re: [julia-users] Re: Parametric types which add or delete fields.

[Anonymous]

edit of previous post: 

I have color and year reversed, color should be ASCIIString and year should 
be Int, same thing with Color and Year.

On Friday, April 15, 2016 at 12:56:16 AM UTC-7, Anonymous wrote:
>
> I need the fields color and year to be Int and ASCIIString, respectively, 
> and I can't just make the types Color and Year type aliases of Int and 
> ASCIIString, since I need these abstract types to distinguish different 
> types of Car for the purposes of multiple dispatch.  
>
> Basically let's say I have 6 possible features and I want to include 
> features 3, 5 and 6.  And let's say those features are ASCIIString, Int 
> and Int, respectively, then I want to be able to write:
>
> Car{Feature3, Feature5, Feature6}(a, b, c)
>
> where a is a string, and b and c are both integers, and then I want the 
> constructor to return:
>
> Car{Void, Void, Feature3, Void, Feature5, Feature6}(nothing, nothing, a, 
> nothing, b, c) 
>
> On Friday, April 15, 2016 at 12:18:56 AM UTC-7, Mauro wrote:
>>
>>
>> On Fri, 2016-04-15 at 07:28, Anonymous  wrote: 
>> > OP here, 
>> > 
>> > So it looks like the consensus is to use a single type with un-used 
>> > features set to nothing.  I've actually been playing around with this 
>> > approach since I posted this question.  Here's what I've got: 
>> > 
>> > abstract AbstractCar 
>> > 
>> > abstract Color 
>> > abstract Year 
>> > 
>> > typealias ColorOrVoid Union{Color, Void} 
>> > typealias YearOrVoid Union{Year, Void} 
>> > 
>> > type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar 
>> >   color::typeMap(C) 
>> >   year::typeMap(Y) 
>> > end 
>>
>> This should work: 
>>
>> type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar 
>>   color::C 
>>   year::Y 
>> end 
>>
>> (Aside: 
>> I think using a function inside the type definition is only possible if 
>> it can be evaluated at compile time (I might be wrong though).  Consider 
>> this example: 
>>
>> julia> g(T) = Vector{T} 
>> g (generic function with 1 method) 
>>
>> julia> type B{T} 
>>b::g(T) 
>>end 
>>
>> julia> B([1,2]) 
>> B{Int64}([1,2]) 
>>
>> julia> h(T) = string(Int.name.name)[1]=="I" ? Int : Float64 
>> h (generic function with 1 method) 
>>
>> julia> h(AbstractString) 
>> Float64 
>>
>> julia> type C{T} 
>>c::h(T) 
>>end 
>> WARNING: static parameter T does not occur in signature for call at 
>> none:2. 
>> The method will not be callable. 
>>
>> end-aside) 
>>
>> > where the function typeMap will send Void to itself, Color to 
>> ASCIIString 
>> > and Year to Int.  However I tried doing this and I got an error, I 
>> probably 
>> > the way to do this is with meta-programming and macros, but I'm not 
>> sure 
>> > how since I'm a complete novice at meta-programming. 
>> > 
>> > I would also like to have outer constructors which allow me to avoid 
>> having 
>> > to enter Void for all the un-used features, so if I'm only interested 
>> in 
>> > Year, I would have an outer constructor of the form: 
>> > 
>> > Car{Year}(y::Int) = Car{Void, Year}(nothing, y) 
>> > 
>> > However this gives me an error saying that *static parameter Year does 
>> not 
>> > occur in signature for call at none*. 
>>
>> Outer constructors are a bit hard to grok because type parameter feature 
>> twice, in the same location, but have a completely different 
>> meaning: 
>>
>> Car{Year}(y::Int) = Car{Void, Year}(nothing, y) 
>> ^^ 
>>  function parameter type parameters 
>>
>> Function parameters need to be inferred from the arguments, whereas type 
>> parameters are part of the type. (this might get cleared up in the 
>> future) 
>>
>> Consider that for just an ordinary function, you cannot do this: 
>>
>> f{T<:Int}(i::I) = 5 
>> # now call it like so 
>> f{Int}(4) # error 
>>
>> Anyway, the solution is just (assuming Color and Year can be 
>> distinguished by type): 
>>
>> Car(y::Year) = Car{Void, Year}(nothing, y) 
>> Car(c::Color) = Car{Color,Void}(c, nothing) 
>> Car(c::Color, y::Year) = Car{Color,Year}(c, y) 
>>
>> If you want to explicate specify the type then (like is used in 
>> Julia-Base for e.g. array constructors): 
>>
>> Car(T::Type{Year}, y) = Car{Void, Year}(nothing, y) 
>> ... 
>>
>>
>> > On Thursday, April 14, 2016 at 10:08:53 PM UTC-7, Toivo Henningsson 
>> wrote: 
>> >> 
>> >> As you say, it's a lot of types. If you would really need to 
>> instantiate 
>> >> an exponential number of types then maybe you should reconsider, 
>> because 
>> >> the jit compiler has to do quite a lot of work for each type that is 
>> used. 
>> >> 
>> >> But if you're not actually going to instantiate such a humongous 
>> number of 
>> >> them, or if you really want to be able to use specialization and 
>> dispatch 
>> >> in this way: How about a middle road where you use a parametric type 
>> and 
>> >> set the types of all unused fields to Void (the type of nothing)? That 
>> >> should be able to support the cases that you mentioned. 
>> >> 

Re: [julia-users] Re: Parametric types which add or delete fields.

[Anonymous]

I need the fields color and year to be Int and ASCIIString, respectively, 
and I can't just make the types Color and Year type aliases of Int and 
ASCIIString, since I need these abstract types to distinguish different 
types of Car for the purposes of multiple dispatch.  

Basically let's say I have 6 possible features and I want to include 
features 3, 5 and 6.  And let's say those features are ASCIIString, Int and 
Int, respectively, then I want to be able to write:

Car{Feature3, Feature5, Feature6}(a, b, c)

where a is a string, and b and c are both integers, and then I want the 
constructor to return:

Car{Void, Void, Feature3, Void, Feature5, Feature6}(nothing, nothing, a, 
nothing, b, c) 

On Friday, April 15, 2016 at 12:18:56 AM UTC-7, Mauro wrote:
>
>
> On Fri, 2016-04-15 at 07:28, Anonymous  
> wrote: 
> > OP here, 
> > 
> > So it looks like the consensus is to use a single type with un-used 
> > features set to nothing.  I've actually been playing around with this 
> > approach since I posted this question.  Here's what I've got: 
> > 
> > abstract AbstractCar 
> > 
> > abstract Color 
> > abstract Year 
> > 
> > typealias ColorOrVoid Union{Color, Void} 
> > typealias YearOrVoid Union{Year, Void} 
> > 
> > type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar 
> >   color::typeMap(C) 
> >   year::typeMap(Y) 
> > end 
>
> This should work: 
>
> type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar 
>   color::C 
>   year::Y 
> end 
>
> (Aside: 
> I think using a function inside the type definition is only possible if 
> it can be evaluated at compile time (I might be wrong though).  Consider 
> this example: 
>
> julia> g(T) = Vector{T} 
> g (generic function with 1 method) 
>
> julia> type B{T} 
>b::g(T) 
>end 
>
> julia> B([1,2]) 
> B{Int64}([1,2]) 
>
> julia> h(T) = string(Int.name.name)[1]=="I" ? Int : Float64 
> h (generic function with 1 method) 
>
> julia> h(AbstractString) 
> Float64 
>
> julia> type C{T} 
>c::h(T) 
>end 
> WARNING: static parameter T does not occur in signature for call at 
> none:2. 
> The method will not be callable. 
>
> end-aside) 
>
> > where the function typeMap will send Void to itself, Color to 
> ASCIIString 
> > and Year to Int.  However I tried doing this and I got an error, I 
> probably 
> > the way to do this is with meta-programming and macros, but I'm not sure 
> > how since I'm a complete novice at meta-programming. 
> > 
> > I would also like to have outer constructors which allow me to avoid 
> having 
> > to enter Void for all the un-used features, so if I'm only interested in 
> > Year, I would have an outer constructor of the form: 
> > 
> > Car{Year}(y::Int) = Car{Void, Year}(nothing, y) 
> > 
> > However this gives me an error saying that *static parameter Year does 
> not 
> > occur in signature for call at none*. 
>
> Outer constructors are a bit hard to grok because type parameter feature 
> twice, in the same location, but have a completely different 
> meaning: 
>
> Car{Year}(y::Int) = Car{Void, Year}(nothing, y) 
> ^^ 
>  function parameter type parameters 
>
> Function parameters need to be inferred from the arguments, whereas type 
> parameters are part of the type. (this might get cleared up in the future) 
>
> Consider that for just an ordinary function, you cannot do this: 
>
> f{T<:Int}(i::I) = 5 
> # now call it like so 
> f{Int}(4) # error 
>
> Anyway, the solution is just (assuming Color and Year can be 
> distinguished by type): 
>
> Car(y::Year) = Car{Void, Year}(nothing, y) 
> Car(c::Color) = Car{Color,Void}(c, nothing) 
> Car(c::Color, y::Year) = Car{Color,Year}(c, y) 
>
> If you want to explicate specify the type then (like is used in 
> Julia-Base for e.g. array constructors): 
>
> Car(T::Type{Year}, y) = Car{Void, Year}(nothing, y) 
> ... 
>
>
> > On Thursday, April 14, 2016 at 10:08:53 PM UTC-7, Toivo Henningsson 
> wrote: 
> >> 
> >> As you say, it's a lot of types. If you would really need to 
> instantiate 
> >> an exponential number of types then maybe you should reconsider, 
> because 
> >> the jit compiler has to do quite a lot of work for each type that is 
> used. 
> >> 
> >> But if you're not actually going to instantiate such a humongous number 
> of 
> >> them, or if you really want to be able to use specialization and 
> dispatch 
> >> in this way: How about a middle road where you use a parametric type 
> and 
> >> set the types of all unused fields to Void (the type of nothing)? That 
> >> should be able to support the cases that you mentioned. 
> >> 
> >> Also, in many cases, storage for a value worth known type of eg Void is 
> >> free, since it is known that there is only one instance. The exception 
> is 
> >> if the value could be uninitialized as well. 
> >> 
> >> 
>

Re: [julia-users] Re: Parametric types which add or delete fields.

[Mauro]

On Fri, 2016-04-15 at 07:28, Anonymous  wrote:
> OP here,
>
> So it looks like the consensus is to use a single type with un-used
> features set to nothing.  I've actually been playing around with this
> approach since I posted this question.  Here's what I've got:
>
> abstract AbstractCar
>
> abstract Color
> abstract Year
>
> typealias ColorOrVoid Union{Color, Void}
> typealias YearOrVoid Union{Year, Void}
>
> type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar
>   color::typeMap(C)
>   year::typeMap(Y)
> end

This should work:

type Car{C<:ColorOrVoid, Y<:YearOrVoid} <: AbstractCar
  color::C
  year::Y
end

(Aside:
I think using a function inside the type definition is only possible if
it can be evaluated at compile time (I might be wrong though).  Consider
this example:

julia> g(T) = Vector{T}
g (generic function with 1 method)

julia> type B{T}
   b::g(T)
   end

julia> B([1,2])
B{Int64}([1,2])

julia> h(T) = string(Int.name.name)[1]=="I" ? Int : Float64
h (generic function with 1 method)

julia> h(AbstractString)
Float64

julia> type C{T}
   c::h(T)
   end
WARNING: static parameter T does not occur in signature for call at none:2.
The method will not be callable.

end-aside)

> where the function typeMap will send Void to itself, Color to ASCIIString
> and Year to Int.  However I tried doing this and I got an error, I probably
> the way to do this is with meta-programming and macros, but I'm not sure
> how since I'm a complete novice at meta-programming.
>
> I would also like to have outer constructors which allow me to avoid having
> to enter Void for all the un-used features, so if I'm only interested in
> Year, I would have an outer constructor of the form:
>
> Car{Year}(y::Int) = Car{Void, Year}(nothing, y)
>
> However this gives me an error saying that *static parameter Year does not
> occur in signature for call at none*.

Outer constructors are a bit hard to grok because type parameter feature
twice, in the same location, but have a completely different
meaning:

Car{Year}(y::Int) = Car{Void, Year}(nothing, y)
^^
 function parameter type parameters

Function parameters need to be inferred from the arguments, whereas type
parameters are part of the type. (this might get cleared up in the future)

Consider that for just an ordinary function, you cannot do this:

f{T<:Int}(i::I) = 5
# now call it like so
f{Int}(4) # error

Anyway, the solution is just (assuming Color and Year can be
distinguished by type):

Car(y::Year) = Car{Void, Year}(nothing, y)
Car(c::Color) = Car{Color,Void}(c, nothing)
Car(c::Color, y::Year) = Car{Color,Year}(c, y)

If you want to explicate specify the type then (like is used in
Julia-Base for e.g. array constructors):

Car(T::Type{Year}, y) = Car{Void, Year}(nothing, y)
...


> On Thursday, April 14, 2016 at 10:08:53 PM UTC-7, Toivo Henningsson wrote:
>>
>> As you say, it's a lot of types. If you would really need to instantiate
>> an exponential number of types then maybe you should reconsider, because
>> the jit compiler has to do quite a lot of work for each type that is used.
>>
>> But if you're not actually going to instantiate such a humongous number of
>> them, or if you really want to be able to use specialization and dispatch
>> in this way: How about a middle road where you use a parametric type and
>> set the types of all unused fields to Void (the type of nothing)? That
>> should be able to support the cases that you mentioned.
>>
>> Also, in many cases, storage for a value worth known type of eg Void is
>> free, since it is known that there is only one instance. The exception is
>> if the value could be uninitialized as well.
>>
>>

[julia-users] Re: a excellent Julia IDE, JuliaDT

[Liye zhang]

New version of the JuliaDT, 

https://github.com/JuliaComputing/JuliaDT/releases/tag/v0.0.2

Many new features added, supporting figure plot to some extent. It's on the 
way to a mature Julia development tool.


On Tuesday, March 8, 2016 at 9:56:39 PM UTC+8, Liye zhang wrote:
>
> If you are trying to find an IDE for Julia which is as convenient as PyDev 
> for python, or RStudio for R, you can test JuliaDT. Thanks for the 
> authors' excellent work!
>
> https://github.com/JuliaComputing/JuliaDT/releases/tag/v0.0.1 
>
> More about this software,
> http://juliacomputing.com/blog/2016/02/06/Eclipse-JuliaDT.html
>