[julia-users] Re: Small packages?

[Jeffrey Sarnoff]

Julia allows you to have submodules; you can collect some of your tiny 
packages into MyUtilityPackages
(sketched, not run)

module MyUtilityPackages

   module StringUtilities
export stringfunction
function stringfunction .. end
end

   module IntegerUtilities
 export integerfunction
 include("integers/MoreIntegerUtilities.jl") # in the subdirectory 
integers, relative to the directory the outer module lives
   end

end # MyUtilityPackages

module MyBigPackage
   using MyUtilityPackages.StringUtilities
   using MyUtilityPackages.IntegerUtilities

   ...
end


On Monday, April 4, 2016 at 11:11:36 PM UTC-4, Eric Forgy wrote:
>
> Hi,
>
> I've been working with Julia for a little while now and notice that I'm 
> starting to develop a number of very small packages that I use and reuse 
> all the time.
>
> I was curious about your opinions on publishing very small "utility" 
> packages? For example, I am consider making a very tiny package the just 
> defines a few types that I will use and reuse in many different/distinct 
> packages and don't want to redefine them each time. However, once I publish 
> the bigger packages, they will have dependencies on these tiny packages, 
> which means I'll need to publish these tiny packages too.
>
> Any thoughts? Is that "ok" or is that bad style?
>
> Best regards,
> Eric
>

[julia-users] Small packages?

[Eric Forgy]

Hi,

I've been working with Julia for a little while now and notice that I'm 
starting to develop a number of very small packages that I use and reuse 
all the time.

I was curious about your opinions on publishing very small "utility" 
packages? For example, I am consider making a very tiny package the just 
defines a few types that I will use and reuse in many different/distinct 
packages and don't want to redefine them each time. However, once I publish 
the bigger packages, they will have dependencies on these tiny packages, 
which means I'll need to publish these tiny packages too.

Any thoughts? Is that "ok" or is that bad style?

Best regards,
Eric

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Scott Jones]

On Monday, April 4, 2016 at 7:27:40 AM UTC-4, Stefan Karpinski wrote:
>
> Number does not imply or assume commutativity. The Quaternions package 
> provides a Quaternion type which is a subtype of Number. Rational, however, 
> only allows integer numerators and denominators. Since integer 
> multiplication is commutative, rational multiplication is too. But I still 
> think it best to reserve \\ with an analogous meaning to //. There are 
> already two syntaxes for integer division, which is plenty.
>

That is your opinion, however a number of other people disagree. Every 
other language I've dealt with has had a simple ASCII sequence for integer 
division, / (in C, C++, Java, Python2 with integer operands), \ (in Mumps & 
Caché Object Script), or // (Python and Lua).
(and no, typing \div in the REPL and something else in an editor [as 
well as having to customize one's editor] just to get a Unicode ÷ 
character, is not really that useful)

About \\ in particular, that's fine then, probably better to reserve that 
for rationals.
To me, it does seem a bit strange though that // was picked for rationals 
in Julia, something sure to cause confusion for people coming from Python 
(which seems to be a large part of people moving to Julia) or Lua, when 
integer division is used so much more frequently than rational numbers.
There are only 6 uses of // outside of rationals.jl in base (4 of those are 
in mpfr.jl), compared to 187 uses of div, and 22 uses of ÷.  (that's uses, 
not definitions, exports, documentation, although the ratios are very 
similar).
Looking at packages, it seems also that div is used frequently, and many 
times more than // for rational numbers.

What about a different two character ASCII sequence that is currently a 
syntax error?
I think /| could be used, and could be easily remembered as being integer 
division (unlike ÷), it could be described as doing a division / and 
cutting off the remainder |.

Re: [julia-users] "Number of packages that depend on this package" at http://pkg.julialang.org/ - which ones?

[Tim Holy]

Pkg.dependents should do it. To get both direct and indirect dependents, you 
can do this:

julia> sold = Set(); s = Pkg.dependents("ParserCombinator")
3-element Array{AbstractString,1}:
 "LightGraphs"
 "QDXML"  
 "LispSyntax" 

julia> sold = Set(); s = Set(Pkg.dependents("ParserCombinator"))
Set(AbstractString["LightGraphs","QDXML","LispSyntax"])

julia> while sold != s
   sold = s
   for p in sold
   s = union(s, Pkg.dependents(p))
   end
   end

julia> s
11-element Array{AbstractString,1}:
 "LightGraphs"   
 "QDXML" 
 "LispSyntax"
 "RobustShortestPath"
 "QuantEcon" 
 "BayesNets" 
 "Metis" 
 "TrafficAssignment" 
 "TikzGraphs"
 "Augur" 
 "DSGE"  

This gives 11 rather than 13, not sure why there's a discrepancy.

Best,
--Tim

On Monday, April 04, 2016 02:04:13 PM Patrick Kofod Mogensen wrote:
> Is it possible to find the packages that depend on a package shown at
> http://pkg.julialang.org/ ?  For example, 13 packages depend
> on ParserCombinator, but which ones?

Re: [julia-users] dispatch slowdown when iterating over array with abstract values

[Yichao Yu]

On Apr 4, 2016 1:36 PM, "Cedric St-Jean"  wrote:
>
> I'm not a compiler dev, but here's how I understand it:
>

Sorry forgot to reply

>
> On Sunday, April 3, 2016 at 6:32:17 PM UTC-4, Greg Plowman wrote:
>>
>> It seems to me that slowness of dynamic dispatch and type instability
are orthogonal.
>>
>> I mean is dynamic dispatch inherently slow, or is it slow because it
involves type instability?
>
>
> Type instability (uncertainty) leads to multiple-dispatch, and multiple
dispatch leads to more type instability (in general, but not always), as
the return type is harder to pin down.
>
>>
>> @code_warntype slow(features) suggests that the return type from
evaluate() is Float64, so I can't see any type instability.
>> If this is correct, then why is dynamic dispatch so much slower than
run-time if statements?
>

I didn't know we are doing this optimization. I think the actual limit for
type inference is how many method actually matches. If you add more subtype
of Feature with different implementation of the function, I think you'll
see type inference give up at some point (the limit used to be 4 iirc)

Currently, whenever type inference cannot determine a single function to
call, it fallback to a full dynamic dispatch at runtime. This is of course
not the best way to do it See
https://github.com/JuliaLang/julia/issues/10805 and
https://github.com/JuliaLang/julia/pull/11862.

>
> Each object contains an ID which is an integer (or a pointer - I don't
know, but it's the same thing).
>
> if isa(x,A)
>
> checks wheter x's ID is equal to A's ID. That's an integer comparison,
and very fast. In contrast, multiple-dispatch involves looking up the
method table for which function to call when x is an Int. I don't know how
it's implemented, but a dictionary look-up is likely, and that's much more
costly.

A "hidden" cost of the dynamic dispatch is that the result needs to be
boxed. Since that's the only way one can return an arbitrary type object in
C. There are thought on how this can be improved but they involve more
complexity and it is not particularly clear if this particular case is
worth optimizing for (i.e. if it will regress more important cases for
example).

>
>>
>>
>> For my own understanding, I was almost hoping that slow() was not
type-stable,
>
>
> slow can be type-stable if the compiler assumes that no other
subtype/method will be added, which it seems to be doing. There's still the
multiple-dispatch cost, since it doesn't know which method to call. To
demonstrate the point about type-stability, if I define
>
> type C <: Feature end
> evaluate(f::C) = 1:3
>
> at the same time as I defined A and B, then slow becomes twice as slow as
before (430 microseconds vs. 210), even though I haven't even instantiated
any C object. That's because the compiler no longer assumes that `evaluate`
returns a Float (check code_warntype) and thus needs a second
multiple-dispatch to make the + call.
>
>>
>> and annotating with evaluate(features[i])::Float64 would let the
compiler produce faster code,
>> but it makes no difference.
>>
>>
>> On Sunday, April 3, 2016 at 11:07:44 PM UTC+10, Cedric St-Jean wrote:
>>>
>>> Good call, it was already pointed out in that thread.
>>>
>>> On Sat, Apr 2, 2016 at 11:11 PM, Yichao Yu  wrote:

 On Sat, Apr 2, 2016 at 10:53 PM, Cedric St-Jean 
wrote:
 > That's actually a compiler bug, nice!
 >
 > abstract Feature
 >
 > type A <: Feature end
 > evaluate(f::A) = 1.0
 >
 > foo(features::Vector{Feature}) = isa(features[1], A) ?
 > evaluate(features[1]::A) : evaluate(features[1])
 >
 > @show foo(Feature[A()])
 >
 > type C <: Feature end
 > evaluate(f::C) = 100
 >
 > @show foo(Feature[C()])
 >
 > yields
 >
 > foo(Feature[A()]) = 1.0
 >
 > foo(Feature[C()]) = 4.94e-322
 >
 >
 > That explains why performance was the same on your computer: the
compiler
 > was making an incorrect assumption about the return type of
`evaluate`. Or
 > maybe it's an intentional gamble by the Julia devs, for the sake of
 > performance.
 >
 > I couldn't find any issue describing this. Yichao?

 This is effectively #265. It's not always predictable what assumption
 the compiler makes now...

 >
 >
 > On Saturday, April 2, 2016 at 10:16:59 PM UTC-4, Greg Plowman wrote:
 >>
 >> Thanks Cedric and Yichao.
 >>
 >> This makes sense that there might be new subtypes and associated
 >> specialised methods. I understand that now. Thanks.
 >>
 >> On my machine (v0.4.5 Windows), fast() and pretty_fast() seem to
run in
 >> similar time.
 >> So I looked as @code_warntype as Yichao suggested and get the
following.
 >> I don't fully know how to interpret output, but return type from
the final
 >> "catchall" evaluate() seems to be inferred/asserted as Float64 (see
 >> 

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Zheng Wendell]

Yes, let's return to the OP. Note that what the author *really wants* is to
get the i-th potion of an array. Either integer division or 0-based alone
can't solve this problem. a[i*100/n : (i+1)*100/n] needs both features.

As Eric puts it, user-written code can be as efficient as the built-in
code. Tomas also provides another walk-around. However, if some body
complains about this simple problem, he may not want to get his hand even
dirtier. He is waiting for the develop team to give him an out-of-box
solution.

I have 2 solutions:
1) float slicing (not indexing)
This enables `a[1:4.5] == a[1:4]`

2) iterable / array view
ita = iter(a, n)
ita[i]
ita.next()



On Mon, Apr 4, 2016 at 7:27 PM, Tomas Lycken wrote:

> It’s also entirely possible to create a macro that lets / do what you
> (the OP) want.
>
> @integer_division begin
>
> # in here, 5 / 2 == 2
>
> end
>
> Basically, you’d just traverse the AST recursively and switch all calls to
> / for calls to div. (I admit, though I wouldn’t want to do it myself, nor
> would I want to maintain code that uses it, but at least the latter is
> probably just a matter of taste…)
>
> The fact that this is even possible in Julia, is in my eyes a perfect
> counter-argument to most of the pain points in the original post. I know of
> no other language which is so painless to use when conforming to the
> (usually very good) design decisions that have already been made, while
> simultaneously giving the user the power to override almost anything if
> desired.
>
> Similarly, it has already been brought-up that it’s quite possible to
> create 0-indexed arrays (and making that even easier is even a current
> hot-topic).
>
> As others have already brought up, there are lots of people who feel quite
> opposite about both integer division and 0- or 1-based indexing. Satisfying
> everyone isn’t going to be possible, but Julia comes damn close.
>
> // T
>
> On Monday, April 4, 2016 at 12:55:57 PM UTC+2, Tim Holy wrote:
>
> On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote:
>> > With \\, would you worry about confusion from the fact that in a \\ b,
>> a is
>> >
>> > > in
>> > > the denominator? Especially if it gets called the "integer division
>> > > operator."
>> >
>> > It might confuse some of the mathematicians, used to a \ b as a inverse
>> > multiplication operator, however, other languages use a \ b for what in
>> > Julia is div(a, b) or a÷b,
>> > so I really don't think a definition of \\ as div(a, b) would be that
>> much
>> > of a problem, no worse than other things you have to remember in Julia,
>> > and it's reminiscent of the // integer division operator in Python and
>> Lua.
>>
>> Thinking about it a second time, there's another reason I'd recommend
>> against
>> this choice: if you're working with non-commutative numbers, for
>> consistency
>> \\ too should be reserved for forming Rationals rather than meaning
>> something
>> completely different. In other words, b//a means RightRational(b, a)
>> (b*inv(a))
>> and a\\b means LeftRational(a, b) (inv(a)*b). I suspect our current
>> Rational
>> framework implicitly assumes commutativity, but that's a separate issue
>> and
>> one that, with a suitable number-traits system, is cleanly resolvable.
>>
>> I'm not trying to argue that making rationals with non-commutative
>> numbers is
>> a daily task, but to me consistency in the meaning of notation seems like
>> the
>> most important guiding principle. Code gets read many more times than it
>> is
>> written, so I don't mind a few extra keystrokes if it makes reading code
>> clearer.
>>
>> But once again, it seems there just aren't enough characters on the
>> keyboard.
>>
>> Best,
>> --Tim
>>
>> ​
>

[julia-users] iterating over a vector of inhomogeneous elements

[Davide Lasagna]

Hi all, 

Look at the following code:

using Benchmarks

const Nf = 1_000_000

immutable PolygonalFace{T, N}
points::NTuple{N, UInt32}
area::T
end

@inline area(p::PolygonalFace) = p.area

function make_abstract_faces(Nf)
faces = PolygonalFace{Float64}[]
for i = 1:Nf
N = rand(3:5) # triangular, quadrilateral or pentagonal faces
f = PolygonalFace{Float64, N}(tuple(rand(1:1000, N)...), rand())
push!(faces, f)
end
faces
end

function make_concrete_faces(Nf, N)
faces = PolygonalFace{Float64, N}[]
for i = 1:Nf
f = PolygonalFace{Float64, N}(tuple(rand(1:1000, N)...), rand())
push!(faces, f)
end
faces
end

# homogeneous elements in both parameters
function sum_areas{T, N}(faces::Vector{PolygonalFace{T, N}})
tot = zero(T)
for face in faces
tot += area(face)
end
tot
end

# homogeneous elements in the first parameter only
function sum_areas{T}(faces::Vector{PolygonalFace{T}})
tot = zero(T)
for face in faces
# use trick discussed 
in https://groups.google.com/forum/#!topic/julia-users/OBs0fmNmjCU
if isa(face, PolygonalFace{T, 3})
tot += area(face::PolygonalFace{T, 3})
elseif isa(face, PolygonalFace{T, 4})
tot += area(face::PolygonalFace{T, 4})
elseif isa(face, PolygonalFace{T, 5})
tot += area(face::PolygonalFace{T, 5})
end
end
tot
end

# create random faces
const ab_faces = make_abstract_faces(Nf)
const co_faces = make_concrete_faces(Nf, 3) # triangles

# benchmark
println(@benchmark sum_areas(ab_faces))
println(@benchmark sum_areas(co_faces))

@time sum_areas(ab_faces)
@time sum_areas(ab_faces)
@time sum_areas(ab_faces)
@time sum_areas(co_faces)
@time sum_areas(co_faces)
@time sum_areas(co_faces)

which results in 

 Benchmark Results 
 Time per evaluation: 10.91 ms [10.44 ms, 11.38 ms]
Proportion of time in GC: 0.00% [0.00%, 0.00%]
Memory allocated: 0.00 bytes
   Number of allocations: 0 allocations
   Number of samples: 100
   Number of evaluations: 100
 Time spent benchmarking: 1.29 s

 Benchmark Results 
 Time per evaluation: 1.09 ms [1.03 ms, 1.14 ms]
Proportion of time in GC: 0.00% [0.00%, 0.00%]
Memory allocated: 0.00 bytes
   Number of allocations: 0 allocations
   Number of samples: 100
   Number of evaluations: 100
 Time spent benchmarking: 0.26 s

  0.012995 seconds (61 allocations: 3.672 KB)
  0.014940 seconds (5 allocations: 176 bytes)
  0.012015 seconds (5 allocations: 176 bytes)
  0.002574 seconds (5 allocations: 176 bytes)
  0.001170 seconds (5 allocations: 176 bytes)
  0.001200 seconds (5 allocations: 176 bytes)

i.e, when the elements of the input vector `x` are homogeneous in the first 
parameter only, the code is about 10 times slower. Are those if branches 
and type asserts so expensive?

Thanks,

Davide 

Re: [julia-users] Re: regression from 0.43 to 0.5dev, and back to 0.43 on fedora23

[Milan Bouchet-Valat]

Le lundi 04 avril 2016 à 10:36 -0700, Johannes Wagner a écrit :
> hey guys,
> so attached you find text files with @code_native output for the
> instructions 
> - r * x[1,:]
> - cis(imexp)
> - sum(imexp) * sum(conj(imexp))
> 
> for julia 0.5. 
> 
> Hardware I run on is a Haswell i5 machine, a Haswell i7 machine, and
> a IvyBridge i5 machine. Turned out on an Haswell i5 machine the code
> also runs fast. Only the Haswell i7 machine is the slow one. This
> really drove me nuts. First I thought it was the OS, then the
> architecture, and now its just from i5 to i7 Anyways, I don't
> know anything about x86 assembly, but the julia 0.45 code is the same
> on all machines. However, for the dot product, the 0.5 code has
> already 2 different instructions on the i5 vs. the i7 (line 44&47).
> For the cis call also (line 149...). And the IvyBridge i5 code is
> similar to the Haswell i5. I included also versioninfo() at the top
> of the file. So you could just look at a vimdiff of the julia0.5
> files... Can anyone make sense out of this?
I'm definitely not an expert in assembly, but that additional leaq
instruction on line 44, and the additional movq instructions on line
111, 151 and 152 really look weird

Could you do the same test with the binary tarballs? If the difference
persists, you should open an issue on GitHub to track this.

BTW, please wrap the fist call in a function to ensure it is
specialized for the arguments types, i.e.:

f(r, x) = r * x[1,:]
@code_native f(r, x)

Also, please check whether you still see the difference with this code:
g(r, x) = r * x
@code_native g(r, x[1,:])

What are the types of r and x? Could you provide a simple reproducible example 
with dummy values?

> The binary tarballs I will still test. If I remove the cis() call,
> the difference is hard to tell, the loop is ~10times faster and more
> or less all around 5ms. For the whole loop with cis() call, from i5
> to i7 the difference is ~ 50ms on i5 to 90ms on i7.
> 
> Shall I also post the julia 0.4 code?
If it's identical for all machines, I don't think it's needed.


Regards


> cheers, Johannes
> 
> 
> 
> > Le mercredi 30 mars 2016 à 15:16 -0700, Johannes Wagner a écrit : 
> > > 
> > > 
> > > > Le mercredi 30 mars 2016 à 04:43 -0700, Johannes Wagner a écrit :  
> > > > > Sorry for not having expressed myself clearly, I meant the latest  
> > > > > version of fedora to work fine (24 development). I always used the  
> > > > > latest julia nightly available on the copr nalimilan repo. Right now  
> > > > > that is: 0.5.0-dev+3292, Commit 9d527c5*, all use  
> > > > > LLVM: libLLVM-3.7.1 (ORCJIT, haswell)  
> > > > >  
> > > > > peakflops on all machines (hardware identical) is ~1.2..1.5e11.    
> > > > >  
> > > > > Fedora 22&23 with julia 0.5 is ~50% slower then 0.4, only on fedora  
> > > > > 24 julia 0.5 is  faster compared to julia 0.4.  
> > > > Could you try to find a simple code to reproduce the problem? In  
> > > > particular, it would be useful to check whether this comes from  
> > > > OpenBLAS differences or whether it also happens with pure Julia code  
> > > > (typical operations which depend on BLAS are matrix multiplication, as  
> > > > well as most of linear algebra). Normally, 0.4 and 0.5 should use the  
> > > > same BLAS, but who knows...  
> > > well thats what I did, and the 3 simple calls inside the loop are 
> > > more or less same speed. only the whole loop seems slower. See my 
> > > code sample fromanswer march 8th (code gets in same proportions 
> > > faster when exp(im .* dotprods) is replaced by cis(dotprods) ).  
> > > So I don't know what I can do then...   
> > Sorry, somehow I had missed that message. This indeed looks like a code 
> > generation issue in Julia/LLVM. 
> > 
> > > > Can you also confirm that all versioninfo() fields are the same for all 
> > > >  
> > > > three machines, both for 0.4 and 0.5? We must envision the possibility  
> > > > that the differences actually come from 0.4.  
> > > ohoh, right! just noticed that my fedora 24 machine was an ivy bridge 
> > > which works fast: 
> > > 
> > > Julia Version 0.5.0-dev+3292 
> > > Commit 9d527c5* (2016-03-28 06:55 UTC) 
> > > Platform Info: 
> > >   System: Linux (x86_64-redhat-linux) 
> > >   CPU: Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz 
> > >   WORD_SIZE: 64 
> > >   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Sandybridge) 
> > >   LAPACK: libopenblasp.so.0 
> > >   LIBM: libopenlibm 
> > >   LLVM: libLLVM-3.7.1 (ORCJIT, ivybridge) 
> > > 
> > > and the other ones with fed22/23 are haswell, which work slow: 
> > > 
> > > Julia Version 0.5.0-dev+3292 
> > > Commit 9d527c5* (2016-03-28 06:55 UTC) 
> > > Platform Info: 
> > >   System: Linux (x86_64-redhat-linux) 
> > >   CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 
> > >   WORD_SIZE: 64 
> > >   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell) 
> > >   LAPACK: libopenblasp.so.0 
> > >   LIBM: libopenlibm 
> > >   LLVM: libLLVM-3.7.1 (ORCJIT, haswell) 
> > > 
> > > I just 

[julia-users] Re: enforcing homogeneity of vector elements in function signature

[Davide Lasagna]

Thanks, yes, I have tried this, but did not mention what happens.

For the signature you suggest, you get a `MethodError` in the case the 
vector `x` is homogeneous in both parameters.

Look at this code

type Foo{T, N}
a::NTuple{N, T}
end

function make_homogeneous_Foos(M)
fs = Foo{Float64, 2}[]
for i = 1:M
f = Foo{Float64, 2}((0.0, 0.0))
push!(fs, f)
end
fs
end

function bar{T}(x::Vector{Foo{T}})
println("Hello, Foo!")
end

const fs = make_homogeneous_Foos(100)

bar(fs)

which results in 

ERROR: LoadError: MethodError: `bar` has no method matching 
bar(::Array{Foo{Float64,2},1})

A workaround would be to have two methods, one for the homogeneous elements 
in the first parameter, as you suggest, and a second for a vector with 
homogeneous elements in both parameters, with both T, N specified in the 
signature. But I have to write an extra method...


On Monday, April 4, 2016 at 9:32:55 PM UTC+1, John Myles White wrote:
>
> Vector{Foo{T}}?
>
> On Monday, April 4, 2016 at 1:25:46 PM UTC-7, Davide Lasagna wrote:
>>
>> Hi all, 
>>
>> Consider the following example code
>>
>> type Foo{T, N}
>> a::NTuple{N, T}
>> end
>>
>> function make_Foos(M)
>> fs = Foo{Float64}[]
>> for i = 1:M
>> N = rand(1:2)
>> f = Foo{Float64, N}(ntuple(i->0.0, N))
>> push!(fs, f)
>> end
>> fs
>> end
>>
>> function bar{F<:Foo}(x::Vector{F})
>> println("Hello, Foo!")
>> end
>>
>> const fs = make_Foos(100)
>>
>> bar(fs)
>>
>> What would be the signature of `bar` to enforce that all the entries of 
>> `x` have the same value for the first parameter T? As it is now, `x` could 
>> contain an `Foo{Float64}` and a `Foo{Int64}`, whereas I would like to 
>> enforce homogeneity of the vector elements in the first parameter.
>>
>> Thanks
>>
>>
>>

[julia-users] Re: enforcing homogeneity of vector elements in function signature

[John Myles White]

Vector{Foo{T}}?

On Monday, April 4, 2016 at 1:25:46 PM UTC-7, Davide Lasagna wrote:
>
> Hi all, 
>
> Consider the following example code
>
> type Foo{T, N}
> a::NTuple{N, T}
> end
>
> function make_Foos(M)
> fs = Foo{Float64}[]
> for i = 1:M
> N = rand(1:2)
> f = Foo{Float64, N}(ntuple(i->0.0, N))
> push!(fs, f)
> end
> fs
> end
>
> function bar{F<:Foo}(x::Vector{F})
> println("Hello, Foo!")
> end
>
> const fs = make_Foos(100)
>
> bar(fs)
>
> What would be the signature of `bar` to enforce that all the entries of 
> `x` have the same value for the first parameter T? As it is now, `x` could 
> contain an `Foo{Float64}` and a `Foo{Int64}`, whereas I would like to 
> enforce homogeneity of the vector elements in the first parameter.
>
> Thanks
>
>
>

Re: [julia-users] I need some advise about File IO in Julia

[Diego Javier Zea]

Hi! 

Finally, I have a PDB and PDBML (xml) parser in the *PDB module* of *MIToS 
 *(the *documentation* is in 
*http://mitos.leloir.org.ar* ). 

Best,

El lunes, 14 de marzo de 2016, 15:49:44 (UTC-3), Joe Greener escribió:
>
> Just bumping this to note that functionality for PDB parsing is now 
> included in BioJulia:
> https://github.com/BioJulia/Bio.jl
>
> With some docs here:
> https://github.com/BioJulia/Bio.jl/blob/master/doc/structure.ipynb
>
> I am interested to hear feedback on the module and ideas for future 
> development. Thanks!
>
>
> On Thursday, 21 May 2015 20:50:50 UTC+1, jonny brooks wrote:
>>
>> Thanks very much. The PdbTool does almost what I need it to but it needs 
>> an extra bit parsed for the unit cell parameters and the symmetry 
>> operators. I may add some more to the package when I get round to working 
>> on it.
>>
>> I've had a brief look at your library. It looks awesome. I look forward 
>> to when you wrap it to Julia. Looks like something that would be useful to 
>> me. Keep up the good work :)
>>
>> On 21 May 2015 at 17:47, Luthaf  wrote:
>>
>>> I have found this, which is not an official package : 
>>> https://github.com/christophfeinauer/PdbTool.jl
>>>
>>> Also, I am currently writing a cross-language chemistry files reader 
>>> library (https://github.com/Luthaf/Chemharp/), and I should wrap it to 
>>> Julia soon (this means 2-3 months maximum). It will support PDB file 
>>> through the VMD molfile plugins, but it will not be native Julia.
>>>
>>> Regards,
>>> Guillaume
>>>
>>> jonny brooks a écrit:
>>>
>>>
>>> Hey Diego,
>>>
>>> Did anything ever come of this? I would like to parse a pdb file with 
>>> julia but there are a real lack of crystallographic/structural biology 
>>> libraries for julia.
>>>
>>> Have you written something to read pdb files in native julia?
>>>
>>>
>>

[julia-users] enforcing homogeneity of vector elements in function signature

[Davide Lasagna]

Hi all, 

Consider the following example code

type Foo{T, N}
a::NTuple{N, T}
end

function make_Foos(M)
fs = Foo{Float64}[]
for i = 1:M
N = rand(1:2)
f = Foo{Float64, N}(ntuple(i->0.0, N))
push!(fs, f)
end
fs
end

function bar{F<:Foo}(x::Vector{F})
println("Hello, Foo!")
end

const fs = make_Foos(100)

bar(fs)

What would be the signature of `bar` to enforce that all the entries of `x` 
have the same value for the first parameter T? As it is now, `x` could 
contain an `Foo{Float64}` and a `Foo{Int64}`, whereas I would like to 
enforce homogeneity of the vector elements in the first parameter.

Thanks

[julia-users] ANN: MIToS v1.0 Released

[Diego Javier Zea]

Hi All,

We've released the 1.0 version of *MIToS 
*! Changes are documented in the 
NEWS.md  file. 

This version includes a new module: *Pfam*. It integrates Information, MSA, 
PDB and SIFTS modules for working with Pfam alignments.

The *documentation* is in *http://mitos.leloir.org.ar* 


MIToS is an environment for *Mutual Information (MI)* analysis and 
implements several useful tools for *Multiple Sequence Alignments (MSAs)* 
and *protein structures (PDB)* management in the Julia language.

Best,

Re: [julia-users] Doing linear algebra on nested subarrays ... quickly

[Kristoffer Carlsson]

Allocating 2^1, 2^2, ..., 2^N is still only allocating 2^(N+1).

Depending on how large N you have, it might very well be worth copying.

Re: [julia-users] Doing linear algebra on nested subarrays ... quickly

[Tim Holy]

It does if isa(A, StridedVecOrMat), they have unit stride along the first 
dimension, and the element type is supported by BLAS (Float32, Float64, 
Complex64, Complex128). These are all simply restrictions of BLAS, not 
limitations of julia.

When those don't hold, there are at least cache-optimized implementations of a 
few algorithms, like matrix-matrix multiplication, already in Base. Not as 
fast as BLAS, but not terrible either.

How are you creating your subarrays?

Best,
--Tim

On Monday, April 04, 2016 11:19:34 AM Gregor Robinson wrote:
> Yep. But, as far as I can tell, BLAS doesn't play with SubMatrix.
> 
> On Monday, April 4, 2016 at 6:11:52 AM UTC-6, Tim Holy wrote:
> > Have you tried `sub`?
> > 
> > --Tim

Re: [julia-users] Doing linear algebra on nested subarrays ... quickly

[Gregor Robinson]

Yep. But, as far as I can tell, BLAS doesn't play with SubMatrix.


On Monday, April 4, 2016 at 6:11:52 AM UTC-6, Tim Holy wrote:
>
> Have you tried `sub`? 
>
> --Tim 
>

Re: [julia-users] Re: regression from 0.43 to 0.5dev, and back to 0.43 on fedora23

[Johannes Wagner]

hey guys,
so attached you find text files with @code_native output for the 
instructions 
- r * x[1,:]
- cis(imexp)
- sum(imexp) * sum(conj(imexp))

for julia 0.5. 

Hardware I run on is a Haswell i5 machine, a Haswell i7 machine, and a 
IvyBridge i5 machine. Turned out on an Haswell i5 machine the code also 
runs fast. Only the Haswell i7 machine is the slow one. This really drove 
me nuts. First I thought it was the OS, then the architecture, and now its 
just from i5 to i7 Anyways, I don't know anything about x86 assembly, 
but the julia 0.45 code is the same on all machines. However, for the dot 
product, the 0.5 code has already 2 different instructions on the i5 vs. 
the i7 (line 44&47). For the cis call also (line 149...). And the IvyBridge 
i5 code is similar to the Haswell i5. I included also versioninfo() at the 
top of the file. So you could just look at a vimdiff of the julia0.5 
files... Can anyone make sense out of this?

The binary tarballs I will still test. If I remove the cis() call, the 
difference is hard to tell, the loop is ~10times faster and more or less 
all around 5ms. For the whole loop with cis() call, from i5 to i7 the 
difference is ~ 50ms on i5 to 90ms on i7.

Shall I also post the julia 0.4 code?

cheers, Johannes



On Thursday, March 31, 2016 at 10:27:11 AM UTC+2, Milan Bouchet-Valat wrote:
>
> Le mercredi 30 mars 2016 à 15:16 -0700, Johannes Wagner a écrit : 
> > 
> > 
> > > Le mercredi 30 mars 2016 à 04:43 -0700, Johannes Wagner a écrit :  
> > > > Sorry for not having expressed myself clearly, I meant the latest  
> > > > version of fedora to work fine (24 development). I always used the  
> > > > latest julia nightly available on the copr nalimilan repo. Right 
> now  
> > > > that is: 0.5.0-dev+3292, Commit 9d527c5*, all use  
> > > > LLVM: libLLVM-3.7.1 (ORCJIT, haswell)  
> > > >  
> > > > peakflops on all machines (hardware identical) is ~1.2..1.5e11.
> > > >  
> > > > Fedora 22&23 with julia 0.5 is ~50% slower then 0.4, only on fedora  
> > > > 24 julia 0.5 is  faster compared to julia 0.4.  
> > > Could you try to find a simple code to reproduce the problem? In  
> > > particular, it would be useful to check whether this comes from  
> > > OpenBLAS differences or whether it also happens with pure Julia code  
> > > (typical operations which depend on BLAS are matrix multiplication, 
> as  
> > > well as most of linear algebra). Normally, 0.4 and 0.5 should use the  
> > > same BLAS, but who knows...  
> > well thats what I did, and the 3 simple calls inside the loop are 
> > more or less same speed. only the whole loop seems slower. See my 
> > code sample fromanswer march 8th (code gets in same proportions 
> > faster when exp(im .* dotprods) is replaced by cis(dotprods) ).  
> > So I don't know what I can do then...   
> Sorry, somehow I had missed that message. This indeed looks like a code 
> generation issue in Julia/LLVM. 
>
> > > Can you also confirm that all versioninfo() fields are the same for 
> all  
> > > three machines, both for 0.4 and 0.5? We must envision the 
> possibility  
> > > that the differences actually come from 0.4.  
> > ohoh, right! just noticed that my fedora 24 machine was an ivy bridge 
> > which works fast: 
> > 
> > Julia Version 0.5.0-dev+3292 
> > Commit 9d527c5* (2016-03-28 06:55 UTC) 
> > Platform Info: 
> >   System: Linux (x86_64-redhat-linux) 
> >   CPU: Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz 
> >   WORD_SIZE: 64 
> >   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Sandybridge) 
> >   LAPACK: libopenblasp.so.0 
> >   LIBM: libopenlibm 
> >   LLVM: libLLVM-3.7.1 (ORCJIT, ivybridge) 
> > 
> > and the other ones with fed22/23 are haswell, which work slow: 
> > 
> > Julia Version 0.5.0-dev+3292 
> > Commit 9d527c5* (2016-03-28 06:55 UTC) 
> > Platform Info: 
> >   System: Linux (x86_64-redhat-linux) 
> >   CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 
> >   WORD_SIZE: 64 
> >   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell) 
> >   LAPACK: libopenblasp.so.0 
> >   LIBM: libopenlibm 
> >   LLVM: libLLVM-3.7.1 (ORCJIT, haswell) 
> > 
> > I just booted an fedora 23 on the ivy bridge machine and it's also 
> fast.  
> >   
> > Now if I use julia 0.45 on both architectures: 
> > 
> > Julia Version 0.4.5 
> > Commit 2ac304d* (2016-03-18 00:58 UTC) 
> > Platform Info: 
> >   System: Linux (x86_64-redhat-linux) 
> >   CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 
> >   WORD_SIZE: 64 
> >   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell) 
> >   LAPACK: libopenblasp.so.0 
> >   LIBM: libopenlibm 
> >   LLVM: libLLVM-3.3 
> > 
> > and: 
> > 
> > Julia Version 0.4.5 
> > Commit 2ac304d* (2016-03-18 00:58 UTC) 
> > Platform Info: 
> >   System: Linux (x86_64-redhat-linux) 
> >   CPU: Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz 
> >   WORD_SIZE: 64 
> >   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Sandybridge) 
> >   LAPACK: libopenblasp.so.0 
> >   LIBM: libopenlibm 
> >   LLVM: libLLVM-3.3 
> > 
> > there is no speed 

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Tomas Lycken]

It’s also entirely possible to create a macro that lets / do what you (the 
OP) want.

@integer_division begin

# in here, 5 / 2 == 2

end

Basically, you’d just traverse the AST recursively and switch all calls to / 
for calls to div. (I admit, though I wouldn’t want to do it myself, nor 
would I want to maintain code that uses it, but at least the latter is 
probably just a matter of taste…)

The fact that this is even possible in Julia, is in my eyes a perfect 
counter-argument to most of the pain points in the original post. I know of 
no other language which is so painless to use when conforming to the 
(usually very good) design decisions that have already been made, while 
simultaneously giving the user the power to override almost anything if 
desired.

Similarly, it has already been brought-up that it’s quite possible to 
create 0-indexed arrays (and making that even easier is even a current 
hot-topic).

As others have already brought up, there are lots of people who feel quite 
opposite about both integer division and 0- or 1-based indexing. Satisfying 
everyone isn’t going to be possible, but Julia comes damn close.

// T

On Monday, April 4, 2016 at 12:55:57 PM UTC+2, Tim Holy wrote:

On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote: 
> > With \\, would you worry about confusion from the fact that in a \\ b, a 
> is 
> > 
> > > in 
> > > the denominator? Especially if it gets called the "integer division 
> > > operator." 
> > 
> > It might confuse some of the mathematicians, used to a \ b as a inverse 
> > multiplication operator, however, other languages use a \ b for what in 
> > Julia is div(a, b) or a÷b, 
> > so I really don't think a definition of \\ as div(a, b) would be that 
> much 
> > of a problem, no worse than other things you have to remember in Julia, 
> > and it's reminiscent of the // integer division operator in Python and 
> Lua. 
>
> Thinking about it a second time, there's another reason I'd recommend 
> against 
> this choice: if you're working with non-commutative numbers, for 
> consistency 
> \\ too should be reserved for forming Rationals rather than meaning 
> something 
> completely different. In other words, b//a means RightRational(b, a) 
> (b*inv(a)) 
> and a\\b means LeftRational(a, b) (inv(a)*b). I suspect our current 
> Rational 
> framework implicitly assumes commutativity, but that's a separate issue 
> and 
> one that, with a suitable number-traits system, is cleanly resolvable. 
>
> I'm not trying to argue that making rationals with non-commutative numbers 
> is 
> a daily task, but to me consistency in the meaning of notation seems like 
> the 
> most important guiding principle. Code gets read many more times than it 
> is 
> written, so I don't mind a few extra keystrokes if it makes reading code 
> clearer. 
>
> But once again, it seems there just aren't enough characters on the 
> keyboard. 
>
> Best, 
> --Tim 
>
> ​

Re: [julia-users] MethodError: '+' has no method matching +(::DateTime, ::Int64)

[Jacob Quinn]

Sorry, I should have been more clear.

I was trying to express that perhaps we should document these
previously-internal methods so that they are actually a part of the
official interface/exported. They're not unsafe or anything and people may
actually have a use for these, so maybe we should just document to
everythings more clear.


On Mon, Apr 4, 2016 at 10:49 AM, Milan Bouchet-Valat 
wrote:

> Le lundi 04 avril 2016 à 10:27 -0600, Jacob Quinn a écrit :
> > Hmmm.yeah, it's not ideal, I guess. Dates.day(::Integer) is
> > indeed an internal method that takes the # of Rata Die days (i.e. the
> > value of Int(Date(2015,1,1))) and returns the day of the month for
> > that Rata Die. It might be worth documenting so that it's more clear
> > what's going on when people search/help it.
> If these methods are internal, they shouldn't be added to exported
> functions. A useful convention is to prefix these with an underscore.
>
>
> Regards
>
>
> > -Jacob
> >
> > On Mon, Apr 4, 2016 at 10:02 AM, Josh Langsfeld 
> > wrote:
> > > Shouldn’t Dates.day(1) be the MethodError here? It calls what
> > > appears to be an internal calculation method that happens to have
> > > the same name as the exported and documented method.
> > >
> > > On Monday, April 4, 2016 at 11:21:47 AM UTC-4, Jacob Quinn wrote:
> > >
> > > > Dates.day is the accessor funciton, returning the day of month
> > > > for a Date/DateTime.
> > > >
> > > > Dates.Day is the Period type representing the span of one day.
> > > >
> > > > So you'll want something like:
> > > >
> > > > now() + Dates.Day(1)
> > > >
> > > > -Jacob
> > > >
> > > >
> > > > On Mon, Apr 4, 2016 at 5:48 AM, Josh  wrote:
> > > > > When trying to increment and decrement dates I get the method
> > > > > error stated above.
> > > > >
> > > > > For example with: now() + Dates.day(1)
> > > > >
> > > > > I get the error:
> > > > >
> > > > > ERROR: MethodError: `+` has no method matching +(::DateTime,
> > > > > ::Int64)
> > > > > Closest candidates are:
> > > > >   +(::Any, ::Any, ::Any, ::Any...)
> > > > >   +(::Int64, ::Int64)
> > > > >   +(::Complex{Bool}, ::Real)
> > > > >   ...
> > > > >
> > > > > But with doing something like this: Date(2015,12,25) - today()
> > > > >
> > > > > I get the correct result with no error.
> > > > >
> > > > > Any ideas?
> > > > > Thanks
> > > > >
> > > > >
> > > >
>

Re: [julia-users] MethodError: '+' has no method matching +(::DateTime, ::Int64)

[Milan Bouchet-Valat]

Le lundi 04 avril 2016 à 10:27 -0600, Jacob Quinn a écrit :
> Hmmm.yeah, it's not ideal, I guess. Dates.day(::Integer) is
> indeed an internal method that takes the # of Rata Die days (i.e. the
> value of Int(Date(2015,1,1))) and returns the day of the month for
> that Rata Die. It might be worth documenting so that it's more clear
> what's going on when people search/help it.
If these methods are internal, they shouldn't be added to exported
functions. A useful convention is to prefix these with an underscore.


Regards


> -Jacob
> 
> On Mon, Apr 4, 2016 at 10:02 AM, Josh Langsfeld 
> wrote:
> > Shouldn’t Dates.day(1) be the MethodError here? It calls what
> > appears to be an internal calculation method that happens to have
> > the same name as the exported and documented method.
> > 
> > On Monday, April 4, 2016 at 11:21:47 AM UTC-4, Jacob Quinn wrote:
> > 
> > > Dates.day is the accessor funciton, returning the day of month
> > > for a Date/DateTime.
> > > 
> > > Dates.Day is the Period type representing the span of one day.
> > > 
> > > So you'll want something like:
> > > 
> > > now() + Dates.Day(1)
> > > 
> > > -Jacob
> > > 
> > > 
> > > On Mon, Apr 4, 2016 at 5:48 AM, Josh  wrote:
> > > > When trying to increment and decrement dates I get the method
> > > > error stated above. 
> > > > 
> > > > For example with: now() + Dates.day(1)
> > > > 
> > > > I get the error:
> > > > 
> > > > ERROR: MethodError: `+` has no method matching +(::DateTime,
> > > > ::Int64)
> > > > Closest candidates are:
> > > >   +(::Any, ::Any, ::Any, ::Any...)
> > > >   +(::Int64, ::Int64)
> > > >   +(::Complex{Bool}, ::Real)
> > > >   ...
> > > > 
> > > > But with doing something like this: Date(2015,12,25) - today() 
> > > > 
> > > > I get the correct result with no error.
> > > > 
> > > > Any ideas?
> > > > Thanks
> > > > 
> > > > 
> > > 

Re: [julia-users] MethodError: '+' has no method matching +(::DateTime, ::Int64)

[Jacob Quinn]

Hmmm.yeah, it's not ideal, I guess. Dates.day(::Integer) is indeed an
internal method that takes the # of Rata Die days (i.e. the value of
Int(Date(2015,1,1))) and returns the day of the month for that Rata Die. It
might be worth documenting so that it's more clear what's going on when
people search/help it.

-Jacob

On Mon, Apr 4, 2016 at 10:02 AM, Josh Langsfeld  wrote:

> Shouldn’t Dates.day(1) be the MethodError here? It calls what appears to
> be an internal calculation method that happens to have the same name as the
> exported and documented method.
>
> On Monday, April 4, 2016 at 11:21:47 AM UTC-4, Jacob Quinn wrote:
>
> Dates.day is the accessor funciton, returning the day of month for a
>> Date/DateTime.
>>
>> Dates.Day is the Period type representing the span of one day.
>>
>> So you'll want something like:
>>
>> now() + Dates.Day(1)
>>
>> -Jacob
>>
>>
>> On Mon, Apr 4, 2016 at 5:48 AM, Josh  wrote:
>>
>>> When trying to increment and decrement dates I get the method error
>>> stated above.
>>>
>>> For example with: now() + Dates.day(1)
>>>
>>> I get the error:
>>>
>>> *ERROR: MethodError: `+` has no method matching +(::DateTime, ::Int64)*
>>>
>>> Closest candidates are:
>>>
>>>   +(::Any, ::Any, *::Any*, *::Any...*)
>>>
>>>   +(*::Int64*, ::Int64)
>>>
>>>   +(*::Complex{Bool}*, ::Real)
>>>
>>>   ...
>>>
>>> But with doing something like this: Date(2015,12,25) - today()
>>>
>>> I get the correct result with no error.
>>>
>>> Any ideas?
>>> Thanks
>>>
>>>
>> ​
>

Re: [julia-users] julia-emacs ...

[Stefan Karpinski]

No worries. The repo is very new and could probably stand to have some more
instructions.

On Mon, Apr 4, 2016 at 10:08 AM, Andrea Pagnani 
wrote:

> Ok ... so just a
>
> git clone https://github.com/JuliaLang/julia-emacs
>
> makes the job + changing the path of where the julia-mode.el is in the
> .emacs file.
>
> Thanks, and sorry for the noise.
>
> A
> On Monday, April 4, 2016 at 11:21:41 AM UTC+2, Stefan Karpinski wrote:
>>
>> The julia-emacs repo is not a Julia package – the julia package manager
>> doesn't install emacs modes. The julia-emacs repo has some brief
>> instruction on how to install the mode:
>> https://github.com/JuliaLang/julia-emacs#install.
>>
>> On Mon, Apr 4, 2016 at 5:02 AM, Andrea Pagnani 
>> wrote:
>>
>>> Dear all,
>>>
>>> I discovered that emacs support that after #15694
>>>  has its own
>>> repository.
>>>
>>> After a Pkg.update()  in 0.5 I tried:
>>>
>>> Pkg.add("julia-emacs") #no success
>>> Pkg.clone("https://github.com/JuliaLang/julia-emacs;) #no success
>>> Pkg.clone("https://github.com/JuliaLang/julia-emacs.git;) #no success
>>> either
>>>
>>> Anybody knows what am I doing wrong?
>>>
>>> Thanks
>>>
>>>
>>

Re: [julia-users] MethodError: '+' has no method matching +(::DateTime, ::Int64)

[Josh Langsfeld]

Shouldn’t Dates.day(1) be the MethodError here? It calls what appears to be 
an internal calculation method that happens to have the same name as the 
exported and documented method.

On Monday, April 4, 2016 at 11:21:47 AM UTC-4, Jacob Quinn wrote:

Dates.day is the accessor funciton, returning the day of month for a 
> Date/DateTime.
>
> Dates.Day is the Period type representing the span of one day.
>
> So you'll want something like:
>
> now() + Dates.Day(1)
>
> -Jacob
>
>
> On Mon, Apr 4, 2016 at 5:48 AM, Josh  
> wrote:
>
>> When trying to increment and decrement dates I get the method error 
>> stated above. 
>>
>> For example with: now() + Dates.day(1)
>>
>> I get the error:
>>
>> *ERROR: MethodError: `+` has no method matching +(::DateTime, ::Int64)*
>>
>> Closest candidates are:
>>
>>   +(::Any, ::Any, *::Any*, *::Any...*)
>>
>>   +(*::Int64*, ::Int64)
>>
>>   +(*::Complex{Bool}*, ::Real)
>>
>>   ...
>>
>> But with doing something like this: Date(2015,12,25) - today() 
>>
>> I get the correct result with no error.
>>
>> Any ideas?
>> Thanks
>>
>>
> ​

[julia-users] Re: dispatch slowdown when iterating over array with abstract values

[Tim Wheeler]

Thank you for everyone's comments.
To summarize, the slow version needs to perform memory allocation to 
protect itself against potential type instability should future types and 
associated evaluate function be defined, whereas the 'fast' version is 
protected from this and the compiler can optimize it.

Also, I learned about code_warntype and code_llvm.

On Friday, April 1, 2016 at 6:56:52 PM UTC-7, Tim Wheeler wrote:
>
> Hello Julia Users.
>
> I ran into a weird slowdown issue and reproduced a minimal working 
> example. Maybe someone can help shed some light.
>
> abstract Feature
>
> type A <: Feature end
> evaluate(f::A) = 1.0
>
> type B <: Feature end
> evaluate(f::B) = 0.0
>
> function slow(features::Vector{Feature})
> retval = 0.0
> for i in 1 : length(features)
> retval += evaluate(features[i])
> end
> retval
> end
>
> function fast(features::Vector{Feature})
> retval = 0.0
> for i in 1 : length(features)
> if isa(features[i], A)
> retval += evaluate(features[i]::A)
> else
> retval += evaluate(features[i]::B)
> end
> end
> retval
> end
>
> using ProfileView
>
> features = Feature[]
> for i in 1 : 1
> push!(features, A())
> end
>
> slow(features)
> @time slow(features)
> fast(features)
> @time fast(features)
>
> The output is:
>
> 0.000136 seconds (10.15 k allocations: 166.417 KB)
> 0.12 seconds (5 allocations: 176 bytes)
>
>
> This is a HUGE difference! Am I missing something big? Is there a good way to 
> inspect code to figure out where I am going wrong?
>
>
> Thank you in advance for any guidance.
>
>
> -Tim
>
>
>
>
>
>

Re: [julia-users] WARNING: Base.String is deprecated [Help defining my own "String"]

[Eric Forgy]

On Monday, April 4, 2016 at 11:32:23 PM UTC+8, Milan Bouchet-Valat wrote:
>
> Even if that's a bug, calling a type String isn't a great idea given 
> that it's going to be the new name for ASCIIString/UTF8String in Base. 
> Better choose something more explicit. 
>

I hear you, but I do want types corresponding to the Entity Data Model. I 
"think" by keeping things in a small encapsulated module, e.g. EDM.String, 
I should be able to avoid too many train wrecks. I'm also using EDM.Int64 
without disastrous results so far. Fingers crossed :) 

Re: [julia-users] WARNING: Base.String is deprecated [Help defining my own "String"]

[Milan Bouchet-Valat]

Le lundi 04 avril 2016 à 10:54 -0400, Yichao Yu a écrit :
> On Mon, Apr 4, 2016 at 10:53 AM, Yichao Yu  wrote:
> > 
> > On Mon, Apr 4, 2016 at 10:27 AM, Eric Forgy  wrote:
> > > 
> > > Hello,
> > > 
> > > I am doing some work trying to get Julia to play nice with .NET and want 
> > > to
> > > define some Julia types corresponding to the Entity Data Model.
> > > 
> > > So far everything is good, but I am getting irritating deprecation 
> > > warnings
> > > about Base.String, but I am not using Base.String anywhere as far as I can
> > > see. I am always using MyModule.String, yet I am still getting these
> > > warnings.
> > Do you define your own `String` type in `MyModule` that is different
> > from `Base.String`.
> > 
> Just tried it on master and this looks like a bug. Please file this on
> the issue tracker.
> 
> ```
> julia> module A
>    type String
>    end
>    end
> A
> 
> julia> A.String
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near no file:0
> A.String
> ```
Even if that's a bug, calling a type String isn't a great idea given
that it's going to be the new name for ASCIIString/UTF8String in Base.
Better choose something more explicit.


Regards


> > > 
> > > 
> > > How can I eliminate the warnings without literally killing the
> > > warnings? All
> > > the code is working fine, so I can try to ignore them, but it is
> > > quite
> > > distracting.
> > > 
> > > The warnings do not always appear, e.g.
> > > 
> > > julia> MyModule.String("Hello")
> > > "Hello"
> > > 
> > > This is good.
> > > 
> > > However,
> > > 
> > > julia> MyModule.String
> > > WARNING: Base.String is deprecated, use AbstractString instead.
> > >   likely near no file:0
> > > 
> > > Is there someway to overwrite some incarnation of "show". I guess
> > > it might
> > > be using Base.String in "show" for some reason.
> > > 
> > > I THINK this is the culprit that is polluting all my other
> > > "shows", so if I
> > > can sort this out, I hope I'm good everywhere.
> > > 
> > > I was using 4.2 (on Windows) and thought upgrading to 4.5 might
> > > help, but I
> > > have the same problem on 4.5.
> > > 
> > > Any ideas?
> > > 
> > > Thank you.

Re: [julia-users] WARNING: Base.String is deprecated [Help defining my own "String"]

[Eric Forgy]

On Monday, April 4, 2016 at 10:54:42 PM UTC+8, Yichao Yu wrote:
>
> Just tried it on master and this looks like a bug. Please file this on 
> the issue tracker. 
>

Ok. Thanks for looking into it Yichao.

https://github.com/JuliaLang/julia/issues/15760 

Re: [julia-users] MethodError: '+' has no method matching +(::DateTime, ::Int64)

[Jacob Quinn]

Dates.day is the accessor funciton, returning the day of month for a
Date/DateTime.

Dates.Day is the Period type representing the span of one day.

So you'll want something like:

now() + Dates.Day(1)

-Jacob


On Mon, Apr 4, 2016 at 5:48 AM, Josh  wrote:

> When trying to increment and decrement dates I get the method error stated
> above.
>
> For example with: now() + Dates.day(1)
>
> I get the error:
>
> *ERROR: MethodError: `+` has no method matching +(::DateTime, ::Int64)*
>
> Closest candidates are:
>
>   +(::Any, ::Any, *::Any*, *::Any...*)
>
>   +(*::Int64*, ::Int64)
>
>   +(*::Complex{Bool}*, ::Real)
>
>   ...
>
> But with doing something like this: Date(2015,12,25) - today()
>
> I get the correct result with no error.
>
> Any ideas?
> Thanks
>
>

[julia-users] Re: QuantLib in Julia: JQuantLib (very very alpha stage at this point!)

[Christopher Alexander]

Hello all,

I just wanted to provide an update on this package.  I haven't officially 
registered it yet (I still have more work I want to do, and I need to add 
more tests), but there have been significant updates in the past month. 
 I've added QuantLib's Monte Carlo simulation features, as well some of its 
market model platform.  There are examples which show how these are 
implemented and also an example which calculates CVA (credit valuation 
adjustment) based off of an example 
here: 
http://nbviewer.jupyter.org/github/mgroncki/IPythonScripts/blob/master/CVA_calculation_I.ipynb
 
 I've also added some documentation 
(http://quantlibjl.readthedocs.org/en/latest/) and some tests, but again, 
this is still very much a work in progress!  Let me know if anyone runs 
into any issues!

Thanks!

Chris

On Tuesday, March 1, 2016 at 7:14:12 PM UTC-5, Christopher Alexander wrote:
>
> OK, I have renamed the package to QuantLib.jl.  The package is located 
> here:  https://github.com/pazzo83/QuantLib.jl
>
> Thanks again for all the feedback!
>
> - Chris
>
> On Tuesday, March 1, 2016 at 8:50:24 AM UTC-5, Jeffrey Sarnoff wrote:
>>
>> As Eric suggests, naming it QuantLib.jl works best with the package 
>> ecosystem and it is not in use elsewhere.
>>
>> On Tuesday, March 1, 2016 at 8:40:32 AM UTC-5, Luigi Ballabio wrote:
>>>
>>> Very interesting--drop me a line if you want me to add a link to your 
>>> project on the QuantLib site.  One thing though: the name JQuantLib has 
>>> been taken for a while by another project (with which I'm not involved) 
>>> that's writing a Java port of QuantLib; see <
>>> http://www.jquantlib.org/en/latest/>.  You might want to come up with a 
>>> new name to avoid confusion.
>>>
>>> Now I just have to learn Julia to have a look at your code :)
>>>
>>> Luigi
>>>
>>>
>>> On Tuesday, March 1, 2016 at 7:56:45 AM UTC+1, Christopher Alexander 
>>> wrote:

 Thanks guys!  I still have a lot of work to do regarding writing tests 
 and all, but one awesome thing is that for the most part, I am matching or 
 beating the C++ timings for the examples I've created so far.

 On Monday, February 29, 2016 at 11:24:09 PM UTC-5, Viral Shah wrote:
>
> You've already got a nice body of code there!
>
> -viral
>
> On Monday, February 29, 2016 at 10:02:16 PM UTC+5:30, Christopher 
> Alexander wrote:
>>
>> Hello all, I'd like to point people in the direction of a package 
>> I've been working on: JQuantLib, to get some feedback.  Basically, I am 
>> trying to write a version of the very popular open-source quantitative 
>> finance library QuantLib in pure Julia.  The library itself is written 
>> in 
>> C++, but it is commonly used in Python (via SWIG).  I thought this would 
>> be 
>> a first attempt at trying to solve a common problem in many financial 
>> firms 
>> where you have basically two different dev environments: a 
>> calculation-heavy one (where speed is important) in C++, C, etc and one 
>> that is increasingly in Python to provide an abstraction to that lower 
>> level.  Julia seems to be a perfect fit for eliminating the myriad 
>> issues 
>> one can encounter with this bifurcated dev setup.
>>
>> The package itself is located here: 
>> https://github.com/pazzo83/JQuantLib
>>
>> There is a bond pricing (NPV) example in the readme itself, and 
>> further examples in the examples folder (these are under development 
>> still).  I am continuing to work on this and add to it, but I'd love 
>> some 
>> feedback!  I'm still relatively new to Julia, but working on this has 
>> definitely improved my fluency of the language.
>>
>> Thanks!
>>
>> Chris
>>
>

Re: [julia-users] WARNING: Base.String is deprecated [Help defining my own "String"]

[Eric Forgy]

Hi Yichao,

> On 4 Apr 2016, at 10:53 PM, Yichao Yu  wrote:
> Do you define your own `String` type in `MyModule` that is different
> from `Base.String`.

Yeah. I just left the office and in a taxi, but this is it:

type String{T<:AbstractString}
value::T
End

Re: [julia-users] WARNING: Base.String is deprecated [Help defining my own "String"]

[Yichao Yu]

On Mon, Apr 4, 2016 at 10:53 AM, Yichao Yu  wrote:
> On Mon, Apr 4, 2016 at 10:27 AM, Eric Forgy  wrote:
>> Hello,
>>
>> I am doing some work trying to get Julia to play nice with .NET and want to
>> define some Julia types corresponding to the Entity Data Model.
>>
>> So far everything is good, but I am getting irritating deprecation warnings
>> about Base.String, but I am not using Base.String anywhere as far as I can
>> see. I am always using MyModule.String, yet I am still getting these
>> warnings.
>
> Do you define your own `String` type in `MyModule` that is different
> from `Base.String`.
>

Just tried it on master and this looks like a bug. Please file this on
the issue tracker.

```
julia> module A
   type String
   end
   end
A

julia> A.String
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near no file:0
A.String
```

>>
>> How can I eliminate the warnings without literally killing the warnings? All
>> the code is working fine, so I can try to ignore them, but it is quite
>> distracting.
>>
>> The warnings do not always appear, e.g.
>>
>> julia> MyModule.String("Hello")
>> "Hello"
>>
>> This is good.
>>
>> However,
>>
>> julia> MyModule.String
>> WARNING: Base.String is deprecated, use AbstractString instead.
>>   likely near no file:0
>>
>> Is there someway to overwrite some incarnation of "show". I guess it might
>> be using Base.String in "show" for some reason.
>>
>> I THINK this is the culprit that is polluting all my other "shows", so if I
>> can sort this out, I hope I'm good everywhere.
>>
>> I was using 4.2 (on Windows) and thought upgrading to 4.5 might help, but I
>> have the same problem on 4.5.
>>
>> Any ideas?
>>
>> Thank you.

Re: [julia-users] WARNING: Base.String is deprecated [Help defining my own "String"]

[Yichao Yu]

On Mon, Apr 4, 2016 at 10:27 AM, Eric Forgy  wrote:
> Hello,
>
> I am doing some work trying to get Julia to play nice with .NET and want to
> define some Julia types corresponding to the Entity Data Model.
>
> So far everything is good, but I am getting irritating deprecation warnings
> about Base.String, but I am not using Base.String anywhere as far as I can
> see. I am always using MyModule.String, yet I am still getting these
> warnings.

Do you define your own `String` type in `MyModule` that is different
from `Base.String`.

>
> How can I eliminate the warnings without literally killing the warnings? All
> the code is working fine, so I can try to ignore them, but it is quite
> distracting.
>
> The warnings do not always appear, e.g.
>
> julia> MyModule.String("Hello")
> "Hello"
>
> This is good.
>
> However,
>
> julia> MyModule.String
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near no file:0
>
> Is there someway to overwrite some incarnation of "show". I guess it might
> be using Base.String in "show" for some reason.
>
> I THINK this is the culprit that is polluting all my other "shows", so if I
> can sort this out, I hope I'm good everywhere.
>
> I was using 4.2 (on Windows) and thought upgrading to 4.5 might help, but I
> have the same problem on 4.5.
>
> Any ideas?
>
> Thank you.

[julia-users] WARNING: Base.String is deprecated [Help defining my own "String"]

[Eric Forgy]

Hello,

I am doing some work trying to get Julia to play nice with .NET and want to 
define some Julia types corresponding to the Entity Data Model 
.

So far everything is good, but I am getting irritating deprecation warnings 
about Base.String, but I am not using Base.String anywhere as far as I can 
see. I am always using MyModule.String, yet I am still getting these 
warnings.

How can I eliminate the warnings without literally killing the warnings? 
All the code is working fine, so I can try to ignore them, but it is quite 
distracting.

The warnings do not always appear, e.g.

julia> MyModule.String("Hello")
"Hello"

This is good.

However,

julia> MyModule.String
WARNING: Base.String is deprecated, use AbstractString instead.
  likely near no file:0

Is there someway to overwrite some incarnation of "show". I guess it might 
be using Base.String in "show" for some reason.

I THINK this is the culprit that is polluting all my other "shows", so if I 
can sort this out, I hope I'm good everywhere.

I was using 4.2 (on Windows) and thought upgrading to 4.5 might help, but I 
have the same problem on 4.5.

Any ideas?

Thank you.

Re: [julia-users] julia-emacs ...

[Andrea Pagnani]

Ok ... so just a 

git clone https://github.com/JuliaLang/julia-emacs

makes the job + changing the path of where the julia-mode.el is in the 
.emacs file.

Thanks, and sorry for the noise.

A
On Monday, April 4, 2016 at 11:21:41 AM UTC+2, Stefan Karpinski wrote:
>
> The julia-emacs repo is not a Julia package – the julia package manager 
> doesn't install emacs modes. The julia-emacs repo has some brief 
> instruction on how to install the mode: 
> https://github.com/JuliaLang/julia-emacs#install.
>
> On Mon, Apr 4, 2016 at 5:02 AM, Andrea Pagnani  > wrote:
>
>> Dear all,
>>
>> I discovered that emacs support that after #15694 
>>  has its own repository.
>>
>> After a Pkg.update()  in 0.5 I tried: 
>>
>> Pkg.add("julia-emacs") #no success
>> Pkg.clone("https://github.com/JuliaLang/julia-emacs;) #no success
>> Pkg.clone("https://github.com/JuliaLang/julia-emacs.git;) #no success 
>> either
>>
>> Anybody knows what am I doing wrong?
>>
>> Thanks
>>
>>
>

[julia-users] Re: Read External file data

[tannirind]

Thank you Fred for your cooperation 

BR,

On Monday, April 4, 2016 at 3:59:03 PM UTC+2, Fred wrote:
>
> Hi,
>
> Of course it is possible :
>
> https://en.wikibooks.org/wiki/Introducing_Julia/Working_with_text_files
>
> You can read data frames to :
>
> https://dataframesjl.readthedocs.org/en/latest/io.html
>

[julia-users] Re: Read External file data

[Fred]

Hi,

Of course it is possible :

https://en.wikibooks.org/wiki/Introducing_Julia/Working_with_text_files

You can read data frames to :

https://dataframesjl.readthedocs.org/en/latest/io.html

Re: [julia-users] Apache Arrow/Feather

[Tamas Papp]

https://github.com/JuliaStats/Feather.jl

On Mon, Apr 04 2016, Michael Turok wrote:

> Any thoughts here on the efforts to build a unified dataframe format 
> between R and Python via Apache Arrow (and Feather?)
>
> Regards,
> Michael

Re: [julia-users] Apache Arrow/Feather

[Stefan Karpinski]

There's been some discussion on julia-dev:

https://groups.google.com/forum/#!topic/julia-dev/qRtkiBAbM9w
https://groups.google.com/forum/#!topic/julia-dev/pFJS4oxKAFE

On Mon, Apr 4, 2016 at 9:32 AM, Michael Turok 
wrote:

> Any thoughts here on the efforts to build a unified dataframe format
> between R and Python via Apache Arrow (and Feather?)
>
> Regards,
> Michael
>
>

[julia-users] MethodError: '+' has no method matching +(::DateTime, ::Int64)

[Josh]

When trying to increment and decrement dates I get the method error stated 
above. 

For example with: now() + Dates.day(1)

I get the error:

*ERROR: MethodError: `+` has no method matching +(::DateTime, ::Int64)*

Closest candidates are:

  +(::Any, ::Any, *::Any*, *::Any...*)

  +(*::Int64*, ::Int64)

  +(*::Complex{Bool}*, ::Real)

  ...

But with doing something like this: Date(2015,12,25) - today() 

I get the correct result with no error.

Any ideas?
Thanks

[julia-users] Re: possibility to define a type that is subtype of more than one supertype

[Hans-Peter]

Not possible. See this issue where it has been discussed: 
https://github.com/JuliaLang/julia/issues/5. I think traits 
(mauro3/Traits.jl) could be helpful for you (just a guess, don't know trait 
specifics atm)

[julia-users] Apache Arrow/Feather

[Michael Turok]

Any thoughts here on the efforts to build a unified dataframe format 
between R and Python via Apache Arrow (and Feather?)

Regards,
Michael

[julia-users] Re: possibility to define a type that is subtype of more than one supertype

[Jason Merrill]

It is not currently possible for a type to have multiple direct supertypes.

You might be interested in the Traits package:

https://github.com/mauro3/Traits.jl

If you don't want to add a dependency, you can use the "traits trick" 
directly, which seems to have first been described here:

https://github.com/JuliaLang/julia/issues/2345#issuecomment-54537633

Base uses this strategy right now to decide how to iterate over subtypes of 
AbstractArrays based on whether the linearindexing function returns 
LinearFast or LinearSlow for the type.

https://github.com/JuliaLang/julia/search?utf8=%E2%9C%93=LinearFast

On Monday, April 4, 2016 at 8:54:24 AM UTC-4, Martin Kuzma wrote:
>
> Hi, since abstract types cant have any fields I think of them as 
> interfaces. I want to specify that a type is subtype of more than one 
> supertype.
> I tried this:
>
> abstract A
>
> abstract B
>
> type T <: A, B end
>
> But I cant do that. Is it even possible to do? Am I using a wrong syntax? 
> Martin.
>

[julia-users] Read External file data

[tannirind]

How we can read data from external file using julia? Tank you for your time.

Best Regards,
Tanveer Iqbal

[julia-users] possibility to define a type that is subtype of more than one supertype

[Martin Kuzma]

Hi, since abstract types cant have any fields I think of them as 
interfaces. I want to specify that a type is subtype of more than one 
supertype.
I tried this:

abstract A

abstract B

type T <: A, B end

But I cant do that. Is it even possible to do? Am I using a wrong syntax? 
Martin.

Re: [julia-users] Doing linear algebra on nested subarrays ... quickly

[Tim Holy]

Have you tried `sub`?

--Tim

On Sunday, April 03, 2016 04:54:58 PM Gregor Robinson wrote:
> I'm working on a problem where I do linear algebra on progressively larger
> n by n submatrices in the upper-left of a (potentially large) N by N
> matrix. If I'm using a plain ol' dense matrix, the linear algebra takes
> place 30 times faster when I plug it into BLAS compared to a (fairly naive,
> tbh) implementation of the same in Julia. So my question is whether anyone
> can think of a cool way to accomplish the task of doing BLAS operations on
> just the submatrices I care about, without doing the nasty total of N-1
> array allocations of size (2^2, 3^2, ... , N^2) and copying one array to
> the next. ...Which I haven't tested but suspect would be substantially
> slower than just doing the linear algebra in Julia.
> 
> Thanks!
> Gregor

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Stefan Karpinski]

Number does not imply or assume commutativity. The Quaternions package
provides a Quaternion type which is a subtype of Number. Rational, however,
only allows integer numerators and denominators. Since integer
multiplication is commutative, rational multiplication is too. But I still
think it best to reserve \\ with an analogous meaning to //. There are
already two syntaxes for integer division, which is plenty.

On Mon, Apr 4, 2016 at 7:20 AM, Jeffrey Sarnoff 
wrote:

> Since supertype(Number) == Any, the most abstract number-like entity that
> Julia has to offer with the current hierarchy is Number.  Most packages I
> have seen that implement number-like types which are outside of the Reals
> use Number as their supertype.  This is more helpful, generally, than
> having Quaternions, Dual Numbers etc be direct subtypes of Any.
>
> On Monday, April 4, 2016 at 7:06:17 AM UTC-4, Sheehan Olver wrote:
>>
>>
>> Rational is currently restricted to numbers:
>> Rational{T<:Number}.  I’m assuming Number implicitly means commutative
>> number (i.e., not Quaternion).
>>
>>
>>
>> > On 4 Apr 2016, at 8:55 PM, Tim Holy  wrote:
>> >
>> > On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote:
>> >> With \\, would you worry about confusion from the fact that in a \\ b,
>> a is
>> >>
>> >>> in
>> >>> the denominator? Especially if it gets called the "integer division
>> >>> operator."
>> >>
>> >> It might confuse some of the mathematicians, used to a \ b as a
>> inverse
>> >> multiplication operator, however, other languages use a \ b for what
>> in
>> >> Julia is div(a, b) or a÷b,
>> >> so I really don't think a definition of \\ as div(a, b) would be that
>> much
>> >> of a problem, no worse than other things you have to remember in
>> Julia,
>> >> and it's reminiscent of the // integer division operator in Python and
>> Lua.
>> >
>> > Thinking about it a second time, there's another reason I'd recommend
>> against
>> > this choice: if you're working with non-commutative numbers, for
>> consistency
>> > \\ too should be reserved for forming Rationals rather than meaning
>> something
>> > completely different. In other words, b//a means RightRational(b, a)
>> (b*inv(a))
>> > and a\\b means LeftRational(a, b) (inv(a)*b). I suspect our current
>> Rational
>> > framework implicitly assumes commutativity, but that's a separate issue
>> and
>> > one that, with a suitable number-traits system, is cleanly resolvable.
>> >
>> > I'm not trying to argue that making rationals with non-commutative
>> numbers is
>> > a daily task, but to me consistency in the meaning of notation seems
>> like the
>> > most important guiding principle. Code gets read many more times than
>> it is
>> > written, so I don't mind a few extra keystrokes if it makes reading
>> code
>> > clearer.
>> >
>> > But once again, it seems there just aren't enough characters on the
>> keyboard.
>> >
>> > Best,
>> > --Tim
>> >
>>
>>

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Jeffrey Sarnoff]

Since supertype(Number) == Any, the most abstract number-like entity that 
Julia has to offer with the current hierarchy is Number.  Most packages I 
have seen that implement number-like types which are outside of the Reals 
use Number as their supertype.  This is more helpful, generally, than 
having Quaternions, Dual Numbers etc be direct subtypes of Any.

On Monday, April 4, 2016 at 7:06:17 AM UTC-4, Sheehan Olver wrote:
>
>
> Rational is currently restricted to numbers: Rational{T<:Number}. 
>  I’m assuming Number implicitly means commutative number (i.e., not 
> Quaternion).   
>
>
>
> > On 4 Apr 2016, at 8:55 PM, Tim Holy  
> wrote: 
> > 
> > On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote: 
> >> With \\, would you worry about confusion from the fact that in a \\ b, 
> a is 
> >> 
> >>> in 
> >>> the denominator? Especially if it gets called the "integer division 
> >>> operator." 
> >> 
> >> It might confuse some of the mathematicians, used to a \ b as a inverse 
> >> multiplication operator, however, other languages use a \ b for what in 
> >> Julia is div(a, b) or a÷b, 
> >> so I really don't think a definition of \\ as div(a, b) would be that 
> much 
> >> of a problem, no worse than other things you have to remember in Julia, 
> >> and it's reminiscent of the // integer division operator in Python and 
> Lua. 
> > 
> > Thinking about it a second time, there's another reason I'd recommend 
> against 
> > this choice: if you're working with non-commutative numbers, for 
> consistency 
> > \\ too should be reserved for forming Rationals rather than meaning 
> something 
> > completely different. In other words, b//a means RightRational(b, a) 
> (b*inv(a)) 
> > and a\\b means LeftRational(a, b) (inv(a)*b). I suspect our current 
> Rational 
> > framework implicitly assumes commutativity, but that's a separate issue 
> and 
> > one that, with a suitable number-traits system, is cleanly resolvable. 
> > 
> > I'm not trying to argue that making rationals with non-commutative 
> numbers is 
> > a daily task, but to me consistency in the meaning of notation seems 
> like the 
> > most important guiding principle. Code gets read many more times than it 
> is 
> > written, so I don't mind a few extra keystrokes if it makes reading code 
> > clearer. 
> > 
> > But once again, it seems there just aren't enough characters on the 
> keyboard. 
> > 
> > Best, 
> > --Tim 
> > 
>
>

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Sheehan Olver]

Rational is currently restricted to numbers: Rational{T<:Number}.  I’m 
assuming Number implicitly means commutative number (i.e., not Quaternion).  



> On 4 Apr 2016, at 8:55 PM, Tim Holy  wrote:
> 
> On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote:
>> With \\, would you worry about confusion from the fact that in a \\ b, a is
>> 
>>> in
>>> the denominator? Especially if it gets called the "integer division
>>> operator."
>> 
>> It might confuse some of the mathematicians, used to a \ b as a inverse
>> multiplication operator, however, other languages use a \ b for what in
>> Julia is div(a, b) or a÷b,
>> so I really don't think a definition of \\ as div(a, b) would be that much
>> of a problem, no worse than other things you have to remember in Julia,
>> and it's reminiscent of the // integer division operator in Python and Lua.
> 
> Thinking about it a second time, there's another reason I'd recommend against 
> this choice: if you're working with non-commutative numbers, for consistency 
> \\ too should be reserved for forming Rationals rather than meaning something 
> completely different. In other words, b//a means RightRational(b, a) 
> (b*inv(a)) 
> and a\\b means LeftRational(a, b) (inv(a)*b). I suspect our current Rational 
> framework implicitly assumes commutativity, but that's a separate issue and 
> one that, with a suitable number-traits system, is cleanly resolvable.
> 
> I'm not trying to argue that making rationals with non-commutative numbers is 
> a daily task, but to me consistency in the meaning of notation seems like the 
> most important guiding principle. Code gets read many more times than it is 
> written, so I don't mind a few extra keystrokes if it makes reading code 
> clearer.
> 
> But once again, it seems there just aren't enough characters on the keyboard.
> 
> Best,
> --Tim
> 

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Tim Holy]

On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote:
> With \\, would you worry about confusion from the fact that in a \\ b, a is
> 
> > in
> > the denominator? Especially if it gets called the "integer division
> > operator."
> 
> It might confuse some of the mathematicians, used to a \ b as a inverse
> multiplication operator, however, other languages use a \ b for what in
> Julia is div(a, b) or a÷b,
> so I really don't think a definition of \\ as div(a, b) would be that much
> of a problem, no worse than other things you have to remember in Julia,
> and it's reminiscent of the // integer division operator in Python and Lua.

Thinking about it a second time, there's another reason I'd recommend against 
this choice: if you're working with non-commutative numbers, for consistency 
\\ too should be reserved for forming Rationals rather than meaning something 
completely different. In other words, b//a means RightRational(b, a) (b*inv(a)) 
and a\\b means LeftRational(a, b) (inv(a)*b). I suspect our current Rational 
framework implicitly assumes commutativity, but that's a separate issue and 
one that, with a suitable number-traits system, is cleanly resolvable.

I'm not trying to argue that making rationals with non-commutative numbers is 
a daily task, but to me consistency in the meaning of notation seems like the 
most important guiding principle. Code gets read many more times than it is 
written, so I don't mind a few extra keystrokes if it makes reading code 
clearer.

But once again, it seems there just aren't enough characters on the keyboard.

Best,
--Tim

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Sheehan Olver]

Why not just add a shortcut in your editor that automatically expands \\ to 
*÷?*

On Monday, April 4, 2016 at 7:12:44 PM UTC+10, Scott Jones wrote:
>
>
>
> On Sunday, April 3, 2016 at 12:09:35 PM UTC-4, Tim Holy wrote:
>>
>> Indexing with // is a bit undesirable because 6//3 gets simplified to 
>> 2//1 upon 
>> construction, and there's no reason to pay the cost of that operation. 
>>
>
> That was Eric's idea - I was strictly talking about integer division, not 
> indexing.
> I do have a lot of hope that a clean, flexible AND performant API will be 
> made for Julia, from the discussions you in particular have been leading on 
> GitHub.
> I would definitely like to have 0-based, row-major arrays that are as 
> performant in Julia as 1-based, column-major ones are, and that allow easy 
> interfacing
> between Julia and C/C++/Java in-memory structures.
>
> With \\, would you worry about confusion from the fact that in a \\ b, a 
>> is in 
>> the denominator? Especially if it gets called the "integer division 
>> operator." 
>>
>
> It might confuse some of the mathematicians, used to a \ b as a inverse 
> multiplication operator, however, other languages use a \ b for what in 
> Julia is div(a, b) or a÷b,
> so I really don't think a definition of \\ as div(a, b) would be that much 
> of a problem, no worse than other things you have to remember in Julia,
> and it's reminiscent of the // integer division operator in Python and Lua.
>
> One could use ///, but that's starting to be pretty comparable to 
>> \div[TAB], 
>> and less pretty to read. 
>>
>
> Most anything would be better than having to use a Unicode operator for 
> such a common operator, having to deal with different ways of typing it in 
> the REPL, your editor, etc, IMO.
>
> -Scott
>

Re: [julia-users] julia-emacs ...

[Stefan Karpinski]

The julia-emacs repo is not a Julia package – the julia package manager
doesn't install emacs modes. The julia-emacs repo has some brief
instruction on how to install the mode:
https://github.com/JuliaLang/julia-emacs#install.

On Mon, Apr 4, 2016 at 5:02 AM, Andrea Pagnani 
wrote:

> Dear all,
>
> I discovered that emacs support that after #15694
>  has its own repository.
>
> After a Pkg.update()  in 0.5 I tried:
>
> Pkg.add("julia-emacs") #no success
> Pkg.clone("https://github.com/JuliaLang/julia-emacs;) #no success
> Pkg.clone("https://github.com/JuliaLang/julia-emacs.git;) #no success
> either
>
> Anybody knows what am I doing wrong?
>
> Thanks
>
>

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Scott Jones]

On Sunday, April 3, 2016 at 12:09:35 PM UTC-4, Tim Holy wrote:
>
> Indexing with // is a bit undesirable because 6//3 gets simplified to 2//1 
> upon 
> construction, and there's no reason to pay the cost of that operation. 
>

That was Eric's idea - I was strictly talking about integer division, not 
indexing.
I do have a lot of hope that a clean, flexible AND performant API will be 
made for Julia, from the discussions you in particular have been leading on 
GitHub.
I would definitely like to have 0-based, row-major arrays that are as 
performant in Julia as 1-based, column-major ones are, and that allow easy 
interfacing
between Julia and C/C++/Java in-memory structures.

With \\, would you worry about confusion from the fact that in a \\ b, a is 
> in 
> the denominator? Especially if it gets called the "integer division 
> operator." 
>

It might confuse some of the mathematicians, used to a \ b as a inverse 
multiplication operator, however, other languages use a \ b for what in 
Julia is div(a, b) or a÷b,
so I really don't think a definition of \\ as div(a, b) would be that much 
of a problem, no worse than other things you have to remember in Julia,
and it's reminiscent of the // integer division operator in Python and Lua.

One could use ///, but that's starting to be pretty comparable to 
> \div[TAB], 
> and less pretty to read. 
>

Most anything would be better than having to use a Unicode operator for 
such a common operator, having to deal with different ways of typing it in 
the REPL, your editor, etc, IMO.

-Scott

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[Scott Jones]

On Sunday, April 3, 2016 at 12:20:44 PM UTC-4, Stefan Karpinski wrote:
>
> I question the alleged ubiquity of integer division. This is not an 
> operation I find myself needing all that often. Of course, everyone's 
> programming needs are different, but I just don't find myself wanting the 
> integer quotient of a and b more often than I want to do a/b and get their 
> ratio as a float.
>

In my programming, I've rarely needed to get a floating point value from 
dividing two integers a and b, and there's another problem with the way 
that Julia handles it, in that, how do you control just what size float to 
return? Does it really make sense that an Int128 / Int128 produces a 
Float64?  To me, things like that make the automatic promotion of Integer / 
Integer to Float64 not very useful.
I'd rather be specific in my code, and have write Float64(a)/b, or 
BigFloat(a)/b, for the very few cases where I'd want a floating point 
result. (and since Julia has the wonderful Rationals, I'd rather use those 
than lossy floating point formats anyway).

[julia-users] Doing linear algebra on nested subarrays ... quickly

[Gregor Robinson]

I'm working on a problem where I do linear algebra on progressively larger 
n by n submatrices in the upper-left of a (potentially large) N by N 
matrix. If I'm using a plain ol' dense matrix, the linear algebra takes 
place 30 times faster when I plug it into BLAS compared to a (fairly naive, 
tbh) implementation of the same in Julia. So my question is whether anyone 
can think of a cool way to accomplish the task of doing BLAS operations on 
just the submatrices I care about, without doing the nasty total of N-1 
array allocations of size (2^2, 3^2, ... , N^2) and copying one array to 
the next. ...Which I haven't tested but suspect would be substantially 
slower than just doing the linear algebra in Julia.

Thanks!
Gregor

[julia-users] julia-emacs ...

[Andrea Pagnani]

Dear all,

I discovered that emacs support that after #15694 
 has its own repository.

After a Pkg.update()  in 0.5 I tried: 

Pkg.add("julia-emacs") #no success
Pkg.clone("https://github.com/JuliaLang/julia-emacs;) #no success
Pkg.clone("https://github.com/JuliaLang/julia-emacs.git;) #no success either

Anybody knows what am I doing wrong?

Thanks

Re: [julia-users] Re: performace of loops Julia vs Blas

[Igor Cerovsky]

Thank you all for suggestions and troubleshooting. I'll try 0.4.5 Julia 
version later, post results.

On Thursday, 24 March 2016 14:31:29 UTC+1, Yichao Yu wrote:
>
> On Thu, Mar 24, 2016 at 9:26 AM, Erik Schnetter  > wrote: 
> > Using only SSE2 instead of AVX is slower by a factor of two. 
> > 
> > You can try a newer version of Julia (0.4.5?) that should build 
> > against LLVM 3.7.1 instead of LLVM 3.3. 
>
> IIRC the 0.4.* binaries should be built with llvm 3.3. 
>
> > 
> > -erik 
> > 
> > On Thu, Mar 24, 2016 at 8:54 AM, Yichao Yu  > wrote: 
> >> On Thu, Mar 24, 2016 at 3:22 AM, Igor Cerovsky 
> >>  wrote: 
> >>> I cannot find ymm instuctions in the assembly code. Does 
> >>> LLVM libLLVM-3.3 supports AVX2 instruction set? 
> >> 
> >> Disabled due to llvm bug. The nightly binary is probably also compiled 
> >> without it. 
> > 
> > 
> > 
> > -- 
> > Erik Schnetter  
> > http://www.perimeterinstitute.ca/personal/eschnetter/ 
>

[julia-users] Re: Capturing Error messages as strings

[Matthew Pearce]

Anyone?

At the moment it is very hard to debug parallel work. With issues like 
#14456  and related 
problems, it would be extraordinarily helpful to have access to the full 
error messages from remotes.

I care enough about this to actually try writing code implementing any 
hints / suggestions people might have.


 



On Wednesday, March 30, 2016 at 5:53:53 PM UTC+1, Matthew Pearce wrote:
>
>
> Anyone know how to capture error messages as strings? This is for 
> debugging of code run on remote machines, as the trace on the master node 
> appears to be incomplete.
>
> Note I am *not* asking about the atexit() behaviour. I am asking about 
> capturing non-fatal errors like sqrt(-1) rather than segfaults etc.
>
> Much appreciated
>
> Matthew
>