Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

[Christoph Ortner]

So here is a reason for keeping the linespace a vector:

julia> t = linspace(0, 1, 1_000_000);
julia> s = collect(t);
julia> @time for n = 1:10; exp(t); end
  0.209307 seconds (20 allocations: 76.295 MB, 3.42% gc time)
julia> @time for n = 1:10; exp(s); end
  0.054603 seconds (20 allocations: 76.295 MB, 17.66% gc time)
julia> @time for n = 1:10; AppleAccelerate.exp(s); end
  0.016640 seconds (40 allocations: 76.295 MB, 31.64% gc time)
julia> @time for n = 1:10; AppleAccelerate.exp!(s,s); end
  0.005702 seconds

Now the natural response will be to say that most of the time I won't care 
so much about performance, and when I do, then I can go optimise. But in 
truth the same can be said about keeping linspace abstract just because it 
saves memory. (obviously it is not faster!) 

I think the argument for abstract types is very strong, but (in my personal 
view) not at the expense of expected behaviour.

Christoph

[julia-users] Re: Questions about ranges

[andy hayden]

> I don't really understand why you can't just use the StepRange for 
everything

You could. However, you can be more efficient by having special types (e.g. 
with UnitRange you don't need to check the steps).

>  `findin(::UnitRange, ::UnitRange)` returns another UnitRange

This seems good.

> `findin(::StepRange, ::StepRange)` returns an array of the indices

You might be able to do some maths here to return a StepRange... at least 
for Integers:

function Base.findin{T <: Integer}(a::StepRange{T}, b::StepRange{T})
start = ??
step = b.step ÷ gcd(a.step, b.step)
stop = max(a.stop, b.stop)
start:step:stop
end

but I 'm not sure this is possible with floats...

Looking in the source mentioning UnitRange here's a more serious 
bug: 
https://github.com/JuliaLang/julia/blob/e16c6784e1ba6f24b6faf0d282c78d8c14a1fbb3/base/array.jl#L866

julia> findin([5.2, 3.3], 3:20)
2-element Array{Int64,1}:
 1
 2

julia> findin([5.2, 3.3], 3:1:20)
0-element Array{Int64,1}

!

On Wednesday, 21 October 2015 19:59:20 UTC-7, Rory Finnegan wrote:
>
> Hi folks,
>
> I just had a couple questions about ranges that maybe someone can answer.
>
>
> 1) Why are there so many Range types? There is a UnitRange (start, stop), 
>  a StepRange (start, step, stop), and a FloatRange(start, step, length, 
> divisor), but I don't really understand why you can't just use the 
> StepRange for everything. Maybe I'm just missing some obvious use cases, 
> but this seems to lead to inconsistent or confusing behaviour like the 1 in 
> my second question.
>
> 2) `findin` seems to have inconsistent behaviour for ranges depending on 
> types in the ranges. `findin(::UnitRange, ::UnitRange)` returns another 
> UnitRange, but `findin(::StepRange, ::StepRange)` returns an array of the 
> indices. Is there some reason that these shouldn't be consistent?
>
> Ex:
> ```
> julia> findin(1:10, 2:5)
> 2:5
>
> julia> findin(1:1:10, 2:2:5)
> 2-element Array{Int64,1}:
>  2
>  4
>
> julia> r1 = DateTime(now())-Dates.Day(60):DateTime(now())
> 2015-08-22T19:07:47:1 day:2015-10-21T19:07:47
>
> julia> r2 = r1[1:20]
> 2015-08-22T19:07:47:1 day:2015-09-10T19:07:47
>
> julia> findin(r1, r2)
> 20-element Array{Int64,1}:
>   1
>   2
>   3
>   4
>   5
>   6
>   7
>   8
>   9
>  10
>  11
>  12
>  13
>  14
>  15
>  16
>  17
>  18
>  19
>  20
> ```
>

[julia-users] Re: Altering matrix inside function

[Glen O]

The reason why it's not working is that you're re-assigning x, rather than 
editing it. By running "x=x[]", you're creating a copy of x with the 
appropriate column removed, and then assigning x to point to the copy, 
rather than to the original array.

If you wanted to edit an array's values, you'd do something like 
"x[:]=x[end:-1:1]" to reverse them in-place - this creates a reversed copy, 
and then copies the values from that reversed copy into the original array. 
Unfortunately, for removing columns or values, it's not quite so simple, 
because you have to deal with changing the size of the matrix.

To get a feel for what is involved, have a look at this:

https://github.com/JuliaLang/julia/blob/master/base/array.jl

That file has the definitions of the functions that you're trying to mimic. 
As you'll see, they end up using "ccall" functions, which are used to call 
C and Fortran libraries. I believe these are necessary if you wish to alter 
the dimensions of an array in-place.

On Thursday, 22 October 2015 09:55:55 UTC+10, Thuener Silva wrote:
>
> I want to change a matrix inside a function. Example( just to illustrate):
>
> julia> x = ones(2,3)
> 2x3 Array{Float64,2}:
>  1.0  1.0  1.0
>  1.0  1.0  1.0
>
> julia> function deletecolumns(x,i)
>   x = x[:,1:size(x,2) .!= i]
>end
> deletecolumns (generic function with 1 method)
>
> julia> deletecolumns(x,1)
> 2x2 Array{Float64,2}:
>  1.0  1.0
>  1.0  1.0 
> 
>   
> 
> julia> x
> 2x3 Array{Float64,2}: 
> 
>  1.0  1.0  1.0 
>
>  1.0  1.0  1.0  
>
> The best way is to do "x = deletecolumns(x,1)" ? I want to make something 
> more like delete!(x,1).
>
>
> Thanks in advance,
> Thuener Silva
>

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

This is where Object Oriented programming can be useful.  If you define a 
Trait and then several abstract classes extending the trait at many levels, 
it will be
possible to define complex polynomial ( p(x)=det(A-x*B) ) specific abstract 
classes at deeper levels for computing coefficients. OOP constructs will
make super-classes and traits to be reusable for lower level abstract 
classes.  A type or operations on a type can both be abstract. 
 Mathematicians
can exploit the power of OOP if the nested structures in mathematical 
expressions are understood properly for writing programs.


On Wednesday, October 21, 2015 at 12:43:17 PM UTC-7, vav...@uwaterloo.ca 
wrote:
>
> Earlier I posted a statement in this thread that object-oriented 
> programming is in many cases not suitable for scientific software because 
> it forces the designer to make decisions too early in the design process 
> that become unwelcome constraints as the project progresses.  
>
> If I understand what people are saying about traits, they may pose the 
> same danger.  Just to give a simple example, suppose you are designing a 
> class for univariate polynomials over a ring K.  You might expect that you 
> will need both dense and sparse (i.e., most coefficients=0) polynomials, so 
> you might create an abstract class for both dense and sparse polynomials. 
>  In current Julia you might write:
>
> abstract UnivariatePolynomial{T}
>
> where T is the underlying ring.  You would specify nothing else.  Now if 
> 'traits' were available as a language feature, you might create a member 
> function "obtainCoefficient" that would work properly for both sparse and 
> dense polynomials.
>
> But the next week, someone asks whether you can handle polynomials 
> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
> polynomials in this format, "obtainCoefficient" is expensive and would not 
> be regarded as a simple "getter" operation.  If many people had already 
> written functions invoking the 'obtainCoefficient' method, then you would 
> be stuck.  You would retrospectively realize that the obtainCoefficient 
> member function was not a good idea.  This example is typical of open-ended 
> scientific software projects.
>
> So again, I would be wary of adding object-oriented features to Julia, at 
> least until the language matures a bit more mature.
>
> I have been on the other side of this fence already: I wrote the code for 
> SortedDict in DataStructures.jl.  I had a mandate from Kevin Squire to make 
> SortedDict a drop-in replacement for Dict.  Since there is no formal 
> interface for 'Dict' defined, and indeed, Julia does not have a  means to 
> specify interfaces, this means that I actually have to read all the code in 
> associative.jl and dict.jl in order to carry out Kevin's mandate.  But this 
> turns out to be not so hard!
>
> -- Steve Vavasis
>
>
>
>
>
>
> On Wednesday, October 21, 2015 at 1:00:25 PM UTC-4, Tom Breloff wrote:
>>
>> I think this discussion shows complementary definitions of traits:
>>
>>- verb-based traits: a type agrees to implement all the verbs 
>>appropriate to the given "verb trait"
>>- noun-based traits: a type agrees to contain certain underlying data 
>>(and thus the getter/setter verbs could be implicitly defined for those 
>>fields)
>>
>> Whatever the final implementation of traits in Julia, I think keeping in 
>> mind this distinction could be helpful.
>>
>> On Wed, Oct 21, 2015 at 12:42 PM, Stefan Karpinski  
>> wrote:
>>
>>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  
>>> wrote:
>>>

 > Above, a relatively simple macro can replace all the "Type..." with 
 the fields of the composed types, applying multiple inheritance of the 
 structures without the baggage required in classic OOP.  Then you can 
 compose your type from other types, but without having to write 
 "unicycle.wheel.radius"... you can just write "unicycle.radius".

 As Stefan mentioned, Go is not traditional OO. This "composition-based" 
 approach is part of Go's OO approach. In go, a type can have named fields 
 of different types (like most OO languages), but also has "embedding". For 
 example, if one declared

 type Unicycle struct {
 Wheel
 Frame
 Seat
 }

 then you could access the individual fields directly. So, if "u' is of 
 type Unicycle, then you could access/set u.Cushiness directly. Similarly, 
 if the embedded types had methods, i.e. frame.Color(), they can be called 
 directly through unicycle, u.Color(). This is similar to, but distinct 
 from, inheritance (the difference is that the Unicycle type doesn't 
 actually have these fields, just the ability to call them easily, which is 
 significant because of interfaces). In the case of clashes, the program 
 must specify which is meant, so if both Seat and Frame had a Color() 

[julia-users] entering latexish text

[John Gibson]

I can't figure out how to enter a few simple things with the latex-based 
unicode entry system. 

I can get a variable with name $x_t$ by entering x\_t-tab, but when I try 
to get an $x_b$  by entering x\_b-tab, it expands to x\_beta. 

And I can't figure out how to do multi-character subscripts, like $R_{jk}$ 
or $\sum_{k=j+1}^m$ (the latter is for a comment about a sum computed in a 
loop).

Extra credit for guessing the numerical algorithm associated with the 
multi-character subscripts.

John

Re: [julia-users] Re: How to feval?

[J Luis]

Speed is not critical here. I am porting this script

   
http://gmt.soest.hawaii.edu/projects/gmt-matlab-octave-api/repository/changes/trunk/src/gmtest.m

that will call the test scripts that live, as for example, here


http://gmt.soest.hawaii.edu/projects/gmt/repository/show/branches/5.2.0/doc/scripts/ml

and compare the produced output with the reference PS file that is also in 
the testing dirs.

If it works, as I hope and will test later. It's good enough for me but off 
course faster alternatives are always wellcome.

Thanks

quinta-feira, 22 de Outubro de 2015 às 18:16:05 UTC+1, Stefan Karpinski 
escreveu:
>
> This will not be fast. It's also wildly insecure if the string come from 
> an external source. I'd strongly recommend figuring out a different 
> approach to what you're doing, but it's hard to provide guidance without 
> more context.
>
> On Thu, Oct 22, 2015 at 12:34 PM, Alex Ames  > wrote:
>
>> You could define your own feval:
>>
>> feval(fn_str, args...) = eval(parse(fn_str))(args...)
>>
>> This has the advantage of accepting anonymous functions and multiple 
>> arguments if necessary:
>> julia> feval("sin",5.0)
>> -0.9589242746631385
>>
>> julia> fn_str = "a_plus_b(a,b) = a + b"
>> "a_plus_b(a,b) = a + b"
>>
>> julia> feval(fn_str,2,3)
>> 5
>>
>> On Thursday, October 22, 2015 at 8:20:33 AM UTC-5, J Luis wrote:
>>>
>>> Thanks, at least it's a place to start.
>>>
>>> quinta-feira, 22 de Outubro de 2015 às 14:10:44 UTC+1, Kristoffer 
>>> Carlsson escreveu:

 Maybe

 julia> eval(Symbol("sin"))(5.0)
 -0.9589242746631385

 Not sure if this is the best solution.


 On Thursday, October 22, 2015 at 2:57:31 PM UTC+2, J Luis wrote:
>
> Hi,
>
> I need to convert this piece of Matlab code
>
>   [ps, orig_path] = feval(str2func(test), out_path);
>
> where 'test' is the name of a function and 'out_path' it unique input 
> argument. I have read and re-read the eval function and for once it's 
> clear 
> for me how it works (sorry, I find this sentence highly cryptic "Evaluate 
> an expression in the given module and return the result" ) but worst, I 
> don't see anywhere how it could call a function with input arguments.
>
> How can I achieve the same result in Julia?
>  
> Thanks. 
>

>

[julia-users] Re: map() vs broadcast()

[Glen O]

I'm uncertain, but I think I may have figured out what's going on.

The hint lies in the number of allocations - map! has 20 million 
allocations, while broadcast! has just 5. So I had a look at how the two 
functions are implemented.

map! is implemented in perhaps the simplest way you can think of - for 
i=1:length(A) dest[i]=f(A[i],B[i]); end - which means that it has to store 
four values per iteration - i, A[i], B[i], and f(A[i],B[i]). Thus, 4 times 
5 million allocations.

broadcast! is using a cache to store values, instead, and I believe it's 
generating instructions using a macro instead of a regular loop, thus 
avoiding the assignments for i. As such, it doesn't need to store anything 
except for the initial caches, and after that it just overwrites the 
existing values. Unfortunately, that's as much as I can figure out from 
broadcast!, because it uses a lot of macros and a lot of relatively opaque 
structure.

I'm also not entirely sure how it avoids the assignments necessary in the 
function call.

On Friday, 23 October 2015 01:54:14 UTC+10, Ján Dolinský wrote:
>
> Hi,
>
> I am exploring Julia's map() and broadcast() functions. I did a simple 
> implementation of MAPE (mean absolute percentage error) using broadcast() 
> and map(). Interestingly, the difference in performance was huge.
>
> A = rand(5_000_000)
> F = rand(5_000_000)
>
> _f(a,f) = (a - f) / a
>
> function mape3(A, F)
> # A - actual target values
> # F - forecasts (model estimations)
>
>   tmp = similar(A)
>   broadcast!(_f, tmp, A, F)
>   100 * sumabs(tmp) / length(A)
>
> end
>
> function mape4(A, F)
> # A - actual target values
> # F - forecasts (model estimations)
>
>   tmp = similar(A)
>   map!(_f, tmp, A, F)
>   100 * sumabs(tmp) / length(A)
>
> end
>
> @time mape3(A,F) # after JIT warm-up
>   0.038686 seconds (8 allocations: 38.147 MB, 2.25% gc time)
> 876.4813057521973
>
> @time mape4(A,F) # after JIT warm-up
>   0.457771 seconds (20.00 M allocations: 343.323 MB, 11.29% gc time)
> 876.4813057521973
>
> I wonder why map() is so much slower ?
>
> Thanks,
> Jan
>

Re: [julia-users] DataFrame type specification

[Milan Bouchet-Valat]

Le jeudi 22 octobre 2015 à 09:59 -0700, Andrew Gibb a écrit :
> I have a csv with some data. One of the columns is something I'd
> always like to be read as a string, although sometimes the value will
> just be numerals. Is there some way to specify that I want this
> column to be an AbstractString in readtable? Or perhaps some way to
> convert that column from (say) integers to strings once loaded?
Yes, just use the 'eltypes' arguments for that:
http://dataframesjl.readthedocs.org/en/latest/io.html?highlight=eltypes


Regards

> Thanks
> 
> Andy

Re: [julia-users] Re: Converting an expression to the function

[Stefan Karpinski]

Doing it with strings and parsing is not necessary (and will make all good
Lispers very sad). You should splice and expression object into a function
definition and eval instead:

julia> ex = :(2x + y)
:(2x + y)

julia> @eval f(x,y) = $ex
f (generic function with 1 method)

julia> f(3,4)
10


On Thu, Oct 22, 2015 at 1:38 PM, Alex Ames 
wrote:

> There may be a slicker way to do this, but this should work:
>
> julia> fngen(expr,fn) = eval(parse(string(fn)* "=" * string(expr)))
> fngen (generic function with 1 method)
>
> julia> expr = :(x + y)
> :(x + y)
>
> julia> fngen(expr,:(f(x,y)))
> func (generic function with 1 method)
>
> julia> f(2,2)
> 4
>
> On Thursday, October 22, 2015 at 11:10:09 AM UTC-5, Jānis Erdmanis wrote:
>>
>> I am implementing boundary element method with curved elements. As it is
>> daunting task to evaluate derivatives I thought about using `Calculus`
>> symbolic differentiation which as output gives expression. Now I need to
>> convert this expression to a function, but how can I do it?
>>
>> As an example consider
>> expr = :(x + y)
>> how can I convert it to the function?
>> function f(x,y)
>> # Some magic here
>> end
>>
>>
>>

Re: [julia-users] Parallel loop

[Tim Holy]

In short: use SharedArrays, if all processes are on the same host. The example 
in the documentation should make this pretty clear, but feel free to post 
again if it's not.

As for # of procs, just try different choices up to the # of cores in your 
machine and see what happens.

--Tim

On Thursday, October 22, 2015 08:06:30 AM amik...@gmail.com wrote:
> Hi all,
> 
> I swear I tried to look into the documentation or online but I can't figure
> out what I want to do.
> I have a lot of sequential code executed and at some point I want to
> parallelize the following loop:
> 
> mat_a = zeros(n, n)
> for i = 1:n
> mat_a[i,i:n] = mean(mat_b[:,i] .* mat_b[:,i:n], 1)
> end
> 
> with mat_b being computed before.
> 
> I have a bunch of questions in order to better understand things:
> 
> - how to best choose the number of procs with which I run julia?
> - since each operation on the rows of mat_a can be done independently from
> the others, I'd like to send mat_b to each worker so that it can compute
> certain lines of the matrix mat_a in the form of an array of vector which I
> would concatenate afterwards to retrieve mat_a. I wanted to send mat_b with
> the @everywhere macro but it seems this works only for definitions of
> variables directly on a worker. I don't know how to send already computed
> data to a specific worker.
> - more generally, is this the best approach to parallelizing this kind of
> code?
> 
> Any advice appreciated,
> 
> Thanks a lot,

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

I found that you are one of the core developers of Julia language. Could 
you please explain how Julia compiler and executor can be called
through APIs ?  Are there any documentations for APIs. 
Is it possible to call Julia compiler and executor through programming 
interfaces from Scala compiler / executor ?  I am 
trying to understand broad strategy for possible implementation of 
ScalaJulia language.

On Wednesday, October 21, 2015 at 12:41:49 PM UTC-7, Stefan Karpinski wrote:
>
> Excellent idea. You should make a PR against the Scala GitHub repo and see 
> how it goes.
>
> On Wed, Oct 21, 2015 at 3:31 PM,  
> wrote:
>
>> How is the idea that any function defined with Julia tag gets into a 
>> first class object with name *Julia* in a combined ScalaJulia language :
>>
>> *Julia* function sphere_vol(r)
>>
>> # julia allows Unicode names 
>>  (in UTF-8 
>> encoding)
>> # so either "pi" or the symbol π can be used
>> return 4/3*pi*r^3end
>>
>> is translated into ScalaJulia language as: 
>>
>> object *Julia* {
>>
>> def sphere_vol(r : Int) {
>>
>>   return ( 4/3*pi*r^3 )
>>
>> }
>>   }
>>
>>
>>
>> Object Julia will get all first level functions defined in Julia syntax.  
>> This is the simplest way to encapsulate
>> Julia functions and inherit in other Scala objects or classes in 
>> ScalaJulia language.   
>>
>> This will preserve simplicity and performance of Julia functions.
>>
>> SS
>>
>>
>> On Wednesday, October 21, 2015 at 10:00:25 AM UTC-7, Tom Breloff wrote:
>>>
>>> I think this discussion shows complementary definitions of traits:
>>>
>>>- verb-based traits: a type agrees to implement all the verbs 
>>>appropriate to the given "verb trait"
>>>- noun-based traits: a type agrees to contain certain underlying 
>>>data (and thus the getter/setter verbs could be implicitly defined for 
>>>those fields)
>>>
>>> Whatever the final implementation of traits in Julia, I think keeping in 
>>> mind this distinction could be helpful.
>>>
>>> On Wed, Oct 21, 2015 at 12:42 PM, Stefan Karpinski >> > wrote:
>>>
 On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  
 wrote:

>
> > Above, a relatively simple macro can replace all the "Type..." with 
> the fields of the composed types, applying multiple inheritance of the 
> structures without the baggage required in classic OOP.  Then you can 
> compose your type from other types, but without having to write 
> "unicycle.wheel.radius"... you can just write "unicycle.radius".
>
> As Stefan mentioned, Go is not traditional OO. This 
> "composition-based" approach is part of Go's OO approach. In go, a type 
> can 
> have named fields of different types (like most OO languages), but also 
> has 
> "embedding". For example, if one declared
>
> type Unicycle struct {
> Wheel
> Frame
> Seat
> }
>
> then you could access the individual fields directly. So, if "u' is of 
> type Unicycle, then you could access/set u.Cushiness directly. Similarly, 
> if the embedded types had methods, i.e. frame.Color(), they can be called 
> directly through unicycle, u.Color(). This is similar to, but distinct 
> from, inheritance (the difference is that the Unicycle type doesn't 
> actually have these fields, just the ability to call them easily, which 
> is 
> significant because of interfaces). In the case of clashes, the program 
> must specify which is meant, so if both Seat and Frame had a Color() 
> method, the user would have to specify u.Frame.Color vs. u.Seat.Color. In 
> Go, this is handled by the compiler, and would need to be handled 
> somewhere 
> in the Julia runtime/REPL. It's a very nice paradigm, but would have to 
> be 
> made to fit within the broader Julia context.
>

 I do like this approach to composition/delegation, but it requires 
 automatically adding a lot of methods to the delegator, i.e.  Unicycle in 
 this example, from all of its components, which feels kind of nasty and 
 dangerous, especially since we allow dynamic addition of methods 
 after-the-fact. In other words, you might add a method to Wheel, Frame or 
 Seat at any time, which would presumably then also apply to Unicycle 
 objects, potentially with unexpected consequences. It would be nice if the 
 delegation was more limited than that. Go doesn't have this problem since 
 you can't dynamically add methods – everything is known at compile time.

>>>
>>>
>

Re: [julia-users] Julia and Object-Oriented Programming

[vavasis]

One way to build a code-base that everyone can share is to specify 
interfaces to datatypes as in methods in C++ base classes.  Another way is 
for each individual to write his/her own code, and then read everyone 
else's code, and then meet at coffee shops and talk on the phone to get 
things to work together.  I am claiming that the second way is better for 
scientific software than the first way because scientific software is more 
open-ended than, say, systems software.  I am claiming that specifying 
interfaces from the outset can lead to prematurely locking in design 
decisions, and that I have seen examples of this in the real world.  Keep 
in mind that Julia is being touted as a suitable language for both the 
initial and the later phases of scientific software development.

In the event that Julia adds new OO or other interface-specifying features, 
obviously it would be possible for a team to ignore them, at least 
initially.  But I have also seen in previous projects that there is a 
tendency for people (including me) to jump onto the fanciest possible 
solution offered by the programming language to solve a software design 
problem.

-- Steve Vavasis


On Thursday, October 22, 2015 at 12:02:21 PM UTC-4, g wrote:
>
> What is the other option here? It seemed like with the OO/Julia way you 
> are complaining about you at least have working (but slow) code handling 
> your new polynomial type. In a case where your new type doesn't work with 
> "obtainCoefficient", it won't 
> work with any of your other code either. You would just have no working 
> code with your new polynomial type. How is that better?
>
> But the next week, someone asks whether you can handle polynomials 
>> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
>> polynomials in this format, "obtainCoefficient" is expensive and would not 
>> be regarded as a simple "getter" operation.  If many people had already 
>> written functions invoking the 'obtainCoefficient' method, then you would 
>> be stuck.  You would retrospectively realize that the obtainCoefficient 
>> member function was not a good idea.  This example is typical of open-ended 
>> scientific software projects.
>>
>>>
>>>

Re: [julia-users] Re: How to feval?

[Stefan Karpinski]

This will not be fast. It's also wildly insecure if the string come from an
external source. I'd strongly recommend figuring out a different approach
to what you're doing, but it's hard to provide guidance without more
context.

On Thu, Oct 22, 2015 at 12:34 PM, Alex Ames 
wrote:

> You could define your own feval:
>
> feval(fn_str, args...) = eval(parse(fn_str))(args...)
>
> This has the advantage of accepting anonymous functions and multiple
> arguments if necessary:
> julia> feval("sin",5.0)
> -0.9589242746631385
>
> julia> fn_str = "a_plus_b(a,b) = a + b"
> "a_plus_b(a,b) = a + b"
>
> julia> feval(fn_str,2,3)
> 5
>
> On Thursday, October 22, 2015 at 8:20:33 AM UTC-5, J Luis wrote:
>>
>> Thanks, at least it's a place to start.
>>
>> quinta-feira, 22 de Outubro de 2015 às 14:10:44 UTC+1, Kristoffer
>> Carlsson escreveu:
>>>
>>> Maybe
>>>
>>> julia> eval(Symbol("sin"))(5.0)
>>> -0.9589242746631385
>>>
>>> Not sure if this is the best solution.
>>>
>>>
>>> On Thursday, October 22, 2015 at 2:57:31 PM UTC+2, J Luis wrote:

 Hi,

 I need to convert this piece of Matlab code

   [ps, orig_path] = feval(str2func(test), out_path);

 where 'test' is the name of a function and 'out_path' it unique input
 argument. I have read and re-read the eval function and for once it's clear
 for me how it works (sorry, I find this sentence highly cryptic "Evaluate
 an expression in the given module and return the result" ) but worst, I
 don't see anywhere how it could call a function with input arguments.

 How can I achieve the same result in Julia?

 Thanks.

>>>

Re: [julia-users] Re: Why am I getting this error?

[Diego Javier Zea]

Yes, if a run it without using* -p *I get the 137 exit code. It was
difficult to find... Do you have any hint about why is it using more RAM in
every iteration (of pmap)? I add a gc() inside main() without results.

2015-10-22 14:31 GMT-03:00 Yichao Yu :

> On Thu, Oct 22, 2015 at 12:56 PM, Diego Javier Zea 
> wrote:
> > Looks like it's using too much RAM and the system is killing it. I get a:
> > ProcessExitedException()
>
> The lack of a better error was the reason it took a long time to
> notice the OOM issue on travis. I'll be nice if we can at least get
> the exit status of local workers (which should indicate that they are
> killed in this case).
>
> >
> >
> > El jueves, 22 de octubre de 2015, 13:09:21 (UTC-3), Diego Javier Zea
> > escribió:
> >>
> >> I am running this script on a large list (92003 lines) of files. At some
> >> point I'm getting this error (unrelated to the files since works fine
> for a
> >> while if I continue from the last file):
> >>
> >> ERROR (unhandled task failure): EOFError: read end of file
> >>  in read at stream.jl:907
> >>  in message_handler_loop at multi.jl:847
> >>  in process_tcp_streams at multi.jl:836
> >>  in anonymous at task.jl:63
> >> Worker 3 terminated.
> >> ERROR (unhandled task failure): EOFError: read end of file
> >>  in read at stream.jl:907
> >>  in message_handler_loop at multi.jl:847
> >>  in process_tcp_streams at multi.jl:836
> >>  in anonymous at task.jl:63
> >>
> >>
> >> How can I solve this?
> >>
> >> Best,
>



-- 
Diego Javier Zea

Departamento de Ciencia y Tecnología
Universidad Nacional de Quilmes
Roque Saenz Pena 182
1876 Bernal
Argentina
Phone:+541143657100 ext 4135

Re: [julia-users] Re: Why am I getting this error?

[Yichao Yu]

On Thu, Oct 22, 2015 at 12:56 PM, Diego Javier Zea  wrote:
> Looks like it's using too much RAM and the system is killing it. I get a:
> ProcessExitedException()

The lack of a better error was the reason it took a long time to
notice the OOM issue on travis. I'll be nice if we can at least get
the exit status of local workers (which should indicate that they are
killed in this case).

>
>
> El jueves, 22 de octubre de 2015, 13:09:21 (UTC-3), Diego Javier Zea
> escribió:
>>
>> I am running this script on a large list (92003 lines) of files. At some
>> point I'm getting this error (unrelated to the files since works fine for a
>> while if I continue from the last file):
>>
>> ERROR (unhandled task failure): EOFError: read end of file
>>  in read at stream.jl:907
>>  in message_handler_loop at multi.jl:847
>>  in process_tcp_streams at multi.jl:836
>>  in anonymous at task.jl:63
>> Worker 3 terminated.
>> ERROR (unhandled task failure): EOFError: read end of file
>>  in read at stream.jl:907
>>  in message_handler_loop at multi.jl:847
>>  in process_tcp_streams at multi.jl:836
>>  in anonymous at task.jl:63
>>
>>
>> How can I solve this?
>>
>> Best,

[julia-users] Re: Converting an expression to the function

[Alex Ames]

There may be a slicker way to do this, but this should work:

julia> fngen(expr,fn) = eval(parse(string(fn)* "=" * string(expr)))
fngen (generic function with 1 method)

julia> expr = :(x + y)
:(x + y)

julia> fngen(expr,:(f(x,y)))
func (generic function with 1 method)

julia> f(2,2)
4

On Thursday, October 22, 2015 at 11:10:09 AM UTC-5, Jānis Erdmanis wrote:
>
> I am implementing boundary element method with curved elements. As it is 
> daunting task to evaluate derivatives I thought about using `Calculus` 
> symbolic differentiation which as output gives expression. Now I need to 
> convert this expression to a function, but how can I do it?
>
> As an example consider
> expr = :(x + y)
> how can I convert it to the function?
> function f(x,y)
> # Some magic here
> end
>
>
>

Re: [julia-users] Re: dynamically describing inner constructors

[Sloan Lindsey]

Oooh, now I think I get it, we use multiple dispatch to make a simple 
wrapper that does the mapping. I went down the path yesterday of trying to 
make my complex setup function into a @generated function (because :new 
isn't available on the first pass at compile time) and ran into too many 
data and type dependencies to be happy. However, in the case that you are 
describing the macro land only occurs in a simple wrapper/mapping function. 
I'll work on prototyping this when I get stuck next on the main part of my 
code.
I actually implemented it by hand (because it is all known ahead of time) 
yesterday afternoon. There are literal walls of assignment statements so I 
need to revisit this.

Thanks 
-Sloan

On Thursday, October 22, 2015 at 8:05:33 AM UTC-7, Yichao Yu wrote:
>
> On Thu, Oct 22, 2015 at 10:55 AM, Dan  
> wrote: 
> > Oops, random click on post. 
> > So: 
> > function MyType(..) 
> > : 
> > : 
> > fieldvalues = Any[val1,val2,val3] 
> >   fnames = fieldnames(MyType) 
> >   for i=1:length(fnames) 
> > setfield!(newobj,fname[i],fieldvalues[i]) 
> >   end 
> >   return newobj 
> > end 
>
> This doesn't work for immutables 
>
> Just to follow up on my mention of @generated in the original issue. 
> Adding a inner constructor like the following (and calling this 
> constructor instead of new) should work (although I also agree it's 
> not a great idea to construct Expr(:new) manually) 
>
> ``` 
> @generated Positive_Vec(args...) = 
>Expr(:new, Positive_Vec, [:(args[$i]) for i in 
> 1:length(args)]...) 
> ``` 
>
> Also note that apply(f, args) is always equivalent to f(args...) so 
> you don't need to use it in any case. 
>
> > 
> > On Thursday, October 22, 2015 at 5:52:34 PM UTC+3, Dan wrote: 
> >> 
> >> the inner constructor, can separate allocation and initialization of a 
> new 
> >> object. specifically, first do a: 
> >> newobj = new() 
> >> then you can set the fields. with a loop this can look like: 
> >>   fieldvalues = Any[val1,val2,val3] 
> >> 
> >> 
> >> On Thursday, October 22, 2015 at 4:14:51 PM UTC+3, Sloan Lindsey wrote: 
> >>> 
> >>> I am trying to make some nice inner constructors for an immutable that 
> >>> acts as a nice container. I've run into a bit of a problem with using 
> the 
> >>> new constructor since I wish to have dynamic construction to avoid 
> having to 
> >>> hardcode the hierarchy. 
> >>> 
> >>> 
> >>> #apply new troubles 
> >>> 
> >>> 
> >>> immutable Vec3 
> >>>   x::Float64 
> >>>   y::Float64 
> >>>   z::Float64 
> >>> end 
> >>> 
> >>> 
> >>> immutable Min_Discription 
> >>>   postion::Array{Vec3} 
> >>>   valid::Bool 
> >>>   angry_butter_fly_quotient::Float64 
> >>> end 
> >>> 
> >>> 
> >>> immutable Positive_Vec 
> >>>   position::Array{Vec3} 
> >>>   positive::BitArray 
> >>>   valid::BitArray 
> >>>   angry_butter_fly_quotient::Array{Float64} 
> >>> 
> >>> 
> >>>   function Positive_Vec(elves::Array{Min_Discription}) 
> >>> size = length(elves) 
> >>> #automagically initialize all the data! 
> >>> defaults=((Type{Array{Vec3}},Vec3,null_pos), 
> >>>   (Type{Array{Int}},Int, -1), 
> >>>   (Type{BitArray},Bool,false), 
> >>>   (Type{Array{Float64}},Float64, -Inf)) 
> >>> 
> >>> 
> >>>   data_types = [fieldtype(Positive_Vec,x) for x in 
> >>> fieldnames(Positive_Vec)] 
> >>>   declare_list = Array(Any,length(data_types)) 
> >>> 
> >>> 
> >>>   for i in 1:length(data_types) 
> >>> for (d_type,primitive, default) in defaults 
> >>>   if d_type == data_types[i] 
> >>> if d_type != Type{BitArray} 
> >>>   declare_list[i] = Array(primitive, size) 
> >>>   fill!(declare_list[i], default) 
> >>> else 
> >>>   declare_list[i] = BitArray(size) 
> >>>   fill!(declare_list[i], default) 
> >>> end 
> >>>   end 
> >>> end 
> >>>   end 
> >>>   #defaults populated. Now overwrite data passed in 
> >>>   for entry in fieldnames(Min_Discription) 
> >>> for (name,index) in enumerate(fieldnames(Positive_Vec)) 
> >>>   if entry==name 
> >>> for (elf,i) in enumerate(elves) 
> >>>   declare_list[index][i]=elf.(entry) 
> >>> end 
> >>>   end 
> >>> end 
> >>>   end 
> >>>   #now we worry about a few special cases 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>   for (symbol, index) in enumerate(fieldnames(Positive_Vec)) 
> >>> name = string(symbol) 
> >>> if name=="positive"   # set the size of the structure 
> >>>   for i in 1:length(elves) 
> >>> declare_list[index][i] = elves[i].position.z>0.0 
> >>>   end 
> >>> end 
> >>>   end 
> >>>   return new(declare_list...)#apply(new, declare_list) 
> >>> end 
> >>> 
> >>> 
> >>> end 
> >>> 
> >>> 
> >>>   a = Min_Discription(Vec3(0.0,0.0,0.0),true,73.27113) 
> >>>   b = 

Re: [julia-users] Re: Converting an expression to the function

[Alex Ames]

Thanks Stefan, I knew there was a cleaner way. Looks like I need to study 
Exprs further.

As a side-note, Janis, you may want to check out the ForwardDiff 
 package, which 
allows for cheap, precise derivative evaluation.

On Thursday, October 22, 2015 at 12:44:15 PM UTC-5, Stefan Karpinski wrote:
>
> Doing it with strings and parsing is not necessary (and will make all good 
> Lispers very sad). You should splice and expression object into a function 
> definition and eval instead:
>
> julia> ex = :(2x + y)
> :(2x + y)
>
> julia> @eval f(x,y) = $ex
> f (generic function with 1 method)
>
> julia> f(3,4)
> 10
>
>
> On Thu, Oct 22, 2015 at 1:38 PM, Alex Ames  > wrote:
>
>> There may be a slicker way to do this, but this should work:
>>
>> julia> fngen(expr,fn) = eval(parse(string(fn)* "=" * string(expr)))
>> fngen (generic function with 1 method)
>>
>> julia> expr = :(x + y)
>> :(x + y)
>>
>> julia> fngen(expr,:(f(x,y)))
>> func (generic function with 1 method)
>>
>> julia> f(2,2)
>> 4
>>
>> On Thursday, October 22, 2015 at 11:10:09 AM UTC-5, Jānis Erdmanis wrote:
>>>
>>> I am implementing boundary element method with curved elements. As it is 
>>> daunting task to evaluate derivatives I thought about using `Calculus` 
>>> symbolic differentiation which as output gives expression. Now I need to 
>>> convert this expression to a function, but how can I do it?
>>>
>>> As an example consider
>>> expr = :(x + y)
>>> how can I convert it to the function?
>>> function f(x,y)
>>> # Some magic here
>>> end
>>>
>>>
>>>
>

Re: [julia-users] Re: Converting an expression to the function

[Jānis Erdmanis]

That looks neat :)

On Thursday, October 22, 2015 at 8:44:15 PM UTC+3, Stefan Karpinski wrote:
>
> Doing it with strings and parsing is not necessary (and will make all good 
> Lispers very sad). You should splice and expression object into a function 
> definition and eval instead:
>
> julia> ex = :(2x + y)
> :(2x + y)
>
> julia> @eval f(x,y) = $ex
> f (generic function with 1 method)
>
> julia> f(3,4)
> 10
>
>
> On Thu, Oct 22, 2015 at 1:38 PM, Alex Ames  > wrote:
>
>> There may be a slicker way to do this, but this should work:
>>
>> julia> fngen(expr,fn) = eval(parse(string(fn)* "=" * string(expr)))
>> fngen (generic function with 1 method)
>>
>> julia> expr = :(x + y)
>> :(x + y)
>>
>> julia> fngen(expr,:(f(x,y)))
>> func (generic function with 1 method)
>>
>> julia> f(2,2)
>> 4
>>
>> On Thursday, October 22, 2015 at 11:10:09 AM UTC-5, Jānis Erdmanis wrote:
>>>
>>> I am implementing boundary element method with curved elements. As it is 
>>> daunting task to evaluate derivatives I thought about using `Calculus` 
>>> symbolic differentiation which as output gives expression. Now I need to 
>>> convert this expression to a function, but how can I do it?
>>>
>>> As an example consider
>>> expr = :(x + y)
>>> how can I convert it to the function?
>>> function f(x,y)
>>> # Some magic here
>>> end
>>>
>>>
>>>
>

Re: [julia-users] Julia and Object-Oriented Programming

[Spencer Russell]

Julia has a well-developed C API, so you can embed it inside other 
applications. Info on using it is here:
http://docs.julialang.org/en/release-0.4/manual/embedding/ 


-s

> On Oct 22, 2015, at 3:07 PM, ssarkarayushnet...@gmail.com wrote:
> 
> I found that you are one of the core developers of Julia language. Could you 
> please explain how Julia compiler and executor can be called
> through APIs ?  Are there any documentations for APIs. 
> Is it possible to call Julia compiler and executor through programming 
> interfaces from Scala compiler / executor ?  I am 
> trying to understand broad strategy for possible implementation of ScalaJulia 
> language.
> 
> On Wednesday, October 21, 2015 at 12:41:49 PM UTC-7, Stefan Karpinski wrote:
> Excellent idea. You should make a PR against the Scala GitHub repo and see 
> how it goes.
> 
> On Wed, Oct 21, 2015 at 3:31 PM,  wrote:
> How is the idea that any function defined with Julia tag gets into a first 
> class object with name Julia in a combined ScalaJulia language :
> 
> Julia function sphere_vol(r)
> # julia allows Unicode names 
>  (in UTF-8 
> encoding)
> # so either "pi" or the symbol π can be used
> return 4/3*pi*r^3
> end
> is translated into ScalaJulia language as: 
> 
> object Julia {
> 
> def sphere_vol(r : Int) {
> 
>   return ( 4/3*pi*r^3 )
> 
> }
>   }
> 
> 
> Object Julia will get all first level functions defined in Julia syntax.  
> This is the simplest way to encapsulate
> Julia functions and inherit in other Scala objects or classes in ScalaJulia 
> language.   
> 
> This will preserve simplicity and performance of Julia functions.
> 
> SS
> 
> 
> On Wednesday, October 21, 2015 at 10:00:25 AM UTC-7, Tom Breloff wrote:
> I think this discussion shows complementary definitions of traits:
> verb-based traits: a type agrees to implement all the verbs appropriate to 
> the given "verb trait"
> noun-based traits: a type agrees to contain certain underlying data (and thus 
> the getter/setter verbs could be implicitly defined for those fields)
> Whatever the final implementation of traits in Julia, I think keeping in mind 
> this distinction could be helpful.
> 
> On Wed, Oct 21, 2015 at 12:42 PM, Stefan Karpinski > 
> wrote:
> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey > 
> wrote:
> 
> > Above, a relatively simple macro can replace all the "Type..." with the 
> > fields of the composed types, applying multiple inheritance of the 
> > structures without the baggage required in classic OOP.  Then you can 
> > compose your type from other types, but without having to write 
> > "unicycle.wheel.radius"... you can just write "unicycle.radius".
> 
> As Stefan mentioned, Go is not traditional OO. This "composition-based" 
> approach is part of Go's OO approach. In go, a type can have named fields of 
> different types (like most OO languages), but also has "embedding". For 
> example, if one declared
> 
> type Unicycle struct {
> Wheel
> Frame
> Seat
> }
> 
> then you could access the individual fields directly. So, if "u' is of type 
> Unicycle, then you could access/set u.Cushiness directly. Similarly, if the 
> embedded types had methods, i.e. frame.Color(), they can be called directly 
> through unicycle, u.Color(). This is similar to, but distinct from, 
> inheritance (the difference is that the Unicycle type doesn't actually have 
> these fields, just the ability to call them easily, which is significant 
> because of interfaces). In the case of clashes, the program must specify 
> which is meant, so if both Seat and Frame had a Color() method, the user 
> would have to specify u.Frame.Color vs. u.Seat.Color. In Go, this is handled 
> by the compiler, and would need to be handled somewhere in the Julia 
> runtime/REPL. It's a very nice paradigm, but would have to be made to fit 
> within the broader Julia context.
> 
> I do like this approach to composition/delegation, but it requires 
> automatically adding a lot of methods to the delegator, i.e.  Unicycle in 
> this example, from all of its components, which feels kind of nasty and 
> dangerous, especially since we allow dynamic addition of methods 
> after-the-fact. In other words, you might add a method to Wheel, Frame or 
> Seat at any time, which would presumably then also apply to Unicycle objects, 
> potentially with unexpected consequences. It would be nice if the delegation 
> was more limited than that. Go doesn't have this problem since you can't 
> dynamically add methods – everything is known at compile time.
> 
> 

Re: [julia-users] Re: How to feval?

[J Luis]

Anyway, unfortunately none of the above solutions work for files. If the 
file is called "GMT_insert.jl", and is in the path, I get variations around 
(+ file extension - file extension) of

ERROR: UndefVarError: GMT_insert not defined
 

quinta-feira, 22 de Outubro de 2015 às 18:30:04 UTC+1, J Luis escreveu:
>
> Speed is not critical here. I am porting this script
>
>
> http://gmt.soest.hawaii.edu/projects/gmt-matlab-octave-api/repository/changes/trunk/src/gmtest.m
>
> that will call the test scripts that live, as for example, here
>
> 
> http://gmt.soest.hawaii.edu/projects/gmt/repository/show/branches/5.2.0/doc/scripts/ml
>
> and compare the produced output with the reference PS file that is also in 
> the testing dirs.
>
> If it works, as I hope and will test later. It's good enough for me but 
> off course faster alternatives are always wellcome.
>
> Thanks
>
> quinta-feira, 22 de Outubro de 2015 às 18:16:05 UTC+1, Stefan Karpinski 
> escreveu:
>>
>> This will not be fast. It's also wildly insecure if the string come from 
>> an external source. I'd strongly recommend figuring out a different 
>> approach to what you're doing, but it's hard to provide guidance without 
>> more context.
>>
>> On Thu, Oct 22, 2015 at 12:34 PM, Alex Ames  
>> wrote:
>>
>>> You could define your own feval:
>>>
>>> feval(fn_str, args...) = eval(parse(fn_str))(args...)
>>>
>>> This has the advantage of accepting anonymous functions and multiple 
>>> arguments if necessary:
>>> julia> feval("sin",5.0)
>>> -0.9589242746631385
>>>
>>> julia> fn_str = "a_plus_b(a,b) = a + b"
>>> "a_plus_b(a,b) = a + b"
>>>
>>> julia> feval(fn_str,2,3)
>>> 5
>>>
>>> On Thursday, October 22, 2015 at 8:20:33 AM UTC-5, J Luis wrote:

 Thanks, at least it's a place to start.

 quinta-feira, 22 de Outubro de 2015 às 14:10:44 UTC+1, Kristoffer 
 Carlsson escreveu:
>
> Maybe
>
> julia> eval(Symbol("sin"))(5.0)
> -0.9589242746631385
>
> Not sure if this is the best solution.
>
>
> On Thursday, October 22, 2015 at 2:57:31 PM UTC+2, J Luis wrote:
>>
>> Hi,
>>
>> I need to convert this piece of Matlab code
>>
>>   [ps, orig_path] = feval(str2func(test), out_path);
>>
>> where 'test' is the name of a function and 'out_path' it unique input 
>> argument. I have read and re-read the eval function and for once it's 
>> clear 
>> for me how it works (sorry, I find this sentence highly cryptic 
>> "Evaluate 
>> an expression in the given module and return the result" ) but worst, I 
>> don't see anywhere how it could call a function with input arguments.
>>
>> How can I achieve the same result in Julia?
>>  
>> Thanks. 
>>
>
>>

Re: [julia-users] Re: How to feval?

[Stefan Karpinski]

Julia doesn't identify functions and files the way Matlab does. You can
just load the file by name.

On Thu, Oct 22, 2015 at 2:56 PM, J Luis  wrote:

> Anyway, unfortunately none of the above solutions work for files. If the
> file is called "GMT_insert.jl", and is in the path, I get variations around
> (+ file extension - file extension) of
>
> ERROR: UndefVarError: GMT_insert not defined
>
>
>
> quinta-feira, 22 de Outubro de 2015 às 18:30:04 UTC+1, J Luis escreveu:
>>
>> Speed is not critical here. I am porting this script
>>
>>
>> http://gmt.soest.hawaii.edu/projects/gmt-matlab-octave-api/repository/changes/trunk/src/gmtest.m
>>
>> that will call the test scripts that live, as for example, here
>>
>>
>> http://gmt.soest.hawaii.edu/projects/gmt/repository/show/branches/5.2.0/doc/scripts/ml
>>
>> and compare the produced output with the reference PS file that is also
>> in the testing dirs.
>>
>> If it works, as I hope and will test later. It's good enough for me but
>> off course faster alternatives are always wellcome.
>>
>> Thanks
>>
>> quinta-feira, 22 de Outubro de 2015 às 18:16:05 UTC+1, Stefan Karpinski
>> escreveu:
>>>
>>> This will not be fast. It's also wildly insecure if the string come from
>>> an external source. I'd strongly recommend figuring out a different
>>> approach to what you're doing, but it's hard to provide guidance without
>>> more context.
>>>
>>> On Thu, Oct 22, 2015 at 12:34 PM, Alex Ames 
>>> wrote:
>>>
 You could define your own feval:

 feval(fn_str, args...) = eval(parse(fn_str))(args...)

 This has the advantage of accepting anonymous functions and multiple
 arguments if necessary:
 julia> feval("sin",5.0)
 -0.9589242746631385

 julia> fn_str = "a_plus_b(a,b) = a + b"
 "a_plus_b(a,b) = a + b"

 julia> feval(fn_str,2,3)
 5

 On Thursday, October 22, 2015 at 8:20:33 AM UTC-5, J Luis wrote:
>
> Thanks, at least it's a place to start.
>
> quinta-feira, 22 de Outubro de 2015 às 14:10:44 UTC+1, Kristoffer
> Carlsson escreveu:
>>
>> Maybe
>>
>> julia> eval(Symbol("sin"))(5.0)
>> -0.9589242746631385
>>
>> Not sure if this is the best solution.
>>
>>
>> On Thursday, October 22, 2015 at 2:57:31 PM UTC+2, J Luis wrote:
>>>
>>> Hi,
>>>
>>> I need to convert this piece of Matlab code
>>>
>>>   [ps, orig_path] = feval(str2func(test), out_path);
>>>
>>> where 'test' is the name of a function and 'out_path' it unique
>>> input argument. I have read and re-read the eval function and for once 
>>> it's
>>> clear for me how it works (sorry, I find this sentence highly cryptic "
>>> Evaluate an expression in the given module and return the result" )
>>> but worst, I don't see anywhere how it could call a function with input
>>> arguments.
>>>
>>> How can I achieve the same result in Julia?
>>>
>>> Thanks.
>>>
>>
>>>

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

[Christoph Ortner]

P.S.: It occurred to me that I should also have tried this:

@time for n = 1:10; AppleAccelerate.exp(collect(s)); end
  0.041035 seconds (60 allocations: 152.589 MB, 22.94% gc time)

[julia-users] Re: Altering matrix inside function

[Thuener Silva]

Thanks. I see that is not easy to change dense matrix. The real problema is 
more complex. I'm using JuMP matrixial operators, I think this only work 
with matrix but actually I didn't test with arrays.
So I have a matrix with 3 dimensions and want to delete some items of this 
matrix. I tried a lot of things but couldn't change a 3D matrix. I couldn't 
also find how to create 3D sparse matrix. Any suggestions for my this case?

On Thursday, October 22, 2015 at 7:21:07 AM UTC-2, Kristoffer Carlsson 
wrote:
>
> There is no way to delete columns here and there and in general end up 
> with a valid dense matrix. 
>
> If you want a view on some of the columns of the matrix you can use slice.
>
> julia> x = reshape(1:100, (10,10));
>
> julia> slice(x, :, 1:3:10)
> 10x4 SubArray{Int64,2,Array{Int64,2},Tuple{Colon,StepRange{Int64,Int64}},1
> }:
>   1  31  61   91
>   2  32  62   92
>   3  33  63   93
>   4  34  64   94
>   5  35  65   95
>   6  36  66   96
>   7  37  67   97
>   8  38  68   98
>   9  39  69   99
>  10  40  70  100
>
> If you want a new "first order" matrix then I don't think you will get 
> something better than
>
> x = x[:, 1:3:10]
>
> What's your use case?
>
> On Thursday, October 22, 2015 at 10:48:21 AM UTC+2, Glen O wrote:
>>
>> The reason why it's not working is that you're re-assigning x, rather 
>> than editing it. By running "x=x[]", you're creating a copy of x with 
>> the appropriate column removed, and then assigning x to point to the copy, 
>> rather than to the original array.
>>
>> If you wanted to edit an array's values, you'd do something like 
>> "x[:]=x[end:-1:1]" to reverse them in-place - this creates a reversed copy, 
>> and then copies the values from that reversed copy into the original array. 
>> Unfortunately, for removing columns or values, it's not quite so simple, 
>> because you have to deal with changing the size of the matrix.
>>
>> To get a feel for what is involved, have a look at this:
>>
>> https://github.com/JuliaLang/julia/blob/master/base/array.jl
>>
>> That file has the definitions of the functions that you're trying to 
>> mimic. As you'll see, they end up using "ccall" functions, which are used 
>> to call C and Fortran libraries. I believe these are necessary if you wish 
>> to alter the dimensions of an array in-place.
>>
>> On Thursday, 22 October 2015 09:55:55 UTC+10, Thuener Silva wrote:
>>>
>>> I want to change a matrix inside a function. Example( just to 
>>> illustrate):
>>>
>>> julia> x = ones(2,3)
>>> 2x3 Array{Float64,2}:
>>>  1.0  1.0  1.0
>>>  1.0  1.0  1.0
>>>
>>> julia> function deletecolumns(x,i)
>>>   x = x[:,1:size(x,2) .!= i]
>>>end
>>> deletecolumns (generic function with 1 method)
>>>
>>> julia> deletecolumns(x,1)
>>> 2x2 Array{Float64,2}:
>>>  1.0  1.0
>>>  1.0  1.0   
>>>   
>>> 
>>>   
>>> julia> x
>>> 2x3 Array{Float64,2}:   
>>>   
>>>  1.0  1.0  1.0   
>>>  
>>>  1.0  1.0  1.0  
>>>
>>> The best way is to do "x = deletecolumns(x,1)" ? I want to make 
>>> something more like delete!(x,1).
>>>
>>>
>>> Thanks in advance,
>>> Thuener Silva
>>>
>>

[julia-users] Re: problem loading PyPlot in windows 10

[Steven G. Johnson]

On Thursday, October 22, 2015 at 5:02:58 PM UTC-4, Aditya Mahajan wrote:
>
> When I try "using PyPlot", I get the following error:
>
> error compiling jl_Function_call: error compiling convert: error compiling 
> pytype_query: error compiling pyint_query: could not load module 
> C:\Users\mahajan1\.julia\v0.3\Conda\deps\usr\python27.dll: The specified 
> module could not be found.
>
>
Is there any DLL in that directory? 

Re: [julia-users] Re: Code runs 500 times slower under 0.4.0

[Stefan Karpinski]

You can try using @code_warntype to see if there are type instabilities.

On Thu, Oct 22, 2015 at 5:50 PM, Gunnar Farnebäck 
wrote:

> If you don't have deprecation warnings I would suspect some change in 0.4
> has introduced type instabilities. If you are using typed concatenations
> you could be hit by https://github.com/JuliaLang/julia/issues/13254.
>
>
> Den torsdag 22 oktober 2015 kl. 23:03:00 UTC+2 skrev Kris De Meyer:
>>
>> Are there any general style guidelines for moving code from 0.3.11 to
>> 0.4.0? Running the unit and functionality tests for a module that I
>> developed under 0.3.11 in 0.4, I experience a 500 times slowdown of blocks
>> of code that I time with @time.
>>
>> Can't even imagine where I have to start looking, and find it
>> flabbergasting that perfectly valid julia code under 0.3.11 (not generating
>> a single warning) can show such a performance degradation under 0.4.0.
>>
>> Anyone seen anything similar? Is there some fundamental difference in how
>> code is JIT-compiled under 0.4.0?
>>
>> Thanks,
>>
>> Kris
>>
>>
>>
>>

Re: [julia-users] entering latexish text

[John Gibson]

That clears it up. Thank you.

On Thursday, October 22, 2015 at 4:09:57 PM UTC-4, Yichao Yu wrote:
>
> On Thu, Oct 22, 2015 at 3:58 PM, John Gibson  > wrote: 
> > I can't figure out how to enter a few simple things with the latex-based 
> > unicode entry system. 
> > 
> > I can get a variable with name $x_t$ by entering x\_t-tab, but when I 
> try to 
> > get an $x_b$  by entering x\_b-tab, it expands to x\_beta. 
>
> It doesn't exist in unicode (at least not yet) 
> https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts 
>
> > 
> > And I can't figure out how to do multi-character subscripts, like 
> $R_{jk}$ 
> > or $\sum_{k=j+1}^m$ (the latter is for a comment about a sum computed in 
> a 
> > loop). 
>
> This is not latex, type each charactors individually (if they exist of 
> course) 
>
> > 
> > Extra credit for guessing the numerical algorithm associated with the 
> > multi-character subscripts. 
> > 
> > John 
> > 
>

[julia-users] Code runs 500 times slower under 0.4.0

[Kris De Meyer]

Are there any general style guidelines for moving code from 0.3.11 to 
0.4.0? Running the unit and functionality tests for a module that I 
developed under 0.3.11 in 0.4, I experience a 500 times slowdown of blocks 
of code that I time with @time. 

Can't even imagine where I have to start looking, and find it 
flabbergasting that perfectly valid julia code under 0.3.11 (not generating 
a single warning) can show such a performance degradation under 0.4.0.

Anyone seen anything similar? Is there some fundamental difference in how 
code is JIT-compiled under 0.4.0?

Thanks,

Kris

[julia-users] problem loading PyPlot in windows 10

[Aditya Mahajan]

When I try "using PyPlot", I get the following error:

error compiling jl_Function_call: error compiling convert: error compiling 
pytype_query: error compiling pyint_query: could not load module 
C:\Users\mahajan1\.julia\v0.3\Conda\deps\usr\python27.dll: The specified module 
could not be found.


Any suggestions as to what's wrong?

ipython --version
4.0.0

python --version
Python 2.7.10 :: Anaconda 2.3.0 (64-bit)

julia> versioninfo()
Julia Version 0.3.11
Commit 483dbf5* (2015-07-27 06:18 UTC)
Platform Info:
  System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

julia> Pkg.status()
11 required packages:
 - BayesNets 0.2.1
 - DataFrames0.6.10
 - Distributions 0.8.7
 - Gadfly0.3.17
 - IJulia1.1.7
 - Images0.4.50
 - Interact  0.2.1
 - Jewel 1.0.6
 - PGFPlots  1.2.2
 - PyPlot2.1.1
 - RDatasets 0.1.2
62 additional packages:
 - ArrayViews0.6.4
 - AutoHashEquals0.0.5
 - BinDeps   0.3.18
 - Calculus  0.1.13
 - Codecs0.1.5
 - ColorTypes0.1.7
 - ColorVectorSpace  0.0.5
 - Colors0.5.4
 - Compat0.7.7
 - Compose   0.3.17
 - Conda 0.1.7
 - Contour   0.0.8
 - DataArrays0.2.19
 - DataStructures0.3.13
 - Dates 0.3.2
 - Distances 0.2.1
 - Docile0.5.19
 - DualNumbers   0.1.5
 - FactCheck 0.4.1
 - FixedPointNumbers 0.0.12
 - GZip  0.2.18
 - Graphics  0.1.0
 - Graphs0.6.0
 - Grid  0.3.11
 - Hexagons  0.0.4
 - HttpCommon0.1.2
 - ImmutableArrays   0.0.11
 - Iterators 0.1.9
 - JSON  0.5.0
 - JuliaParser   0.6.2
 - KernelDensity 0.1.2
 - LNR   0.0.1
 - LaTeXStrings  0.1.6
 - Lazy  0.10.1
 - LibExpat  0.1.0
 - LightGraphs   0.3.4
 - LightXML  0.2.1
 - Loess 0.0.5
 - MacroTools0.2.0
 - NaNMath   0.1.1
 - Nettle0.2.0
 - Optim 0.4.4
 - PDMats0.3.6
 - ParserCombinator  1.7.1
 - PyCall1.1.2
 - Reactive  0.2.4
 - Reexport  0.0.3
 - Requires  0.2.0
 - SHA   0.1.2
 - SIUnits   0.0.5
 - Showoff   0.0.6
 - SortingAlgorithms 0.0.6
 - StatsBase 0.7.4
 - StatsFuns 0.1.4
 - TexExtensions 0.0.2
 - TikzGraphs0.0.2
 - TikzPictures  0.2.5
 - URIParser 0.0.7
 - WinRPM0.1.13
 - WoodburyMatrices  0.1.2
 - ZMQ   0.3.0
 - Zlib  0.1.12

Re: [julia-users] entering latexish text

[Yichao Yu]

On Thu, Oct 22, 2015 at 3:58 PM, John Gibson  wrote:
> I can't figure out how to enter a few simple things with the latex-based
> unicode entry system.
>
> I can get a variable with name $x_t$ by entering x\_t-tab, but when I try to
> get an $x_b$  by entering x\_b-tab, it expands to x\_beta.

It doesn't exist in unicode (at least not yet)
https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts

>
> And I can't figure out how to do multi-character subscripts, like $R_{jk}$
> or $\sum_{k=j+1}^m$ (the latter is for a comment about a sum computed in a
> loop).

This is not latex, type each charactors individually (if they exist of course)

>
> Extra credit for guessing the numerical algorithm associated with the
> multi-character subscripts.
>
> John
>

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

It is very nice to exchange thoughts with mathematicians. If classes, 
instances, types, inheritance, polymorphism and many other things in OOP 
were derived from concepts in mathematics then there should be no 
contradiction between scientific computing and OOP.  It is just matter of 
correct interpretation to relate mathematical model to programming model.

On Thursday, October 22, 2015 at 1:00:36 PM UTC-7, vav...@uwaterloo.ca 
wrote:
>
> One way to build a code-base that everyone can share is to specify 
> interfaces to datatypes as in methods in C++ base classes.  Another way is 
> for each individual to write his/her own code, and then read everyone 
> else's code, and then meet at coffee shops and talk on the phone to get 
> things to work together.  I am claiming that the second way is better for 
> scientific software than the first way because scientific software is more 
> open-ended than, say, systems software.  I am claiming that specifying 
> interfaces from the outset can lead to prematurely locking in design 
> decisions, and that I have seen examples of this in the real world.  Keep 
> in mind that Julia is being touted as a suitable language for both the 
> initial and the later phases of scientific software development.
>
> In the event that Julia adds new OO or other interface-specifying 
> features, obviously it would be possible for a team to ignore them, at 
> least initially.  But I have also seen in previous projects that there is a 
> tendency for people (including me) to jump onto the fanciest possible 
> solution offered by the programming language to solve a software design 
> problem.
>
> -- Steve Vavasis
>
>
> On Thursday, October 22, 2015 at 12:02:21 PM UTC-4, g wrote:
>>
>> What is the other option here? It seemed like with the OO/Julia way you 
>> are complaining about you at least have working (but slow) code handling 
>> your new polynomial type. In a case where your new type doesn't work with 
>> "obtainCoefficient", it won't 
>> work with any of your other code either. You would just have no working 
>> code with your new polynomial type. How is that better?
>>
>> But the next week, someone asks whether you can handle polynomials 
>>> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
>>> polynomials in this format, "obtainCoefficient" is expensive and would not 
>>> be regarded as a simple "getter" operation.  If many people had already 
>>> written functions invoking the 'obtainCoefficient' method, then you would 
>>> be stuck.  You would retrospectively realize that the obtainCoefficient 
>>> member function was not a good idea.  This example is typical of open-ended 
>>> scientific software projects.
>>>

[julia-users] Code runs 500 times slower under 0.4.0

[Kristoffer Carlsson]

Just run ProfileView and see what is taking time. Then post the relevant code 
here and it can likely be fixed. 

Re: [julia-users] entering latexish text

[John Gibson]

That clears it up. Thank you.

On Thursday, October 22, 2015 at 4:09:57 PM UTC-4, Yichao Yu wrote:
>
> On Thu, Oct 22, 2015 at 3:58 PM, John Gibson  > wrote: 
> > I can't figure out how to enter a few simple things with the latex-based 
> > unicode entry system. 
> > 
> > I can get a variable with name $x_t$ by entering x\_t-tab, but when I 
> try to 
> > get an $x_b$  by entering x\_b-tab, it expands to x\_beta. 
>
> It doesn't exist in unicode (at least not yet) 
> https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts 
>
> > 
> > And I can't figure out how to do multi-character subscripts, like 
> $R_{jk}$ 
> > or $\sum_{k=j+1}^m$ (the latter is for a comment about a sum computed in 
> a 
> > loop). 
>
> This is not latex, type each charactors individually (if they exist of 
> course) 
>
>
>

Re: [julia-users] Code runs 500 times slower under 0.4.0

[Stefan Karpinski]

Are there any deprecation warnings? Deprecated calls are pretty slow.

On Thu, Oct 22, 2015 at 1:29 PM, Kris De Meyer  wrote:

> Are there any general style guidelines for moving code from 0.3.11 to
> 0.4.0? Running the unit and functionality tests for a module that I
> developed under 0.3.11 in 0.4, I experience a 500 times slowdown of blocks
> of code that I time with @time.
>
> Can't even imagine where I have to start looking, and find it
> flabbergasting that perfectly valid julia code under 0.3.11 (not generating
> a single warning) can show such a performance degradation under 0.4.0.
>
> Anyone seen anything similar? Is there some fundamental difference in how
> code is JIT-compiled under 0.4.0?
>
> Thanks,
>
> Kris
>
>
>
>

[julia-users] Re: Code runs 500 times slower under 0.4.0

[Gunnar Farnebäck]

If you don't have deprecation warnings I would suspect some change in 0.4 
has introduced type instabilities. If you are using typed concatenations 
you could be hit by https://github.com/JuliaLang/julia/issues/13254.

Den torsdag 22 oktober 2015 kl. 23:03:00 UTC+2 skrev Kris De Meyer:
>
> Are there any general style guidelines for moving code from 0.3.11 to 
> 0.4.0? Running the unit and functionality tests for a module that I 
> developed under 0.3.11 in 0.4, I experience a 500 times slowdown of blocks 
> of code that I time with @time. 
>
> Can't even imagine where I have to start looking, and find it 
> flabbergasting that perfectly valid julia code under 0.3.11 (not generating 
> a single warning) can show such a performance degradation under 0.4.0.
>
> Anyone seen anything similar? Is there some fundamental difference in how 
> code is JIT-compiled under 0.4.0?
>
> Thanks,
>
> Kris
>
>
>
>

[julia-users] sub vs. ArrayViews in 0.4?

[John Brock]

As of 0.4, when should I choose to use sub versus ArrayViews.jl? The 
ArrayViews.jl README mentions that sub uses a less efficient view 
representation, but just how much less efficient is it? Is there ever a 
good reason to use sub instead of ArrayViews, despite the less efficient 
representation?

-John

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

Thank you for the link. I guess an intermediate layer of C application 
should be written for specific function calls, parameter passing and result 
set accumulation or manipulation. From Scala compiler (and executor) this 
application can be accessed through Native Interfaces (JNA4Scala !!). I am 
going to explore the documentation to see how GC works (important) and how 
DataFrames / DataArrays are stored in cache when called from Scala through 
Native Interfaces (JNA4Scala !). 

Please provide any other important links. 


On Thursday, October 22, 2015 at 12:42:07 PM UTC-7, Spencer Russell wrote:
>
> Julia has a well-developed C API, so you can embed it inside other 
> applications. Info on using it is here:
> http://docs.julialang.org/en/release-0.4/manual/embedding/ 
> 
>
> -s
>
> On Oct 22, 2015, at 3:07 PM, ssarkaray...@gmail.com  wrote:
>
> I found that you are one of the core developers of Julia language. Could 
> you please explain how Julia compiler and executor can be called
> through APIs ?  Are there any documentations for APIs. 
> Is it possible to call Julia compiler and executor through programming 
> interfaces from Scala compiler / executor ?  I am 
> trying to understand broad strategy for possible implementation of 
> ScalaJulia language.
>
> On Wednesday, October 21, 2015 at 12:41:49 PM UTC-7, Stefan Karpinski 
> wrote:
>>
>> Excellent idea. You should make a PR against the Scala GitHub repo and 
>> see how it goes.
>>
>> On Wed, Oct 21, 2015 at 3:31 PM,  wrote:
>>
>>> How is the idea that any function defined with Julia tag gets into a 
>>> first class object with name *Julia* in a combined ScalaJulia language :
>>>
>>> *Julia* function sphere_vol(r)
>>>
>>> # julia allows Unicode names 
>>>  (in UTF-8 
>>> encoding)
>>> # so either "pi" or the symbol π can be used
>>> return 4/3*pi*r^3end
>>>
>>> is translated into ScalaJulia language as: 
>>>
>>> object *Julia* {
>>>
>>> def sphere_vol(r : Int) {
>>>
>>>   return ( 4/3*pi*r^3 )
>>>
>>> }
>>>   }
>>>
>>>
>>>
>>> Object Julia will get all first level functions defined in Julia 
>>> syntax.  This is the simplest way to encapsulate
>>> Julia functions and inherit in other Scala objects or classes in 
>>> ScalaJulia language.   
>>>
>>> This will preserve simplicity and performance of Julia functions.
>>>
>>> SS
>>>
>>>
>>> On Wednesday, October 21, 2015 at 10:00:25 AM UTC-7, Tom Breloff wrote:

 I think this discussion shows complementary definitions of traits:

- verb-based traits: a type agrees to implement all the verbs 
appropriate to the given "verb trait"
- noun-based traits: a type agrees to contain certain underlying 
data (and thus the getter/setter verbs could be implicitly defined for 
those fields)

 Whatever the final implementation of traits in Julia, I think keeping 
 in mind this distinction could be helpful.

 On Wed, Oct 21, 2015 at 12:42 PM, Stefan Karpinski <
 ste...@karpinski.org> wrote:

> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  
> wrote:
>
>>
>> > Above, a relatively simple macro can replace all the "Type..." with 
>> the fields of the composed types, applying multiple inheritance of the 
>> structures without the baggage required in classic OOP.  Then you can 
>> compose your type from other types, but without having to write 
>> "unicycle.wheel.radius"... you can just write "unicycle.radius".
>>
>> As Stefan mentioned, Go is not traditional OO. This 
>> "composition-based" approach is part of Go's OO approach. In go, a type 
>> can 
>> have named fields of different types (like most OO languages), but also 
>> has 
>> "embedding". For example, if one declared
>>
>> type Unicycle struct {
>> Wheel
>> Frame
>> Seat
>> }
>>
>> then you could access the individual fields directly. So, if "u' is 
>> of type Unicycle, then you could access/set u.Cushiness directly. 
>> Similarly, if the embedded types had methods, i.e. frame.Color(), they 
>> can 
>> be called directly through unicycle, u.Color(). This is similar to, but 
>> distinct from, inheritance (the difference is that the Unicycle type 
>> doesn't actually have these fields, just the ability to call them 
>> easily, 
>> which is significant because of interfaces). In the case of clashes, the 
>> program must specify which is meant, so if both Seat and Frame had a 
>> Color() method, the user would have to specify u.Frame.Color vs. 
>> u.Seat.Color. In Go, this is handled by the compiler, and would need to 
>> be 
>> handled somewhere in the Julia 

[julia-users] Re: problem loading PyPlot in windows 10

[Tony Kelman]

You can also try running dlopen on that file if it exists, and checking it 
using Dependency Walker to get more information.

Re: [julia-users] Re: parse of string followed by number turned into @doc ?

[Tony Kelman]

Are you on master? I believe we recently merged a PR by Michael Hatherly that 
got rid of documenting a string. Any remaining inconsistencies woukd probably 
be worth an issue.

[julia-users] Re: Module reloading/Autoreloading workflow in 0.4

[Jonathan Malmaud]

Ya, at this point it's the future of Juno. 

I still use the Jupyter notebook - I find they are useful for different 
things. Juno is great when I'm writing a library of reusable code or 
working on an existing library (such as the Julia standard library) and 
want to use the advanced text editing, file navigation, and searching 
features of Atom (my "night" job). 

Jupyter is good for when I'm using Julia to interactively do data analysis 
on my experiments and want to visualize results and keep the visualizations 
tied the block of code that generated them. In that context, I'm not really 
interested in the reusability and shareability of the code I'm writing, but 
rather in the results of the analysis and their visualizations (my "day" 
job). 


On Wednesday, October 21, 2015 at 6:49:15 PM UTC-4, Cedric St-Jean wrote:
>
> Hi Jonathan,
>
> Thank you for maintaining Autoreload and for all the pointers. It made me 
> seriously consider Atom. Do you know if it's the future of Juno (vs. 
> Lighttable)? How do you like it as a Jupyter notebook replacement?
>
> I'll try to get some reproducible bug description filed.
>
> Best,
>
> Cédric
>
> On Wednesday, October 21, 2015 at 12:05:08 PM UTC-4, Jonathan Malmaud 
> wrote:
>>
>> Hi, I'm the author of Autoreload. 
>> I stopped maintaining it since I now use the great Atom Julia plugin (
>> https://github.com/JunoLab/atom-julia-client, built by Mike Innes, who 
>> participates in this forum). Its workflow is described in 
>> https://github.com/JunoLab/atom-julia-client/blob/master/docs/workflow.md
>> . 
>>
>> That said, please file an issue on 
>> https://github.com/malmaud/Autoreload.jl to prod me to get it functional 
>> again. 
>>
>> On Wednesday, October 21, 2015 at 11:24:50 AM UTC-4, Cedric St-Jean wrote:
>>>
>>> I'm struggling to get a good workflow going in 0.4. The docs 
>>>  tell me what 
>>> I can do, but not so much what I should. How does everybody work? What does 
>>> your "startup code" look like? In particular:
>>>
>>> 1. Should I `push!(LOAD_PATH, ".")`, or should I include every file 
>>> manually? I don't know why this behavior was removed in 0.4...
>>>
>>> 2. Inside my modules, should I `include("blah.jl")` then `using blah`?
>>>
>>> 3. How does everyone reload modules when working interactively? Do you 
>>> have a big block that goes
>>> workspace()
>>> reload("Blag")
>>> using LastMain.Other_Module
>>> and you just run it every time you change something in Blag? I don't 
>>> understand workspace()'s purpose. Wiping all variables (even if saved 
>>> elsewhere) is awfully drastic for interactive work.
>>>
>>> 4. Has anybody succeeded in getting Autoreload.jl to work? If I 
>>> `arequire("Blag")` I get warnings that require is deprecated, and it 
>>> sorta-kinda works, but if I add dependencies `arequire("Blag", 
>>> depends_on=["OtherModule"])` then it seems to get in a bad state where 
>>> nothing gets reloaded at all.
>>>
>>> Thank you,
>>>
>>> Cédric
>>>
>>

Re: [julia-users] sub vs. ArrayViews in 0.4?

[Tim Holy]

"Efficient" has several meanings, but keep in mind that `git blame` shows that 
particular line was written on 2014-01-24, i.e., getting close to 2 years ago. 
`sub` in base has changed *radically* in the meantime.

In general, with 0.4 I think there are few cases to use ArrayViews anymore. 
SubArrays are much faster in many circumstances (e.g., when you're not 
creating a ContiguousView---try creating row slices and you'll see what I 
mean). SubArrays can encapsulate an arbitrary AbstractArray rather than being 
limited to Arrays.

Best,
--Tim

On Thursday, October 22, 2015 02:57:46 PM John Brock wrote:
> As of 0.4, when should I choose to use sub versus ArrayViews.jl? The
> ArrayViews.jl README mentions that sub uses a less efficient view
> representation, but just how much less efficient is it? Is there ever a
> good reason to use sub instead of ArrayViews, despite the less efficient
> representation?
> 
> -John

[julia-users] Re: Altering matrix inside function

[Kristoffer Carlsson]

There is no way to delete columns here and there and in general end up with 
a valid dense matrix. 

If you want a view on some of the columns of the matrix you can use slice.

julia> x = reshape(1:100, (10,10));

julia> slice(x, :, 1:3:10)
10x4 SubArray{Int64,2,Array{Int64,2},Tuple{Colon,StepRange{Int64,Int64}},1}:
  1  31  61   91
  2  32  62   92
  3  33  63   93
  4  34  64   94
  5  35  65   95
  6  36  66   96
  7  37  67   97
  8  38  68   98
  9  39  69   99
 10  40  70  100

If you want a new "first order" matrix then I don't think you will get 
something better than

x = x[:, 1:3:10]

What's your use case?

On Thursday, October 22, 2015 at 10:48:21 AM UTC+2, Glen O wrote:
>
> The reason why it's not working is that you're re-assigning x, rather than 
> editing it. By running "x=x[]", you're creating a copy of x with the 
> appropriate column removed, and then assigning x to point to the copy, 
> rather than to the original array.
>
> If you wanted to edit an array's values, you'd do something like 
> "x[:]=x[end:-1:1]" to reverse them in-place - this creates a reversed copy, 
> and then copies the values from that reversed copy into the original array. 
> Unfortunately, for removing columns or values, it's not quite so simple, 
> because you have to deal with changing the size of the matrix.
>
> To get a feel for what is involved, have a look at this:
>
> https://github.com/JuliaLang/julia/blob/master/base/array.jl
>
> That file has the definitions of the functions that you're trying to 
> mimic. As you'll see, they end up using "ccall" functions, which are used 
> to call C and Fortran libraries. I believe these are necessary if you wish 
> to alter the dimensions of an array in-place.
>
> On Thursday, 22 October 2015 09:55:55 UTC+10, Thuener Silva wrote:
>>
>> I want to change a matrix inside a function. Example( just to illustrate):
>>
>> julia> x = ones(2,3)
>> 2x3 Array{Float64,2}:
>>  1.0  1.0  1.0
>>  1.0  1.0  1.0
>>
>> julia> function deletecolumns(x,i)
>>   x = x[:,1:size(x,2) .!= i]
>>end
>> deletecolumns (generic function with 1 method)
>>
>> julia> deletecolumns(x,1)
>> 2x2 Array{Float64,2}:
>>  1.0  1.0
>>  1.0  1.0 
>> 
>>   
>> 
>> julia> x
>> 2x3 Array{Float64,2}: 
>> 
>>  1.0  1.0  1.0   
>>  
>>  1.0  1.0  1.0  
>>
>> The best way is to do "x = deletecolumns(x,1)" ? I want to make something 
>> more like delete!(x,1).
>>
>>
>> Thanks in advance,
>> Thuener Silva
>>
>

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

[Andras Niedermayer]

You're making a good point about an Array being sometimes faster than a 
LinSpace. But a LinSpace gets you a factor N improvement in terms of memory 
efficiency for a size N range, an Array only gets you a constant factor 
improvement in speed (the factor 15 being admittedly relatively large in 
this example).

Memory efficiency typically matters more for usability in an exploratory 
interactive session: if my Julia session needs 5 GB RAM, a factor 3 
increase of memory will crash my computer. If my code runs for 10 seconds 
in an interactive session, 30 seconds is mildly annoying, but not a deal 
breaker. (Obviously, you can construct different examples with memory/time 
where this is different. But my point is that inconvenience changes 
discontinuously in memory usage.)

On Thursday, October 22, 2015 at 9:12:22 AM UTC+2, Christoph Ortner wrote:
>
> P.S.: It occurred to me that I should also have tried this:
>
> @time for n = 1:10; AppleAccelerate.exp(collect(s)); end
>   0.041035 seconds (60 allocations: 152.589 MB, 22.94% gc time)
>

Re: [julia-users] Re: using chol command in Julia v.0.4.0

[Milan Bouchet-Valat]

A PR was just merged to change the behavior of chol() for 0.5:
https://github.com/JuliaLang/julia/pull/13680


Le dimanche 18 octobre 2015 à 10:14 -0700, Christoph Ortner a écrit :
> I agree - that would be much nicer.
> 
> Christoph

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

[Milan Bouchet-Valat]

Le mercredi 21 octobre 2015 à 16:22 -0400, Spencer Russell a écrit :
> On Wed, Oct 21, 2015, at 04:07 PM, Gabriel Gellner wrote:
> > That doesn't feel like a reason that they can't be iterators,
> > rather that they might be slow ;) a la python. My point is not
> > about speed but the consistency of the language. Are there many
> > cases in Julia where there is a special type like this because it
> > is convenient/elegant to implement? This feels like a recipe for
> > madness, my guess is that this would be crazy rare.
> >  
> > People wondered why people might mind that we get a LinSpace object
> > vs an Array. For me it is this strange feeling that I am getting a
> > special case that doesn't feel well motivated other than there is a
> > nice way to implement it (and that people, again, assumed that it
> > would largely be used for looping). If not all things can be made
> > consistently iterators when they are vector-like then why not have
> > a special function that returns this special type (like your
> > aforementioned linrange)? The fact that I lose my iterator when I
> > use certain functions but not others is a way that this
> > polymorphism that everyone is describing doesn't feel as nice to
> > me, since it will not compose in cases where it likely should,
> > outside of implementation details.
>  
> Can you clarify with an example of when you lose the iterator? IMO
> that would be an example of breaking the AbstractArray contract and
> worthy of fixing.
>  
> I see your point that there are other functions that return array
> -like objects that could also be implemented without fully
> constructing the array, e.g. `zeros(20)` could return a `Zeros{20}`
> object that acts like a length-20 array full of zeros. As far as I
> know there's no compelling design reason that's a bad idea, it's just
> that nobody has done it.
A related discussion is about a special Ones type representing an array
of 1, which would allow efficient generic implementations of
(non-)weighted statistical functions:
https://github.com/JuliaStats/StatsBase.jl/issues/135

But regarding zeros(), there might not be any compelling use case to
return a special type. Anyway, if arrays are changed to initialize to
zero [1], that function go could away entirely.


Regards


1: https://github.com/JuliaLang/julia/issues/9147


> The nice thing is that as long as people don't over-specify their
> type annotations that change can be done under-the-hood and it
> shouldn't break code. From a pedagogical standpoint I see how these
> sorts of things can add confusion and cause new folks to question
> their understanding, and more consistency reduces that conceptual
> friction.
>  
> -s

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

[Tim Holy]

I may have said this earlier, but we just need 
https://github.com/JuliaLang/julia/issues/7799.

--Tim

On Thursday, October 22, 2015 12:11:05 AM Christoph Ortner wrote:
> So here is a reason for keeping the linespace a vector:
> 
> julia> t = linspace(0, 1, 1_000_000);
> julia> s = collect(t);
> julia> @time for n = 1:10; exp(t); end
>   0.209307 seconds (20 allocations: 76.295 MB, 3.42% gc time)
> julia> @time for n = 1:10; exp(s); end
>   0.054603 seconds (20 allocations: 76.295 MB, 17.66% gc time)
> julia> @time for n = 1:10; AppleAccelerate.exp(s); end
>   0.016640 seconds (40 allocations: 76.295 MB, 31.64% gc time)
> julia> @time for n = 1:10; AppleAccelerate.exp!(s,s); end
>   0.005702 seconds
> 
> Now the natural response will be to say that most of the time I won't care
> so much about performance, and when I do, then I can go optimise. But in
> truth the same can be said about keeping linspace abstract just because it
> saves memory. (obviously it is not faster!)
> 
> I think the argument for abstract types is very strong, but (in my personal
> view) not at the expense of expected behaviour.
> 
> Christoph

[julia-users] Re: dynamically describing inner constructors

[Dan]

Oops, random click on post.
So:
function MyType(..)
:
:
fieldvalues = Any[val1,val2,val3]
  fnames = fieldnames(MyType)
  for i=1:length(fnames)
setfield!(newobj,fname[i],fieldvalues[i])
  end
  return newobj
end

On Thursday, October 22, 2015 at 5:52:34 PM UTC+3, Dan wrote:
>
> the inner constructor, can separate allocation and initialization of a new 
> object. specifically, first do a:
> newobj = new()
> then you can set the fields. with a loop this can look like:
>   fieldvalues = Any[val1,val2,val3]
>
>
> On Thursday, October 22, 2015 at 4:14:51 PM UTC+3, Sloan Lindsey wrote:
>>
>> I am trying to make some nice inner constructors for an immutable that 
>> acts as a nice container. I've run into a bit of a problem with using the 
>> new constructor since I wish to have dynamic construction to avoid having 
>> to hardcode the hierarchy. 
>>
>>
>> #apply new troubles
>>
>>
>> immutable Vec3
>>   x::Float64
>>   y::Float64
>>   z::Float64
>> end
>>
>>
>> immutable Min_Discription
>>   postion::Array{Vec3}
>>   valid::Bool
>>   angry_butter_fly_quotient::Float64
>> end
>>
>>
>> immutable Positive_Vec
>>   position::Array{Vec3}
>>   positive::BitArray
>>   valid::BitArray
>>   angry_butter_fly_quotient::Array{Float64}
>>
>>
>>   function Positive_Vec(elves::Array{Min_Discription})
>> size = length(elves) 
>> #automagically initialize all the data!
>> defaults=((Type{Array{Vec3}},Vec3,null_pos),
>>   (Type{Array{Int}},Int, -1),
>>   (Type{BitArray},Bool,false),
>>   (Type{Array{Float64}},Float64, -Inf))
>>
>>
>>   data_types = [fieldtype(Positive_Vec,x) for x in fieldnames(
>> Positive_Vec)]
>>   declare_list = Array(Any,length(data_types))
>>
>>
>>   for i in 1:length(data_types)
>> for (d_type,primitive, default) in defaults
>>   if d_type == data_types[i]
>> if d_type != Type{BitArray}
>>   declare_list[i] = Array(primitive, size)
>>   fill!(declare_list[i], default)
>> else
>>   declare_list[i] = BitArray(size)
>>   fill!(declare_list[i], default)
>> end
>>   end
>> end
>>   end
>>   #defaults populated. Now overwrite data passed in
>>   for entry in fieldnames(Min_Discription)
>> for (name,index) in enumerate(fieldnames(Positive_Vec))
>>   if entry==name
>> for (elf,i) in enumerate(elves)
>>   declare_list[index][i]=elf.(entry)
>> end
>>   end
>> end
>>   end
>>   #now we worry about a few special cases
>>
>>
>>
>>
>>   for (symbol, index) in enumerate(fieldnames(Positive_Vec))
>> name = string(symbol)
>> if name=="positive"   # set the size of the structure
>>   for i in 1:length(elves)
>> declare_list[index][i] = elves[i].position.z>0.0
>>   end
>> end
>>   end
>>   return new(declare_list...)#apply(new, declare_list)
>> end
>>
>>
>> end
>>
>>
>>   a = Min_Discription(Vec3(0.0,0.0,0.0),true,73.27113)
>>   b = Min_Discription(Vec3(0.0,0.31,1.0),true,892.73165)
>>   c = Min_Discription(Vec3(0.8364,7.4,500.0),true,4.0)
>>
>>
>>   elves = Array(Min_Discription,3)
>>   elves[1],elves[2],elves[3]= a,b,c
>>   Positive_Vec(elves)
>>
>>
>>
>> julia> include("apply_new_troubles.jl")
>> ERROR: LoadError: syntax: ... is not supported inside "new"
>>  in include at boot.jl:261
>>  in include_from_node1 at loading.jl:304
>>
>> trying to use apply(new, declare_list) doesn't work either.
>>
>> I'm being pointed towards making a an expression and doing some macro 
>> things over here:
>> https://github.com/JuliaLang/julia/issues/13700#issuecomment-149861728
>> and the developers actually told me this was a use question so I'm here.
>>
>> In summary is there a good way to dynamically describe an inner 
>> constructor in julia? 
>>
>> Presently, I'm thinking of something to emulate the missing splat 
>> functionality (whether it be interpolation or some @generated code), Or 
>> even moving the entire generation part into a macro, since all the dynamic 
>> parts are known at compile time (I simply wish to avoid a wall of hardcoded 
>> variables that will be difficult to maintain). 
>> Are there other avenues to follow? I would prefer to keep the functions 
>> attached to the constructor as this facilitates code clarity. 
>>
>> Any assistance or advice would be appreciated.
>>
>

Re: [julia-users] Re: TinySegmenter benchmark

[Michiaki ARIGA]

Masahiro Nakagawa a.k.a. repeatedly told me my mistakes of the benchmark, I
re-benchmarked.

Node.jsPython2Python3JuliaRuby9.6293.0823.941.4619.44

- loop number of Python was 10 times smaller than other languages
- repeatedly optimized Ruby implementation
- changed loop size from 100 to 10

repeatedly also benchmarked in dlang, I will do it after updating El
Capitan :)
http://repeatedly.github.io/ja/2015/10/tinysegmenter-benchmark-and-d/


On Thu, Oct 22, 2015 at 6:28 AM Pontus Stenetorp 
wrote:

> On 21 October 2015 at 17:49, Stefan Karpinski 
> wrote:
> >
> > That's an excellent performance comparison case study! Nice work, Chezou
> and nice blog post (the Google translation is pretty readable).
>
> Very readable indeed and I am always happy to see more NLP code in
> Julia!  Keep up the good work!
>
> Pontus
>

Re: [julia-users] Julia object Destructor or module Unload routine

[Yichao Yu]

On Thu, Oct 22, 2015 at 9:42 AM,   wrote:
> Hi Julia-Users
> I know that Julia has a Garbage Collector that is being aware of unusable
> memory pointers. [ref] I think some other languages e.g. Java also do it
> automatically, and Java programmers rarely need to do it manually [ref],
> while writing such routines is very common in C++ [ref].
> Is it possible to have something like Java finalize or C++ ~ in Julia?
> This routine may be called
>- by Julia REPL when a kill signal (Ctrl+D) is sent.
>- or workspace() is called.
>- or by Garbage Collector before removing a pointer.

We do have finalizer
However, there's a few things to note.
* The finalizer is run by the GC. Don't call `gc()` in it (it will be
no-op). (Actually, don't ever call gc() unless you are absolutely sure
you know what you are doing and you need it)
* We will never have garentee on when, how or in which order the
finalizers are called, which I think is common in tracing GCs.
* Do not use the finalizer to manage resources you care about. The GC
doesn't (yet) have any notion of resources pressure other than the GC
memory usage so it may not collect your resources at the time you
want. You should explicitly free those resources (the `do` block,
try/finally, wrap one of these in macro etc)

> type mytype
>   mytype()=new()
>   function ~mytype()
>  close(file)
>  free(memory)
>  kill(externals)
>  delete(temps)
>  gc()
>   end
>   file::File
>   memory::Pointer
>   externals::Any
>   temps::File
> end
> module mymodule
>   function unload()
>  close(file)
>  free(memory)
>  kill(externals)
>  delete(temps)
>  gc()
>   end
>   file::File
>   memory::Pointer
>   externals::Any
>   temps::File
> end
>

Re: [julia-users] Julia object Destructor or module Unload routine

[Stefan Karpinski]

There's also atexit:

  atexit(f)

  Register a zero-argument function f() to be called at process exit.
atexit() hooks
  are called in last in first out (LIFO) order and run before object
finalizers.

On Thu, Oct 22, 2015 at 10:48 AM, Yichao Yu  wrote:

> On Thu, Oct 22, 2015 at 9:42 AM,   wrote:
> > Hi Julia-Users
> > I know that Julia has a Garbage Collector that is being aware of unusable
> > memory pointers. [ref] I think some other languages e.g. Java also do it
> > automatically, and Java programmers rarely need to do it manually [ref],
> > while writing such routines is very common in C++ [ref].
> > Is it possible to have something like Java finalize or C++ ~ in Julia?
> > This routine may be called
> >- by Julia REPL when a kill signal (Ctrl+D) is sent.
> >- or workspace() is called.
> >- or by Garbage Collector before removing a pointer.
>
> We do have finalizer
> However, there's a few things to note.
> * The finalizer is run by the GC. Don't call `gc()` in it (it will be
> no-op). (Actually, don't ever call gc() unless you are absolutely sure
> you know what you are doing and you need it)
> * We will never have garentee on when, how or in which order the
> finalizers are called, which I think is common in tracing GCs.
> * Do not use the finalizer to manage resources you care about. The GC
> doesn't (yet) have any notion of resources pressure other than the GC
> memory usage so it may not collect your resources at the time you
> want. You should explicitly free those resources (the `do` block,
> try/finally, wrap one of these in macro etc)
>
> > type mytype
> >   mytype()=new()
> >   function ~mytype()
> >  close(file)
> >  free(memory)
> >  kill(externals)
> >  delete(temps)
> >  gc()
> >   end
> >   file::File
> >   memory::Pointer
> >   externals::Any
> >   temps::File
> > end
> > module mymodule
> >   function unload()
> >  close(file)
> >  free(memory)
> >  kill(externals)
> >  delete(temps)
> >  gc()
> >   end
> >   file::File
> >   memory::Pointer
> >   externals::Any
> >   temps::File
> > end
> >
>

[julia-users] good textbook for Julia software engineering?

[Steven G. Johnson]

Many of my students come from a non-CS background, and aren't familiar with 
basic ideas of software engineering like modularity, choosing 
datastructures, putting code into re-usable functions rather than writing 
long copy-and-paste scripts, etcetera.   I'd like to point them at a good 
book, but I mostly didn't learn this stuff from books and don't know what 
is out there.

Is there a good book on basic software engineering that is easily 
applicable to Julia?   (This rules out a lot of the "design patterns" style 
books that are heavily oriented towards traditional OOP languages.)

--SGJ

Re: [julia-users] Julia and Object-Oriented Programming

[Abe Schneider]

I think this is generally in-line with what I've been advocating for, and 
not that different from Scala's mix-ins:

trait Wheel {
  // ...
}

trait Frame {
  // ...
}

class Unicycle extends trait Wheel, Frame {
   // ...
}

is essentially doing the same thing (i.e. copying the member variables and 
methods over).

As Stefan mentioned, Go is not traditional OO. This "composition-based" 
> approach is part of Go's OO approach. In go, a type can have named fields 
> of different types (like most OO languages), but also has "embedding". For 
> example, if one declared
>
> type Unicycle struct {
> Wheel
> Frame
> Seat
> }
>
> then you could access the individual fields directly. So, if "u' is of 
> type Unicycle, then you could access/set u.Cushiness directly. Similarly, 
> if the embedded types had methods, i.e. frame.Color(), they can be called 
> directly through unicycle, u.Color(). This is similar to, but distinct 
> from, inheritance (the difference is that the Unicycle type doesn't 
> actually have these fields, just the ability to call them easily, which is 
> significant because of interfaces). In the case of clashes, the program 
> must specify which is meant, so if both Seat and Frame had a Color() 
> method, the user would have to specify u.Frame.Color vs. u.Seat.Color. In 
> Go, this is handled by the compiler, and would need to be handled somewhere 
> in the Julia runtime/REPL. It's a very nice paradigm, but would have to be 
> made to fit within the broader Julia context.
>
>
>
>

Re: [julia-users] Julia and Object-Oriented Programming

[Brendan Tracey]

> I do like this approach to composition/delegation, but it requires 
> automatically adding a lot of methods to the delegator, i.e.  Unicycle in 
> this example, from all of its components, which feels kind of nasty and 
> dangerous, especially since we allow dynamic addition of methods 
> after-the-fact. In other words, you might add a method to Wheel, Frame or 
> Seat at any time, which would presumably then also apply to Unicycle 
> objects, potentially with unexpected consequences. It would be nice if the 
> delegation was more limited than that. Go doesn't have this problem since 
> you can't dynamically add methods – everything is known at compile time.
>

Yea, it's this kind of thing that makes it tricky in Julia. The obvious 
problem is that you add a method (say cushiness to Frame) which makes 
dispatch ambiguous. One could add higher-level dispatch rules, but that's 
likely to add a lot of complexity.


On Thursday, October 22, 2015 at 7:03:43 AM UTC-6, Abe Schneider wrote:
>
> I think this is generally in-line with what I've been advocating for, and 
> not that different from Scala's mix-ins:
>
> trait Wheel {
>   // ...
> }
>
> trait Frame {
>   // ...
> }
>
> class Unicycle extends trait Wheel, Frame {
>// ...
> }
>
> is essentially doing the same thing (i.e. copying the member variables and 
> methods over).
>
>
I'm not familiar with Scala, so sorry if I'm telling you something you 
know, but in go the member variables and methods are not copied over. The 
Unicycle struct in go does not itself have those fields, the fields of the 
struct do. In other words, defining

type Unicycle struct {
Frame
Wheel
Seat
} 

Is exactly like declaring 

type Unicycle struct {
   Frame Frame
   Wheel Wheel
   SeatSeat
} 

except that in the former case one can call unicycle.Cushiness() , and in 
the latter one must call unicycle.Seat.Cushiness(). In particular, if you 
swap out one Frame in the unicycle for a different Frame, the field values 
change (the methods won't, since methods are with a type).

[julia-users] Julia object Destructor or module Unload routine

[rafzalan]

Hi Julia-Users
I know that Julia has a Garbage Collector that is being aware of unusable 
memory pointers. [ref 
] 
I think some other languages e.g. Java also do it automatically, and Java 
programmers rarely need to do it manually [ref 
], while writing such 
routines is very common in C++ [ref 
]. 
Is it possible to have something like Java finalize or C++ *~* in Julia?
This routine may be called 
   - by Julia REPL when a kill signal (Ctrl+D) is sent.
   - or workspace() is called.
   - or by Garbage Collector before removing a pointer.
type mytype
  mytype()=new()
  function ~mytype()
 close(file)
 free(memory)
 kill(externals)
 delete(temps)
 gc()
  end
  file::File
  memory::Pointer
  externals::Any
  temps::File
end
module mymodule
  function unload()
 close(file)
 free(memory)
 kill(externals)
 delete(temps)
 gc()
  end
  file::File
  memory::Pointer
  externals::Any
  temps::File
end

[julia-users] Re: dynamically describing inner constructors

[Dan]

the inner constructor, can separate allocation and initialization of a new 
object. specifically, first do a:
newobj = new()
then you can set the fields. with a loop this can look like:
  fieldvalues = Any[val1,val2,val3]


On Thursday, October 22, 2015 at 4:14:51 PM UTC+3, Sloan Lindsey wrote:
>
> I am trying to make some nice inner constructors for an immutable that 
> acts as a nice container. I've run into a bit of a problem with using the 
> new constructor since I wish to have dynamic construction to avoid having 
> to hardcode the hierarchy. 
>
>
> #apply new troubles
>
>
> immutable Vec3
>   x::Float64
>   y::Float64
>   z::Float64
> end
>
>
> immutable Min_Discription
>   postion::Array{Vec3}
>   valid::Bool
>   angry_butter_fly_quotient::Float64
> end
>
>
> immutable Positive_Vec
>   position::Array{Vec3}
>   positive::BitArray
>   valid::BitArray
>   angry_butter_fly_quotient::Array{Float64}
>
>
>   function Positive_Vec(elves::Array{Min_Discription})
> size = length(elves) 
> #automagically initialize all the data!
> defaults=((Type{Array{Vec3}},Vec3,null_pos),
>   (Type{Array{Int}},Int, -1),
>   (Type{BitArray},Bool,false),
>   (Type{Array{Float64}},Float64, -Inf))
>
>
>   data_types = [fieldtype(Positive_Vec,x) for x in fieldnames(
> Positive_Vec)]
>   declare_list = Array(Any,length(data_types))
>
>
>   for i in 1:length(data_types)
> for (d_type,primitive, default) in defaults
>   if d_type == data_types[i]
> if d_type != Type{BitArray}
>   declare_list[i] = Array(primitive, size)
>   fill!(declare_list[i], default)
> else
>   declare_list[i] = BitArray(size)
>   fill!(declare_list[i], default)
> end
>   end
> end
>   end
>   #defaults populated. Now overwrite data passed in
>   for entry in fieldnames(Min_Discription)
> for (name,index) in enumerate(fieldnames(Positive_Vec))
>   if entry==name
> for (elf,i) in enumerate(elves)
>   declare_list[index][i]=elf.(entry)
> end
>   end
> end
>   end
>   #now we worry about a few special cases
>
>
>
>
>   for (symbol, index) in enumerate(fieldnames(Positive_Vec))
> name = string(symbol)
> if name=="positive"   # set the size of the structure
>   for i in 1:length(elves)
> declare_list[index][i] = elves[i].position.z>0.0
>   end
> end
>   end
>   return new(declare_list...)#apply(new, declare_list)
> end
>
>
> end
>
>
>   a = Min_Discription(Vec3(0.0,0.0,0.0),true,73.27113)
>   b = Min_Discription(Vec3(0.0,0.31,1.0),true,892.73165)
>   c = Min_Discription(Vec3(0.8364,7.4,500.0),true,4.0)
>
>
>   elves = Array(Min_Discription,3)
>   elves[1],elves[2],elves[3]= a,b,c
>   Positive_Vec(elves)
>
>
>
> julia> include("apply_new_troubles.jl")
> ERROR: LoadError: syntax: ... is not supported inside "new"
>  in include at boot.jl:261
>  in include_from_node1 at loading.jl:304
>
> trying to use apply(new, declare_list) doesn't work either.
>
> I'm being pointed towards making a an expression and doing some macro 
> things over here:
> https://github.com/JuliaLang/julia/issues/13700#issuecomment-149861728
> and the developers actually told me this was a use question so I'm here.
>
> In summary is there a good way to dynamically describe an inner 
> constructor in julia? 
>
> Presently, I'm thinking of something to emulate the missing splat 
> functionality (whether it be interpolation or some @generated code), Or 
> even moving the entire generation part into a macro, since all the dynamic 
> parts are known at compile time (I simply wish to avoid a wall of hardcoded 
> variables that will be difficult to maintain). 
> Are there other avenues to follow? I would prefer to keep the functions 
> attached to the constructor as this facilitates code clarity. 
>
> Any assistance or advice would be appreciated.
>

[julia-users] Re: Help on optimization problem

[Miles Lubin]

On Tuesday, October 20, 2015 at 11:12:44 PM UTC-4, Spencer Russell wrote:
>
>
> 1. What solver is appropriate for this sort of problem? (or should I just 
> go with a spring-force algorithm like in GraphLayout.jl?) 
>

That depends very directly on the precise formulation for the objective 
function. If you could sketch out what it might look like algebraically 
then we can give better suggestions.
 

> 2. (JuMP Specific) - Should I specify my known positions as model 
> variables with equality constraints, or just normal julia variables that 
> show up in my objective function?
>

In the case of nonlinear optimization, it may make the solver's job easier 
if you avoid equality constraints and substitute in the known values 
directly.

[julia-users] Re: Help on optimization problem

[vavasis]

The problem of recovering (x,y,z) coordinates given partial pairwise 
distance information is a famous problem in the optimization community and 
has attracted the attention of many top people.  It is sometimes called the 
'Euclidean distance matrix completion' problem by mathematicians and the 
'sensor localization' problem by engineers.  If you search in google 
scholar on either of these terms, you'll find many papers.  Jon Dattorio 
wrote an entire book on the problem.

-- Steve Vavasis


On Tuesday, October 20, 2015 at 11:12:44 PM UTC-4, Spencer Russell wrote:
>
> I have a bunch of points in 3D whose positions I know approximately, with 
> low-noise distance measurements between them (not necessarily fully 
> connected). I want to improve my estimate of their 3D coordinates. This 
> smells like an optimization problem so I’m thinking of using it as an 
> excuse to learn JuMP. The model variables (coordinates) and objective 
> function seem pretty straightforward (probably sum of squared distance 
> errors for the objective?) but I don’t know enough about the various 
> solvers to know which one to use. I know a tiny bit about optimization 
> (I’ve implemented simplex, L-M, and conjugate GD for a class) but get 
> quickly outside my depth when it gets theoretical. 
>
> Without any known positions the system is underconstrained because the 
> whole collection could can translate, rotate, and reflect, but if I set 3 
> non-colinear points at known positions it should be solvable. I can also 
> supply pretty good guesses for initial values on locations, at least close 
> enough that the closest minima is the one I want (I think). 
>
> so in short my questions boil down to: 
>
> 1. What solver is appropriate for this sort of problem? (or should I just 
> go with a spring-force algorithm like in GraphLayout.jl?) 
> 2. (JuMP Specific) - Should I specify my known positions as model 
> variables with equality constraints, or just normal julia variables that 
> show up in my objective function? 
>
> Thanks! 
>
> -s

[julia-users] Array of type generates error in parallel computing

[Simone Mazzola]

Hi all,

I'm really new to Julia language, especially in parallel computing. My 
general code structure is something like this:


using MyModule #  in this module the type "MyType" is defined

MyTypeArray=Array(MyType,z)


for i=1:z
println(MyTypeArray[i])
end


*Using the standard loop cycle everything works fine*. If I try to move to 
parallel computing using this:


using MyModule #  in this module the type "MyType" is defined

MyTypeArray=Array(MyType,z)

@parallel for i=1:z
println(MyTypeArray[i])
end


the code doesn't work and I obtain this error for each worker:

*1-element Array{Any,1}:*

*fatal error on 2:  RemoteRef{Channel{Any}}(2,1,4)*


*julia> **ERROR: MethodError: `convert` has no method matching 
convert(::Type{LambdaStaticData}, ::Array{Any,1})*

*This may have arisen from a call to the constructor LambdaStaticData(...),*

*since type constructors fall back to convert methods.*

*Closest candidates are:*

*  call{T}(::Type{T}, ::Any)*

*  convert{T}(::Type{T}, !Matched::T)*

* in deserialize at serialize.jl:534*

* in handle_deserialize at serialize.jl:461*

* in deserialize at serialize.jl:694*

* in deserialize_datatype at serialize.jl:647*

* in handle_deserialize at serialize.jl:461*

* in deserialize_array at serialize.jl:612*

* in handle_deserialize at serialize.jl:461*

* in deserialize at serialize.jl:694*

* in deserialize_datatype at serialize.jl:647*

* in handle_deserialize at serialize.jl:461*

* in deserialize_array at serialize.jl:612*

* in handle_deserialize at serialize.jl:461*

* in deserialize at serialize.jl:480*

* in handle_deserialize at serialize.jl:461*

* in deserialize at serialize.jl:536*

* in handle_deserialize at serialize.jl:461*

* in deserialize at serialize.jl:480*

* in handle_deserialize at serialize.jl:461*

* in deserialize at serialize.jl:536*

* in handle_deserialize at serialize.jl:461*

* in deserialize at serialize.jl:694*

* in deserialize_datatype at serialize.jl:647*

* in handle_deserialize at serialize.jl:461*

* in message_handler_loop at multi.jl:847*

* in process_tcp_streams at multi.jl:836*

* in anonymous at task.jl:63*

*Worker 2 terminated.*

*ERROR (unhandled task failure): EOFError: read end of file*

Does anyone have any suggestion?

Thanks,
Simone

[julia-users] Julia talk video

[Jason Grout]

Hi everyone,

I just posted up a video of Spencer Lyon's PyData NYC meetup talk on Julia:

https://youtu.be/mHr-cEGqiuw?t=56m14s

I thought it was a great talk.  Spencer also talked about QuantEcon (though 
with a slant towards the python half of the project, since it was a pydata 
meetup). See the video description for a table of contents of other talks.

Thanks,

Jason

[julia-users] dynamically describing inner constructors

[Sloan Lindsey]

I am trying to make some nice inner constructors for an immutable that acts 
as a nice container. I've run into a bit of a problem with using the new 
constructor since I wish to have dynamic construction to avoid having to 
hardcode the hierarchy. 


#apply new troubles


immutable Vec3
  x::Float64
  y::Float64
  z::Float64
end


immutable Min_Discription
  postion::Array{Vec3}
  valid::Bool
  angry_butter_fly_quotient::Float64
end


immutable Positive_Vec
  position::Array{Vec3}
  positive::BitArray
  valid::BitArray
  angry_butter_fly_quotient::Array{Float64}


  function Positive_Vec(elves::Array{Min_Discription})
size = length(elves) 
#automagically initialize all the data!
defaults=((Type{Array{Vec3}},Vec3,null_pos),
  (Type{Array{Int}},Int, -1),
  (Type{BitArray},Bool,false),
  (Type{Array{Float64}},Float64, -Inf))


  data_types = [fieldtype(Positive_Vec,x) for x in fieldnames(
Positive_Vec)]
  declare_list = Array(Any,length(data_types))


  for i in 1:length(data_types)
for (d_type,primitive, default) in defaults
  if d_type == data_types[i]
if d_type != Type{BitArray}
  declare_list[i] = Array(primitive, size)
  fill!(declare_list[i], default)
else
  declare_list[i] = BitArray(size)
  fill!(declare_list[i], default)
end
  end
end
  end
  #defaults populated. Now overwrite data passed in
  for entry in fieldnames(Min_Discription)
for (name,index) in enumerate(fieldnames(Positive_Vec))
  if entry==name
for (elf,i) in enumerate(elves)
  declare_list[index][i]=elf.(entry)
end
  end
end
  end
  #now we worry about a few special cases




  for (symbol, index) in enumerate(fieldnames(Positive_Vec))
name = string(symbol)
if name=="positive"   # set the size of the structure
  for i in 1:length(elves)
declare_list[index][i] = elves[i].position.z>0.0
  end
end
  end
  return new(declare_list...)#apply(new, declare_list)
end


end


  a = Min_Discription(Vec3(0.0,0.0,0.0),true,73.27113)
  b = Min_Discription(Vec3(0.0,0.31,1.0),true,892.73165)
  c = Min_Discription(Vec3(0.8364,7.4,500.0),true,4.0)


  elves = Array(Min_Discription,3)
  elves[1],elves[2],elves[3]= a,b,c
  Positive_Vec(elves)



julia> include("apply_new_troubles.jl")
ERROR: LoadError: syntax: ... is not supported inside "new"
 in include at boot.jl:261
 in include_from_node1 at loading.jl:304

trying to use apply(new, declare_list) doesn't work either.

I'm being pointed towards making a an expression and doing some macro 
things over here:
https://github.com/JuliaLang/julia/issues/13700#issuecomment-149861728
and the developers actually told me this was a use question so I'm here.

In summary is there a good way to dynamically describe an inner constructor 
in julia? 

Presently, I'm thinking of something to emulate the missing splat 
functionality (whether it be interpolation or some @generated code), Or 
even moving the entire generation part into a macro, since all the dynamic 
parts are known at compile time (I simply wish to avoid a wall of hardcoded 
variables that will be difficult to maintain). 
Are there other avenues to follow? I would prefer to keep the functions 
attached to the constructor as this facilitates code clarity. 

Any assistance or advice would be appreciated.


apply_new_troubles.jl
Description: Binary data

[julia-users] How to feval?

[J Luis]

Hi,

I need to convert this piece of Matlab code

  [ps, orig_path] = feval(str2func(test), out_path);

where 'test' is the name of a function and 'out_path' it unique input 
argument. I have read and re-read the eval function and for once it's clear 
for me how it works (sorry, I find this sentence highly cryptic "Evaluate 
an expression in the given module and return the result" ) but worst, I 
don't see anywhere how it could call a function with input arguments.

How can I achieve the same result in Julia?
 
Thanks. 

[julia-users] Re: ANN: ParallelAccelerator.jl v0.1 released

[Raj Barik]

After Julia's multithreading is ready for release, we will have a native 
path to interface with it. This will hopefully enable multiple shm 
execution paths for users to experiment with.


On Wednesday, October 21, 2015 at 9:12:50 AM UTC-5, Steven Sagaert wrote:
>
> Great news!
> Apart from the focus on parallelism, the architecture seems similar to 
> numba . 
> Good to finally have shared memory parallelism in Julia (not counting the 
> shared memory array under Linux via shm).
> I wonder how this is going to interact with the upcoming multithreading in 
> julia in the future. Will they play nice together or fight each other?
>
> Sincerely,
> Steven Sagaert
>
> On Wednesday, October 21, 2015 at 2:57:17 AM UTC+2, Lindsey Kuper wrote:
>>
>> The High Performance Scripting team at Intel Labs is pleased to announce 
>> the release of version 0.1 of ParallelAccelerator.jl, a package for 
>> high-performance parallel computing in Julia.
>>
>> ParallelAccelerator provides an @acc (short for "accelerate") macro for 
>> annotating Julia functions.  Together with a system C compiler (ICC or 
>> GCC), it compiles @acc-annotated functions to optimized native code.
>>
>> Under the hood, ParallelAccelerator is essentially a domain-specific 
>> compiler written in Julia. It performs additional analysis and optimization 
>> on top of the Julia compiler. ParallelAccelerator discovers and exploits 
>> the implicit parallelism in source programs that use parallel programming 
>> patterns such as map, reduce, comprehension, and stencil. For example, 
>> Julia array operators such as .+, .-, .*, ./ are translated by 
>> ParallelAccelerator internally into data-parallel map operations over all 
>> elements of input arrays. For the most part, these patterns are already 
>> present in standard Julia, so programmers can use ParallelAccelerator to 
>> run the same Julia program without (significantly) modifying the source 
>> code.
>>
>> Version 0.1 should be considered an alpha release, suitable for early 
>> adopters and Julia enthusiasts.  Please file bugs at 
>> https://travis-ci.org/IntelLabs/ParallelAccelerator.jl/issues .
>>
>> ParallelAccelerator requires Julia v0.4.0.  See our GitHub repository at 
>> https://github.com/IntelLabs/ParallelAccelerator.jl for a complete list 
>> of prerequisites, supported platforms, example programs, and documentation.
>>
>> Thanks to our colleagues at Intel and Intel Labs, the Julia team, and the 
>> broader Julia community for their support of our efforts!
>>
>> Best regards,
>> The High Performance Scripting team
>> (Programming Systems Lab, Intel Labs)
>>
>>

Re: [julia-users] Any plans for free tutorials on Coursera,edX or Udacity?

[Isaiah Norton]

There have been occasional whispers about a MOOC with Julia, but they have
not materialized so far (to my knowledge). I think at this point, there is
a need to strike a balance between promotion and maturing the foundations,
and perhaps it is wise to err toward the latter.

If you are looking for learning materials, a great place to start is David
Sanders' workshop at JuliaCon 2015:
https://www.youtube.com/playlist?list=PLP8iPy9hna6Sdx4soiGrSefrmOPdUWixM
https://github.com/dpsanders/invitation_to_julia (materials)


On Wed, Oct 21, 2015 at 5:31 AM, Brian 
wrote:

> Hi,
>
> Are there any plans for free online tutorials at Coursera, EdX or Udacity?
> I guess "Introduction to Julia", "Introduction to Data Analysis with
> Julia", "Introduction to Machine Learning with Julia" etc. would bring a
> lot of attention and "spread the word".
>
> Best,
>
> Brian
>

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

[Tom Breloff]

On Thursday, October 22, 2015 at 9:44:28 AM UTC-4, Gabriel Gellner wrote:
>
> A related discussion is about a special Ones type representing an array 
>> of 1, which would allow efficient generic implementations of 
>> (non-)weighted statistical functions: 
>> https://github.com/JuliaStats/StatsBase.jl/issues/135 
>>
>> But regarding zeros(), there might not be any compelling use case to 
>> return a special type. Anyway, if arrays are changed to initialize to 
>> zero [1], that function go could away entirely
>
>
> lol never thought of this kind of special case. You could simply have a 
> "SameVector" object that just stores the value and the length. * + - ^ 
> would be easy to define and the space/(# of operations) savings could be 
> massive ;). With this you would have no need to special case zeros(n) 
> either just have it return a SameVector with value 0. We could even 
> generalize it to "BlockVector" for sequences of same values storing start 
> and stop locations.
>

[julia-users] Re: How to feval?

[J Luis]

Thanks, at least it's a place to start.

quinta-feira, 22 de Outubro de 2015 às 14:10:44 UTC+1, Kristoffer Carlsson 
escreveu:
>
> Maybe
>
> julia> eval(Symbol("sin"))(5.0)
> -0.9589242746631385
>
> Not sure if this is the best solution.
>
>
> On Thursday, October 22, 2015 at 2:57:31 PM UTC+2, J Luis wrote:
>>
>> Hi,
>>
>> I need to convert this piece of Matlab code
>>
>>   [ps, orig_path] = feval(str2func(test), out_path);
>>
>> where 'test' is the name of a function and 'out_path' it unique input 
>> argument. I have read and re-read the eval function and for once it's clear 
>> for me how it works (sorry, I find this sentence highly cryptic "Evaluate 
>> an expression in the given module and return the result" ) but worst, I 
>> don't see anywhere how it could call a function with input arguments.
>>
>> How can I achieve the same result in Julia?
>>  
>> Thanks. 
>>
>

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

[Gabriel Gellner]

>
> A related discussion is about a special Ones type representing an array 
> of 1, which would allow efficient generic implementations of 
> (non-)weighted statistical functions: 
> https://github.com/JuliaStats/StatsBase.jl/issues/135 
>
> But regarding zeros(), there might not be any compelling use case to 
> return a special type. Anyway, if arrays are changed to initialize to 
> zero [1], that function go could away entirely


lol never thought of this kind of special case. You could simply have a 
"SameVector" object that just stores the value and the length. * + - ^ 
would be easy to define and the space/(# of operations) savings could be 
massive ;). With this you would have no need to special case zeros(n) 
either just have it return a SameVector with value 0. We could even 
generalize it to "BlockVector" for sequences of same values storing start 
and stop locations.

Re: [julia-users] Re: map() vs. comprehensions

[Ján Dolinský]

Hi,

This is an interesting syntax indeed. Thanks!

Jan

Dňa streda, 21. októbra 2015 18:04:47 UTC+2 Ben Arthur napísal(-a):
>
> element-wise multiplication of string vectors works too, but only if one 
> vector is of length 1:
>
> julia> @time ["["] .* ["as", "sdf", "qwer"] .* ["]"] 
> 0.33 seconds (35 allocations: 1.656 KB) 
> 3-element Array{ASCIIString,1}: 
> "[as]" 
> "[sdf]" 
> "[qwer]"
>
> if you prefer this syntax to map or comprehension, extending .* as follows 
> uses less memory:
>
> julia> import Base.(.*) 
>
> julia> (.*){T<:AbstractString}(v::Vector{T},s::T) = [i*s for i in v] 
> .* (generic function with 36 methods) 
>
> julia> (.*){T<:AbstractString}(s::T,v::Vector{T}) = [s*i for i in v] 
> .* (generic function with 37 methods)
>
> julia> @time "[" .* ["as", "sdf", "qwer"] .* "]" 
> 0.10 seconds (19 allocations: 1024 bytes) 
> 3-element Array{ASCIIString,1}: 
> "[as]" 
> "[sdf]" 
> "[qwer]"
>
> see https://github.com/JuliaLang/julia/issues/13053
>

Re: [julia-users] Re: dynamically describing inner constructors

[Yichao Yu]

On Thu, Oct 22, 2015 at 10:55 AM, Dan  wrote:
> Oops, random click on post.
> So:
> function MyType(..)
> :
> :
> fieldvalues = Any[val1,val2,val3]
>   fnames = fieldnames(MyType)
>   for i=1:length(fnames)
> setfield!(newobj,fname[i],fieldvalues[i])
>   end
>   return newobj
> end

This doesn't work for immutables

Just to follow up on my mention of @generated in the original issue.
Adding a inner constructor like the following (and calling this
constructor instead of new) should work (although I also agree it's
not a great idea to construct Expr(:new) manually)

```
@generated Positive_Vec(args...) =
   Expr(:new, Positive_Vec, [:(args[$i]) for i in
1:length(args)]...)
```

Also note that apply(f, args) is always equivalent to f(args...) so
you don't need to use it in any case.

>
> On Thursday, October 22, 2015 at 5:52:34 PM UTC+3, Dan wrote:
>>
>> the inner constructor, can separate allocation and initialization of a new
>> object. specifically, first do a:
>> newobj = new()
>> then you can set the fields. with a loop this can look like:
>>   fieldvalues = Any[val1,val2,val3]
>>
>>
>> On Thursday, October 22, 2015 at 4:14:51 PM UTC+3, Sloan Lindsey wrote:
>>>
>>> I am trying to make some nice inner constructors for an immutable that
>>> acts as a nice container. I've run into a bit of a problem with using the
>>> new constructor since I wish to have dynamic construction to avoid having to
>>> hardcode the hierarchy.
>>>
>>>
>>> #apply new troubles
>>>
>>>
>>> immutable Vec3
>>>   x::Float64
>>>   y::Float64
>>>   z::Float64
>>> end
>>>
>>>
>>> immutable Min_Discription
>>>   postion::Array{Vec3}
>>>   valid::Bool
>>>   angry_butter_fly_quotient::Float64
>>> end
>>>
>>>
>>> immutable Positive_Vec
>>>   position::Array{Vec3}
>>>   positive::BitArray
>>>   valid::BitArray
>>>   angry_butter_fly_quotient::Array{Float64}
>>>
>>>
>>>   function Positive_Vec(elves::Array{Min_Discription})
>>> size = length(elves)
>>> #automagically initialize all the data!
>>> defaults=((Type{Array{Vec3}},Vec3,null_pos),
>>>   (Type{Array{Int}},Int, -1),
>>>   (Type{BitArray},Bool,false),
>>>   (Type{Array{Float64}},Float64, -Inf))
>>>
>>>
>>>   data_types = [fieldtype(Positive_Vec,x) for x in
>>> fieldnames(Positive_Vec)]
>>>   declare_list = Array(Any,length(data_types))
>>>
>>>
>>>   for i in 1:length(data_types)
>>> for (d_type,primitive, default) in defaults
>>>   if d_type == data_types[i]
>>> if d_type != Type{BitArray}
>>>   declare_list[i] = Array(primitive, size)
>>>   fill!(declare_list[i], default)
>>> else
>>>   declare_list[i] = BitArray(size)
>>>   fill!(declare_list[i], default)
>>> end
>>>   end
>>> end
>>>   end
>>>   #defaults populated. Now overwrite data passed in
>>>   for entry in fieldnames(Min_Discription)
>>> for (name,index) in enumerate(fieldnames(Positive_Vec))
>>>   if entry==name
>>> for (elf,i) in enumerate(elves)
>>>   declare_list[index][i]=elf.(entry)
>>> end
>>>   end
>>> end
>>>   end
>>>   #now we worry about a few special cases
>>>
>>>
>>>
>>>
>>>   for (symbol, index) in enumerate(fieldnames(Positive_Vec))
>>> name = string(symbol)
>>> if name=="positive"   # set the size of the structure
>>>   for i in 1:length(elves)
>>> declare_list[index][i] = elves[i].position.z>0.0
>>>   end
>>> end
>>>   end
>>>   return new(declare_list...)#apply(new, declare_list)
>>> end
>>>
>>>
>>> end
>>>
>>>
>>>   a = Min_Discription(Vec3(0.0,0.0,0.0),true,73.27113)
>>>   b = Min_Discription(Vec3(0.0,0.31,1.0),true,892.73165)
>>>   c = Min_Discription(Vec3(0.8364,7.4,500.0),true,4.0)
>>>
>>>
>>>   elves = Array(Min_Discription,3)
>>>   elves[1],elves[2],elves[3]= a,b,c
>>>   Positive_Vec(elves)
>>>
>>>
>>>
>>> julia> include("apply_new_troubles.jl")
>>> ERROR: LoadError: syntax: ... is not supported inside "new"
>>>  in include at boot.jl:261
>>>  in include_from_node1 at loading.jl:304
>>>
>>> trying to use apply(new, declare_list) doesn't work either.
>>>
>>> I'm being pointed towards making a an expression and doing some macro
>>> things over here:
>>> https://github.com/JuliaLang/julia/issues/13700#issuecomment-149861728
>>> and the developers actually told me this was a use question so I'm here.
>>>
>>> In summary is there a good way to dynamically describe an inner
>>> constructor in julia?
>>>
>>> Presently, I'm thinking of something to emulate the missing splat
>>> functionality (whether it be interpolation or some @generated code), Or even
>>> moving the entire generation part into a macro, since all the dynamic parts
>>> are known at compile time (I simply wish to avoid a wall of hardcoded
>>> variables that will be 

[julia-users] Parallel loop

[amiksvi]

Hi all,

I swear I tried to look into the documentation or online but I can't figure 
out what I want to do.
I have a lot of sequential code executed and at some point I want to 
parallelize the following loop:

mat_a = zeros(n, n)
for i = 1:n
mat_a[i,i:n] = mean(mat_b[:,i] .* mat_b[:,i:n], 1)
end

with mat_b being computed before.

I have a bunch of questions in order to better understand things:

- how to best choose the number of procs with which I run julia?
- since each operation on the rows of mat_a can be done independently from 
the others, I'd like to send mat_b to each worker so that it can compute 
certain lines of the matrix mat_a in the form of an array of vector which I 
would concatenate afterwards to retrieve mat_a. I wanted to send mat_b with 
the @everywhere macro but it seems this works only for definitions of 
variables directly on a worker. I don't know how to send already computed 
data to a specific worker.
- more generally, is this the best approach to parallelizing this kind of 
code?

Any advice appreciated,

Thanks a lot,

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

[Christoph Ortner]

On Thursday, 22 October 2015 10:24:50 UTC+1, Andras Niedermayer wrote:
>
> You're making a good point about an Array being sometimes faster than a 
> LinSpace. But a LinSpace gets you a factor N improvement in terms of memory 
> efficiency for a size N range, an Array only gets you a constant factor 
> improvement in speed (the factor 15 being admittedly relatively large in 
> this example).
>
> Memory efficiency typically matters more for usability in an exploratory 
> interactive session: if my Julia session needs 5 GB RAM, a factor 3 
> increase of memory will crash my computer. If my code runs for 10 seconds 
> in an interactive session, 30 seconds is mildly annoying, but not a deal 
> breaker. (Obviously, you can construct different examples with memory/time 
> where this is different. But my point is that inconvenience changes 
> discontinuously in memory usage.)
>

In my domain (PDEs and related), memory usage is hardly ever an issue for 
one-dimensional arrays (as in I cannot for the life of me think of a case 
where it is). I don't know about other domains of course.

Christoph

Re: [julia-users] Julia object Destructor or module Unload routine

[rafzalan]

Interesting, although, I don't know how to do such hooking ... 

On Thursday, October 22, 2015 at 6:21:05 PM UTC+3:30, Stefan Karpinski 
wrote:
>
> There's also atexit:
>
>   atexit(f)
>
>   Register a zero-argument function f() to be called at process exit. 
> atexit() hooks
>   are called in last in first out (LIFO) order and run before object 
> finalizers.
>
> On Thu, Oct 22, 2015 at 10:48 AM, Yichao Yu  > wrote:
>
>> On Thu, Oct 22, 2015 at 9:42 AM,   
>> wrote:
>> > Hi Julia-Users
>> > I know that Julia has a Garbage Collector that is being aware of 
>> unusable
>> > memory pointers. [ref] I think some other languages e.g. Java also do it
>> > automatically, and Java programmers rarely need to do it manually [ref],
>> > while writing such routines is very common in C++ [ref].
>> > Is it possible to have something like Java finalize or C++ ~ in Julia?
>> > This routine may be called
>> >- by Julia REPL when a kill signal (Ctrl+D) is sent.
>> >- or workspace() is called.
>> >- or by Garbage Collector before removing a pointer.
>>
>> We do have finalizer
>> However, there's a few things to note.
>> * The finalizer is run by the GC. Don't call `gc()` in it (it will be
>> no-op). (Actually, don't ever call gc() unless you are absolutely sure
>> you know what you are doing and you need it)
>> * We will never have garentee on when, how or in which order the
>> finalizers are called, which I think is common in tracing GCs.
>> * Do not use the finalizer to manage resources you care about. The GC
>> doesn't (yet) have any notion of resources pressure other than the GC
>> memory usage so it may not collect your resources at the time you
>> want. You should explicitly free those resources (the `do` block,
>> try/finally, wrap one of these in macro etc)
>>
>> > type mytype
>> >   mytype()=new()
>> >   function ~mytype()
>> >  close(file)
>> >  free(memory)
>> >  kill(externals)
>> >  delete(temps)
>> >  gc()
>> >   end
>> >   file::File
>> >   memory::Pointer
>> >   externals::Any
>> >   temps::File
>> > end
>> > module mymodule
>> >   function unload()
>> >  close(file)
>> >  free(memory)
>> >  kill(externals)
>> >  delete(temps)
>> >  gc()
>> >   end
>> >   file::File
>> >   memory::Pointer
>> >   externals::Any
>> >   temps::File
>> > end
>> >
>>
>
>

[julia-users] Re: How to feval?

[Alex Ames]

You could define your own feval:

feval(fn_str, args...) = eval(parse(fn_str))(args...)

This has the advantage of accepting anonymous functions and multiple 
arguments if necessary:
julia> feval("sin",5.0)
-0.9589242746631385

julia> fn_str = "a_plus_b(a,b) = a + b"
"a_plus_b(a,b) = a + b"

julia> feval(fn_str,2,3)
5

On Thursday, October 22, 2015 at 8:20:33 AM UTC-5, J Luis wrote:
>
> Thanks, at least it's a place to start.
>
> quinta-feira, 22 de Outubro de 2015 às 14:10:44 UTC+1, Kristoffer Carlsson 
> escreveu:
>>
>> Maybe
>>
>> julia> eval(Symbol("sin"))(5.0)
>> -0.9589242746631385
>>
>> Not sure if this is the best solution.
>>
>>
>> On Thursday, October 22, 2015 at 2:57:31 PM UTC+2, J Luis wrote:
>>>
>>> Hi,
>>>
>>> I need to convert this piece of Matlab code
>>>
>>>   [ps, orig_path] = feval(str2func(test), out_path);
>>>
>>> where 'test' is the name of a function and 'out_path' it unique input 
>>> argument. I have read and re-read the eval function and for once it's clear 
>>> for me how it works (sorry, I find this sentence highly cryptic "Evaluate 
>>> an expression in the given module and return the result" ) but worst, I 
>>> don't see anywhere how it could call a function with input arguments.
>>>
>>> How can I achieve the same result in Julia?
>>>  
>>> Thanks. 
>>>
>>

[julia-users] map() vs broadcast()

[Ján Dolinský]

Hi,

I am exploring Julia's map() and broadcast() functions. I did a simple 
implementation of MAPE (mean absolute percentage error) using broadcast() 
and map(). Interestingly, the difference in performance was huge.

A = rand(5_000_000)
F = rand(5_000_000)

_f(a,f) = (a - f) / a

function mape3(A, F)
# A - actual target values
# F - forecasts (model estimations)

  tmp = similar(A)
  broadcast!(_f, tmp, A, F)
  100 * sumabs(tmp) / length(A)

end

function mape4(A, F)
# A - actual target values
# F - forecasts (model estimations)

  tmp = similar(A)
  map!(_f, tmp, A, F)
  100 * sumabs(tmp) / length(A)

end

@time mape3(A,F) # after JIT warm-up
  0.038686 seconds (8 allocations: 38.147 MB, 2.25% gc time)
876.4813057521973

@time mape4(A,F) # after JIT warm-up
  0.457771 seconds (20.00 M allocations: 343.323 MB, 11.29% gc time)
876.4813057521973

I wonder why map() is so much slower ?

Thanks,
Jan

Re: [julia-users] Re: parse of string followed by number turned into @doc ?

[Michael Francis]

Coming back to this -- this appears to cause inconsistencies - It is not so 
much that that you can doc a float, but more that the behavior is 
surprising. 



julia> "hello" 2.3
  hello


julia> "hello" (x)->x+1


WARNING: deprecated syntax "hello (".
Use "hello(" instead.
ERROR: syntax: ""hello"(x)" is not a valid function argument name


julia> "hello" z() = 1
z (generic function with 1 method)


julia> "hello" "world"
  hello


julia> "hello" "world" "again"
ERROR: syntax: extra token """ after end of expression


julia> "hello" type foo end


julia> 


julia> function bar()
   "hello" 1.23
ERROR: syntax: extra token "1.23" after end of expression

julia> "hello" x = 2
  hello




On Saturday, October 10, 2015 at 2:04:39 PM UTC-4, Stefan Karpinski wrote:
>
> While it's a bit odd to document numbers, making the criteria for whether 
> something is a doc string or not as simple as possible seems like it may be 
> a good thing, even if this particular instance of the syntax isn't terribly 
> useful.
>
> On Sat, Oct 10, 2015 at 9:47 PM, Isaiah Norton  > wrote:
>
>> I agree with MDC Francis that this is kind of odd. Is it common to doc 
>> arbitrary numbers? Supporting this isnt necessary to doc MathConsts...
>>
>> (it also didn't seem to work properly for ints or floats when I tried -- 
>> the doc was added to meta, but help didn't seem to find it).
>> On Oct 10, 2015 11:50 AM, "Michael Hatherly" > > wrote:
>>
>>> If you want to disable the automatic @doc then you can append a ; to 
>>> the string or nest the expressions in a begin ... end block:
>>>
>>> "hello";
>>> 3.142
>>>
>>> begin
>>> "hello"
>>> 3.142
>>> end
>>>
>>> — Mike
>>> ​
>>>
>>>
>>> On Friday, 9 October 2015 22:02:37 UTC+2, Michael Francis wrote:

 Julia 0.4 rc4 

 I get the following unexpected (to me) behavior - 

 julia> parse( "\"hello\"\n3.142" )
 :(@doc "hello" 3.142)

 is this intentional ? 


>

Re: [julia-users] good textbook for Julia software engineering?

[Steven G. Johnson]

On Thursday, October 22, 2015 at 11:31:49 AM UTC-4, Stefan Karpinski wrote:
>
> The Pragmatic Programmer 
> 
>  
> is pretty good. It takes view of someone doing for-pay software 
> engineering, which isn't entirely applicable, but many of the basic lessons 
> (don't repeat yourself, use version control, etc.) are very much 
> applicable. It's a short, easy read so probably worthwhile.
>

Thanks, Stefan, that sounds perfect. 

Re: [julia-users] Julia and Object-Oriented Programming

[ggggg]

What is the other option here? It seemed like with the OO/Julia way you are 
complaining about you at least have working (but slow) code handling your 
new polynomial type. In a case where your new type doesn't work with 
"obtainCoefficient", it won't 
work with any of your other code either. You would just have no working 
code with your new polynomial type. How is that better?

But the next week, someone asks whether you can handle polynomials 
> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
> polynomials in this format, "obtainCoefficient" is expensive and would not 
> be regarded as a simple "getter" operation.  If many people had already 
> written functions invoking the 'obtainCoefficient' method, then you would 
> be stuck.  You would retrospectively realize that the obtainCoefficient 
> member function was not a good idea.  This example is typical of open-ended 
> scientific software projects.
>
>>
>>

[julia-users] Converting an expression to the function

[Jānis Erdmanis]

I am implementing boundary element method with curved elements. As it is 
daunting task to evaluate derivatives I thought about using `Calculus` 
symbolic differentiation which as output gives expression. Now I need to 
convert this expression to a function, but how can I do it?

As an example consider
expr = :(x + y)
how can I convert it to the function?
function f(x,y)
# Some magic here
end

[julia-users] Why am I getting this error?

[Diego Javier Zea]

I am running this script 
 on 
a large list (92003 lines) of files. At some point I'm getting this error 
(unrelated to the files since works fine for a while if I continue from the 
last file):

ERROR (unhandled task failure): EOFError: read end of file
 in read at stream.jl:907
 in message_handler_loop at multi.jl:847
 in process_tcp_streams at multi.jl:836
 in anonymous at task.jl:63
Worker 3 terminated.
ERROR (unhandled task failure): EOFError: read end of file
 in read at stream.jl:907
 in message_handler_loop at multi.jl:847
 in process_tcp_streams at multi.jl:836
 in anonymous at task.jl:63


How can I solve this?

Best,

[julia-users] Re: Questions about ranges

[Rory Finnegan]

Wow, you're right, that is a more serious bug.

On Thursday, 22 October 2015 02:29:13 UTC-5, andy hayden wrote:
>
> > I don't really understand why you can't just use the StepRange for 
> everything
>
> You could. However, you can be more efficient by having special types 
> (e.g. with UnitRange you don't need to check the steps).
>
> >  `findin(::UnitRange, ::UnitRange)` returns another UnitRange
>
> This seems good.
>
> > `findin(::StepRange, ::StepRange)` returns an array of the indices
>
> You might be able to do some maths here to return a StepRange... at least 
> for Integers:
>
> function Base.findin{T <: Integer}(a::StepRange{T}, b::StepRange{T})
> start = ??
> step = b.step ÷ gcd(a.step, b.step)
> stop = max(a.stop, b.stop)
> start:step:stop
> end
>
> but I 'm not sure this is possible with floats...
>
> Looking in the source mentioning UnitRange here's a more serious bug: 
> https://github.com/JuliaLang/julia/blob/e16c6784e1ba6f24b6faf0d282c78d8c14a1fbb3/base/array.jl#L866
>
> julia> findin([5.2, 3.3], 3:20)
> 2-element Array{Int64,1}:
>  1
>  2
>
> julia> findin([5.2, 3.3], 3:1:20)
> 0-element Array{Int64,1}
>
> !
>
> On Wednesday, 21 October 2015 19:59:20 UTC-7, Rory Finnegan wrote:
>>
>> Hi folks,
>>
>> I just had a couple questions about ranges that maybe someone can answer.
>>
>>
>> 1) Why are there so many Range types? There is a UnitRange (start, stop), 
>>  a StepRange (start, step, stop), and a FloatRange(start, step, length, 
>> divisor), but I don't really understand why you can't just use the 
>> StepRange for everything. Maybe I'm just missing some obvious use cases, 
>> but this seems to lead to inconsistent or confusing behaviour like the 1 in 
>> my second question.
>>
>> 2) `findin` seems to have inconsistent behaviour for ranges depending on 
>> types in the ranges. `findin(::UnitRange, ::UnitRange)` returns another 
>> UnitRange, but `findin(::StepRange, ::StepRange)` returns an array of the 
>> indices. Is there some reason that these shouldn't be consistent?
>>
>> Ex:
>> ```
>> julia> findin(1:10, 2:5)
>> 2:5
>>
>> julia> findin(1:1:10, 2:2:5)
>> 2-element Array{Int64,1}:
>>  2
>>  4
>>
>> julia> r1 = DateTime(now())-Dates.Day(60):DateTime(now())
>> 2015-08-22T19:07:47:1 day:2015-10-21T19:07:47
>>
>> julia> r2 = r1[1:20]
>> 2015-08-22T19:07:47:1 day:2015-09-10T19:07:47
>>
>> julia> findin(r1, r2)
>> 20-element Array{Int64,1}:
>>   1
>>   2
>>   3
>>   4
>>   5
>>   6
>>   7
>>   8
>>   9
>>  10
>>  11
>>  12
>>  13
>>  14
>>  15
>>  16
>>  17
>>  18
>>  19
>>  20
>> ```
>>
>

[julia-users] Re: good textbook for Julia software engineering?

[Cedric St-Jean]

On Thursday, October 22, 2015 at 11:33:39 AM UTC-4, Sisyphuss wrote:
>
> I have some idea in the previous post. But it seems that they are just 
> ignored...
>

Not to derail this thread, but FWIW, I liked your OOP equivalences, and it 
made me consider writing shorter, focused modules.
 

>
>
> On Thursday, October 22, 2015 at 4:56:58 PM UTC+2, Steven G. Johnson wrote:
>>
>> Many of my students come from a non-CS background, and aren't familiar 
>> with basic ideas of software engineering like modularity, choosing 
>> datastructures, putting code into re-usable functions rather than writing 
>> long copy-and-paste scripts, etcetera.   I'd like to point them at a good 
>> book, but I mostly didn't learn this stuff from books and don't know what 
>> is out there.
>>
>> Is there a good book on basic software engineering that is easily 
>> applicable to Julia?   (This rules out a lot of the "design patterns" style 
>> books that are heavily oriented towards traditional OOP languages.)
>>
>> --SGJ
>>
>

[julia-users] Re: Why am I getting this error?

[Diego Javier Zea]

Looks like it's using too much RAM and the system is killing it. I get 
a: ProcessExitedException()

El jueves, 22 de octubre de 2015, 13:09:21 (UTC-3), Diego Javier Zea 
escribió:
>
> I am running this script 
>  
> on a large list (92003 lines) of files. At some point I'm getting this 
> error (unrelated to the files since works fine for a while if I continue 
> from the last file):
>
> ERROR (unhandled task failure): EOFError: read end of file
>  in read at stream.jl:907
>  in message_handler_loop at multi.jl:847
>  in process_tcp_streams at multi.jl:836
>  in anonymous at task.jl:63
> Worker 3 terminated.
> ERROR (unhandled task failure): EOFError: read end of file
>  in read at stream.jl:907
>  in message_handler_loop at multi.jl:847
>  in process_tcp_streams at multi.jl:836
>  in anonymous at task.jl:63
>
>
> How can I solve this?
>
> Best,
>

[julia-users] DataFrame type specification

[Andrew Gibb]

I have a csv with some data. One of the columns is something I'd always 
like to be read as a string, although sometimes the value will just be 
numerals. Is there some way to specify that I want this column to be an 
AbstractString in readtable? Or perhaps some way to convert that column 
from (say) integers to strings once loaded?

Thanks

Andy