Re: [julia-users] Re: Is Dict{ASCIIString, Any} not a superset of Dict{ASCIIString, Float64}?

[Ivar Nesje]

The explanation that made me stop suggesting that `Sometype{T1} <: 
Sometype{T2} if T1<:T2` was the following function:

function foo( a::Array{Any, 1})
# I can now get objects from the array, and they will be subtypes of Any
b = a[1]
# And I can insert Any object into the array
push!(a, STDIN)
end

This function will not work if I call `foo([1.:6.])` because the array will 
be of type `Array{Float64, 1}`, but if we changed Julia to allow such 
constructs, it would fail when you push STDIN onto a Float64 array. So in 
essence the difference is whether the argument type should match for 
reading or writing.

Ivar


kl. 06:04:48 UTC+1 torsdag 27. november 2014 skrev K leo følgende:
>
> Thanks, now I understand it. 
>
> The problem I had was this, which I imagine to exist with many other 
> non-computer scientists new to Julia. 
>
> This topic is discussed under the parametric type section of the manual, 
> and since I had not attempted to use parametric types (the things with 
> the mysterious T), I didn't bother to read that section.  I ran into the 
> problem with mostly arrays, and it is not obvious that things like 
> Array{Any,1} is a parametric type.  So it became very strange to me when 
> Array{Int,1} can not be passed in the place of Array{Any,1}. 
>
> On 2014年11月27日 12:19, ele...@gmail.com  wrote: 
> > It is demonstrated in the manual at 
> > 
> http://docs.julialang.org/en/release-0.3/manual/types/#parametric-composite-types
>  
> > that parametric types do not have any relationship even if their 
> > parameter types have some relationship.  Perhaps it would be better 
> > emphasise that and to explain it simply and clearly for the 
> > non-*computer* scientists as something like: 
> > 
> > Two parametric types Sometype{T1} and Sometype{T2} have no subtype or 
> > supertype relationship even if T1 has a subtype or supertype 
> > relationship to T2. 
> > 
> > Cheers 
> > Lex 
> > 
> > On Thursday, November 27, 2014 1:37:53 PM UTC+10, John Myles White 
> wrote: 
> > 
> > All types do have Any as a parent. 
> > 
> > It is clear that many people are confused about what covariance, 
> > contravariance and invariance mean in computer science. As such, I 
> > very strongly encourage everyone who isn't sure that they 
> > understand Julia's type system to read through the wikipedia 
> > article on covariance and contravariance: 
> > 
> http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
>  
> > <
> http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29>
>  
>
> > 
> > 
> > Perhaps the Julia manual should have a "prerequisites" section 
> > that lists all of the concepts that readers are assumed to already 
> > understand. 
> > 
> >  -- John 
> > 
> > On Nov 26, 2014, at 7:27 PM, K Leo  > > wrote: 
> > 
> > > I ran into similar mental difficulty regarding whether type Any 
> > is a superset of any other types.  I did not find anything to 
> > read, but simply accepted the fact through painstaking experiments. 
> > > 
> > > I think the word "Any" here is confusing.  The English 
> > definition of it means that it ought to include any types. 
> >  Perhaps we should seek other word to define this type.  Word like 
> > "Mixed" might be more appropriate for this? 
> > > 
> > > On 2014年11月27日 08:17, Patrick O'Leary wrote: 
> > >> 
> > >> You've hit type invariance. In Julia, parametric types are 
> > invariant--that is, Dict{ASCIIString,Float64} is not a subtype of 
> > Dict{ASCIIString,Any}. 
> > >> 
> > >> For more information on why we use invariant parametric types, 
> > search the list for "parametric invariant" or similar; there have 
> > been a few discussions on the topic. 
> > >> 
> > >> Patrick 
> > > 
> > 
>
>

Re: [julia-users] Installing IJulia

[stonebig34]

Hi Abram,

If all else fails, you have still this alternative

http://nbviewer.ipython.org/github/winpython/winpython_afterdoc/blob/master/examples/installing_julia_and_ijulia.ipynb

On Thursday, November 27, 2014 6:57:41 AM UTC+1, cdm wrote:
>
>
> if you are not averse to trying IJulia in your browser, then have a look 
> at this post ...
>
>
> https://groups.google.com/forum/#!searchin/julia-users/tmpnb|sort:relevance/julia-users/zEp8pKkEYHk/qY7tPqrOp9gJ
>
>
> there are other ways to work with IJulia on kernels hosted elsewhere; let 
> me know
> if you are interested.
>
> best,
>
> cdm
>
>
> On Wednesday, November 26, 2014 3:26:51 PM UTC-8, Abram Demski wrote:
>>
>> Pileas,
>>
>> Given that I've still been unable to install IJulia, that's very helpful, 
>> thanks.
>>
>>

Re: [julia-users] Installing IJulia

[cdm]

if you are not averse to trying IJulia in your browser, then have a look at 
this post ...

   
https://groups.google.com/forum/#!searchin/julia-users/tmpnb|sort:relevance/julia-users/zEp8pKkEYHk/qY7tPqrOp9gJ


there are other ways to work with IJulia on kernels hosted elsewhere; let 
me know
if you are interested.

best,

cdm


On Wednesday, November 26, 2014 3:26:51 PM UTC-8, Abram Demski wrote:
>
> Pileas,
>
> Given that I've still been unable to install IJulia, that's very helpful, 
> thanks.
>
>

[julia-users] Re: julia vs cython benchmark

[Jeff Waller]

There is one thing is see as a potential.

The outer loop *i* is incrementing the first index, and Julia stores things 
in column-major order, so any speed gain from CPU cache is potentially lost 
since you using elements that are not contiguous in the inner loops.

Re: [julia-users] Re: Is Dict{ASCIIString, Any} not a superset of Dict{ASCIIString, Float64}?

[K Leo]

Thanks, now I understand it.

The problem I had was this, which I imagine to exist with many other 
non-computer scientists new to Julia.


This topic is discussed under the parametric type section of the manual, 
and since I had not attempted to use parametric types (the things with 
the mysterious T), I didn't bother to read that section.  I ran into the 
problem with mostly arrays, and it is not obvious that things like 
Array{Any,1} is a parametric type.  So it became very strange to me when 
Array{Int,1} can not be passed in the place of Array{Any,1}.


On 2014年11月27日 12:19, ele...@gmail.com wrote:
It is demonstrated in the manual at 
http://docs.julialang.org/en/release-0.3/manual/types/#parametric-composite-types 
that parametric types do not have any relationship even if their 
parameter types have some relationship.  Perhaps it would be better 
emphasise that and to explain it simply and clearly for the 
non-*computer* scientists as something like:


Two parametric types Sometype{T1} and Sometype{T2} have no subtype or 
supertype relationship even if T1 has a subtype or supertype 
relationship to T2.


Cheers
Lex

On Thursday, November 27, 2014 1:37:53 PM UTC+10, John Myles White wrote:

All types do have Any as a parent.

It is clear that many people are confused about what covariance,
contravariance and invariance mean in computer science. As such, I
very strongly encourage everyone who isn't sure that they
understand Julia's type system to read through the wikipedia
article on covariance and contravariance:

http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29




Perhaps the Julia manual should have a "prerequisites" section
that lists all of the concepts that readers are assumed to already
understand.

 -- John

On Nov 26, 2014, at 7:27 PM, K Leo > wrote:

> I ran into similar mental difficulty regarding whether type Any
is a superset of any other types.  I did not find anything to
read, but simply accepted the fact through painstaking experiments.
>
> I think the word "Any" here is confusing.  The English
definition of it means that it ought to include any types.
 Perhaps we should seek other word to define this type.  Word like
"Mixed" might be more appropriate for this?
>
> On 2014年11月27日 08:17, Patrick O'Leary wrote:
>>
>> You've hit type invariance. In Julia, parametric types are
invariant--that is, Dict{ASCIIString,Float64} is not a subtype of
Dict{ASCIIString,Any}.
>>
>> For more information on why we use invariant parametric types,
search the list for "parametric invariant" or similar; there have
been a few discussions on the topic.
>>
>> Patrick
>

[julia-users] julia vs cython benchmark

[Andre Bieler]

Did a benchmark for calculating shadowing of a triangulated surface mesh in 
julia and cython.
It is basically a loop over all surface elements and checks if any other of 
the surface elements intersect
with the line of sight pointing towards a light source. (see pic below, 
light source on the positive x axis and object
with roughly 35000 surface elements)
For the example below the whole calculation takes roughly 29.5 s for cython 
and 30.1 s with julia. so i am pretty
happy with the result. 

If anyone sees something stupid in either of the codes that drags 
performance down please comment!
(only posted the function that does all the heavy lifting)

function isSunlit(triangles::Array{Float64,3}, n_hat::Array{Float64, 2}, r::
Array{Float64,1}, p0::Array{Float64,1}, nTriangles::Int64, currIndex::Int64)
  i = 0
  j = 0
  k = 0
  
  a = 0.0
  b = 0.0
  rI = 0.0
  
  dot_uv = 0.0
  dot_uu = 0.0
  dot_vv = 0.0
  dot_wv = 0.0
  dot_wu = 0.0
  
  divisor = 0.0
  sI = 0.0
  tI = 0.0
  
  pI = [0.,0.,0.]
  u = [0.,0.,0.]
  v = [0.,0.,0.]
  w = [0.,0.,0.]
  
  for i=1:nTriangles
a = 0.0
b = 0.0
for j=1:3
  a = a + n_hat[i,j] * (triangles[i,1,j] - p0[j]) 
  b = b + n_hat[i,j] * r[j]  
end
if ((b != 0.0) && (a != 0.0))
  rI = a / b
  if rI >= 0.0
dot_uv = 0.0
dot_uu = 0.0
dot_vv = 0.0
dot_wu = 0.0
dot_wv = 0.0

for k=1:3
  pI[k] = p0[k] + rI * r[k]
  u[k] = triangles[i,2,k] - triangles[i,1,k]
  v[k] = triangles[i,3,k] - triangles[i,1,k]
  w[k] = pI[k] - triangles[i,1,k]
  
  dot_uv = dot_uv + u[k]*v[k]
  dot_uu = dot_uu + u[k]*u[k]
  dot_vv = dot_vv + v[k]*v[k]
  dot_wu = dot_wu + w[k]*u[k]
  dot_wv = dot_wv + w[k]*v[k]
end

divisor = dot_uv*dot_uv - dot_uu * dot_vv
sI = (dot_uv*dot_wv - dot_vv*dot_wu) / divisor
tI = (dot_uv*dot_wu - dot_uu*dot_wv) / divisor
 if ((sI >= 0.0) && (tI >= 0.0) && (sI + tI < 1.0))
  if currIndex != i
return 0
  end
end

  end
  
end
  end
  return 1

end



and here is the cython code

# cython code
import numpy as np
cimport numpy as np
cimport cython

cdef extern from "math.h":
double sqrt(double x)

@cython.boundscheck(False)
@cython.wraparound(False)
def calculate_shadow(np.ndarray[np.float_t, ndim=3] triangles, 
np.ndarray[np.float_t, ndim=2] n_hat, np.ndarray[np.float_t, ndim=1] r, 
np.ndarray[np.float_t, ndim=1] p0, int nTriangles, int currIndex):
# return 0 if in shadow and 1 if not
cdef int i = 0
cdef int j = 0
cdef int k = 0
cdef float a = 0.0
cdef float b = 0.0
cdef float C1 = 0.0
cdef float C2 = 0.0
cdef float rI
cdef float dot_uv, dot_uu, dot_vv, dot_wv, dot_wu
cdef float divisor, sI, tI
cdef np.ndarray[np.float_t, ndim=1] pI = np.zeros(3)
cdef np.ndarray[np.float_t, ndim=1] u = np.zeros(3)
cdef np.ndarray[np.float_t, ndim=1] v = np.zeros(3)
cdef np.ndarray[np.float_t, ndim=1] w = np.zeros(3)

for i in range(nTriangles):
a = 0.0
b = 0.0
for j in range(3):
a = a + n_hat[i,j] * (triangles[i,0,j] - p0[j])
b = b + n_hat[i,j] * r[j]

if (b != 0.0) and (a != 0.0):
rI = a / b
if rI >= 0:
dot_uv = 0.0
dot_uu = 0.0
dot_vv = 0.0
dot_wu = 0.0
dot_wv = 0.0
for k in range(3):
pI[k] = p0[k] + rI * r[k]
u[k] = triangles[i,1,k] - triangles[i,0,k]
v[k] = triangles[i,2,k] - triangles[i,0,k]
w[k] = pI[k] - triangles[i,0,k]

dot_uv = dot_uv + u[k]*v[k]
dot_uu = dot_uu + u[k]*u[k]
dot_vv = dot_vv + v[k]*v[k]
dot_wu = dot_wu + w[k]*u[k]
dot_wv = dot_wv + w[k]*v[k]

divisor = dot_uv*dot_uv - dot_uu * dot_vv
sI = (dot_uv*dot_wv - dot_vv*dot_wu) / divisor
tI = (dot_uv*dot_wu - dot_uu*dot_wv) / divisor

if ((sI >= 0.00) and (tI >= 0.00) and (sI + tI < 1.0)):
if i != currIndex:
return 0
return 1

[julia-users] Re: Animation with Gadfly and IJulia?

[Sheehan Olver]

I figured out an approach that works for animation, thanks to Jiahao Chen, 
using 2 IJulia inputs:


# In[1]
using ApproxFun,Gadfly,Reactive
x=Input(Fun(exp))
lift(ApproxFun.plot, x)

# In[2]
for k=1:10
push!(x,Fun(x->cos(k*x)))
end



On Tuesday, November 4, 2014 2:46:44 AM UTC-6, Sheehan Olver wrote:
>
>
>
> I'm wondering whether there's an example of doing animation directly in 
> IJulia with Gadfly.  Where by animation I mean plotting a sequence of 
> functions, lets say each frame is calculated from the previous frame and 
> wants to be plotted as soon as calculated.
>
> Its clearly possible as its possible with Interact.jl: the code below does 
> work, but is not elegant and seems to run into problems if the calculation 
> is slow.  There is also the extra unneeded slide bar for k.   I can't seem 
> to figure out how to get ride of the @manipulate.
>
> @manipulate for k=1:1, t_dt=timestamp(fps(30.))
> # calculate plot
> end
>
>
>

Re: [julia-users] Re: Is Dict{ASCIIString, Any} not a superset of Dict{ASCIIString, Float64}?

[elextr]

It is demonstrated in the manual at 
http://docs.julialang.org/en/release-0.3/manual/types/#parametric-composite-types
 
that parametric types do not have any relationship even if their parameter 
types have some relationship.  Perhaps it would be better emphasise that 
and to explain it simply and clearly for the non-*computer* scientists as 
something like:

Two parametric types Sometype{T1} and Sometype{T2} have no subtype or 
supertype relationship even if T1 has a subtype or supertype relationship 
to T2.

Cheers
Lex

On Thursday, November 27, 2014 1:37:53 PM UTC+10, John Myles White wrote:
>
> All types do have Any as a parent. 
>
> It is clear that many people are confused about what covariance, 
> contravariance and invariance mean in computer science. As such, I very 
> strongly encourage everyone who isn't sure that they understand Julia's 
> type system to read through the wikipedia article on covariance and 
> contravariance: 
> http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
>  
>
> Perhaps the Julia manual should have a "prerequisites" section that lists 
> all of the concepts that readers are assumed to already understand. 
>
>  -- John 
>
> On Nov 26, 2014, at 7:27 PM, K Leo > 
> wrote: 
>
> > I ran into similar mental difficulty regarding whether type Any is a 
> superset of any other types.  I did not find anything to read, but simply 
> accepted the fact through painstaking experiments. 
> > 
> > I think the word "Any" here is confusing.  The English definition of it 
> means that it ought to include any types.  Perhaps we should seek other 
> word to define this type.  Word like "Mixed" might be more appropriate for 
> this? 
> > 
> > On 2014年11月27日 08:17, Patrick O'Leary wrote: 
> >> 
> >> You've hit type invariance. In Julia, parametric types are 
> invariant--that is, Dict{ASCIIString,Float64} is not a subtype of 
> Dict{ASCIIString,Any}. 
> >> 
> >> For more information on why we use invariant parametric types, search 
> the list for "parametric invariant" or similar; there have been a few 
> discussions on the topic. 
> >> 
> >> Patrick 
> > 
>
>

Re: [julia-users] Re: Is Dict{ASCIIString, Any} not a superset of Dict{ASCIIString, Float64}?

[John Myles White]

All types do have Any as a parent.

It is clear that many people are confused about what covariance, contravariance 
and invariance mean in computer science. As such, I very strongly encourage 
everyone who isn't sure that they understand Julia's type system to read 
through the wikipedia article on covariance and contravariance: 
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29

Perhaps the Julia manual should have a "prerequisites" section that lists all 
of the concepts that readers are assumed to already understand.

 -- John

On Nov 26, 2014, at 7:27 PM, K Leo  wrote:

> I ran into similar mental difficulty regarding whether type Any is a superset 
> of any other types.  I did not find anything to read, but simply accepted the 
> fact through painstaking experiments.
> 
> I think the word "Any" here is confusing.  The English definition of it means 
> that it ought to include any types.  Perhaps we should seek other word to 
> define this type.  Word like "Mixed" might be more appropriate for this?
> 
> On 2014年11月27日 08:17, Patrick O'Leary wrote:
>> 
>> You've hit type invariance. In Julia, parametric types are invariant--that 
>> is, Dict{ASCIIString,Float64} is not a subtype of Dict{ASCIIString,Any}.
>> 
>> For more information on why we use invariant parametric types, search the 
>> list for "parametric invariant" or similar; there have been a few 
>> discussions on the topic.
>> 
>> Patrick
> 

Re: [julia-users] Re: Is Dict{ASCIIString, Any} not a superset of Dict{ASCIIString, Float64}?

[K Leo]

I ran into similar mental difficulty regarding whether type Any is a 
superset of any other types.  I did not find anything to read, but 
simply accepted the fact through painstaking experiments.


I think the word "Any" here is confusing.  The English definition of it 
means that it ought to include any types.  Perhaps we should seek other 
word to define this type.  Word like "Mixed" might be more appropriate 
for this?


On 2014年11月27日 08:17, Patrick O'Leary wrote:


You've hit type invariance. In Julia, parametric types are 
invariant--that is, Dict{ASCIIString,Float64} is not a subtype of 
Dict{ASCIIString,Any}.


For more information on why we use invariant parametric types, search 
the list for "parametric invariant" or similar; there have been a few 
discussions on the topic.


Patrick

[julia-users] Re: Is Dict{ASCIIString, Any} not a superset of Dict{ASCIIString, Float64}?

[Test This]

Patrick, thank you for your response and the link. I will need to read it 
more carefully and try to understand as it since it deals with concepts I 
am not familiar with. However, wouldn't the solution you proposed restrict 
all values of the rec Dict to the same type in any given call. Am I correct 
in understanding that they can be of any type, however, they have to be the 
same type?

Thank you.


On Wednesday, November 26, 2014 7:17:48 PM UTC-5, Patrick O'Leary wrote:
>
> On Wednesday, November 26, 2014 6:01:56 PM UTC-6, Test This wrote:
>>
>> I have the following function defined to check whether a record exists in 
>> a Mongodb database (thanks a million for PyCall, which make it easy to use 
>> pymongo 
>> to interact with mongodb in julia).
>>
>> function doesrecexist(collectn::PyObject, rec::Dict{ASCIIString,Any})
>> # checks if record exists.
>> r = collectn[:find_one](rec)
>> return r
>> end 
>>
>>
>> If I define 
>>
>> rec = ["p" => 0.3] 
>>
>> julia recognizes it as Dict{ASCIIString, Float64}. Then if I do, 
>>
>> doesrecexist(collectn, rec), I get an error saying *ERROR: 
>> `doesrecexist` has no method matching doesrecexist(::PyObject, 
>> ::Dict{ASCIIString,Float64})*
>>
>> If I remove the type declaration for rec in doesrecexist, things work 
>> fine. I have no other method defined for doesrecexist. Does it make sense 
>> to get this error, given 
>> that I intend to allow any values in the rec Dict by declaring Any? Is 
>> there a workaround where I can declare the type for rec when defining the 
>> function, without having 
>> to define doesrecexist for Float values, Int values, String values etc.
>>
>> Thank you.
>>
>
> You've hit type invariance. In Julia, parametric types are invariant--that 
> is, Dict{ASCIIString,Float64} is not a subtype of Dict{ASCIIString,Any}. 
> However, you can use generic types instead:
>
> function doesrecexist{T}(collectn::PyObject, rec::Dict{ASCIIString, T})
> ...
> end
>
> Which will match for all T. You can also restrict T to subtypes of a given 
> type in the curly-braced section. For instance, if you wanted to guarantee 
> that the type T was a subtype of Real:
>
> function doesrecexist{T<:Real}(...)
> ...
> end
>
> For more information on why we use invariant parametric types, search the 
> list for "parametric invariant" or similar; there have been a few 
> discussions on the topic.
>
> Patrick
>

[julia-users] Re: Is Dict{ASCIIString, Any} not a superset of Dict{ASCIIString, Float64}?

[Patrick O'Leary]

On Wednesday, November 26, 2014 6:01:56 PM UTC-6, Test This wrote:
>
> I have the following function defined to check whether a record exists in 
> a Mongodb database (thanks a million for PyCall, which make it easy to use 
> pymongo 
> to interact with mongodb in julia).
>
> function doesrecexist(collectn::PyObject, rec::Dict{ASCIIString,Any})
> # checks if record exists.
> r = collectn[:find_one](rec)
> return r
> end 
>
>
> If I define 
>
> rec = ["p" => 0.3] 
>
> julia recognizes it as Dict{ASCIIString, Float64}. Then if I do, 
>
> doesrecexist(collectn, rec), I get an error saying *ERROR: `doesrecexist` 
> has no method matching doesrecexist(::PyObject, 
> ::Dict{ASCIIString,Float64})*
>
> If I remove the type declaration for rec in doesrecexist, things work 
> fine. I have no other method defined for doesrecexist. Does it make sense 
> to get this error, given 
> that I intend to allow any values in the rec Dict by declaring Any? Is 
> there a workaround where I can declare the type for rec when defining the 
> function, without having 
> to define doesrecexist for Float values, Int values, String values etc.
>
> Thank you.
>

You've hit type invariance. In Julia, parametric types are invariant--that 
is, Dict{ASCIIString,Float64} is not a subtype of Dict{ASCIIString,Any}. 
However, you can use generic types instead:

function doesrecexist{T}(collectn::PyObject, rec::Dict{ASCIIString, T})
...
end

Which will match for all T. You can also restrict T to subtypes of a given 
type in the curly-braced section. For instance, if you wanted to guarantee 
that the type T was a subtype of Real:

function doesrecexist{T<:Real}(...)
...
end

For more information on why we use invariant parametric types, search the 
list for "parametric invariant" or similar; there have been a few 
discussions on the topic.

Patrick

[julia-users] Is Dict{ASCIIString, Any} not a superset of Dict{ASCIIString, Float64}?

[Test This]

I have the following function defined to check whether a record exists in a 
Mongodb database (thanks a million for PyCall, which make it easy to use 
pymongo 
to interact with mongodb in julia).

function doesrecexist(collectn::PyObject, rec::Dict{ASCIIString,Any})
# checks if record exists.
r = collectn[:find_one](rec)
return r
end 


If I define 

rec = ["p" => 0.3] 

julia recognizes it as Dict{ASCIIString, Float64}. Then if I do, 

doesrecexist(collectn, rec), I get an error saying *ERROR: `doesrecexist` 
has no method matching doesrecexist(::PyObject, 
::Dict{ASCIIString,Float64})*

If I remove the type declaration for rec in doesrecexist, things work fine. 
I have no other method defined for doesrecexist. Does it make sense to get 
this error, given 
that I intend to allow any values in the rec Dict by declaring Any? Is 
there a workaround where I can declare the type for rec when defining the 
function, without having 
to define doesrecexist for Float values, Int values, String values etc.

Thank you.

Re: [julia-users] Installing IJulia

[Abram Demski]

Pileas,

Given that I've still been unable to install IJulia, that's very helpful,
thanks.

On Tue, Nov 25, 2014 at 6:29 PM, Pileas  wrote:

> I have to suggest a very good editor that supports "Julia" and it is
> called Atom. It becomes better each day:
>
> Give it a try if you have time: https://atom.io/
>
> Τη Τρίτη, 25 Νοεμβρίου 2014 6:12:52 μ.μ. UTC-5, ο χρήστης Abram Demski
> έγραψε:
>>
>> Thanks! I figured out how to do it in the default shell:
>>
>> julia> print(ENV["PATH"])
>> C:\Users\abram\AppData\Local\Julia-0.3.3\bin;C:\Users\
>> abram\AppData\Local\Julia-
>> 0.3.3\bin\..\Git\bin;C:\Program Files (x86)\Intel\iCLS
>> Client\;C:\Program Files\
>> Intel\iCLS Client\;C:\windows\system32;C:\windows;C:\windows\System32\
>> Wbem;C:\wi
>> ndows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\Intel(R)
>> Managemen
>> t Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine
>> Compon
>> ents\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine
>> Components\DAL;
>> C:\Program Files (x86)\Intel\Intel(R) Management Engine
>> Components\IPT;C:\Progra
>> m Files\Intel\WiFi\bin\;C:\Program Files\Common
>> Files\Intel\WirelessCommon\;C:\P
>> rogram Files\Condusiv Technologies\ExpressCache\;C:\Program Files
>> (x86)\Common F
>> iles\lenovo\easyplussdk\bin;C:\ProgramData\Lenovo\ReadyApps;
>> C:\Anaconda;C:\Anaco
>> nda\Scripts
>>
>> (I have not used windows much since Windows 98! ;p)
>>
>> On Tue, Nov 25, 2014 at 3:02 PM, cdm  wrote:
>>
>>>
>>> if you have access to the PowerShell in Windows 8 ( ... and similar,
>>> new-ish, MS OSs ...),
>>> then highlighting a block of text from the PowerShell and right clicking
>>> should rip it to the
>>> clipboard for pasting else-where ...
>>>
>>> best,
>>>
>>> cdm
>>>
>>>
>>>
>>> On Tuesday, November 25, 2014 2:42:51 PM UTC-8, Abram Demski wrote:


 Julia shows a similar PATH when I run ENV["PATH"], but with more
 julia-specific things. (It seems that command prompts in Windows 8.1 do not
 allow one to copy text out of them directly.. otherwise I'd copy.)


>>
>>
>> --
>> Abram Demski
>> Blog: http://lo-tho.blogspot.com/
>>
>


-- 
Abram Demski
Blog: http://lo-tho.blogspot.com/

Re: [julia-users] JuliaBox

[Zenna Tavares]

I would like to get an invite code if at all possible.

Thanks!

Zenna

On Saturday, November 15, 2014 4:07:51 AM UTC-5, Viral Shah wrote:
>
> Yes, we certainly want to add GitHub to the mix. 
>
> -viral 
>
>
>
> > On 14-Nov-2014, at 7:16 pm, Daniel Carrera  > wrote: 
> > 
> > 
> > 
> > On Friday, 14 November 2014 12:45:54 UTC+1, Stefan Karpinski wrote: 
> > Using GitHub for auth actually makes a lot of sense and would allow us 
> to use GitHub for persistence unconditionally instead of as an option, 
> which might be simpler. Of course then there will always be someone who 
> objects to having a GitHub account ;-) 
> > 
> > 
> > 
> > Is there an advantage to using GitHub specifically instead of a generic 
> OpenID login? (e.g. "Login with [Google] , [Facebook], [GitHub], [Other]"). 
> > 
> > Cheers, 
> > Daniel. 
>
>

Re: [julia-users] Re: Meshgrid in Julia: a working example and possible alternatives

[Pileas]

I found out that the code works when I use IJulia, but not when I run the 
command: julia file.jl.

This is weird indeed ...

Τη Τετάρτη, 26 Νοεμβρίου 2014 9:05:32 π.μ. UTC-5, ο χρήστης Steven G. 
Johnson έγραψε:
>
>
>
> On Wednesday, November 26, 2014 12:45:09 AM UTC-5, David Smith wrote:
>>
>> My up-to-date version of Matplotlib won't plot NaNs either.
>>
>
> That's weird; it works fine for me in Matplotlib 1.4.0.
>
> In any case, you can always zero out the NaN values in W via:
> W[isnan(W)] = 0
> before plotting. 
>

Re: [julia-users] Flexible construction of types

[Jameson Nash]

it should be noted that there's nothing inherently "wrong" or "bad" about
using non-concrete type specifications in type declarations. it does,
however, limit certain optimizations that might provide performance
benefits, and may be especially important for native numerical types.

On Wed Nov 26 2014 at 4:54:37 PM Marc Gallant 
wrote:

> Thanks for your quick response! I have a couple questions/concerns about
> your implementation:
>
> - MyType(1, [2, 3], "xyz") fails requirement #2
> - MyType(1, [2, 10], "xyz") throws InexactError()
> - Does the declaration s::String cause the ambiguities described in the
> FAQ here
> ?
> More specifically, does MyType suffer from the same ambiguity
> as MyStillAmbiguousType in the FAQ?
>
> Thanks again!
> Marc
>

Re: [julia-users] Flexible construction of types

[Mauro]

> Thanks for your quick response! I have a couple questions/concerns about 
> your implementation:
>
> - MyType(1, [2, 3], "xyz") fails requirement #2

MyType{T1<:Real, T2<:Real}(x::T1, v::Vector{T2}, s::String) = 
(T=promote_type(T1,T2,Float64); MyType{T}(x, v, s))

If you want to keep Float16, etc this does not work.  It will be at
least Float64 (or BigFloat).

If you need Float16 etc kept then it's going to be quite a bit more
verbose as arithmetic with pi promotes to Float64.

If you're fine with just Float64 and don't care about BigFloat then just
do:

immutable MyType
x::Float64
v::Vector{Float64}
s::String
...
end 


> - MyType(1, [2, 10], "xyz") throws InexactError()

Should be fixed as well

> - Does the declaration s::String cause the ambiguities described in the FAQ 
> here 
> ?
>  
> More specifically, does MyType suffer from the same ambiguity 
> as MyStillAmbiguousType in the FAQ?

I think this should only affect functions which actually use .s but not
.x or .v. 

You can check this like so:

julia> f(a::MyType) = a.x+a.v[1]
f (generic function with 1 methods)

julia> f(aa)
3.0

julia> @code_typed f(aa)
1-element Array{Any,1}:
 :($(Expr(:lambda, {:a}, {{},{{:a,MyType{Float64},0}},{}}, :(begin  # none, 
line 1:
return 
(top(box))(Float64,(top(add_float))((top(getfield))(a::MyType{Float64},:x)::Float64,(top(arrayref))((top(getfield))(a::MyType{Float64},:v)::Array{Float64,1},1)::Float64))::Float64
end::Float64

This shows that Julia knows that the return type is Float64 (the last
bit of the returned thingy).

Compare this to:

julia> immutable MyType2
   x
   v::Vector
   s::String
   end

julia> b=MyType2(1, [2, 10], "xyz")
MyType2(1,[2,10],"xyz")

julia> g(a::MyType2) = a.x+a.v[1]
g (generic function with 1 method)

julia> g(b)
3

julia> @code_typed g(b)
1-element Array{Any,1}:
 :($(Expr(:lambda, {:a}, {{},{{:a,MyType2,0}},{}}, :(begin  # none, line 1:
return (top(getfield))(a::MyType2,:x) + 
(top(arrayref))((top(getfield))(a::MyType2,:v)::Array{T,1},1)
end

No type annotation at the end of the output here, thus Julia cannot
infer the return type.

Re: [julia-users] Re: Neuro-Dynamic Programming in Julia

[wildart]

Defining an RL-agent environment in RL-Glue API is a straightforward task. 
Apart from (de)initialization calls, an environment respond for the agent 
action must me defined. This respond should have an appropriate reward for 
the agent (There are two separate placeholders for integer and real 
rewards. The way API deals with different types). If environment is 
dynamic, its internal state could be programmed as you see fit. Examples 
are here: http://library.rl-community.org/wiki/Category:Environments.


On Tuesday, November 25, 2014 10:34:23 AM UTC-5, John Myles White wrote:
>
> Sounds like a cool project. Are the state space representations that 
> RL-Glue uses easy to work with?
>
>  — John
>
> On Nov 24, 2014, at 10:09 PM, wil...@gmail.com  wrote:
>
> Reinforcement learning (RL) isn't covered much in Julia packages. There is 
> a collection of RL algorithms over MDP in package: 
> https://github.com/cpritcha/MDP. There is a collection of IJulia 
> notebooks from a Stanford course that cover more RL algorithms: 
> https://github.com/sisl/aa228-notebook/tree/master
>
> Unfortunately, more advanced function approximation techniques, beyond 
> look-up table, that allow to tackle large action-state spaces, are nowhere 
> to find.
>
> Couple a month ago, Shane Conway, the guy behind RL-Glue 
> , talked about developing 
> Julia RL-Glue client. If that happens, it would be quite simple to use 
> various advanced RL algorithms, including value function approximators, in 
> Julia. 
>
>
> On Saturday, November 22, 2014 11:12:29 PM UTC-5, Pileas wrote:
>>
>> Some problems have the so-called curse of dimensionality and curse of 
>> modeling. For this reason Bersekas and Tsimtsiklis (at MIT) introduced the 
>> so-called Neuro-Dynamic Programing.
>>
>> Does Julia offer support for the aforementioned and if not, how about the 
>> future?
>>
>
>

Re: [julia-users] Flexible construction of types

[Marc Gallant]

Thanks for your quick response! I have a couple questions/concerns about 
your implementation:

- MyType(1, [2, 3], "xyz") fails requirement #2
- MyType(1, [2, 10], "xyz") throws InexactError()
- Does the declaration s::String cause the ambiguities described in the FAQ 
here 
?
 
More specifically, does MyType suffer from the same ambiguity 
as MyStillAmbiguousType in the FAQ?

Thanks again!
Marc

Re: [julia-users] Flexible construction of types

[Mauro]

How about

immutable MyType{T<:Real}
x::T
v::Vector{T}
s::String

function MyType(x, v, s)
x = subtractpi(x)
v = map(subtractpi, v)
new(x, v, s)
end
end
MyType{T1<:Real, T2<:Real}(x::T1, v::Vector{T2}, s::String) = 
(T=promote_type(T1,T2); MyType{T}(x, v, s))

T1 and T2 are both needed to fulfil 5.  Otherwise calling `MyType(11.4, [1, 2, 
55])
will set T to Float64 and thus error on the array

On Wed, 2014-11-26 at 22:20, Marc Gallant  wrote:
> Suppose I have a type called MyType that has one floating point field "x". 
> When constructed, if the value provided for "x" is greater than, let's say, 
> 5, it has pi subtracted from it. For example,
>
> a = MyType(4)  # x = 4.0
> b = MyType(-11) # x = 11.0
> c = MyType(10)  # x = 6.8584
> d = MyType(-1.443)  # x = -1.443
>
> What is the best way to declare MyType and its constructor(s) to ensure 
> that:
>
> 1. You can provide MyType with any real number to construct it
> 2. typeof(a.x) and typeof(c.x) are both Float64
> 3. The pi constraint is properly applied (is an inner constructor 
> appropriate here?)
> 4. The same behaviour applies to the entries of a second field "y" that is 
> a vector (e.g., MyType(10, [3, 10, 11, -2]) has x = 6.8584, y = [3.0, 
> 6.8584, 7.8584, -2.0]).
> 5. (if possible) You can construct MyType from a mixture of real number 
> types (e.g., MyType(11.4, [1, 2, 55]))
> 6. MyType has a third field "z" that is a string
>
> Here is an implementation I wrote that doesn't meet 1, 5, or 6:
>
> function subtractpi(x::Real)
> x, y = promote(x, x - pi)
> return x > 5 ? y : x
> end
>
> immutable MyType{T<:FloatingPoint}
> x::T
> v::Vector{T}
>
> function MyType(x, v)
> x = subtractpi(x)
> v = map(subtractpi, v)
> new(x, v)
> end
> end
> MyType{T<:FloatingPoint}(x::T, v::Vector{T}) = MyType{T}(x, v)
>
> Thanks. I am working on my understanding of types in Julia.

[julia-users] Flexible construction of types

[Marc Gallant]

Suppose I have a type called MyType that has one floating point field "x". 
When constructed, if the value provided for "x" is greater than, let's say, 
5, it has pi subtracted from it. For example,

a = MyType(4)  # x = 4.0
b = MyType(-11) # x = 11.0
c = MyType(10)  # x = 6.8584
d = MyType(-1.443)  # x = -1.443

What is the best way to declare MyType and its constructor(s) to ensure 
that:

1. You can provide MyType with any real number to construct it
2. typeof(a.x) and typeof(c.x) are both Float64
3. The pi constraint is properly applied (is an inner constructor 
appropriate here?)
4. The same behaviour applies to the entries of a second field "y" that is 
a vector (e.g., MyType(10, [3, 10, 11, -2]) has x = 6.8584, y = [3.0, 
6.8584, 7.8584, -2.0]).
5. (if possible) You can construct MyType from a mixture of real number 
types (e.g., MyType(11.4, [1, 2, 55]))
6. MyType has a third field "z" that is a string

Here is an implementation I wrote that doesn't meet 1, 5, or 6:

function subtractpi(x::Real)
x, y = promote(x, x - pi)
return x > 5 ? y : x
end

immutable MyType{T<:FloatingPoint}
x::T
v::Vector{T}

function MyType(x, v)
x = subtractpi(x)
v = map(subtractpi, v)
new(x, v)
end
end
MyType{T<:FloatingPoint}(x::T, v::Vector{T}) = MyType{T}(x, v)

Thanks. I am working on my understanding of types in Julia.

Re: [julia-users] simplex in Julia is very slow

[Stefan Karpinski]

I wonder if \ might be type unstable.

On Wed, Nov 26, 2014 at 2:49 PM, Stefan Karpinski 
wrote:

> It turns out that doesn't actually matter but there are other unrelated
> ill-typed variables in the code:
>
> Xb, o, y, r, e, Nj, ind, q, t
>
>
> I haven't determined why this is happening, but something is ill-typed
> here.
>
> On Wed, Nov 26, 2014 at 1:20 PM, Tim Holy  wrote:
>
>> Stefan's point is more relevant than you realize; if the type of the
>> variable
>> is uncertain, the loop will be very slow. You can make that resize
>> operation a
>> separate function, from which you call your main routine.
>>
>> --Tim
>>
>> On Wednesday, November 26, 2014 09:26:35 AM Emerson Vitor Castelani wrote:
>> > Humm, It's useful but I guess that the problem is something in loop
>> while...
>> >
>> > Em quarta-feira, 26 de novembro de 2014 15h05min03s UTC-2, Stefan
>> Karpinski
>> >
>> > escreveu:
>> > > I'm not sure if this is the problem, but changing the type of a
>> variable
>> > > in a function body causes problems for type inference. For that
>> reason,
>> > > the
>> > > first two lines of this code may cause performance issue if you call
>> this
>> > > with b and c as matrices. A more Julian idiom for this is to do
>> something
>> > > like this:
>> > >
>> > > function simplex(A::Matrix, b::Vector, c::Vector)
>> > >
>> > > (m,n) = size(A);
>> > > ...
>> > >
>> > > end
>> > > simplex(A::Matrix, b::Matrix, c::Matrix) = simplex(A, vec(b), vec(c))
>> > >
>> > >
>> > > This also avoids copying the data of b and c needlessly.
>> > >
>> > > On Wednesday, November 26, 2014, Emerson Vitor Castelani <
>> > >
>> > > emerso...@gmail.com > wrote:
>> > >> Have you considered the example scsd8.mat?
>> > >>
>> > >> Em quarta-feira, 26 de novembro de 2014 14h39min14s UTC-2, Pileas
>> > >>
>> > >> escreveu:
>> > >>> Result with tic() toc() at the very beginning and at the very end:
>> > >>>
>> > >>> elapsed time: 0.025719973 seconds
>> > >>>
>> > >>>
>> > >>> Τη Τετάρτη, 26 Νοεμβρίου 2014 11:06:26 π.μ. UTC-5, ο χρήστης Emerson
>> > >>>
>> > >>> Vitor Castelani έγραψε:
>> >  Well, I am tried to implement a simple version of simplex in Julia
>> and
>> >  I have had some troubles. In Julia, my algorithm spends about 30
>> sec
>> >  and in
>> >  matlab/octave 3 sec for the same problem. So, I saw some tips in
>> order
>> >  to
>> >  get a better performance but the best that I got in Julia was 17-20
>> >  sec.
>> >  The codes are in attachment. I am new in Julia and the algorithms
>> are
>> >  little roughly implemented but they are very similar.
>> > 
>> >  Thanks
>>
>>
>

Re: [julia-users] simplex in Julia is very slow

[Stefan Karpinski]

It turns out that doesn't actually matter but there are other unrelated
ill-typed variables in the code:

Xb, o, y, r, e, Nj, ind, q, t


I haven't determined why this is happening, but something is ill-typed here.

On Wed, Nov 26, 2014 at 1:20 PM, Tim Holy  wrote:

> Stefan's point is more relevant than you realize; if the type of the
> variable
> is uncertain, the loop will be very slow. You can make that resize
> operation a
> separate function, from which you call your main routine.
>
> --Tim
>
> On Wednesday, November 26, 2014 09:26:35 AM Emerson Vitor Castelani wrote:
> > Humm, It's useful but I guess that the problem is something in loop
> while...
> >
> > Em quarta-feira, 26 de novembro de 2014 15h05min03s UTC-2, Stefan
> Karpinski
> >
> > escreveu:
> > > I'm not sure if this is the problem, but changing the type of a
> variable
> > > in a function body causes problems for type inference. For that reason,
> > > the
> > > first two lines of this code may cause performance issue if you call
> this
> > > with b and c as matrices. A more Julian idiom for this is to do
> something
> > > like this:
> > >
> > > function simplex(A::Matrix, b::Vector, c::Vector)
> > >
> > > (m,n) = size(A);
> > > ...
> > >
> > > end
> > > simplex(A::Matrix, b::Matrix, c::Matrix) = simplex(A, vec(b), vec(c))
> > >
> > >
> > > This also avoids copying the data of b and c needlessly.
> > >
> > > On Wednesday, November 26, 2014, Emerson Vitor Castelani <
> > >
> > > emerso...@gmail.com > wrote:
> > >> Have you considered the example scsd8.mat?
> > >>
> > >> Em quarta-feira, 26 de novembro de 2014 14h39min14s UTC-2, Pileas
> > >>
> > >> escreveu:
> > >>> Result with tic() toc() at the very beginning and at the very end:
> > >>>
> > >>> elapsed time: 0.025719973 seconds
> > >>>
> > >>>
> > >>> Τη Τετάρτη, 26 Νοεμβρίου 2014 11:06:26 π.μ. UTC-5, ο χρήστης Emerson
> > >>>
> > >>> Vitor Castelani έγραψε:
> >  Well, I am tried to implement a simple version of simplex in Julia
> and
> >  I have had some troubles. In Julia, my algorithm spends about 30 sec
> >  and in
> >  matlab/octave 3 sec for the same problem. So, I saw some tips in
> order
> >  to
> >  get a better performance but the best that I got in Julia was 17-20
> >  sec.
> >  The codes are in attachment. I am new in Julia and the algorithms
> are
> >  little roughly implemented but they are very similar.
> > 
> >  Thanks
>
>

Re: [julia-users] Memory allocation issue

[Colin Lea]

Ah, ok. Thanks! I ran those as functions and got similar timings.


> On Nov 26, 2014, at 1:35 PM, John Myles White  
> wrote:
> 
> Yes, the global scope is scarcely optimized and doesn't provide useful 
> information about performance.
> 
>  -- John
> 
> On Nov 26, 2014, at 10:33 AM, Colin Lea  > wrote:
> 
>> That was in global scope. Should that matter?
>> 
>> 
>>> On Nov 26, 2014, at 1:30 PM, John Myles White >> > wrote:
>>> 
>>> ?
>> 
> 

[julia-users] Re: SharedArray no longer shared after loading from jld file

[Ariel Keselman]

One more issue: The example above can be fixed by reassigning `a` to a new 
shared array. But in my case this won't work since I have this array within 
a wrapper type... seems like another semi related issue?

Re: [julia-users] Memory allocation issue

[John Myles White]

Yes, the global scope is scarcely optimized and doesn't provide useful 
information about performance.

 -- John

On Nov 26, 2014, at 10:33 AM, Colin Lea  wrote:

> That was in global scope. Should that matter?
> 
> 
>> On Nov 26, 2014, at 1:30 PM, John Myles White  
>> wrote:
>> 
>> ?
> 

Re: [julia-users] Memory allocation issue

[Colin Lea]

That was in global scope. Should that matter?


> On Nov 26, 2014, at 1:30 PM, John Myles White  
> wrote:
> 
> ?

Re: [julia-users] Memory allocation issue

[John Myles White]

Are these functions? Or are you timing expressions in the global scope?

 -- John
 
On Nov 26, 2014, at 10:28 AM, Colin Lea  wrote:

> Thanks to you both! However, there is still another odd issue. 
> 
> These two functions should be the same, but take very different amounts of 
> time/memory. Both 'T' and 'n_classes' are both of type Int64. 
> 
> @time (
> for t = 2:T
> for n = 1:n_classes
> for j = 1:n_classes
> end
> end
> end
> )
> 
> @time (
> for t = 2:5000
> for n = 1:10
> for j = 1:10
> end
> end
> end
> )
> 
> elapsed time: 0.063186286 seconds (18190040 bytes allocated)
> elapsed time: 0.002261641 seconds (71824 bytes allocated)
> 
> Any insight on this?
> 
> 
> On Wednesday, November 26, 2014 12:37:12 PM UTC-5, Tim Holy wrote:
> Nice job using track-allocation to figure out where the problem is. 
> 
> If you really don't want allocation, then you should investigate Devec.jl or 
> InPlaceOps.jl, or write out these steps using loops to access each element of 
> those matrices. 
> 
> --Tim 
> 
> On Wednesday, November 26, 2014 07:55:59 AM Colin Lea wrote: 
> > I'm implementing an inference algorithm and am running into memory 
> > allocation issues that are slowing it down. I created a minimal example 
> > that resembles my algorithm and see that the problem persists. 
> > 
> > The issue is that Julia is allocating a lot of extra memory when adding 
> > matrices together. This happens regardless of whether or not I preallocate 
> > the output matrix. 
> > 
> > Minimal example: 
> > https://gist.github.com/colincsl/ab44884c5542539f813d 
> > 
> > Memory output of minimal example (using julia --track-allocation=user): 
> > https://gist.github.com/colincsl/c9c9dd86fca277705873 
> > 
> > Am I misunderstanding something? Should I be performing the operation 
> > differently? 
> > 
> > One thing I've played with is the matrix C. The indices are a sliding 
> > window (e.g. use C[t-10:t] for all t). When I remove C from the equation 
> > the performance increases by a factor of 2.5. However, it still uses more 
> > memory than expected. Could this be the primary issue? 
> 

Re: [julia-users] Memory allocation issue

[Colin Lea]

Thanks to you both! However, there is still another odd issue. 

These two functions should be the same, but take very different amounts of 
time/memory. Both 'T' and 'n_classes' are both of type Int64. 

@time (
for t = 2:T
for n = 1:n_classes
for j = 1:n_classes
end
end
end
)

@time (
for t = 2:5000
for n = 1:10
for j = 1:10
end
end
end
)

elapsed time: 0.063186286 seconds (18190040 bytes allocated)
elapsed time: 0.002261641 seconds (71824 bytes allocated)

Any insight on this?


On Wednesday, November 26, 2014 12:37:12 PM UTC-5, Tim Holy wrote:
>
> Nice job using track-allocation to figure out where the problem is. 
>
> If you really don't want allocation, then you should investigate Devec.jl 
> or 
> InPlaceOps.jl, or write out these steps using loops to access each element 
> of 
> those matrices. 
>
> --Tim 
>
> On Wednesday, November 26, 2014 07:55:59 AM Colin Lea wrote: 
> > I'm implementing an inference algorithm and am running into memory 
> > allocation issues that are slowing it down. I created a minimal example 
> > that resembles my algorithm and see that the problem persists. 
> > 
> > The issue is that Julia is allocating a lot of extra memory when adding 
> > matrices together. This happens regardless of whether or not I 
> preallocate 
> > the output matrix. 
> > 
> > Minimal example: 
> > https://gist.github.com/colincsl/ab44884c5542539f813d 
> > 
> > Memory output of minimal example (using julia --track-allocation=user): 
> > https://gist.github.com/colincsl/c9c9dd86fca277705873 
> > 
> > Am I misunderstanding something? Should I be performing the operation 
> > differently? 
> > 
> > One thing I've played with is the matrix C. The indices are a sliding 
> > window (e.g. use C[t-10:t] for all t). When I remove C from the equation 
> > the performance increases by a factor of 2.5. However, it still uses 
> more 
> > memory than expected. Could this be the primary issue? 
>
>

[julia-users] SharedArray no longer shared after loading from jld file

[Ariel Keselman]

Consider the following simple example:

using HDF5, JLD

addprocs(2)

# create and save the shared array
a = SharedArray(Int64, 100)
save("example.jld", "a", a)

# clear the shared array...
a = nothing

# load what we saved...
a = load("example.jld")["a"]

# try to use it...
@parallel for i in 1:length(a)
a[i] = i
end

# Now its filled with zeros, as if it were a normal array.
@show a

So two issues here:

1) is there a way to "reassign" a shared array to processes? This seems 
useful when adding/removing procs
2) JLD should use the shared array constructor, I'm not sure how it 
constructs the array now. Should I open an issue?

Thanks!

Re: [julia-users] simplex in Julia is very slow

[Tim Holy]

Stefan's point is more relevant than you realize; if the type of the variable 
is uncertain, the loop will be very slow. You can make that resize operation a 
separate function, from which you call your main routine.

--Tim

On Wednesday, November 26, 2014 09:26:35 AM Emerson Vitor Castelani wrote:
> Humm, It's useful but I guess that the problem is something in loop while...
> 
> Em quarta-feira, 26 de novembro de 2014 15h05min03s UTC-2, Stefan Karpinski
> 
> escreveu:
> > I'm not sure if this is the problem, but changing the type of a variable
> > in a function body causes problems for type inference. For that reason,
> > the
> > first two lines of this code may cause performance issue if you call this
> > with b and c as matrices. A more Julian idiom for this is to do something
> > like this:
> > 
> > function simplex(A::Matrix, b::Vector, c::Vector)
> > 
> > (m,n) = size(A);
> > ...
> > 
> > end
> > simplex(A::Matrix, b::Matrix, c::Matrix) = simplex(A, vec(b), vec(c))
> > 
> > 
> > This also avoids copying the data of b and c needlessly.
> > 
> > On Wednesday, November 26, 2014, Emerson Vitor Castelani <
> > 
> > emerso...@gmail.com > wrote:
> >> Have you considered the example scsd8.mat?
> >> 
> >> Em quarta-feira, 26 de novembro de 2014 14h39min14s UTC-2, Pileas
> >> 
> >> escreveu:
> >>> Result with tic() toc() at the very beginning and at the very end:
> >>> 
> >>> elapsed time: 0.025719973 seconds
> >>> 
> >>> 
> >>> Τη Τετάρτη, 26 Νοεμβρίου 2014 11:06:26 π.μ. UTC-5, ο χρήστης Emerson
> >>> 
> >>> Vitor Castelani έγραψε:
>  Well, I am tried to implement a simple version of simplex in Julia and
>  I have had some troubles. In Julia, my algorithm spends about 30 sec
>  and in
>  matlab/octave 3 sec for the same problem. So, I saw some tips in order
>  to
>  get a better performance but the best that I got in Julia was 17-20
>  sec.
>  The codes are in attachment. I am new in Julia and the algorithms are
>  little roughly implemented but they are very similar.
>  
>  Thanks

[julia-users] Re: Significant rounding error in Julia: N * (1/1) == N + 1

[Pileas]

It does not happen in my machine either.

Τη Τετάρτη, 19 Νοεμβρίου 2014 2:47:20 μ.μ. UTC-5, ο χρήστης Intrinsic Audio 
έγραψε:
>
> I've found an interesting issue in Julia that, though it seems trivial in 
> the application I've given, is really messing up my code and my ability to 
> guarantee its performance.
>
> Apparently, 44099 * (1/1) == 44100, which in my book is a very massive 
> error.
>
> I wrote a resample() function for the project I'm working on, and I found 
> that rounding errors in Julia have made the language unacceptable to my 
> superiors.  Is this a fundamental issue with Julia, or is there something I 
> can do to fix this?
>
> Here is a screenshot of a simple script that demonstrates this:
>
> http://i.imgur.com/mA9hpqw.png
>
> Why does this happen?
>

Re: [julia-users] Memory allocation issue

[Tim Holy]

Nice job using track-allocation to figure out where the problem is.

If you really don't want allocation, then you should investigate Devec.jl or 
InPlaceOps.jl, or write out these steps using loops to access each element of 
those matrices.

--Tim

On Wednesday, November 26, 2014 07:55:59 AM Colin Lea wrote:
> I'm implementing an inference algorithm and am running into memory
> allocation issues that are slowing it down. I created a minimal example
> that resembles my algorithm and see that the problem persists.
> 
> The issue is that Julia is allocating a lot of extra memory when adding
> matrices together. This happens regardless of whether or not I preallocate
> the output matrix.
> 
> Minimal example:
> https://gist.github.com/colincsl/ab44884c5542539f813d
> 
> Memory output of minimal example (using julia --track-allocation=user):
> https://gist.github.com/colincsl/c9c9dd86fca277705873
> 
> Am I misunderstanding something? Should I be performing the operation
> differently?
> 
> One thing I've played with is the matrix C. The indices are a sliding
> window (e.g. use C[t-10:t] for all t). When I remove C from the equation
> the performance increases by a factor of 2.5. However, it still uses more
> memory than expected. Could this be the primary issue?

Re: [julia-users] simplex in Julia is very slow

[Milan Bouchet-Valat]

Le mercredi 26 novembre 2014 à 09:26 -0800, Emerson Vitor Castelani a
écrit :
> Humm, It's useful but I guess that the problem is something in loop
> while...
If I were you I'd have a look at where time is spent are where
allocations are happening, and try to improve this by writing explicit
loops at the relevant places. See how to use the profiler and track
memory allocation here:
http://docs.julialang.org/en/latest/stdlib/profile/#stdlib-profiling


Regards


> Em quarta-feira, 26 de novembro de 2014 15h05min03s UTC-2, Stefan
> Karpinski escreveu:
> I'm not sure if this is the problem, but changing the type of
> a variable in a function body causes problems for type
> inference. For that reason, the first two lines of this code
> may cause performance issue if you call this with b and c as
> matrices. A more Julian idiom for this is to do something like
> this:
> 
> 
> function simplex(A::Matrix, b::Vector, c::Vector)
> (m,n) = size(A); 
> ...
> end
> simplex(A::Matrix, b::Matrix, c::Matrix) = simplex(A,
> vec(b), vec(c))
> 
> 
> This also avoids copying the data of b and c needlessly.
> 
> 
> On Wednesday, November 26, 2014, Emerson Vitor Castelani
>  wrote:
> Have you considered the example scsd8.mat?
> 
> Em quarta-feira, 26 de novembro de 2014 14h39min14s
> UTC-2, Pileas escreveu:
> Result with tic() toc() at the very beginning
> and at the very end:
> 
> 
> elapsed time: 0.025719973 seconds
> 
> 
> 
> 
> Τη Τετάρτη, 26 Νοεμβρίου 2014 11:06:26 π.μ.
> UTC-5, ο χρήστης Emerson Vitor Castelani
> έγραψε:
> Well, I am tried to implement a simple
> version of simplex in Julia and I have
> had some troubles. In Julia, my
> algorithm spends about 30 sec and in
> matlab/octave 3 sec for the same
> problem. So, I saw some tips in order
> to get a better performance but the
> best that I got in Julia was 17-20
> sec. The codes are in attachment. I am
> new in Julia and the algorithms are
> little roughly implemented but they
> are very similar.
> 
> 
> Thanks
> 
> 
> 
> 

Re: [julia-users] Re: what's the best way to do R table() in julia? (why does StatsBase.count(x,k) need k?)

[David van Leeuwen]

Hello again,

I worked hard on NamedArrays.jl to solve the problems indicated below:

On Monday, November 10, 2014 1:43:57 AM UTC+1, Dahua Lin wrote:
>
> NamedArrays.jl generally goes along this way. However, it remains limited 
> in two aspects:
>
> 1. Some fields in NamedArrays are not declared of specific types. In 
> particular, the field `dicts` is of the type `Vector{Dict}`, and the use of 
> this field is on the critical path when looping over the table, e.g. when 
> counting. This would potentially lead to substantial impact on performance.
>
> A NamedArray is now parameterized by the complete set of Dicts that are 
used for the indices.  It took me a while to get the constructors right, in 
intermediate stages of the development I ended up with VarType parameters 
of NamedArray.  
 

> 2. Currently, it only accepts a limited set of types for indices, e.g. 
> Real and String. But in some cases, people may go beyond this. I don't 
> think we have to impose this limit. 
>
> The indexing code is completely overhauled now, and the indices() methods 
are now explicitly parameterized by the dictionary key type, their call 
should be efficient.  It should now be possible to index a NamedArray with 
any type, although some types (AbstractVector, Range, Int) are interpreted 
specially.  

As a consequence, the type of the key for the indices cannot be altered 
after initialization of a NamedArray (the names themselves still can). 
 Thus, if you want other types than ASCIIString (which is used to give 
default names to indices), you need to call a constructor with your names 
prepared instead of filling them in afterwards. 

You can try the code for julia-0.3 with Pkg.checkout("NamedArrays"), or 
read it at Github. 

Cheers, 

---david
 

> Dahua
>
>
> On Monday, November 10, 2014 8:35:32 AM UTC+8, Dahua Lin wrote:
>>
>> I have been observing an interesting differences between people coming 
>> from stats and machine learning.
>>
>> Stats people tend to favor the approach that allows one to directly use 
>> the category names to index the table, e.g. A["apple"]. This tendency is 
>> clearly reflected in the design of R, where one can attach a name to 
>> everything.
>>
>> While in machine learning practice, it is a common convention to just 
>> encode categories into integers, and simply use an ordinary array to 
>> represent a counting table. Whereas it makes it a little bit inconvenient 
>> in an interactive environment, this way is generally more efficient when 
>> you have to deal with these categories over a large number of samples.
>>
>> These differences aside, I believe, however, that there exist a very 
>> generic approach to this problem -- a multi-dimensional associative map, 
>> which allows one to write A[i1, i2, ...] where the indices can be arbitrary 
>> hashable & equality-comparable instances, including integers, strings, 
>> symbols, among many other things.
>>
>> A multi-dimensional associative map can be considered as a 
>> multi-dimensional generalization of dictionaries, which can be easily 
>> implemented via an multidimensional array and several dictionaries, each 
>> for one dimension, to map user-side indexes to integer indexes. 
>>
>> - Dahua
>>
>>
>>
>>
>> On Monday, November 10, 2014 8:12:54 AM UTC+8, David van Leeuwen wrote:
>>>
>>> Hi, 
>>>
>>> On Sunday, November 9, 2014 5:10:19 PM UTC+1, Milan Bouchet-Valat wrot
>>>
 Actually I didn't do it because NamedArrays.jl didn't work well on 0.3 
 when I first worked on the package. Now I see the tests are still failing. 
 Do you know what is needed to make them work?

 What is exactly not working, could you maybe file an issue?  Travis 
>>> tells me all is fine. 
>>>
>>> ---david
>>>  
>>>
 Another point is that I think this deserves going into StatsBase, but 
 before that we need everybody to agree on a design for NamedArrays.

 Regards


  On Sunday, November 9, 2014 4:26:45 PM UTC+1, Milan Bouchet-Valat 
 wrote: 

  Le jeudi 06 novembre 2014 à 11:17 -0800, Conrad Stack a écrit : 

 I was also looking for a function like this, but could not find one in 
 docs.julialang.org.  I was doing this (v0.4.0-dev), for anyone who is 
 interested:


 example = rand(1:10,100)
 uexample = sort(unique(example))
 counts = map(x->count(y->x==y,example),uexample)


 It's pretty ugly, so thanks, Johan, for pointing out the 
 StatsBase->countmap 

 I've also put together a small package precisely aimed at offering an 
 equivalent of R's table():
 https://github.com/nalimilan/ 
 Tables.jl 

 But there's a more general issue about how to handle arrays with 
 dimension names in Julia. NamedArrays.jl (which is used in my package) 
 attempts to tackle this issue, but I don't think we've reached a consensus 
 yet about the best 

Re: [julia-users] simplex in Julia is very slow

[Emerson Vitor Castelani]

Humm, It's useful but I guess that the problem is something in loop while...

Em quarta-feira, 26 de novembro de 2014 15h05min03s UTC-2, Stefan Karpinski 
escreveu:
>
> I'm not sure if this is the problem, but changing the type of a variable 
> in a function body causes problems for type inference. For that reason, the 
> first two lines of this code may cause performance issue if you call this 
> with b and c as matrices. A more Julian idiom for this is to do something 
> like this:
>
> function simplex(A::Matrix, b::Vector, c::Vector)
> (m,n) = size(A); 
> ...
> end
> simplex(A::Matrix, b::Matrix, c::Matrix) = simplex(A, vec(b), vec(c))
>
>
> This also avoids copying the data of b and c needlessly.
>
> On Wednesday, November 26, 2014, Emerson Vitor Castelani <
> emerso...@gmail.com > wrote:
>
>> Have you considered the example scsd8.mat?
>>
>> Em quarta-feira, 26 de novembro de 2014 14h39min14s UTC-2, Pileas 
>> escreveu:
>>>
>>> Result with tic() toc() at the very beginning and at the very end:
>>>
>>> elapsed time: 0.025719973 seconds
>>>
>>>
>>> Τη Τετάρτη, 26 Νοεμβρίου 2014 11:06:26 π.μ. UTC-5, ο χρήστης Emerson 
>>> Vitor Castelani έγραψε:

 Well, I am tried to implement a simple version of simplex in Julia and 
 I have had some troubles. In Julia, my algorithm spends about 30 sec and 
 in 
 matlab/octave 3 sec for the same problem. So, I saw some tips in order to 
 get a better performance but the best that I got in Julia was 17-20 sec. 
 The codes are in attachment. I am new in Julia and the algorithms are 
 little roughly implemented but they are very similar.

 Thanks

Re: [julia-users] Memory allocation issue

[Milan Bouchet-Valat]

Le mercredi 26 novembre 2014 à 07:55 -0800, Colin Lea a écrit :
> I'm implementing an inference algorithm and am running into memory
> allocation issues that are slowing it down. I created a minimal
> example that resembles my algorithm and see that the problem persists.
> 
> 
> The issue is that Julia is allocating a lot of extra memory when
> adding matrices together. This happens regardless of whether or not I
> preallocate the output matrix. 
> 
> 
> Minimal example: 
> https://gist.github.com/colincsl/ab44884c5542539f813d
> 
> 
> Memory output of minimal example (using
> julia --track-allocation=user):
> https://gist.github.com/colincsl/c9c9dd86fca277705873
> 
> 
> Am I misunderstanding something? Should I be performing the operation
> differently?
> 
> 
> One thing I've played with is the matrix C. The indices are a sliding
> window (e.g. use C[t-10:t] for all t). When I remove C from the
> equation the performance increases by a factor of 2.5. However, it
> still uses more memory than expected. Could this be the primary issue?
Matrix addition returns a copy (at least currently), so you want to
avoid using it in a tight loop. You can simply write another loop inside
the existing ones to go over 'out' an fill it element by element.


Regards

Re: [julia-users] simplex in Julia is very slow

[Stefan Karpinski]

I'm not sure if this is the problem, but changing the type of a variable in
a function body causes problems for type inference. For that reason, the
first two lines of this code may cause performance issue if you call this
with b and c as matrices. A more Julian idiom for this is to do something
like this:

function simplex(A::Matrix, b::Vector, c::Vector)
(m,n) = size(A);
...
end
simplex(A::Matrix, b::Matrix, c::Matrix) = simplex(A, vec(b), vec(c))


This also avoids copying the data of b and c needlessly.

On Wednesday, November 26, 2014, Emerson Vitor Castelani <
emersonvi...@gmail.com> wrote:

> Have you considered the example scsd8.mat?
>
> Em quarta-feira, 26 de novembro de 2014 14h39min14s UTC-2, Pileas escreveu:
>>
>> Result with tic() toc() at the very beginning and at the very end:
>>
>> elapsed time: 0.025719973 seconds
>>
>>
>> Τη Τετάρτη, 26 Νοεμβρίου 2014 11:06:26 π.μ. UTC-5, ο χρήστης Emerson
>> Vitor Castelani έγραψε:
>>>
>>> Well, I am tried to implement a simple version of simplex in Julia and I
>>> have had some troubles. In Julia, my algorithm spends about 30 sec and in
>>> matlab/octave 3 sec for the same problem. So, I saw some tips in order to
>>> get a better performance but the best that I got in Julia was 17-20 sec.
>>> The codes are in attachment. I am new in Julia and the algorithms are
>>> little roughly implemented but they are very similar.
>>>
>>> Thanks
>>>
>>>
>>>

[julia-users] Re: Q4 2014 Lint.jl update

[Tony Fong]

On Wednesday, November 26, 2014 11:41:09 PM UTC+7, Nils Gudat wrote:
 An example:
>
> function f{T<:Float64}(x1::T, x2::T, x3::Array) will give me "Error: 
> Float64 is a leaf type. As a type constraint it makes no sense in 
> T<:Float64". I thought this was a way of efficiently expressing that both 
> x1 and x2 should be of type Float64, but apparently that's not a great idea?
>

yes, you could have just written
function f( x1::Float64, x2::Float64, x3::Array )
Float64 is concrete type, so you don't need curly to express that.

[julia-users] Re: simplex in Julia is very slow

[Emerson Vitor Castelani]

Have you considered the example scsd8.mat?

Em quarta-feira, 26 de novembro de 2014 14h39min14s UTC-2, Pileas escreveu:
>
> Result with tic() toc() at the very beginning and at the very end:
>
> elapsed time: 0.025719973 seconds
>
>
> Τη Τετάρτη, 26 Νοεμβρίου 2014 11:06:26 π.μ. UTC-5, ο χρήστης Emerson Vitor 
> Castelani έγραψε:
>>
>> Well, I am tried to implement a simple version of simplex in Julia and I 
>> have had some troubles. In Julia, my algorithm spends about 30 sec and in 
>> matlab/octave 3 sec for the same problem. So, I saw some tips in order to 
>> get a better performance but the best that I got in Julia was 17-20 sec. 
>> The codes are in attachment. I am new in Julia and the algorithms are 
>> little roughly implemented but they are very similar.
>>
>> Thanks
>>
>>
>>

[julia-users] Re: Q4 2014 Lint.jl update

[Tony Fong]

Ah yes, array related type checks is a major issue. See 
https://github.com/tonyhffong/Lint.jl/issues/27

Post your issues there and we should be able to knock them off. It's not 
difficult, just need to know where the priorities are.

Tony

On Wednesday, November 26, 2014 11:49:58 PM UTC+7, Nils Gudat wrote:
>
> Another thing: Consider the following example
>
> X1 = zeros(100, 100)
> X2 = Array(Float64, (100, 100))
> X1[1, 1]
> X2[1, 1]
>
> In this piece of code, I will get an error saying "X2[1, 1] has more 
> indices than dimensions", even though it hasn't. In light of the recent 
> discussion on this list about the speed advantages of initializing unfilled 
> Arrays I recently changed all my code from zeros to Arrays, so I'm getting 
> this a lot...
>

[julia-users] Re: Q4 2014 Lint.jl update

[Nils Gudat]

Another thing: Consider the following example

X1 = zeros(100, 100)
X2 = Array(Float64, (100, 100))
X1[1, 1]
X2[1, 1]

In this piece of code, I will get an error saying "X2[1, 1] has more 
indices than dimensions", even though it hasn't. In light of the recent 
discussion on this list about the speed advantages of initializing unfilled 
Arrays I recently changed all my code from zeros to Arrays, so I'm getting 
this a lot...

[julia-users] Re: Constant attributes of Composite Type

[Robert Gates]

My bad :)

On Tuesday, November 25, 2014 10:00:59 PM UTC+1, Robert Gates wrote:
>
> Hi Julians:
>
> I'm still new to Julia and am having a little trouble correctly 
> understanding composite types. I would like to create a composite type with 
> a mixture of constant attributes, i.e. class attributes, and mutable 
> attributes. In practice, the problem is that I need to instantiate many, 
> e.g. 10e8, type instances and would like to avoid having to allocate memory 
> for values which are constant over a large subset of these instances. Is 
> there any way to do this correctly?
>
> Thanks for your help!
>
> Robert
>

Re: [julia-users] Re: Constant attributes of Composite Type

[John Myles White]

Vector{MyType} is a type, not a value. Did you mean Array(MyType, 1)?

 — John

On Nov 26, 2014, at 8:38 AM, Robert Gates  wrote:

> OK thanks John, I ended up doing a bit differently but it works fine. Sorry 
> to keep asking, but now I have another problem I can't seem to wrap my head 
> around: consider
> 
> my_type_collection = Vector{MyType}
> my_type_collection[1] = MyType(a,b,c)
> 
> returns: `setindex!` has no method matching 
> setindex!(::Type{Array{MyType,1}}, ::MyType, ::Int64)
> 
> Seems a bit weird to me, since
> 
> my_type_collection = [MyType(a,b,c); MyType(d,e,f)]
> my_type_collection[1] = my_type_collection[2]
> 
> works just fine.
> 
> 
> 
> 
> 
> On Tuesday, November 25, 2014 10:00:59 PM UTC+1, Robert Gates wrote:
> Hi Julians:
> 
> I'm still new to Julia and am having a little trouble correctly understanding 
> composite types. I would like to create a composite type with a mixture of 
> constant attributes, i.e. class attributes, and mutable attributes. In 
> practice, the problem is that I need to instantiate many, e.g. 10e8, type 
> instances and would like to avoid having to allocate memory for values which 
> are constant over a large subset of these instances. Is there any way to do 
> this correctly?
> 
> Thanks for your help!
> 
> Robert

[julia-users] Re: Q4 2014 Lint.jl update

[Nils Gudat]

Hi Tony,

I've only been using Lint for two days, so I might be doing it wrong, but 
I'm getting a lot of false positives about values I've declared, but not 
used - upon closer inspection of my code, they are almost always used, 
sometimes within loops, sometimes in if/else branches, sometimes as 
arguments when constructing a function within a function. Is there a limit 
to where Lint can detect whether I'm using a variable or not?

Futher, I'm sometimes getting UndefVarErrors when I use functions from 
packages (such as pdf from distributions, or PyPlot), even when the 
packages are loaded. Any way to get around this?

Also, I'm often getting Errors about my type constraints, but I'm sure this 
is related to my limited understanding of how this works. An example:
function f{T<:Float64}(x1::T, x2::T, x3::Array) will give me "Error: 
Float64 is a leaf type. As a type constraint it makes no sense in 
T<:Float64". I thought this was a way of efficiently expressing that both 
x1 and x2 should be of type Float64, but apparently that's not a great idea?

In any case it's a great package that has already helped me catch quite a 
few significant mistakes in my code, so thanks a lot for your work!

Best,
Nils

[julia-users] Re: simplex in Julia is very slow

[Pileas]

Result with tic() toc() at the very beginning and at the very end:

elapsed time: 0.025719973 seconds


Τη Τετάρτη, 26 Νοεμβρίου 2014 11:06:26 π.μ. UTC-5, ο χρήστης Emerson Vitor 
Castelani έγραψε:
>
> Well, I am tried to implement a simple version of simplex in Julia and I 
> have had some troubles. In Julia, my algorithm spends about 30 sec and in 
> matlab/octave 3 sec for the same problem. So, I saw some tips in order to 
> get a better performance but the best that I got in Julia was 17-20 sec. 
> The codes are in attachment. I am new in Julia and the algorithms are 
> little roughly implemented but they are very similar.
>
> Thanks
>
>
>

[julia-users] Re: Constant attributes of Composite Type

[Robert Gates]

OK thanks John, I ended up doing a bit differently but it works fine. Sorry 
to keep asking, but now I have another problem I can't seem to wrap my head 
around: consider

my_type_collection = Vector{MyType}
my_type_collection[1] = MyType(a,b,c)

returns: `setindex!` has no method matching 
setindex!(::Type{Array{MyType,1}}, ::MyType, ::Int64)

Seems a bit weird to me, since

my_type_collection = [MyType(a,b,c); MyType(d,e,f)]
my_type_collection[1] = my_type_collection[2]

works just fine.





On Tuesday, November 25, 2014 10:00:59 PM UTC+1, Robert Gates wrote:
>
> Hi Julians:
>
> I'm still new to Julia and am having a little trouble correctly 
> understanding composite types. I would like to create a composite type with 
> a mixture of constant attributes, i.e. class attributes, and mutable 
> attributes. In practice, the problem is that I need to instantiate many, 
> e.g. 10e8, type instances and would like to avoid having to allocate memory 
> for values which are constant over a large subset of these instances. Is 
> there any way to do this correctly?
>
> Thanks for your help!
>
> Robert
>

[julia-users] Re: simplex in Julia is very slow

[cdm]

a search of the julia-users list for the string "simplex" yields nine posts 
...

since an attribute of benchmarking is speed/timing, this post stood out:

  
 
https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/simplex|sort:date/julia-users/QCPHX63r0oQ/mheoSJqD96YJ


within that post, there is a link to a proper Julia implementation of 
simplex:

https://github.com/mlubin/SimplexBenchmarks 



you may find the contents therein useful and/or interesting.



On Wednesday, November 26, 2014 8:06:26 AM UTC-8, Emerson Vitor Castelani 
wrote:
>
> Well, I am tried to implement a simple version of simplex in Julia and I 
> have had some troubles. In Julia, my algorithm spends about 30 sec and in 
> matlab/octave 3 sec for the same problem. So, I saw some tips in order to 
> get a better performance but the best that I got in Julia was 17-20 sec. 
> The codes are in attachment. I am new in Julia and the algorithms are 
> little roughly implemented but they are very similar.
>
> Thanks
>
>
>

[julia-users] Memory allocation issue

[Colin Lea]

I'm implementing an inference algorithm and am running into memory 
allocation issues that are slowing it down. I created a minimal example 
that resembles my algorithm and see that the problem persists.

The issue is that Julia is allocating a lot of extra memory when adding 
matrices together. This happens regardless of whether or not I preallocate 
the output matrix. 

Minimal example: 
https://gist.github.com/colincsl/ab44884c5542539f813d

Memory output of minimal example (using julia --track-allocation=user):
https://gist.github.com/colincsl/c9c9dd86fca277705873

Am I misunderstanding something? Should I be performing the operation 
differently?

One thing I've played with is the matrix C. The indices are a sliding 
window (e.g. use C[t-10:t] for all t). When I remove C from the equation 
the performance increases by a factor of 2.5. However, it still uses more 
memory than expected. Could this be the primary issue?

[julia-users] Re: PyPlot.plot_date: How do I alter the time format?

[Nat Wilson]

You might try something like:

majorformatter = matplotlib[:dates][:DateFormatter]("%m/%d")
minorformatter = matplotlib[:dates][:DateFormatter]("%H:%M")
majorlocator = matplotlib[:dates][:DayLocator](interval=1)
minorlocator = matplotlib[:dates][:HourLocator](byhour=(8, 16))
ax1[:xaxis][:set_major_formatter](majorformatter)
ax1[:xaxis][:set_minor_formatter](minorformatter)
ax1[:xaxis][:set_major_locator](majorlocator)
ax1[:xaxis][:set_minor_locator](minorlocator)

See an example here:
http://matplotlib.org/examples/pylab_examples/date_demo2.html

Nat


On Wednesday, November 26, 2014 8:38:43 AM UTC-5, RecentConvert wrote:
>
> using PyPlot
> using Dates
>
> # Create Data
> dt = Millisecond(200)
> time = [DateTime(2014,11,20):dt:DateTime(2014,11,24)]
> y = fill!(Array(Float64,length(time)),42)
> #y = floor(100*rand(length(time))) # Causes error: "OverflowError: 
> Allocated too many blocks"
>
> font1 = ["fontname"=>"Sans","style"=>"normal"]
> time = float64(time)/1000/60/60/24 # Convert time from milliseconds from 
> day 0 to days from day 0
>
> # Plot
> fig = figure("Test Plot",figsize=(16,10)) # Create a figure and save the 
> handle
> ax1 = axes()
> p1 = plot_date(time,y,linestyle="-",marker="None",label="test")
> axis("tight")
> title("Random Data Against Time\n" * timespan)
> grid("on")
> xlabel("Time")
> ylabel("Stuff",fontdict=font1)
> fig[:autofmt_xdate](bottom=0.2,rotation=30,ha="right")
> fig[:canvas][:draw]() # Update the figure
> PyPlot.tight_layout()
>
> It would be much easier to have midnight be the date and every 4, 6, or 8 
> hours be time of day. I would be happy with just the dates part though.
>

[julia-users] Q4 2014 Lint.jl update

[Tony Fong]

Fellow Julia enthusiasts,

It seems a quarterly update to Lint.jl carries enough weight without being 
overwhelming, so here it is again.

Here are the new abuses that would be caught. Most of them I encountered 
them the hard way, so hopefully new users won't random-walk into them.

   - A first stab at linting staged function (or whatever name it will be 
   finalized into). It is fairly basic, catching comparisons between 
   incompatible types.
   - Since 0.4 will introduce a few coding style changes (Dict,Array 
   constructions, Symbol() instead of (or maybe in addition to) symbol() 
   and so on), some packages would have VERSION predicates. Lint tries to 
   understand basic predicates (like VERSION < v"0.4-") and would give more 
   version-appropriate messages
   - Catch dangerous variables (e.g. call = 1.0) that would almost 
   certainly explode in your face
   - Catch [1 :end] and [end -1]
   - Catch new() with the number of arguments different from the number of 
   fields in the type (INFO if too few, ERROR if too many)
   - Catch silly curly brackets mistake that generates hard-to-debug type 
   inference error. e.g. d = Dict{ :Symbol, Any}()
   - Catch assigning a.b = something when a is proven to be of an immutable 
   type e.g. Complex. 
   - Remind Array{ T,n } is not Array( T, n ). (Subsequent usage will 
   generate type related lint errors.)
   - Unused function arguments.
   - Other improvements:
  - More accurate code locations from the lint messages.
  - @doc aware
   

Thanks to Ariel, Sam, Tim, Tomas and others who pointed out issues.

On IDE integration: some users find the package a bit "bulky" (well it does 
check a lot of things) so Julia+Lint takes a while to load, reducing the 
code-lint-fix loop productivity. It is certainly an issue. I'm up for 
suggestions. 

Again please continue with your support by reporting gaps, false positives, 
and even better, PR. 

Tony

[julia-users] Re: [Offtopic:] Why you did choose the name "Julia"?

[Neal Becker]

All the good names were taken :)

Pileas wrote:

> Is there a specific reason you guys chose this name?
> 
> It kinda reminds me Linux Mint where each distro. has a girl's name ...
-- 
-- Those who don't understand recursion are doomed to repeat it

Re: [julia-users] Re: Meshgrid in Julia: a working example and possible alternatives

[Steven G. Johnson]

On Wednesday, November 26, 2014 12:45:09 AM UTC-5, David Smith wrote:
>
> My up-to-date version of Matplotlib won't plot NaNs either.
>

That's weird; it works fine for me in Matplotlib 1.4.0.

In any case, you can always zero out the NaN values in W via:
W[isnan(W)] = 0
before plotting. 

[julia-users] Re: PyPlot.plot_date: How do I alter the time format?

[RecentConvert]

using PyPlot
using Dates

# Create Data
dt = Millisecond(200)
time = [DateTime(2014,11,20):dt:DateTime(2014,11,24)]
y = fill!(Array(Float64,length(time)),42)
#y = floor(100*rand(length(time))) # Causes error: "OverflowError: 
Allocated too many blocks"

font1 = ["fontname"=>"Sans","style"=>"normal"]
time = float64(time)/1000/60/60/24 # Convert time from milliseconds from 
day 0 to days from day 0

# Plot
fig = figure("Test Plot",figsize=(16,10)) # Create a figure and save the 
handle
ax1 = axes()
p1 = plot_date(time,y,linestyle="-",marker="None",label="test")
axis("tight")
title("Random Data Against Time\n" * timespan)
grid("on")
xlabel("Time")
ylabel("Stuff",fontdict=font1)
fig[:autofmt_xdate](bottom=0.2,rotation=30,ha="right")
fig[:canvas][:draw]() # Update the figure
PyPlot.tight_layout()

It would be much easier to have midnight be the date and every 4, 6, or 8 
hours be time of day. I would be happy with just the dates part though.

[julia-users] Re: Significant rounding error in Julia: N * (1/1) == N + 1

[Mike Innes]

Woops, shouldn't have missed this thread.

Either way I just pushed 0.9.1 which turns off all rounding in display.

On Thursday, 20 November 2014 10:59:25 UTC, Ken B wrote:
>
> for reference, here is the issue 
> https://github.com/one-more-minute/Julia-LT/issues/114
> I've been bitten by this one also in the past, but luckily it's only the 
> display
>
> On Thursday, 20 November 2014 10:27:02 UTC+1, Arch Call wrote:
>>
>> Requested screen print is attached.
>>
>>
>>
>> On Wednesday, November 19, 2014 2:47:20 PM UTC-5, Intrinsic Audio wrote:
>>>
>>> I've found an interesting issue in Julia that, though it seems trivial 
>>> in the application I've given, is really messing up my code and my ability 
>>> to guarantee its performance.
>>>
>>> Apparently, 44099 * (1/1) == 44100, which in my book is a very massive 
>>> error.
>>>
>>> I wrote a resample() function for the project I'm working on, and I 
>>> found that rounding errors in Julia have made the language unacceptable to 
>>> my superiors.  Is this a fundamental issue with Julia, or is there 
>>> something I can do to fix this?
>>>
>>> Here is a screenshot of a simple script that demonstrates this:
>>>
>>> http://i.imgur.com/mA9hpqw.png
>>>
>>> Why does this happen?
>>>
>>

Re: [julia-users] A Test Matrix Collection for Julia

[Weijian Zhang]

Dear Tamas,

Thanks for your suggestion. 

After seeing your post, I spent some time trying to know the difference 
between
symbols and strings. This stackoverflow post 
 was 
helpful. I think both symbols 
and strings are fine for Matrix Depot, as you said this is more of a matter 
of taste.
But I would like to draw an analogy bewteen matrixdepot and readtable. See 
for example:

df = readtable("data.csv",header = false)
A = matrixdepot("hilb", 3, 4)

where "hilb" is really just a name of a matrix data, so string for me is 
more natural. 

Thanks,

Weijian

On Tuesday, 25 November 2014 11:56:32 UTC, Tamas Papp wrote:
>
> Hi, 
>
> This is a great idea. 
>
> Just a cosmetic suggestion: given that Julia has symbols, would it make 
> sense to use them (eg :hilb, :cauchy) instead of strings for selection? 
> Strings are popular in S/R/S-plus for this purpose, but the syntax of 
> Julia is more lispy so symbols may feel more natural (but this is, of 
> course, a matter of taste). 
>
> Best, 
>
> Tamas 
>
> On Tue, Nov 25 2014, Weijian Zhang > 
> wrote: 
>
> > Hello, 
> > 
> > We are designing a test matrix collection for Julia. The idea is to use 
> a 
> > single function to call many different test matrices. It has some 
> > similarity to MATLAB's gallery function but is more powerful. 
> > 
> > The function name is matrixdepot. Every matrix in the collection is 
> > represented by a string, for example, the Cauchy matrix is represented 
> by 
> > "cauchy" and the Hilbert matrix is represented by "hilb". 
> > 
> > The properties of the matrices in the collection are also symbolized by 
> > strings. For example, the class of the symmetric matrices is symbolized 
> by 
> > "symmetric". 
> > 
> >- 
> > 
> >matrixdepot(matrix_name, p1, p2, ...) returns a matrix specified by 
> the 
> >query string matrix_name.  p1, p2, ... are input parameters depending 
> on 
> >matrix_name. 
> >- 
> > 
> >matrixdepot(matrix_name) returns the parameter options and the 
> >properties of matrix_name. 
> >- 
> > 
> >matrixdepot(property_name) returns a list of matrices with the 
> property 
> >property_name. 
> > 
> > 
> > The main features are listed in the file matrixdepot_doc.html. All the 
> code 
> > is provided in the zip file. 
> > 
> > Please let us know if you have any suggestions or any features you think 
> we 
> > should add. 
> > 
> > Thanks, 
> > 
> > Weijian 
>

[julia-users] Re: ternary operator with return() gives (sometimes) errors

[andreas]

Thanks!

The short-circuit evaluations is really neat.