[julia-users] Re: Optimizing Function Injection in Julia

[Christopher Alexander]

Yea, can someone explain the proper syntax here?  What would be the case if 
I wanted to build a callable type?  What if I want to do something like 
this?

call{T <: MyAbstractType)(t::T, a::Int) = t.a + a

Thanks!

Chris

On Sunday, January 31, 2016 at 4:27:00 AM UTC-5, Bryan Rivera wrote:
>
> I just realized #13412  has 
> been merged.
>
> What should this look like now that `Base.call(...)` is deprecated?
>
> Thinking something like:
>
> (_::SomeCallBack)(c) = _.z + c
>
>
> On Sunday, January 31, 2016 at 3:47:03 AM UTC-5, Bryan Rivera wrote:
>>
>> Cedric, I refactored the problem and this works well.
>>
>> What do you mean "I would favor using a regular function call with a 
>> descriptive name"?
>>
>> I was thinking replace `Base.call` with a function name.  But that does 
>> not work if the function is in the top-level scope in another file.
>>
>> On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean wrote:
>>>
>>> Something like this?
>>>
>>> function function1(a, b, f) # Variable needed in callback fun injected.
>>> if(a > b)
>>>   c = a + b
>>>   res = f(c) # Callback function has been injected.
>>>   return res + 1
>>> else
>>>   # do anything
>>>   # but return nothing
>>> end
>>> end
>>>
>>> type SomeCallBack
>>> z::Int
>>> end
>>> Base.call(callback::SomeCallBack, c) = c + callback.z
>>>
>>> function1(2, 1, SomeCallBack(10))
>>>
>>> Because of JIT, this is 100% equivalent to your "callback function has 
>>> been injected" example, performance-wise. My feeling is that .call 
>>> overloading is not to be abused in Julia, so I would favor using a regular 
>>> function call with a descriptive name instead of call overloading, but the 
>>> same performance guarantees apply. Does that answer your question?
>>>
>>> On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera wrote:

 I think what I wrote above might be too complicated, as it is an 
 attempt to solve this problem.

 In essence this is what I want: 



 function function1(a, b, onGreaterThanCallback)
   if(a > b)
 c = a + b
 res = onGreaterThanCallback(c, z)
 return res + 1
   else
 # do anything
 # but return nothing
   end
 end


 global onGreaterThanCallback = (c) -> c + z

 function1(a, b, onGreaterThanCallback)


 Problems:

 The global variable.

 The anonymous function which has performance impact (vs other 
 approaches).  We could use Tim Holy's @anon, but then the value of `z` is 
 fixed at function definition, which we don't always want.

 I think that the ideal optimization would look like this:

   function function1(a, b, z) # Variable needed in callback fun 
 injected.
 if(a > b)
   c = a + b
   res = c + z # Callback function has been injected.
   return res + 1
 else
   # do anything
   # but return nothing
 end
   end


   function1(a, b, z)

 In OO languages we would be using an abstract class or its equivalent. 
  But I've thought about it, and read the discussions on interfaces, and 
 don't see those solutions optimizing the code out like I did above.

 Any ideas?

>>>

Re: [julia-users] Re: Optimizing Function Injection in Julia

[Bryan Rivera]

"the type parameter can simply be replaced with the abstract type itself. " 
 I believe I was having trouble with this.  Could be part of the bug.
 

Re: [julia-users] Re: Optimizing Function Injection in Julia

[Bryan Rivera]

Yichao, try it on 0.5.0-dev+2422

julia> type SomeCallBack
   z::Int 
   end 

julia> (_::SomeCallBack)(c) = _.z + c 

julia> s = SomeCallBack(24) 

SomeCallBack(24) 

julia> s(10) 

34






On Sunday, January 31, 2016 at 4:01:09 PM UTC-5, Yichao Yu wrote:
>
> On Sun, Jan 31, 2016 at 1:10 PM, Christopher Alexander 
>  wrote: 
> > Yea, can someone explain the proper syntax here?  What would be the case 
> if 
> > I wanted to build a callable type?  What if I want to do something like 
> > this? 
> > 
> > call{T <: MyAbstractType)(t::T, a::Int) = t.a + a 
>
> If the parameter is not used otherwise you can simply do 
>
> `(t::MyAbstractType)(a::Int) = t.a + a` 
>
>
> Simply using a type parameter doesn't seem to work and that feels like 
> a bug to me. 
>
>
> > 
> > Thanks! 
> > 
> > Chris 
> > 
> > 
> > On Sunday, January 31, 2016 at 4:27:00 AM UTC-5, Bryan Rivera wrote: 
> >> 
> >> I just realized #13412 has been merged. 
> >> 
> >> What should this look like now that `Base.call(...)` is deprecated? 
> >> 
> >> Thinking something like: 
> >> 
> >> (_::SomeCallBack)(c) = _.z + c 
> >> 
> >> 
> >> On Sunday, January 31, 2016 at 3:47:03 AM UTC-5, Bryan Rivera wrote: 
> >>> 
> >>> Cedric, I refactored the problem and this works well. 
> >>> 
> >>> What do you mean "I would favor using a regular function call with a 
> >>> descriptive name"? 
> >>> 
> >>> I was thinking replace `Base.call` with a function name.  But that 
> does 
> >>> not work if the function is in the top-level scope in another file. 
> >>> 
> >>> On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean 
> wrote: 
>  
>  Something like this? 
>  
>  function function1(a, b, f) # Variable needed in callback fun 
> injected. 
>  if(a > b) 
>    c = a + b 
>    res = f(c) # Callback function has been injected. 
>    return res + 1 
>  else 
>    # do anything 
>    # but return nothing 
>  end 
>  end 
>  
>  type SomeCallBack 
>  z::Int 
>  end 
>  Base.call(callback::SomeCallBack, c) = c + callback.z 
>  
>  function1(2, 1, SomeCallBack(10)) 
>  
>  Because of JIT, this is 100% equivalent to your "callback function 
> has 
>  been injected" example, performance-wise. My feeling is that .call 
>  overloading is not to be abused in Julia, so I would favor using a 
> regular 
>  function call with a descriptive name instead of call overloading, 
> but the 
>  same performance guarantees apply. Does that answer your question? 
>  
>  On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera 
> wrote: 
> > 
> > I think what I wrote above might be too complicated, as it is an 
> > attempt to solve this problem. 
> > 
> > In essence this is what I want: 
> > 
> > 
> > 
> > function function1(a, b, onGreaterThanCallback) 
> >   if(a > b) 
> > c = a + b 
> > res = onGreaterThanCallback(c, z) 
> > return res + 1 
> >   else 
> > # do anything 
> > # but return nothing 
> >   end 
> > end 
> > 
> > 
> > global onGreaterThanCallback = (c) -> c + z 
> > 
> > function1(a, b, onGreaterThanCallback) 
> > 
> > 
> > Problems: 
> > 
> > The global variable. 
> > 
> > The anonymous function which has performance impact (vs other 
> > approaches).  We could use Tim Holy's @anon, but then the value of 
> `z` is 
> > fixed at function definition, which we don't always want. 
> > 
> > I think that the ideal optimization would look like this: 
> > 
> >   function function1(a, b, z) # Variable needed in callback fun 
> > injected. 
> > if(a > b) 
> >   c = a + b 
> >   res = c + z # Callback function has been injected. 
> >   return res + 1 
> > else 
> >   # do anything 
> >   # but return nothing 
> > end 
> >   end 
> > 
> > 
> >   function1(a, b, z) 
> > 
> > In OO languages we would be using an abstract class or its 
> equivalent. 
> > But I've thought about it, and read the discussions on interfaces, 
> and don't 
> > see those solutions optimizing the code out like I did above. 
> > 
> > Any ideas? 
>

Re: [julia-users] Re: Optimizing Function Injection in Julia

[Yichao Yu]

On Sun, Jan 31, 2016 at 4:25 PM, Bryan Rivera  wrote:
> Working on 0.5.0-dev+2422:
>
> julia> type SomeCallBack
>z::Int
>end
>
> julia> (_::SomeCallBack)(c) = _.z + c
>
> julia> s = SomeCallBack(24)
>
> SomeCallBack(24)
>
> julia> s(10)
>
> 34
>
> julia> @code_llvm s(10)
>
> define i64 @julia_SomeCallBack_23730(%jl_value_t*, i64) #0 {
>
> top:
>   %2 = bitcast %jl_value_t* %0 to i64*
>   %3 = load i64, i64* %2, align 16
>   %4 = add i64 %3, %1
>   ret i64 %4
> }
>
>
> I tried various combos with parametric types to no avail.
>
>

This is essentially the same with the code I had that **works**, what
does not work currently is

```
julia> abstract A

julia> (t::T){T<:A}() = t
ERROR: function type in method definition is not a type
```

which should be the equivalence of

```
julia> call{T<:A}(t::T) = t

WARNING: deprecated syntax "call(t::T, ...)".
Use "(t::T)(...)" instead.
ERROR: function type in method definition is not a type
```

As I mentioned, I agree that this itself won't be useful since the
type parameter can simply be replaced with the abstract type itself.
However, this would be useful if the type parameter is used somewhere
else too. e.g.

```
julia> (t::T){T<:A}(t2::T) = t
ERROR: function type in method definition is not a type
```

And this is why I think it's a bug.

Re: [julia-users] Escher example problem

[Shashi Gowda]

I believe this to be fixed now?

On Mon, Jan 11, 2016 at 1:09 PM, Leonardo  wrote:

> Hi, I've a problem running Escher's example plotting.jl caused by Gadfly:
>
> WARNING: using Gadfly.render in module Main conflicts with an existing
> identifier.
> WARNING: Method definition convert(Type{Escher.Tile}, Gadfly.Plot) in
> module Escher at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/lazyload.
> jl:73 overwritten in module Main at C:\Users\Leonardo\.julia\v0.4\Escher\
> src\basics\lazyload.jl:73.
> WARNING: Error requiring DataFrames from Main:
> LoadError: error in method definition: function Escher.render must be
> explicitly imported to be extended
>  in include at boot.jl:261
>  in include_from_node1 at loading.jl:304
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:60
>  in err at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:47
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:59
>  in withpath at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:37
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:58
>  in listenmod at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:21
>  in include at boot.jl:261
>  in include_from_node1 at loading.jl:304
>  in external_setup at C:\Users\Leonardo\.julia\v0.4\Escher\src\Escher.jl:
> 53
>  in include at boot.jl:261
>  in include_from_node1 at loading.jl:304
>  in loadfile at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl:17
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl:164
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:15
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>  in splitquery at C:\Users\Leonardo\.julia\v0.4\Mux\src\basics.jl:28
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>  in wcatch at C:\Users\Leonardo\.julia\v0.4\Mux\src\websockets_integration
> .jl:12
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>  in todict at C:\Users\Leonardo\.julia\v0.4\Mux\src\basics.jl:21
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:12 (repeats
> 2 times)
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\server.jl:38
>  in handle at C:\Users\Leonardo\.julia\v0.4\WebSockets\src\WebSockets.jl:
> 382
>  in on_message_complete at C:\Users\Leonardo\.julia\v0.4\HttpServer\src\
> HttpServer.jl:393
>  in on_message_complete at C:\Users\Leonardo\.julia\v0.4\HttpServer\src\
> RequestParser.jl:104
>  in http_parser_execute at C:\Users\Leonardo\.julia\v0.4\HttpParser\src\
> HttpParser.jl:92
>  in process_client at C:\Users\Leonardo\.julia\v0.4\HttpServer\src\
> HttpServer.jl:365
>  in anonymous at task.jl:447
> while loading C:\Users\Leonardo\.julia\v0.4\Escher\src\library\table.jl,
> in expression starting on line 34
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> in call at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> in call at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> in call at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
> Error handling websocket connection:
> MethodError: `isfinished` has no method matching isfinished(::Compose.
> Patchable)
>  in draw at C:\Users\Leonardo\.julia\v0.4\Compose\src\container.jl:430
>  in compose_render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics\
> lazyload.jl:54
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics\lazyload.jl:
> 63
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/tile.jl:89
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:
> 290
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:
> 462
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:
> 471
>  in start_updates at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl
> :115
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl:181
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:15
>  in anonymous at 

Re: [julia-users] Escher global and local context

[Shashi Gowda]

Hi Leonardo

If you have a single Escher process serving multiple requests and you want
to share some state between them, my recommendation would be to put the
shared data in signal, which can optionally be persisted to disk/DB

something like

if !isdefined(:my_global_var) # this condition makes sure all your UIs are
referring to the same variable
my_global_signal = Signal(Any, initial_value)

# you could also persist this to disk/DB for re-reading later, if you
have a function that can do that.
Reactive.foreach(save_to_disk, my_global_signal)

# optionally you could save throttle(1.0, my_global_signal) to make
sure the state is saved at most once every second so as to not hit the disk
often
end

function main(window)
   # ... use my_global_signal here, to get and put updates: every client
will be notified of updates...
end



On Sun, Jan 31, 2016 at 5:47 PM, Leonardo  wrote:

> Hi all,
> I want write an application with a Web UI (e.g. a chat) that has a local
> state (specific for each client) and global one (a state bind to web
> server).
> These requirements are useful for example to permit communications between
> different client (e.g. into a chat) and/or handle centralized resources
> (like a DB connection shared by all client and created once into web
> server).
>
> How can I do that?
>
> Many thanks in advance
>
> Leonardo
>
>

[julia-users] Re: SharedArray / parallel question

[Christopher Alexander]

Is this something that would really only be solved by proper 
multi-threading?

On Saturday, January 30, 2016 at 12:49:50 PM UTC-5, Christopher Alexander 
wrote:
>
> I can confirm that I do not see the seg fault issue in 0.5 (the latest 
> master), but I am getting fundamentally different results when using the 
> @sync @parallel construction.  In essence, @sync @parallel is causing 
> arrays of different values (compared to using a non-parallelized 
> construction) to be built, which is causing an issue further along in my 
> program.  It is also much slower, so I am wondering if I my syntax is 
> incorrect.
>
> Any input would be appreciated.  You can see what is supposed to be 
> generated by loading this script (
> https://github.com/pazzo83/QuantJulia.jl/blob/master/swaption_test_code.jl) 
> and calling main().
>
> Thanks!
>
> On Saturday, January 30, 2016 at 4:48:51 AM UTC-5, Lutfullah Tomak wrote:
>>
>> There is this issue on on github 
>> https://github.com/JuliaLang/julia/issues/14764 . I am no expert about 
>> parallel computing but may be related.
>>
>> Regards
>>
>

Re: [julia-users] Re: Optimizing Function Injection in Julia

[Yichao Yu]

On Sun, Jan 31, 2016 at 1:10 PM, Christopher Alexander
 wrote:
> Yea, can someone explain the proper syntax here?  What would be the case if
> I wanted to build a callable type?  What if I want to do something like
> this?
>
> call{T <: MyAbstractType)(t::T, a::Int) = t.a + a

If the parameter is not used otherwise you can simply do

`(t::MyAbstractType)(a::Int) = t.a + a`


Simply using a type parameter doesn't seem to work and that feels like
a bug to me.


>
> Thanks!
>
> Chris
>
>
> On Sunday, January 31, 2016 at 4:27:00 AM UTC-5, Bryan Rivera wrote:
>>
>> I just realized #13412 has been merged.
>>
>> What should this look like now that `Base.call(...)` is deprecated?
>>
>> Thinking something like:
>>
>> (_::SomeCallBack)(c) = _.z + c
>>
>>
>> On Sunday, January 31, 2016 at 3:47:03 AM UTC-5, Bryan Rivera wrote:
>>>
>>> Cedric, I refactored the problem and this works well.
>>>
>>> What do you mean "I would favor using a regular function call with a
>>> descriptive name"?
>>>
>>> I was thinking replace `Base.call` with a function name.  But that does
>>> not work if the function is in the top-level scope in another file.
>>>
>>> On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean wrote:

 Something like this?

 function function1(a, b, f) # Variable needed in callback fun injected.
 if(a > b)
   c = a + b
   res = f(c) # Callback function has been injected.
   return res + 1
 else
   # do anything
   # but return nothing
 end
 end

 type SomeCallBack
 z::Int
 end
 Base.call(callback::SomeCallBack, c) = c + callback.z

 function1(2, 1, SomeCallBack(10))

 Because of JIT, this is 100% equivalent to your "callback function has
 been injected" example, performance-wise. My feeling is that .call
 overloading is not to be abused in Julia, so I would favor using a regular
 function call with a descriptive name instead of call overloading, but the
 same performance guarantees apply. Does that answer your question?

 On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera wrote:
>
> I think what I wrote above might be too complicated, as it is an
> attempt to solve this problem.
>
> In essence this is what I want:
>
>
>
> function function1(a, b, onGreaterThanCallback)
>   if(a > b)
> c = a + b
> res = onGreaterThanCallback(c, z)
> return res + 1
>   else
> # do anything
> # but return nothing
>   end
> end
>
>
> global onGreaterThanCallback = (c) -> c + z
>
> function1(a, b, onGreaterThanCallback)
>
>
> Problems:
>
> The global variable.
>
> The anonymous function which has performance impact (vs other
> approaches).  We could use Tim Holy's @anon, but then the value of `z` is
> fixed at function definition, which we don't always want.
>
> I think that the ideal optimization would look like this:
>
>   function function1(a, b, z) # Variable needed in callback fun
> injected.
> if(a > b)
>   c = a + b
>   res = c + z # Callback function has been injected.
>   return res + 1
> else
>   # do anything
>   # but return nothing
> end
>   end
>
>
>   function1(a, b, z)
>
> In OO languages we would be using an abstract class or its equivalent.
> But I've thought about it, and read the discussions on interfaces, and 
> don't
> see those solutions optimizing the code out like I did above.
>
> Any ideas?

[julia-users] Plotting with Plot

[digxx]

I use Plot as Plotting Device with Gadfly Backend and used 

savefig("testfile") to save my previously plotted figure..
Apparently it has some issues with the font. Do I need to load it in Julia 
seperately?

(julia.exe:6312): Pango-WARNING **: couldn't load font "Helvetica 
Not-Rotated 10.669921875px", falling back to "Sans Not-Rotated 
10.669921875px", expect ugly output.

(julia.exe:6312): Pango-WARNING **: couldn't load font "Helvetica 
Not-Rotated 14.669921875px", falling back to "Sans Not-Rotated 
14.669921875px", expect ugly output.

Re: [julia-users] Escher global and local context

[Shashi Gowda]

On Sun, Jan 31, 2016 at 11:41 PM, Shashi Gowda 
wrote:

> Hi Leonardo
>
> put the shared data in signal, which can optionally be persisted to disk/DB
>

I meant to say  "put the shared data in a global signal"

[julia-users] Sparse matrix memory preallocation?

[Gabriel Goh]

Generating a sparse matrix from scratch seems to be quite memory intensive. 
and slow. Say I wish to create a large block diagonal matrix with 2x2 block 
entries.

Doing it naively is quite slow

function f(k)
  M = spzeros(2*k,2*k)
  for i = 1:k
D = (i-1)*2 + 1:i*2
M[D,D] = randn(2,2)
  end
  return M
end

julia> @time f(1)
2.534277 seconds (239.26 k allocations: 3.013 GB, 15.58% gc time)

Is there a way to speed this up by preallocating the memory somehow?

[julia-users] Re: Optimizing Function Injection in Julia

[Bryan Rivera]

Working on 0.5.0-dev+2422:

julia> type SomeCallBack
   z::Int 
   end 

julia> (_::SomeCallBack)(c) = _.z + c 

julia> s = SomeCallBack(24) 

SomeCallBack(24) 

julia> s(10) 

34

julia> @code_llvm s(10)  

define i64 @julia_SomeCallBack_23730(%jl_value_t*, i64) #0 { 

top: 
  %2 = bitcast %jl_value_t* %0 to i64* 
  %3 = load i64, i64* %2, align 16 
  %4 = add i64 %3, %1 
  ret i64 %4 
}


I tried various combos with parametric types to no avail.

Re: [julia-users] ERROR: LoadError: OutOfMemoryError()

[jda]

I eventually resolved this problem.  I found a place in my code where I was 
using the less efficient diag(sparse(vector)) instead of the more efficient 
diagm(vector).  This ended up being crucial for performance.  Now my code 
is running on both machines with simply the laptop running slower as 
expected in comparison to the desktop.



On Tuesday, January 26, 2016 at 5:29:24 PM UTC-5, jda wrote:
>
> Thanks, I have considered much of what you mentioned while making my code 
> but of course it can always be rechecked over again for these things.  Good 
> point about float32; in my calculation precision ends up being 
> important.  I do wonder whether my code which is mostly vectorized (i.e. 
> matlab styled) is the most efficient way for matrix calculations, or if in 
> Julia the best way of calculating would be better in fact if I inserted 
> loops to replace vectorized statements.  What do you think about this?  In 
> any case the backslash operator is really the key statement that's creating 
> the OutOfMemory error and the backslash cannot be un-vectorized itself that 
> I know.  I am looking through memory cleaners or other system optimizers 
> but I am skeptical that this would be the main problem because the 8GB 
> windows computer really should have done much much better than the 4GB 
> laptop.  That is the part that I find to be most quizzical !  Could there 
> be some useful info about how memory is utilized by Julia that I am missing?
>
>
>
> On Tuesday, January 26, 2016 at 4:46:30 PM UTC-5, Milan Bouchet-Valat 
> wrote:
>>
>> Le mardi 26 janvier 2016 à 12:59 -0800, jda a écrit : 
>> > The OSes and the Julia versions are all 64-bit.  Thanks for the .exe 
>> > links, I was looking for them.  Good suggestion to install the 0.4.3 
>> > version of Julia on the mac laptop.   
>> > 
>> > What I found has led me to a different question.  I have found that 
>> > actually the same size matrix that before ran just fine on the mac 
>> > laptop no longer run -- giving the OutOfMemory error now.  So this 
>> > problem seems to *not* be related to the version of Julia but rather 
>> > the state of the system.  I must say in advance that I am trying to 
>> > push the limits -- trying to run simulations for the biggest grid 
>> > possible for the best results.  In doing so it seems that I need to 
>> > learn much more about optimizing memory usage and possible (?) other 
>> > aspects of how the system is setup?  Any info that would help me to 
>> > navigate this would be greatly appreciated. 
>> It's hard to tell without seeing the code, but in general you should 
>> avoid allocating temporary arrays by unrolling your loops and using in- 
>> place versions of functions where possible. Of course, also make sure 
>> that there is no type instability in your code which would trigger 
>> unwanted memory allocations. 
>>
>> You could also use Float32 instead of Float64 if reduced precision 
>> isn't an issue for your application. 
>>
>>
>> Regards 
>>
>>
>>
>> > 
>> > On Tuesday, January 26, 2016 at 4:53:38 AM UTC-5, Milan Bouchet-Valat 
>> > wrote: 
>> > > Le lundi 25 janvier 2016 à 21:51 -0800, jda a écrit :  
>> > > > I've run into the following problem while running a simulation 
>> > > code  
>> > > > (of a differential equation).  Because of the nature of the  
>> > > > problem, the matrices are dense.  In particular one line of code 
>> > > that  
>> > > > runs the backslash operator gives an OutOfMemory error on one  
>> > > > computer but not on another computer.  
>> > > >  
>> > > >  
>> > > > The error is:  
>> > > > ERROR: LoadError: OutOfMemoryError()  
>> > > >  in .* at arraymath.jl:118  
>> > > >  in * at abstractarraymath.jl:54  
>> > > >  in functionName at C:\Users\user\Google Drive\codefile.jl:158  
>> > > >  in include at boot.jl:261  
>> > > >  in include_from_node1 at loading.jl:304  
>> > > > while loading C:\Users\user\Google Drive\codefile.jl, in 
>> > > expression  
>> > > > starting  
>> > > >  on line 155  
>> > > >  
>> > > > (error points to  backslash operator )  
>> > > >  
>> > > >  
>> > > > Info for the computer that works fine:  
>> > > > mac laptop  
>> > > > 1.6 GHz i5 processor  
>> > > > 4 GB memory  
>> > > > 250 GB  
>> > > > running Julia 0.4.1  
>> > > >  
>> > > > Info for the computer that gives the error:  
>> > > > windows desktop  
>> > > > Intel(R) Core(TM) i5-4590 CPU @3.30GHz  
>> > > > 8 GB memory  
>> > > > 420 GB drive  
>> > > > running Julia 0.4.3  
>> > > An important information is whether these are 64-bit OSes, and 
>> > > whether  
>> > > you're using the 32-bit or 64-bit Julia. The latter will use more  
>> > > memory to store pointers and integers.  
>> > > 
>> > > > Both computers are not running any other programs, and are both  
>> > > > fairly new with plenty of space available (the computers  
>> > > > are specifically designated to run such code).  I am sure that 
>> > > my  
>> > > > next step should be to install Julia 0.4.1 on the windows 

[julia-users] Need Ref on UInt32 but not Float64

[Bryan Rivera]

For some reason I need to specify Ref{UInt32} instead of just UInt32. 
 Float64 does not seem to require the same. 

Can anyone explain this behavior?

function callbackfun(a::UInt32, b::Float64, c::UInt32)
...
end

cfunction(callbackfun, Void, (Ref{UInt32},Float64,Ref{UInt32}))  


typedef void (*CALLBACKFUN)(unsigned int z, double b, unsigned int c);

Re: [julia-users] Escher example problem

[Leonardo]

Yes, this error don't occurr anymore, but other errors occurr (reported 
in another message)


Thanks

Leonardo


Il 31/01/2016 19:11, Shashi Gowda ha scritto:

I believe this to be fixed now?

On Mon, Jan 11, 2016 at 1:09 PM, Leonardo > wrote:

Hi, I've a problem running Escher's example plotting.jl caused by
Gadfly:

|
WARNING:usingGadfly.render inmoduleMainconflicts withan existing
identifier.
WARNING:Methoddefinition
convert(Type{Escher.Tile},Gadfly.Plot)inmoduleEscherat
C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/lazyload.jl:73overwritten
inmoduleMainat
C:\Users\Leonardo\.julia\v0.4\Escher\src\basics\lazyload.jl:73.
WARNING:Errorrequiring DataFramesfromMain:
LoadError:error inmethod definition:functionEscher.render must be
explicitly imported to be extended
ininclude at boot.jl:261
ininclude_from_node1 at loading.jl:304
inanonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:60
inerr at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:47
inanonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:59
inwithpath at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:37
inanonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:58
inlistenmod at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:21
ininclude at boot.jl:261
ininclude_from_node1 at loading.jl:304
inexternal_setup at
C:\Users\Leonardo\.julia\v0.4\Escher\src\Escher.jl:53
ininclude at boot.jl:261
ininclude_from_node1 at loading.jl:304
inloadfile at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl:17
inanonymous at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl:164
inanonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:15
inanonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
insplitquery at C:\Users\Leonardo\.julia\v0.4\Mux\src\basics.jl:28
inanonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
inwcatch at
C:\Users\Leonardo\.julia\v0.4\Mux\src\websockets_integration.jl:12
inanonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
intodict at C:\Users\Leonardo\.julia\v0.4\Mux\src\basics.jl:21
inanonymous at
C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:12(repeats 2times)
inanonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
inanonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\server.jl:38
inhandle at
C:\Users\Leonardo\.julia\v0.4\WebSockets\src\WebSockets.jl:382
inon_message_complete at
C:\Users\Leonardo\.julia\v0.4\HttpServer\src\HttpServer.jl:393
inon_message_complete at
C:\Users\Leonardo\.julia\v0.4\HttpServer\src\RequestParser.jl:104
inhttp_parser_execute at
C:\Users\Leonardo\.julia\v0.4\HttpParser\src\HttpParser.jl:92
inprocess_client at
C:\Users\Leonardo\.julia\v0.4\HttpServer\src\HttpServer.jl:365
inanonymous at task.jl:447
whileloading
C:\Users\Leonardo\.julia\v0.4\Escher\src\library\table.jl,inexpression
starting on line 34
WARNING:Base.Stringisdeprecated,useAbstractStringinstead.
   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
WARNING:Base.Stringisdeprecated,useAbstractStringinstead.
   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
WARNING:Base.Stringisdeprecated,useAbstractStringinstead.
   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
WARNING:Base.Stringisdeprecated,useAbstractStringinstead.
   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
WARNING:Base.Stringisdeprecated,useAbstractStringinstead.
   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
incall at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
WARNING:Base.Stringisdeprecated,useAbstractStringinstead.
   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
incall at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
WARNING:Base.Stringisdeprecated,useAbstractStringinstead.
   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
incall at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
Errorhandling websocket connection:
MethodError:`isfinished`has nomethod matching
isfinished(::Compose.Patchable)
indraw at C:\Users\Leonardo\.julia\v0.4\Compose\src\container.jl:430
incompose_render at
C:\Users\Leonardo\.julia\v0.4\Escher\src\basics\lazyload.jl:54
inrender at
C:\Users\Leonardo\.julia\v0.4\Escher\src\basics\lazyload.jl:63
inrender at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/tile.jl:89
inrender at
C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:290
inrender at
C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:462
inrender at
C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:471
instart_updates at

[julia-users] recommended graphics packages for multiple curves on a single canvas

[Michael Landis]

Can anyone recommend a graphics capable of plotting multiple curves on a 
single canvas.  Python's pyplot/matplotlib multi-curve capabilities appear 
to be unavailable within Julia (maybe I'm doing it wrong).

[julia-users] Re: deep learning for regression?

[Jason Eckstein]

The reason why most of the deep learning focus is on classification is 
because image classification and voice recognition is where all the 
research money and focus is for the large companies that are investing in 
machine learning, i.e. Google, Baidu, Facebook, Microsoft, etc  Also a 
number of important competitions focus on image recognition.  That doesn't 
mean that the same success, challenges, and tools don't exist for 
regression problems, it's just not a primary focus in the community right 
now.  There are a number of interesting papers on solving regression 
problems and all the regularization techniques and network architectures 
that are useful but it really depends on your particular problem and how 
much data you have to work with.  I can tell you from personal experience 
that neural networks can be very effective at solving these types of 
problems and fitting very complex functions but doing it correctly requires 
careful regularization and choosing the right network architecture.  Also, 
if you use stochastic gradient descent or batch gradient descent, redundant 
inputs are not really a problem at all.  Since these problems are so 
specific to each problem you're trying to solve I can't really give you 
more help other than this general advice.  A more detailed discussion of 
all this is probably better suited to a private email exchange.  As far as 
the most modern state of the art techniques go, many of them can be applied 
to regression problems as well even though the use examples shown are for 
classification.

On Saturday, January 30, 2016 at 7:46:06 AM UTC-7, michae...@gmail.com 
wrote:
>
> Thanks, that's pretty much my understanding. Scaling the inputs seems to 
> be important, too, from what I read. I'm also interested in a framework 
> that will trim off redundant inputs. 
>
> I have run the mocha tutorial examples, and it looks very promising 
> because the structure is clear, and there are C++ and cuda backends. The 
> C++ backend, with openmp, gives me a good performance boost over the pure 
> Julia backend. However, I'm not so sure that it will allow for trimming 
> redundant inputs. Also, I have some ideas on how to restrict the net to 
> remove observationally equivalent configurations, which should aid in 
> training, and I don't think I could implement those ideas with mocha.
>
> From what I see, the focus of much recent work in neural nets seems to be 
> on classification and labeling of images, and regression examples using the 
> modern tools seem to be scarce. I'm wondering if that's because other tools 
> work better for regression, or simply because it's an old problem that is 
> considered to be well studied. I would like to see some examples of 
> regression nets that work well, using the modern tools, though, if there 
> are any out there.
>
> On Saturday, January 30, 2016 at 2:32:16 PM UTC+1, Jason Eckstein wrote:
>>
>> I've been using NN for regression and I've experimented with Mocha.  I 
>> ended up coding my own network for speed purposes but in general you simply 
>> leave the final output of the neural network as a linear combination 
>> without applying an activation function.  That way the output can represent 
>> a real number rather than compress it into a 0 to 1 or -1 to 1 range for 
>> classification.  You can leave the rest of the network unchanged.
>>
>> On Saturday, January 30, 2016 at 3:45:27 AM UTC-7, michae...@gmail.com 
>> wrote:
>>>
>>> I'm interested in using neural networks (deep learning) for multivariate 
>>> multiple regression, with multiple real valued inputs and multiple real 
>>> valued outputs. At the moment, the mocha.jl package looks very promising, 
>>> but the examples seem to be all for classification problems. Does anyone 
>>> have examples of use of mocha (or other deep learning packages for Julia) 
>>> for regression problems? Or any tips for deep learning and regression?
>>>
>>

[julia-users] Re: jl_call function in c++ code

[Shamika]

I rooted the input arguments but I'm not able to access the output 
arguments.  If jl_value_t *ret = (jl_array_t*)jl_call(func,args,nargs); 
returns a double matrix and a double scalar, could you show me how to 
access each output argument. If you could point me to some example code, 
that would be helpful.


On Wednesday, January 6, 2016 at 12:00:36 PM UTC+5:30, Shamika wrote:
>
>
>
> I'm using Julia in c++ code. I have a few doubts regarding the jl_call 
> function.The code is 
>
> jl_array_t *ret = (jl_array_t*)jl_call(func,args,nargs);
>
> 1. Can args contain both scalar/array values? Does it use zero based or 
> one based indexing?
> 2. Is there any data type that can hold both scalar/array output that is 
> returned by jl_call? Right now, I have to define the output as jl_value_t 
> or jl_array_t. Is there something more generic?
>
> Thanks,
> Shamika
>

[julia-users] Re: Optimizing Function Injection in Julia

[Bryan Rivera]

Cedric, I refactored the problem and this works well.

What do you mean "I would favor using a regular function call with a 
descriptive name"?

I was thinking replace `Base.call` with a function name.  But that does not 
work if the function is in the top-level scope in another file.

On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean wrote:
>
> Something like this?
>
> function function1(a, b, f) # Variable needed in callback fun injected.
> if(a > b)
>   c = a + b
>   res = f(c) # Callback function has been injected.
>   return res + 1
> else
>   # do anything
>   # but return nothing
> end
> end
>
> type SomeCallBack
> z::Int
> end
> Base.call(callback::SomeCallBack, c) = c + callback.z
>
> function1(2, 1, SomeCallBack(10))
>
> Because of JIT, this is 100% equivalent to your "callback function has 
> been injected" example, performance-wise. My feeling is that .call 
> overloading is not to be abused in Julia, so I would favor using a regular 
> function call with a descriptive name instead of call overloading, but the 
> same performance guarantees apply. Does that answer your question?
>
> On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera wrote:
>>
>> I think what I wrote above might be too complicated, as it is an attempt 
>> to solve this problem.
>>
>> In essence this is what I want: 
>>
>>
>>
>> function function1(a, b, onGreaterThanCallback)
>>   if(a > b)
>> c = a + b
>> res = onGreaterThanCallback(c, z)
>> return res + 1
>>   else
>> # do anything
>> # but return nothing
>>   end
>> end
>>
>>
>> global onGreaterThanCallback = (c) -> c + z
>>
>> function1(a, b, onGreaterThanCallback)
>>
>>
>> Problems:
>>
>> The global variable.
>>
>> The anonymous function which has performance impact (vs other 
>> approaches).  We could use Tim Holy's @anon, but then the value of `z` is 
>> fixed at function definition, which we don't always want.
>>
>> I think that the ideal optimization would look like this:
>>
>>   function function1(a, b, z) # Variable needed in callback fun 
>> injected.
>> if(a > b)
>>   c = a + b
>>   res = c + z # Callback function has been injected.
>>   return res + 1
>> else
>>   # do anything
>>   # but return nothing
>> end
>>   end
>>
>>
>>   function1(a, b, z)
>>
>> In OO languages we would be using an abstract class or its equivalent. 
>>  But I've thought about it, and read the discussions on interfaces, and 
>> don't see those solutions optimizing the code out like I did above.
>>
>> Any ideas?
>>
>

[julia-users] Re: Optimizing Function Injection in Julia

[Bryan Rivera]

Cedric, I refactored the problem and this works well.

What do you mean "I would favor using a regular function call with a 
descriptive name"?

I am taking that to mean replace `Base.call` with a function name.  But 
that does not work if the function is in top-level scope in another file.

On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean wrote:
>
> Something like this?
>
> function function1(a, b, f) # Variable needed in callback fun injected.
> if(a > b)
>   c = a + b
>   res = f(c) # Callback function has been injected.
>   return res + 1
> else
>   # do anything
>   # but return nothing
> end
> end
>
> type SomeCallBack
> z::Int
> end
> Base.call(callback::SomeCallBack, c) = c + callback.z
>
> function1(2, 1, SomeCallBack(10))
>
> Because of JIT, this is 100% equivalent to your "callback function has 
> been injected" example, performance-wise. My feeling is that .call 
> overloading is not to be abused in Julia, so I would favor using a regular 
> function call with a descriptive name instead of call overloading, but the 
> same performance guarantees apply. Does that answer your question?
>
> On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera wrote:
>>
>> I think what I wrote above might be too complicated, as it is an attempt 
>> to solve this problem.
>>
>> In essence this is what I want: 
>>
>>
>>
>> function function1(a, b, onGreaterThanCallback)
>>   if(a > b)
>> c = a + b
>> res = onGreaterThanCallback(c, z)
>> return res + 1
>>   else
>> # do anything
>> # but return nothing
>>   end
>> end
>>
>>
>> global onGreaterThanCallback = (c) -> c + z
>>
>> function1(a, b, onGreaterThanCallback)
>>
>>
>> Problems:
>>
>> The global variable.
>>
>> The anonymous function which has performance impact (vs other 
>> approaches).  We could use Tim Holy's @anon, but then the value of `z` is 
>> fixed at function definition, which we don't always want.
>>
>> I think that the ideal optimization would look like this:
>>
>>   function function1(a, b, z) # Variable needed in callback fun 
>> injected.
>> if(a > b)
>>   c = a + b
>>   res = c + z # Callback function has been injected.
>>   return res + 1
>> else
>>   # do anything
>>   # but return nothing
>> end
>>   end
>>
>>
>>   function1(a, b, z)
>>
>> In OO languages we would be using an abstract class or its equivalent. 
>>  But I've thought about it, and read the discussions on interfaces, and 
>> don't see those solutions optimizing the code out like I did above.
>>
>> Any ideas?
>>
>

[julia-users] Re: Optimizing Function Injection in Julia

[Bryan Rivera]

I just realized #13412  has 
been merged.

What should this look like now that `Base.call(...)` is deprecated?

Thinking something like:

(_::SomeCallBack)(c) = _.z + c


On Sunday, January 31, 2016 at 3:47:03 AM UTC-5, Bryan Rivera wrote:
>
> Cedric, I refactored the problem and this works well.
>
> What do you mean "I would favor using a regular function call with a 
> descriptive name"?
>
> I was thinking replace `Base.call` with a function name.  But that does 
> not work if the function is in the top-level scope in another file.
>
> On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean wrote:
>>
>> Something like this?
>>
>> function function1(a, b, f) # Variable needed in callback fun injected.
>> if(a > b)
>>   c = a + b
>>   res = f(c) # Callback function has been injected.
>>   return res + 1
>> else
>>   # do anything
>>   # but return nothing
>> end
>> end
>>
>> type SomeCallBack
>> z::Int
>> end
>> Base.call(callback::SomeCallBack, c) = c + callback.z
>>
>> function1(2, 1, SomeCallBack(10))
>>
>> Because of JIT, this is 100% equivalent to your "callback function has 
>> been injected" example, performance-wise. My feeling is that .call 
>> overloading is not to be abused in Julia, so I would favor using a regular 
>> function call with a descriptive name instead of call overloading, but the 
>> same performance guarantees apply. Does that answer your question?
>>
>> On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera wrote:
>>>
>>> I think what I wrote above might be too complicated, as it is an attempt 
>>> to solve this problem.
>>>
>>> In essence this is what I want: 
>>>
>>>
>>>
>>> function function1(a, b, onGreaterThanCallback)
>>>   if(a > b)
>>> c = a + b
>>> res = onGreaterThanCallback(c, z)
>>> return res + 1
>>>   else
>>> # do anything
>>> # but return nothing
>>>   end
>>> end
>>>
>>>
>>> global onGreaterThanCallback = (c) -> c + z
>>>
>>> function1(a, b, onGreaterThanCallback)
>>>
>>>
>>> Problems:
>>>
>>> The global variable.
>>>
>>> The anonymous function which has performance impact (vs other 
>>> approaches).  We could use Tim Holy's @anon, but then the value of `z` is 
>>> fixed at function definition, which we don't always want.
>>>
>>> I think that the ideal optimization would look like this:
>>>
>>>   function function1(a, b, z) # Variable needed in callback fun 
>>> injected.
>>> if(a > b)
>>>   c = a + b
>>>   res = c + z # Callback function has been injected.
>>>   return res + 1
>>> else
>>>   # do anything
>>>   # but return nothing
>>> end
>>>   end
>>>
>>>
>>>   function1(a, b, z)
>>>
>>> In OO languages we would be using an abstract class or its equivalent. 
>>>  But I've thought about it, and read the discussions on interfaces, and 
>>> don't see those solutions optimizing the code out like I did above.
>>>
>>> Any ideas?
>>>
>>

[julia-users] Escher global and local context

[Leonardo]

Hi all,
I want write an application with a Web UI (e.g. a chat) that has a local 
state (specific for each client) and global one (a state bind to web 
server).
These requirements are useful for example to permit communications between 
different client (e.g. into a chat) and/or handle centralized resources 
(like a DB connection shared by all client and created once into web 
server).

How can I do that?

Many thanks in advance

Leonardo

[julia-users] Anonymous functions now faster? Need for functors?

[Ben Ward]

Hi,

I just saw this merged PR .

In the past I used the functor trick of defining a type, and then a call 
method for the type, and passing this to a function, to get past the 
anonymous function inefficiency.

Does this PR mean (to a mortal like me) that on 0.5 now this is no longer 
necessary?

Thanks,
Ben.

Re: [julia-users] Anonymous functions now faster? Need for functors?

[Mauro]

> Hi,
>
> I just saw this merged PR .
>
> In the past I used the functor trick of defining a type, and then a call
> method for the type, and passing this to a function, to get past the
> anonymous function inefficiency.
>
> Does this PR mean (to a mortal like me) that on 0.5 now this is no longer
> necessary?

Yes!  Hooray!

[julia-users] Re: Optimizing Function Injection in Julia

[Cedric St-Jean]

On Sunday, January 31, 2016 at 4:27:00 AM UTC-5, Bryan Rivera wrote:
>
> I just realized #13412  has 
> been merged.
>
> What should this look like now that `Base.call(...)` is deprecated?
>

It will be once Julia 0.5 is released (and it still has no announced 
release date, so it can be a ways off)
 

>
> Thinking something like:
>
> (_::SomeCallBack)(c) = _.z + c
>
>
> On Sunday, January 31, 2016 at 3:47:03 AM UTC-5, Bryan Rivera wrote:
>>
>> Cedric, I refactored the problem and this works well.
>>
>> What do you mean "I would favor using a regular function call with a 
>> descriptive name"?
>>
>> I was thinking replace `Base.call` with a function name.  But that does 
>> not work if the function is in the top-level scope in another file.
>>
>> On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean wrote:
>>>
>>> Something like this?
>>>
>>> function function1(a, b, f) # Variable needed in callback fun injected.
>>> if(a > b)
>>>   c = a + b
>>>   res = f(c) # Callback function has been injected.
>>>   return res + 1
>>> else
>>>   # do anything
>>>   # but return nothing
>>> end
>>> end
>>>
>>> type SomeCallBack
>>> z::Int
>>> end
>>> Base.call(callback::SomeCallBack, c) = c + callback.z
>>>
>>> function1(2, 1, SomeCallBack(10))
>>>
>>> Because of JIT, this is 100% equivalent to your "callback function has 
>>> been injected" example, performance-wise. My feeling is that .call 
>>> overloading is not to be abused in Julia, so I would favor using a regular 
>>> function call with a descriptive name instead of call overloading, but the 
>>> same performance guarantees apply. Does that answer your question?
>>>
>>> On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera wrote:

 I think what I wrote above might be too complicated, as it is an 
 attempt to solve this problem.

 In essence this is what I want: 



 function function1(a, b, onGreaterThanCallback)
   if(a > b)
 c = a + b
 res = onGreaterThanCallback(c, z)
 return res + 1
   else
 # do anything
 # but return nothing
   end
 end


 global onGreaterThanCallback = (c) -> c + z

 function1(a, b, onGreaterThanCallback)


 Problems:

 The global variable.

 The anonymous function which has performance impact (vs other 
 approaches).  We could use Tim Holy's @anon, but then the value of `z` is 
 fixed at function definition, which we don't always want.

 I think that the ideal optimization would look like this:

   function function1(a, b, z) # Variable needed in callback fun 
 injected.
 if(a > b)
   c = a + b
   res = c + z # Callback function has been injected.
   return res + 1
 else
   # do anything
   # but return nothing
 end
   end


   function1(a, b, z)

 In OO languages we would be using an abstract class or its equivalent. 
  But I've thought about it, and read the discussions on interfaces, and 
 don't see those solutions optimizing the code out like I did above.

 Any ideas?

>>>

[julia-users] Re: Optimizing Function Injection in Julia

[Cedric St-Jean]

On Sunday, January 31, 2016 at 3:47:03 AM UTC-5, Bryan Rivera wrote:
>
> What do you mean "I would favor using a regular function call with a 
> descriptive name"?
>

> I was thinking replace `Base.call` with a function name. 
>

Yes, that's what I meant. It depends on the context, sometimes "function 
application" is the most natural way to do it.   

 But that does not work if the function is in the top-level scope in 
> another file.
>

It will work if you share the same function through `using` and `import 
ThatModule.function_name` directives. Check out the docs.

Cédric
 

>
> On Thursday, January 21, 2016 at 9:56:51 PM UTC-5, Cedric St-Jean wrote:
>>
>> Something like this?
>>
>> function function1(a, b, f) # Variable needed in callback fun injected.
>> if(a > b)
>>   c = a + b
>>   res = f(c) # Callback function has been injected.
>>   return res + 1
>> else
>>   # do anything
>>   # but return nothing
>> end
>> end
>>
>> type SomeCallBack
>> z::Int
>> end
>> Base.call(callback::SomeCallBack, c) = c + callback.z
>>
>> function1(2, 1, SomeCallBack(10))
>>
>> Because of JIT, this is 100% equivalent to your "callback function has 
>> been injected" example, performance-wise. My feeling is that .call 
>> overloading is not to be abused in Julia, so I would favor using a regular 
>> function call with a descriptive name instead of call overloading, but the 
>> same performance guarantees apply. Does that answer your question?
>>
>> On Thursday, January 21, 2016 at 9:02:50 PM UTC-5, Bryan Rivera wrote:
>>>
>>> I think what I wrote above might be too complicated, as it is an attempt 
>>> to solve this problem.
>>>
>>> In essence this is what I want: 
>>>
>>>
>>>
>>> function function1(a, b, onGreaterThanCallback)
>>>   if(a > b)
>>> c = a + b
>>> res = onGreaterThanCallback(c, z)
>>> return res + 1
>>>   else
>>> # do anything
>>> # but return nothing
>>>   end
>>> end
>>>
>>>
>>> global onGreaterThanCallback = (c) -> c + z
>>>
>>> function1(a, b, onGreaterThanCallback)
>>>
>>>
>>> Problems:
>>>
>>> The global variable.
>>>
>>> The anonymous function which has performance impact (vs other 
>>> approaches).  We could use Tim Holy's @anon, but then the value of `z` is 
>>> fixed at function definition, which we don't always want.
>>>
>>> I think that the ideal optimization would look like this:
>>>
>>>   function function1(a, b, z) # Variable needed in callback fun 
>>> injected.
>>> if(a > b)
>>>   c = a + b
>>>   res = c + z # Callback function has been injected.
>>>   return res + 1
>>> else
>>>   # do anything
>>>   # but return nothing
>>> end
>>>   end
>>>
>>>
>>>   function1(a, b, z)
>>>
>>> In OO languages we would be using an abstract class or its equivalent. 
>>>  But I've thought about it, and read the discussions on interfaces, and 
>>> don't see those solutions optimizing the code out like I did above.
>>>
>>> Any ideas?
>>>
>>