Re: [julia-users] Re: Order of multiple for-loops

[Glen O]

That's the long, complicated way to do it, in my opinion.

An easier approach in the long run would be to simply define a new Array 
type (RMArray (for Row Major Array), perhaps), and overload the getindex 
and setindex functions for them, etc.

Indeed, perhaps someone could make a package that does this? I'm kind of 
surprised there isn't already such a package.

On Saturday, 31 October 2015 03:54:10 UTC+10, Tomas Lycken wrote:
>
> However, Julia is an incredibly expressive language, and you could quite 
> easily write a macro that re-orders the indices for you:
>
> julia> macro rowmajor(expr)
>@assert expr.head == :ref
>
>Expr(:ref, expr.args[1], expr.args[end:-1:2]...)
>end
>
> julia> macroexpand(:(@rowmajor A[i,j]))
> :(A[j,i])
>
> Of course, this only works on one indexing expression at a time, but it 
> can be extended to work recursively through an expression tree and rewrite 
> all array indexing expressions it finds, allowing usage as
>
> @rowmajor begin
> # formulate row-major algorithm here
> end
>
> No need to change the language - just bend it to do what you need :)
>
> ​
>

[julia-users] Re: copy a local variable to all parallel workers

[Andre Bieler]

I have a similar question about getting data to all workers. Consider the 
following code:

'''
addprocs(2)
using pfuncs

#=
@everywhere function showData()
  @show(data)
end
=#

function pstep()
  @sync begin
for p in workers()
@async begin
remotecall_fetch(p, showData)
end
end
  end
end

@everywhere data = myid()
pstep()
'''

If I uncomment the part where the showData() function is defined, it works 
as expected. If I put the definition of showData() into the file pfuncs.jl 
and import it as in the example above, it does not work.

>From the manual I figure

"using DummyModule causes the module to be loaded on all processes; 
however, the module is brought into scope only on the one executing the 
statement."

addresses the problem, but does not help me solve it.
I also tried the let block posted by Jameson.

How do I get the same behaviour as with the @everywhere function definition 
in the commented block but being able to use modules?

For completeness here is the pfuncs.jl module:

'''
module pfuncs
  export showData

function showData()
  @show(data)
end

end
'''

Re: [julia-users] Enums in Julia

[Eric Forgy]

Thank you Jacob.

I've now got my Enums working following your suggestion (embarrassed for 
asking), but now I am unclear whether there is any benefit to using enums 
versus just creating a bunch of instances of a composite immutable type.

Any wisdom you can share on the circumstances under which you might want to 
use Enums with additional get methods or create a composite immutable type? 
My initial thought with enums was that since the number of countries is 
finite, there is no need to allow a constructor to construct MORE 
countries. With a composite immutable type, the user could, in principle, 
create extra countries and I'm not sure that makes sense.

Is there any performance gotchas I should be aware of? Thank you again for 
patience with naive questions.

[julia-users] Re: parallel and PyCall

[Yakir Gagnon]

OK, I found a horrible work around that might be good enough (for me):
Here is a mock python script:

import math, time
x = math.sin(math.pi/4)
time.sleep(5) # mock local work
print(x) # spit it out to julia

and here is the julia code that runs it:

r = @spawn readall(`python example.py`)
sleep(2) # mock local work
wait(r) # wait on python
t = fetch(r)
x = parse(t)
x - sin(pi/4) # not zero but it works...

This seems to work no matter what. It’s horrid, but better than nothing.

On Friday, October 30, 2015 at 11:14:18 PM UTC+10, Matthew Pearce wrote:


> So I got something working for my pylab example. 
>
> julia> import PyCall
>
> julia> PyCall.@pyimport pylab
>
> julia> @everywhere import PyCall
>
> julia> @everywhere PyCall.@pyimport pylab
>
> julia> @everywhere A = pylab.cumsum(collect(1:10))*1.
>
> julia> fetch(@spawnat remotes[1] A)
> 10-element Array{Float64,1}:
>   1.0
>   3.0
>   6.0
>  10.0
>  15.0
>  21.0
>  28.0
>  36.0
>  45.0
>  55.0
>
>
>
>
> No luck with the math module I'm afraid. Two different types of errors 
> depending on style:
>
> julia> @spawnat remotes[1] PyCall.@pyimport math as pymath
> RemoteRef{Channel{Any}}(2,1,305)
>
> julia> fetch(@spawnat remotes[1] (pymath.sin(pymath.pi / 4) - sin(pymath.pi 
> / 4)) )
> ERROR: On worker 2:
> UndefVarError: pymath not defined
>  in anonymous at multi.jl:1330
>  in anonymous at multi.jl:889
>  in run_work_thunk at multi.jl:645
>  in run_work_thunk at multi.jl:654
>  in anonymous at task.jl:54
>  in remotecall_fetch at multi.jl:731
>  [inlined code] from multi.jl:368
>  in call_on_owner at multi.jl:776
>  in fetch at multi.jl:784
>
> julia> @everywhere PyCall.@pyimport math as pymath
>
> julia> fetch(@spawnat remotes[1] (pymath.sin(pymath.pi / 4) - sin(pymath.pi 
> / 4)) )
> Worker 2 terminated.srun: error: mrc-bsu-tesla1: task 0: Exited with exit 
> code 1
> ERROR: ProcessExitedException()
>  in yieldto at ./task.jl:67
>  in wait at ./task.jl:367
>  in wait at ./task.jl:282
>  in wait at ./channels.jl:97
>  in take! at ./channels.jl:84
>  in take! at ./multi.jl:792
>  in remotecall_fetch at multi.jl:729
>  [inlined code] from multi.jl:368
>  in call_on_owner at multi.jl:776
>  in fetch at multi.jl:784
>
>
> ERROR (unhandled task failure): EOFError: read end of file
>
>
>
>
>
> On Friday, October 30, 2015 at 1:28:21 AM UTC, Yakir Gagnon wrote:
>>
>> @Matthew: did you find a solution? 
>>  
>> On Tuesday, October 27, 2015 at 8:44:53 AM UTC+10, Yakir Gagnon wrote:
>>>
>>> Yea, right? So what’s the answer? How can we if at all do any PyCalls 
>>> parallely? 
>>>
>>> On Monday, October 26, 2015 at 11:49:35 PM UTC+10, Matthew Pearce wrote:
>>>
>>> Thought I had an idea about this, I was wrong:

 ```julia

 julia> @everywhere using PyCall

 julia> @everywhere @pyimport pylab

 julia> remotecall_fetch(pylab.cumsum, 5, collect(1:10))
 ERROR: cannot serialize a pointer
  [inlined code] from error.jl:21
  in serialize at serialize.jl:420
  [inlined code] from dict.jl:372
  in serialize at serialize.jl:428
  in serialize at serialize.jl:310
  in serialize at serialize.jl:420 (repeats 2 times)
  in serialize at serialize.jl:302
  in serialize at serialize.jl:420
  [inlined code] from dict.jl:372
  in serialize at serialize.jl:428
  in serialize at serialize.jl:310
  in serialize at serialize.jl:420 (repeats 2 times)
  in serialize at serialize.jl:302
  in serialize at serialize.jl:420
  [inlined code] from dict.jl:372
  in send_msg_ at multi.jl:222
  [inlined code] from multi.jl:177
  in remotecall_fetch at multi.jl:728
  [inlined code] from multi.jl:368
  in remotecall_fetch at multi.jl:734

 julia> pylab.cumsum(collect(1:10))
 10-element Array{Int64,1}:
   1
   3
   6
  10
  15
  21
  28
  36
  45
  55

 ```

>>> ​
>>>
>> ​

Re: [julia-users] Package requirements and pinning

[Tony Kelman]

https://github.com/JuliaLang/METADATA.jl/issues/2800
https://github.com/JuliaLang/METADATA.jl/issues/2417

And plenty of other offline discussions. I think the more-or-less consensus 
is that we need to implement package namespaces, but how to do so (and who 
has the bandwidth to do the implementation work) is not yet clear and we 
need to start a design discussion about what we want it to look like.


On Friday, October 30, 2015 at 10:03:55 AM UTC-7, Tom Breloff wrote:
>
> Ok thanks Yichao.  I'll have to think on all this a little while to 
> suggest changes to the documentation.
>
> Back to the original post... I heard a rumor that there is discussion 
> underway about making changes to how packages and METADATA work.  I've only 
> been involved on the periphery... are there issues or PRs where future 
> METADATA design is being discussed? 
>
> On Fri, Oct 30, 2015 at 12:55 PM, Yichao Yu  > wrote:
>
>> On Fri, Oct 30, 2015 at 12:26 PM, Tom Breloff > > wrote:
>> > Huh... that's something I didn't know.  What's the environment 
>> variable?  Is
>> > that documented?
>>
>> It is documented here[1]. It is a little hard to find  (I didn't
>> remember that it was and figured out by checking the pkg.jl test in
>> base julia.). Suggestions or PR about how to make it more
>> discoverable are welcome.
>>
>> [1] 
>> http://julia.readthedocs.org/en/latest/stdlib/pkg/?highlight=julia_pkgdir
>>
>> >
>> > On Fri, Oct 30, 2015 at 12:24 PM, Yichao Yu > > wrote:
>> >>
>> >> On Fri, Oct 30, 2015 at 12:13 PM, Tom Breloff > > wrote:
>> >> > In this case, Plots doesn't actually depend on Gadfly at all... it's 
>> an
>> >> > optional dependency.  (I only added it to the require to test what 
>> might
>> >> > happen)  However in the general case it's really tricky if the only
>> >> > "real"
>> >> > solution is "fix the package so the restriction isn't necessary".
>> >> >
>> >> > What if a user installs a package that requires an old version of
>> >> > StatsBase
>> >> > (say, before some change to the interface).  Then if the user has 10
>> >> > other
>> >> > packages which all expect a more recent version of StatsBase, they 
>> will
>> >> > all
>> >> > break (or Pkg will generate an error if any of the version 
>> dependencies
>> >> > in
>> >> > REQUIRE were properly written).  The user may never use those 
>> packages
>> >> > in
>> >> > the same julia session, but because the package states are shared 
>> among
>> >> > all
>> >> > 0.4 versions of Julia (there's only one ~/.julia/v0.4 directory), 
>> he/she
>> >> > cannot keep that package installed.  There's got to be a better
>> >> > solution.
>> >>
>> >> You can change this directory with environment variable
>> >>
>> >> >
>> >> > Of course, a better error message would be helpful too.
>> >> >
>> >> > On Fri, Oct 30, 2015 at 11:50 AM, Yichao Yu > > wrote:
>> >> >>
>> >> >> On Fri, Oct 30, 2015 at 11:30 AM, Tom Breloff > > wrote:
>> >> >> > Ok, I tried that out, and you're right that I get an error (it 
>> didn't
>> >> >> > fallback to an older version, unless maybe that would happen with
>> >> >> > Pkg.update()?)
>> >> >> >
>> >> >> >
>> >> >> > julia> Pkg.resolve()
>> >> >> > ERROR: unsatisfiable package requirements detected: no feasible
>> >> >> > version
>> >> >> > could be found for package: Gadfly
>> >> >> >  in error at ./error.jl:21
>> >> >> >  in resolve at ./pkg/resolve.jl:37
>> >> >> >  in resolve at ./pkg/entry.jl:422
>> >> >> >  in resolve at pkg/entry.jl:404
>> >> >> >  in anonymous at pkg/dir.jl:31
>> >> >> >  in cd at file.jl:22
>> >> >> >  in cd at pkg/dir.jl:31
>> >> >> >  in resolve at pkg.jl:46
>> >> >> >
>> >> >> > julia>
>> >> >> > [tom@tomoffice Plots]$ cat REQUIRE
>> >> >> > julia 0.3
>> >> >> >
>> >> >> > Colors
>> >> >> > Reexport
>> >> >> > Compat
>> >> >> > Gadfly 0.3.18
>> >> >> >
>> >> >> > How should I go about rectifying this error?  In this case I know
>> >> >> > that
>> >> >> > the
>> >> >> > requirement clash is with Immerse (which has "Gadfly 0.3.16 
>> 0.3.17"
>> >> >> > in
>> >> >> > its
>> >> >> > require file), but if a user sees this error they would likely be
>> >> >> > lost.
>> >> >> > I
>> >> >> > fear that there's not a good solution once a single package has
>> >> >> > special
>> >> >> > requirements.
>> >> >> >
>> >> >>
>> >> >> We could probably print out the actual conflicting requirements and
>> >> >> where they are coming from. This should help the user to know where 
>> to
>> >> >> look (or which package to blame)
>> >> >>
>> >> >> IMHO, for this particular conflict, the best solution would be to 
>> fix
>> >> >> Immerse to work with newer version of Gadfly. Or if you need it now,
>> >> >> maybe try to pin Plots down to an earlier version that doesn't 
>> require
>> >> >> Gadfly 0.3.18 (if it has one of course).
>> >> >>
>> >> >> >
>> >> >> > On Friday, October 30, 2015 at 11:15:52 AM UTC-4, Yichao Yu wrote:
>> >> >> >>
>> >> >> >> On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu 
>> >> >> >> wrote:
>> >> >> >> > On Fri,

Re: [julia-users] Enums in Julia

[Jacob Quinn]

Eric,

Currently in Julia, officially supported Enums can only take on integer
values. This excludes the ability to use an arbitrary type as values for
enum members. You could, however, use enums as a part of a solution:

@enum Country Brazil China Canada USA etc.

immutable CountryData
field1::Int
field2::ASCIIString
end

const COUNTRYDATA = [CountryData(1,"hey"), CountryData(2,"there"), ...]

Then usage would be along the lines of

function getfield1(x::Country)
return COUNTRYDATA[x]
end



On Fri, Oct 30, 2015 at 4:41 PM, Eric Forgy  wrote:

> Hi Mauro,
>
> Thank you for your response and sorry I did not ask very clearly. Let me
> try again.
>
> I am considering creating a composite immutable type. I know there will
> always only be a finite number of them, e.g. Country, and I'd like to just
> create them in the beginning of my code. Each Country will have a set of
> fields I need.
>
> I've never used an enumerable type before, but they seem handy when you
> know there is only going to be a finite number of them like Weekdays or
> something.
>
> Chronologically, I created my composite immutable type, Country, with
> fields I need for each country and then had the idea to make Country an
> Enum.
>
> So my question is: Can I make Country an Enum and still allow each country
> to have its own data like a composite immutable type?
>
> For example,
>
> @enum Country countryA countryB
>
> And then be able to access data like
>
> countryA.population
>
> ?
>
> Sorry again for not asking a clear question. As often happens, if I
> understood well enough the language and what I'm try to do with it so that
> I could ask a clear question, then, ironically, I probably would not need
> to ask the question :)
>
> Sent from my iPhone
>
> > On 30 Oct 2015, at 9:13 PM, Mauro  wrote:
> >
> > I don't quite understand what you fail to achieve.  Using other values
> > than integers for the enum does not work, if that is the question.
> >
> > If you just try to make your custom enum, then it cannot be used with
> > the @enum macro.
> >
> > immutable MyEnum
> >field1::Type1
> >filed2::Type2
> > end
> >
> > # no need/use for @enum:
> > enum1 = MyEnum(f11,f12)
> > enum2 = MyEnum(f21,f22)
> >
> > But it seems a bit strange to have an enumeration which uses two values,
> > as an enumeration suggests that there is a mapping to the integers!
> >
> > Mauro
> >
> >> On Fri, 2015-10-30 at 09:37, Eric Forgy  wrote:
> >> I am thinking about making an Enum type MyEnum, but each MyEnum is a
> >> composite immutable type. Is that possible (recommended) and how could
> I do
> >> that?
> >>
> >> I've looked at
> >>
> >>   - https://github.com/JuliaLang/julia/pull/10168
> >>   - And the @enum section of Docs
> >>
> >> but it still isn't obvious to me yet how to do it or if it is even
> >> possible/recommended.
> >>
> >> In psuedo-code, I'd like something like this:
> >>
> >> @enum MyEnum enum1 enum2 enum3
> >>
> >> but each enum[i] is a composite immutable type. How would I construct
> them?
> >>
> >> I thought of something like:
> >>
> >> immutable MyEnum
> >>field1::Type1
> >>filed2::Type2
> >> end
> >>
> >> @enum MyEnum enum1 = MyEnum(f11,f12) enum2 = MyEnum(f21,f22)
> >>
> >> but I don't think that will work.
> >>
> >> Any ideas?
> >>
> >> Thank you.
> >>
> >>
> >>> On Tuesday, January 27, 2015 at 4:55:18 AM UTC+8, Reid Atcheson wrote:
> >>>
> >>> Ok now that you have put it there, the comments in the documentation
> make
> >>> more sense to me. It looks like both yours and mine are essentially
> >>> equivalent, but yours is simpler. I was aiming for the following
> behavior
> >>> with my implementation:
> >>>
> >>> - different enum types won't typecheck (can't do "if e1::EnumType1 ==
> >>> e2::EnumType2" without error).
> >>> - Array of enum type values contiguous in memory, for easy passing to
> C.
> >>> (immutable should do this)
> >>> - referring to enum fields by name, not by their numbering.
> >>>
> >>> I will switch to what you have written, it looks like it hits all of my
> >>> points while not simultaneously abusing the type system.
> >>>
>  On Monday, January 26, 2015 at 2:16:33 PM UTC-6, Mauro wrote:
> 
>  There is a FAQ entry on this which suggests not to use types each of
>  elements of the enum (if I recall correctly).
> 
>  I recently did a enum like this:
> 
>  export nonstiff, mildlystiff, stiff
>  abstract Enum
>  immutable Stiff <: Enum
> val::Int
> function Stiff(i::Integer)
> @assert 0<=i<=2
> new(i)
> end
>  end
>  const nonstiff = Stiff(0)
>  const mildlystiff = Stiff(1)
>  const stiff = Stiff(2)
> 
>  Then you can just do
>  if someflag==nonstiff
>    do_something
>  end
> 
>  So no need either to refer to the numeral value.  But I'm not sure
>  whether this is better or not.
> 
> > On Mon, 2015-01-26 at 19:49, Reid Atcheson 
> wrote:
> > Hey a

Re: [julia-users] Enums in Julia

[Eric Forgy]

Hi Mauro,

Thank you for your response and sorry I did not ask very clearly. Let me try 
again.

I am considering creating a composite immutable type. I know there will always 
only be a finite number of them, e.g. Country, and I'd like to just create them 
in the beginning of my code. Each Country will have a set of fields I need.

I've never used an enumerable type before, but they seem handy when you know 
there is only going to be a finite number of them like Weekdays or something.

Chronologically, I created my composite immutable type, Country, with fields I 
need for each country and then had the idea to make Country an Enum.

So my question is: Can I make Country an Enum and still allow each country to 
have its own data like a composite immutable type?

For example,

@enum Country countryA countryB

And then be able to access data like

countryA.population

?

Sorry again for not asking a clear question. As often happens, if I understood 
well enough the language and what I'm try to do with it so that I could ask a 
clear question, then, ironically, I probably would not need to ask the question 
:)

Sent from my iPhone

> On 30 Oct 2015, at 9:13 PM, Mauro  wrote:
> 
> I don't quite understand what you fail to achieve.  Using other values
> than integers for the enum does not work, if that is the question.
> 
> If you just try to make your custom enum, then it cannot be used with
> the @enum macro.
> 
> immutable MyEnum
>field1::Type1
>filed2::Type2
> end
> 
> # no need/use for @enum:
> enum1 = MyEnum(f11,f12)
> enum2 = MyEnum(f21,f22)
> 
> But it seems a bit strange to have an enumeration which uses two values,
> as an enumeration suggests that there is a mapping to the integers!
> 
> Mauro
> 
>> On Fri, 2015-10-30 at 09:37, Eric Forgy  wrote:
>> I am thinking about making an Enum type MyEnum, but each MyEnum is a
>> composite immutable type. Is that possible (recommended) and how could I do
>> that?
>> 
>> I've looked at
>> 
>>   - https://github.com/JuliaLang/julia/pull/10168
>>   - And the @enum section of Docs
>> 
>> but it still isn't obvious to me yet how to do it or if it is even
>> possible/recommended.
>> 
>> In psuedo-code, I'd like something like this:
>> 
>> @enum MyEnum enum1 enum2 enum3
>> 
>> but each enum[i] is a composite immutable type. How would I construct them?
>> 
>> I thought of something like:
>> 
>> immutable MyEnum
>>field1::Type1
>>filed2::Type2
>> end
>> 
>> @enum MyEnum enum1 = MyEnum(f11,f12) enum2 = MyEnum(f21,f22)
>> 
>> but I don't think that will work.
>> 
>> Any ideas?
>> 
>> Thank you.
>> 
>> 
>>> On Tuesday, January 27, 2015 at 4:55:18 AM UTC+8, Reid Atcheson wrote:
>>> 
>>> Ok now that you have put it there, the comments in the documentation make
>>> more sense to me. It looks like both yours and mine are essentially
>>> equivalent, but yours is simpler. I was aiming for the following behavior
>>> with my implementation:
>>> 
>>> - different enum types won't typecheck (can't do "if e1::EnumType1 ==
>>> e2::EnumType2" without error).
>>> - Array of enum type values contiguous in memory, for easy passing to C.
>>> (immutable should do this)
>>> - referring to enum fields by name, not by their numbering.
>>> 
>>> I will switch to what you have written, it looks like it hits all of my
>>> points while not simultaneously abusing the type system.
>>> 
 On Monday, January 26, 2015 at 2:16:33 PM UTC-6, Mauro wrote:
 
 There is a FAQ entry on this which suggests not to use types each of
 elements of the enum (if I recall correctly).
 
 I recently did a enum like this:
 
 export nonstiff, mildlystiff, stiff
 abstract Enum
 immutable Stiff <: Enum
val::Int
function Stiff(i::Integer)
@assert 0<=i<=2
new(i)
end
 end
 const nonstiff = Stiff(0)
 const mildlystiff = Stiff(1)
 const stiff = Stiff(2)
 
 Then you can just do
 if someflag==nonstiff
   do_something
 end
 
 So no need either to refer to the numeral value.  But I'm not sure
 whether this is better or not.
 
> On Mon, 2015-01-26 at 19:49, Reid Atcheson  wrote:
> Hey all. I have frequently been in the position of wanting enumerations
 in
> Julia. I have finally settled on the implementation linked below which
 lets
> me refer to flags
> in a named way and only specify their underlying numbering once. Is
 this
> the best way, or are there better ways I haven't figured out?
> 
> https://github.com/ReidAtcheson/EnumsInJulia
 
 

[julia-users] Re: A grateful scientist

[Patrick Kofod Mogensen]

I'll get in the "Thank you!" line. I'm still learning every day, but I use 
Julia for pretty much everything (Economics Ph.D. student here). So yeah, 
thanks a lot - and a special thanks to Andreas Noack for transmitting the 
Julia-bug before leaving UCPH. 

On Monday, October 26, 2015 at 4:30:26 AM UTC+1, Yakir Gagnon wrote:
>
> Hi Julia community and developers,
> I'm a postdoc researching color vision, biological optics, polarization 
> vision, and camouflage. I've always used Matlab in my research and made the 
> switch to Julia about two years ago. I just wanted to report, for what it's 
> worth, that as a researcher I think Julia is the best. I promote it 
> everywhere I think it's appropriate, and use it almost exclusively. 
> Just wanted to say a big fat thank you to all the developers and community 
> for creating this magnificence.
>
> THANK YOU! 
>

[julia-users] Re: Order of multiple for-loops

[Tk]

As for "column-majorness" of matrix algebra, it seems to be natural (for 
me) because it is common to write a vector in column form. But of course, 
one could start with a row vector as the basic building block, so it looks 
like a matter of convention...

The reason for this choice might ultimately be traced back to the greater 
ratio of right-handed people (just my guess!).
As English is written from left to right so as to be convenient for 
right-handed people with pen (again a guess!!), 
old mathematician in German, France, and US (where people often write from 
left to right) might have preferred to
use right eigenvectors A x = lambda x rather than left eigenvectors x A = 
lambda x, in such a way that sentences begin with
capital letters (Hello rather than helloW). Also, people may prefer reading 
tabular data from left to right because it is
close to reading a sentence in a book. So the true question is why there 
are more right-handed people :)

And because there are countries where people write from top to bottom or 
right to left, it would have been interesting
if matrix algebra originated from such countries...

[julia-users] Re: Order of multiple for-loops

[Tk]

Thanks very much for various information. And I am sorry if my question 
might be misleading or indicate
confusion or complaints about memory order (indeed, column-major is 
perfectly fine for me).
So let me explain a bit more about my question...

Given that Julia's arrays are column-major order, the following loop is 
most efficient for m x n array A:

 for i2=1:n,
   i1=1:m
   A[ i1, i2 ] = 10 * i1 + i2
end

or equivalently,

 for i2=1:n,  i1=1:m  # (1)
   A[ i1, i2 ] = 10 * i1 + i2
end

To create the same array using comprehension, I once thought that the 
expression might be
something like this

 A = [ 10 * i1 + i2  for  i2=1:n, i1=1:m ] # (2) 

where the index most far from "for" runs faster. Then for-loops in (1) and 
(2) would take the same form.
In fact, Julia employs a different definition

A = [ 10 * i1 + i2  for i1=1:m, i2=1:n ] # (3)

where the index closer to "for" runs faster.
So part of my question was why the definition (2) was not employed (within 
the column-major order)
but (3) was employed.

But come to think of it..., the definition (2) is clearly not nice-looking 
(because the indices are swapped)
while Julia's definition in (3) is more intuitive (although the order in 
(1) and (3) is different).
So I guess this would be the reason for this choice (sorry if this is a 
silly question...).
And I now understand Stephan's comment about row-major order (thanks :)

RE how to memorize the definition (3), the following form is close to (3):

B = [ [ 10 * i1 + i2 for i1=1:m ] for i2=1:n ]

although this gives an array of arrays. So, the definition (3) may be 
viewed as a "rectangularized" or serialized
version of B. This is also easy for me to memorize it (Btw, the above 
expression is similar to implied do-loops
in Fortran, but in fact the content is very different!)

Anyway, thanks very much :)

Re: [julia-users] Re: Order of multiple for-loops

[Tom Breloff]

>
>  We have to choose


Tomas: I agree with most of what you said, except for this part.  I do
think that Julia is expressive and flexible enough that we shouldn't have
to choose one way for everyone.  I made this suggestion
 a
little while ago and I still think it's a reasonable goal for the language.
 (and I still find that picture hilarious)  It's Julia... we can have our
cake and eat it too... right?

To be clear... I do *not* want to switch everything to be row-based, but I
do like the idea of abstracting the ordering, so that either paradigm can
be used.

On Fri, Oct 30, 2015 at 1:54 PM, Tomas Lycken 
wrote:

> in my experience practical applications favor row ordering
>
> The keyword there is that it was *your* experience. The thing about
> something as central to number crunching as organizing memory layouts in
> row- or column major orderings, is that there are more practical
> applications than any of us can imagine - in fact, most likely we couldn’t
> come up with all possible cases where one is significantly better than the
> other even if we stopped discussing Julia and just discussed that for a
> year.
>
> For some applications column major is better, but for others row major
> rocks. We have to choose, and even if the choice was once quite arbitrary,
> the gain from switching is so extremely low it’s ridiculous to even
> consider it. Thus, I don’t think it’s fruitful to discuss here.
>
> However, Julia is an incredibly expressive language, and you could quite
> easily write a macro that re-orders the indices for you:
>
> julia> macro rowmajor(expr)
>@assert expr.head == :ref
>
>Expr(:ref, expr.args[1], expr.args[end:-1:2]...)
>end
>
> julia> macroexpand(:(@rowmajor A[i,j]))
> :(A[j,i])
>
> Of course, this only works on one indexing expression at a time, but it
> can be extended to work recursively through an expression tree and rewrite
> all array indexing expressions it finds, allowing usage as
>
> @rowmajor begin
> # formulate row-major algorithm here
> end
>
> No need to change the language - just bend it to do what you need :)
>
> // T
> On Friday, October 30, 2015 at 5:25:36 PM UTC+1, Tom Breloff wrote:
>
> Preference for row ordering is more related to the way people view tabular
>> data, I think.  For many applications/data, there are many more rows than
>> columns (think of database tables or csv files), and it's slightly
>> unnatural to read those into a transposed data structure for analysis.
>> Putting a time series into a TxN matrix is natural (that's likely how the
>> data is stored), but inefficient if data access is sequentially through
>> time.  Without a "TransposeView" or similar, we're forced to make a choice
>> between poor performance or an unintuitive representation of the data.
>>
>> I can appreciate that matrix operations could be more natural with column
>> ordering, but in my experience practical applications favor row ordering.
>>
>> On Fri, Oct 30, 2015 at 11:44 AM, John Gibson  wrote:
>>
>>> Agreed w Glenn H here. "math being column major" is because the range of
>>> a matrix being the span of its columns, and consequently most linear
>>> algebra algorithms are naturally expressed as operations on the columns of
>>> the matrix, for example QR decomp via Gramm-Schmidt or Householder, LU
>>> without pivoting, all Krylov subspace methods. An exception would be LU
>>> with full or partial row pivoting.
>>>
>>> I think preference for row-ordering comes from the fact that the
>>> textbook presentation of matrix-vector multiply is given as computing y(i)=
>>> sum_j A(i,j) x(j) for each value of i. Ordering the operations that way
>>> would make row-ordering of A cache-friendly. But if instead you understand
>>> mat-vec mult as forming a linear combination of the columns of A, and you
>>> do the computation via y = sum_j A(:,j) x(j), column-ordering is
>>> cache-friendly. And it's the latter version that generalizes into all the
>>> important linear algebra algorithms.
>>>
>>> John
>>>
>>>
>>> On Friday, October 30, 2015 at 10:46:36 AM UTC-4, Glen H wrote:


 On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski
 wrote:
>
> Yes, this is an unfortunate consequence of mathematics being
> column-major – oh how I wish it weren't so. The storage order is actually
> largely irrelevant, the whole issue stems from the fact that the element 
> in
> the ith row and the jth column of a matrix is indexes as A[i,j]. If it 
> were
> A[j,i] then these would agree (and many things would be simpler). I like
> your explanation of "an index closer to the expression to be
> evaluated runs faster" – that's a really good way to remember/explain it.
>
>
 To help understand, is "math being column major" referring to matrix
 operations in math textbooks are done by columns?  For example:


 http://eli

Re: [julia-users] Re: typealias vs. const

[Yichao Yu]

On Fri, Oct 30, 2015 at 1:34 PM, Tomas Lycken  wrote:
>> `const A = T` is what `typealias A T` lowered to when it doesn't have type
>> parameters
>
> I wanted to inspect the output of this lowering pass, but `@code_lowered`
> was apparently not what I was looking for (at least, `@code_lowered
> :(typealias Foo Int)` didn't work...).
>
> However, I understand your statement as follows:
>
> `typealias A T` is equivalent to `const A = T`, while `typealias A{S} T{S}`
> does something more involved? What does `typealias A{S} T{Foo,S}` do? I
> assume these are not possible using `const  = ` constructs, right?

right. Try `expand(:(typealias A B))`

>
> // T
>
> On Friday, October 30, 2015 at 1:45:37 PM UTC+1, Yichao Yu wrote:
>>
>> On Fri, Oct 30, 2015 at 8:29 AM, FANG Colin  wrote:
>> > I have got the same confusion. Any ideas?
>> >
>> > I have even seen usage of A = T (no const)
>> > (http://docs.julialang.org/en/release-0.4/manual/types/#type-unions), is
>> > it
>> > supposed to be bad (slow) because it is a global variable?
>> >
>>
>> no const will have performance issue since it's a global.
>> `const A = T` is what `typealias A T` lowered to when it doesn't have
>> type parameters. In this case, it's just a matter of style. Being
>> consistent within a file is probably better but you can pick whichever
>> you prefer.
>>
>> >
>> >
>> > On Thursday, November 6, 2014 at 3:38:41 PM UTC, Steven G. Johnson
>> > wrote:
>> >>
>> >> Given a type T, what is the difference in practice between
>> >>  typealias A T
>> >> and
>> >>  const A = T
>> >> ?
>> >>
>> >> There seems to be some disagreement over which one to use (e.g.
>> >>
>> >> https://github.com/JuliaLang/Compat.jl/commit/8211e38ac7d8448298a2bb3ab36d6f0b6398b577).
>> >>
>> >> My impression is that there is no difference, and that the only
>> >> advantage
>> >> of a typealias is that it can be parameterized.  Is that right?
>> >>
>> >> If they are equivalent, what is the Julian style?  Even in Julia Base
>> >> it
>> >> doesn't seem to be entirely consistent.

Re: [julia-users] Re: Order of multiple for-loops

[Tomas Lycken]

in my experience practical applications favor row ordering

The keyword there is that it was *your* experience. The thing about 
something as central to number crunching as organizing memory layouts in 
row- or column major orderings, is that there are more practical 
applications than any of us can imagine - in fact, most likely we couldn’t 
come up with all possible cases where one is significantly better than the 
other even if we stopped discussing Julia and just discussed that for a 
year.

For some applications column major is better, but for others row major 
rocks. We have to choose, and even if the choice was once quite arbitrary, 
the gain from switching is so extremely low it’s ridiculous to even 
consider it. Thus, I don’t think it’s fruitful to discuss here.

However, Julia is an incredibly expressive language, and you could quite 
easily write a macro that re-orders the indices for you:

julia> macro rowmajor(expr)
   @assert expr.head == :ref

   Expr(:ref, expr.args[1], expr.args[end:-1:2]...)
   end

julia> macroexpand(:(@rowmajor A[i,j]))
:(A[j,i])

Of course, this only works on one indexing expression at a time, but it can 
be extended to work recursively through an expression tree and rewrite all 
array indexing expressions it finds, allowing usage as

@rowmajor begin
# formulate row-major algorithm here
end

No need to change the language - just bend it to do what you need :)

// T
On Friday, October 30, 2015 at 5:25:36 PM UTC+1, Tom Breloff wrote:

Preference for row ordering is more related to the way people view tabular 
> data, I think.  For many applications/data, there are many more rows than 
> columns (think of database tables or csv files), and it's slightly 
> unnatural to read those into a transposed data structure for analysis.  
> Putting a time series into a TxN matrix is natural (that's likely how the 
> data is stored), but inefficient if data access is sequentially through 
> time.  Without a "TransposeView" or similar, we're forced to make a choice 
> between poor performance or an unintuitive representation of the data.
>
> I can appreciate that matrix operations could be more natural with column 
> ordering, but in my experience practical applications favor row ordering.
>
> On Fri, Oct 30, 2015 at 11:44 AM, John Gibson  > wrote:
>
>> Agreed w Glenn H here. "math being column major" is because the range of 
>> a matrix being the span of its columns, and consequently most linear 
>> algebra algorithms are naturally expressed as operations on the columns of 
>> the matrix, for example QR decomp via Gramm-Schmidt or Householder, LU 
>> without pivoting, all Krylov subspace methods. An exception would be LU 
>> with full or partial row pivoting. 
>>
>> I think preference for row-ordering comes from the fact that the textbook 
>> presentation of matrix-vector multiply is given as computing y(i)= sum_j 
>> A(i,j) x(j) for each value of i. Ordering the operations that way would 
>> make row-ordering of A cache-friendly. But if instead you understand 
>> mat-vec mult as forming a linear combination of the columns of A, and you 
>> do the computation via y = sum_j A(:,j) x(j), column-ordering is 
>> cache-friendly. And it's the latter version that generalizes into all the 
>> important linear algebra algorithms.
>>
>> John
>>
>>
>> On Friday, October 30, 2015 at 10:46:36 AM UTC-4, Glen H wrote:
>>>
>>>
>>> On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski 
>>> wrote:

 Yes, this is an unfortunate consequence of mathematics being 
 column-major – oh how I wish it weren't so. The storage order is actually 
 largely irrelevant, the whole issue stems from the fact that the element 
 in 
 the ith row and the jth column of a matrix is indexes as A[i,j]. If it 
 were 
 A[j,i] then these would agree (and many things would be simpler). I like 
 your explanation of "an index closer to the expression to be evaluated 
 runs faster" – that's a really good way to remember/explain it.


>>> To help understand, is "math being column major" referring to matrix 
>>> operations in math textbooks are done by columns?  For example:
>>>
>>>
>>> http://eli.thegreenplace.net/2015/visualizing-matrix-multiplication-as-a-linear-combination/
>>>
>>> While the order is by convention (eg not that is has to be that way), 
>>> this is how people are taught.
>>>
>>> Glen
>>>
>>
> ​

Re: [julia-users] Base.backtrace() returning different results in 32-bit Windows builds (inlining issue?)

[Stefan Karpinski]

I like it. This is really more like how we should handle backtraces in Base
Julia itself.

On Fri, Oct 30, 2015 at 1:01 PM, Gem Newman  wrote:

> I've been developing StackTraces.jl
>  to provide easy to use,
> programmatically accessible stack traces in Julia.
>
> After some fiddling with @noinline and --inline=no (which have obvious
> implications for comparing stack traces), test cases pass for 0.4 and
> nightly on Linux, Mac, and Win64, but still fail for Win32. I don't have
> easy access to a 32-bit Windows instance and have limited time to explore
> the issue further, but my best guess is that there is an issue with simple
> functions being inlined despite both the @noinline macro and the
> --inline=no flag being used. Unit tests are written using FactCheck.jl.
>
> You can see the build here:
> https://ci.appveyor.com/project/spurll/stacktraces-jl/build/1.0.10
>
> The relevant test code:
>
> @noinline child() = stacktrace()
> @noinline parent() = child()
> @noinline grandparent() = parent()
> ...
> facts() do
> context("basic") do
>  stack = grandparent()
> @fact stack[1:3] --> [
> StackFrame(:child, @__FILE__, 5, Symbol(""), -1, false),
> StackFrame(:parent, @__FILE__, 6, Symbol(""), -1, false),
> StackFrame(:grandparent, @__FILE__, 7, Symbol(""), -1, false)
> ]
> end
>
> ...
> end
>
> A relevant snippet:
>
> > basic
> Failure :: (line:-1) :: basic :: fact was false
>   Expression: stack[1:3] --> [StackFrame(:child,@__FILE__(),5,Symbol(
> ""),-1,false),StackFrame(:parent,@__FILE__(),6,Symbol(""),-1,false),
> StackFrame(:grandparent,@__FILE__(),7,Symbol(""),-1,false)]
> Expected: [StackTraces.StackFrame(:child,symbol(
> "C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),5,
> symbol(""),-1,false),StackTraces.StackFrame(:parent,symbol(
> "C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),6,
> symbol(""),-1,false),StackTraces.StackFrame(:grandparent,symbol(
> "C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),7,
> symbol(""),-1,false)]
> Occurred: [StackTraces.StackFrame(:backtrace,symbol("error.jl"),26
> ,symbol(""),-1,false),StackTraces.StackFrame(:anonymous,symbol(
> "C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),25,
> symbol(""),-1,false),StackTraces.StackFrame(:context,symbol(
> "C:\\Users\\appveyor\\.julia\\v0.4\\FactCheck\\src\\FactCheck.jl"),474,
> symbol(""),-1,false)]
>
> Other relevant information: the stacktrace function erases its own stack
> frame from the stack trace before returning it (along with all other
> "deeper" stack frames that appear while generating the stack trace). I
> expect the stack trace to look like this:
>
> C functions (stacktrace removes these by default)
> Base.backtrace (removed along with stacktrace)
> StackTraces.stacktrace (removed before the trace is returned)
> child
> parent
> grandparent
> anonymous function that calls grandparent
> FactCheck.context
>
> Instead we see this:
>
> C functions (presumably present but removed by stacktrace)
> Base.backtrace (not removed!)
> anonymous function that calls grandparent
> FactCheck.context
>
> So it appears that my test cases are calling Base.backtrace directly
> (perhaps due to some aggressive inlining). My guess is that Base.backtrace
> doesn't get removed because StackTraces.stacktrace doesn't see itself on
> the stack.
>
> (I suppose it's also possible that there is an issue with FactCheck.jl,
> but I'm not sure.)
>

Re: [julia-users] Re: Order of multiple for-loops

[Stefan Karpinski]

Yes, this is what I meant by "mathematics is column major" – the fact that
a vector is conventionally identified with the columns of matrices and that
you multiply vectors by matrices as columns from the right instead of as
rows from the left. This is at odds with the fact that in English we read
left-to-right then top-to-bottom. So I suppose that if we read
top-to-bottom first, we would also avoid this issue, but that seems like an
even bigger change.

On Fri, Oct 30, 2015 at 11:44 AM, John Gibson  wrote:

> Agreed w Glenn H here. "math being column major" is because the range of a
> matrix being the span of its columns, and consequently most linear algebra
> algorithms are naturally expressed as operations on the columns of the
> matrix, for example QR decomp via Gramm-Schmidt or Householder, LU without
> pivoting, all Krylov subspace methods. An exception would be LU with full
> or partial row pivoting.
>
> I think preference for row-ordering comes from the fact that the textbook
> presentation of matrix-vector multiply is given as computing y(i)= sum_j
> A(i,j) x(j) for each value of i. Ordering the operations that way would
> make row-ordering of A cache-friendly. But if instead you understand
> mat-vec mult as forming a linear combination of the columns of A, and you
> do the computation via y = sum_j A(:,j) x(j), column-ordering is
> cache-friendly. And it's the latter version that generalizes into all the
> important linear algebra algorithms.
>
> John
>
>
> On Friday, October 30, 2015 at 10:46:36 AM UTC-4, Glen H wrote:
>>
>>
>> On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski wrote:
>>>
>>> Yes, this is an unfortunate consequence of mathematics being
>>> column-major – oh how I wish it weren't so. The storage order is actually
>>> largely irrelevant, the whole issue stems from the fact that the element in
>>> the ith row and the jth column of a matrix is indexes as A[i,j]. If it were
>>> A[j,i] then these would agree (and many things would be simpler). I like
>>> your explanation of "an index closer to the expression to be evaluated
>>> runs faster" – that's a really good way to remember/explain it.
>>>
>>>
>> To help understand, is "math being column major" referring to matrix
>> operations in math textbooks are done by columns?  For example:
>>
>>
>> http://eli.thegreenplace.net/2015/visualizing-matrix-multiplication-as-a-linear-combination/
>>
>> While the order is by convention (eg not that is has to be that way),
>> this is how people are taught.
>>
>> Glen
>>
>

Re: [julia-users] Re: typealias vs. const

[Tomas Lycken]

> `const A = T` is what `typealias A T` lowered to when it doesn't 
have type parameters

I wanted to inspect the output of this lowering pass, but `@code_lowered` 
was apparently not what I was looking for (at least, `@code_lowered 
:(typealias Foo Int)` didn't work...).

However, I understand your statement as follows:

`typealias A T` is equivalent to `const A = T`, while `typealias A{S} T{S}` 
does something more involved? What does `typealias A{S} T{Foo,S}` do? I 
assume these are not possible using `const  = ` constructs, right?

// T 

On Friday, October 30, 2015 at 1:45:37 PM UTC+1, Yichao Yu wrote:
>
> On Fri, Oct 30, 2015 at 8:29 AM, FANG Colin  > wrote: 
> > I have got the same confusion. Any ideas? 
> > 
> > I have even seen usage of A = T (no const) 
> > (http://docs.julialang.org/en/release-0.4/manual/types/#type-unions), 
> is it 
> > supposed to be bad (slow) because it is a global variable? 
> > 
>
> no const will have performance issue since it's a global. 
> `const A = T` is what `typealias A T` lowered to when it doesn't have 
> type parameters. In this case, it's just a matter of style. Being 
> consistent within a file is probably better but you can pick whichever 
> you prefer. 
>
> > 
> > 
> > On Thursday, November 6, 2014 at 3:38:41 PM UTC, Steven G. Johnson 
> wrote: 
> >> 
> >> Given a type T, what is the difference in practice between 
> >>  typealias A T 
> >> and 
> >>  const A = T 
> >> ? 
> >> 
> >> There seems to be some disagreement over which one to use (e.g. 
> >> 
> https://github.com/JuliaLang/Compat.jl/commit/8211e38ac7d8448298a2bb3ab36d6f0b6398b577).
>  
>
> >> 
> >> My impression is that there is no difference, and that the only 
> advantage 
> >> of a typealias is that it can be parameterized.  Is that right? 
> >> 
> >> If they are equivalent, what is the Julian style?  Even in Julia Base 
> it 
> >> doesn't seem to be entirely consistent. 
>

Re: [julia-users] Re: A grateful scientist

[John Gibson]

I'll join in here as well. For years I've seen the mess associated with 
existing languages like C, C++, and Fortran as a very substantial 
impediment to students developing professional-level expertise in 
scientific computation, and in fact I've shied away from trying to teach 
what I know, because there's so much tedious overhead. 

But all of a sudden, I have a language I feel good about teaching, which my 
students like learning, and which won't limit them in the long run. As 
gentle a learning curve as Matlab, as general-purpose as Python, as 
powerful as Lisp, and as fast as C. And free. It's a totally winning 
combination. 

Since attending JuliaCon2015 this summer I have transitioned my graduate 
numerical linear algebra course at U New Hampshire to Julia. I'll do 
undergrad numerical methods in Julia next fall, and over the next year or 
so I'll try to convince relevant departments that Julia belongs in our 
freshman/sophomore level intro to engineering computing courses. 

Many, many thanks to the Julia team for recognizing the need for a better 
language, and then for designing and implementing it so well. I'm really 
grateful.

John


On Friday, October 30, 2015 at 12:52:11 PM UTC-4, Jonathan Malmaud wrote:
>
> Thanks Eric! 
>
> On Thu, Oct 29, 2015 at 9:31 PM Eric Forgy  > wrote:
>
>> Hi Jonathan,
>>
>> I'm in the same boat as a grateful scientist/entrepreneur and thank all 
>> the Julia developers, but since we're at it, I want to say a special "Thank 
>> you" to YOU for all the work you've done on JuliaWeb. Requests.jl, in 
>> particular, is making my life much easier. It's become an invaluable tool 
>> for my team for testing our APIs (and I've learned a lot by watching the 
>> incremental improvements). We are still building up our Julia skills and 
>> hope we can start contributing back as well.
>>
>> On Wednesday, October 28, 2015 at 8:26:07 AM UTC+8, Jonathan Malmaud 
>> wrote:
>>>
>>> As someone who volunteers my free time to developing Julia, it means a 
>>> lot to hear that. 
>>
>>

[julia-users] Base.backtrace() returning different results in 32-bit Windows builds (inlining issue?)

[Gem Newman]

I've been developing StackTraces.jl 
 to provide easy to use, 
programmatically accessible stack traces in Julia.

After some fiddling with @noinline and --inline=no (which have obvious 
implications for comparing stack traces), test cases pass for 0.4 and 
nightly on Linux, Mac, and Win64, but still fail for Win32. I don't have 
easy access to a 32-bit Windows instance and have limited time to explore 
the issue further, but my best guess is that there is an issue with simple 
functions being inlined despite both the @noinline macro and the 
--inline=no flag being used. Unit tests are written using FactCheck.jl.

You can see the build here: 
https://ci.appveyor.com/project/spurll/stacktraces-jl/build/1.0.10

The relevant test code:

@noinline child() = stacktrace()
@noinline parent() = child()
@noinline grandparent() = parent()
...
facts() do
context("basic") do
 stack = grandparent()
@fact stack[1:3] --> [
StackFrame(:child, @__FILE__, 5, Symbol(""), -1, false),
StackFrame(:parent, @__FILE__, 6, Symbol(""), -1, false),
StackFrame(:grandparent, @__FILE__, 7, Symbol(""), -1, false)
]
end

...
end

A relevant snippet:

> basic 
Failure :: (line:-1) :: basic :: fact was false 
  Expression: stack[1:3] --> [StackFrame(:child,@__FILE__(),5,Symbol(""
),-1,false),StackFrame(:parent,@__FILE__(),6,Symbol(""),-1,false),StackFrame
(:grandparent,@__FILE__(),7,Symbol(""),-1,false)] 
Expected: [StackTraces.StackFrame(:child,symbol(
"C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),5,
symbol(""),-1,false),StackTraces.StackFrame(:parent,symbol(
"C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),6,
symbol(""),-1,false),StackTraces.StackFrame(:grandparent,symbol(
"C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),7,
symbol(""),-1,false)] 
Occurred: [StackTraces.StackFrame(:backtrace,symbol("error.jl"),26,
symbol(""),-1,false),StackTraces.StackFrame(:anonymous,symbol(
"C:\\Users\\appveyor\\.julia\\v0.4\\StackTraces\\test\\runtests.jl"),25,
symbol(""),-1,false),StackTraces.StackFrame(:context,symbol(
"C:\\Users\\appveyor\\.julia\\v0.4\\FactCheck\\src\\FactCheck.jl"),474,
symbol(""),-1,false)] 

Other relevant information: the stacktrace function erases its own stack 
frame from the stack trace before returning it (along with all other 
"deeper" stack frames that appear while generating the stack trace). I 
expect the stack trace to look like this:

C functions (stacktrace removes these by default)
Base.backtrace (removed along with stacktrace)
StackTraces.stacktrace (removed before the trace is returned)
child
parent
grandparent
anonymous function that calls grandparent
FactCheck.context

Instead we see this:

C functions (presumably present but removed by stacktrace)
Base.backtrace (not removed!)
anonymous function that calls grandparent
FactCheck.context

So it appears that my test cases are calling Base.backtrace directly 
(perhaps due to some aggressive inlining). My guess is that Base.backtrace 
doesn't get removed because StackTraces.stacktrace doesn't see itself on 
the stack.

(I suppose it's also possible that there is an issue with FactCheck.jl, but 
I'm not sure.)

Re: [julia-users] Package requirements and pinning

[Tom Breloff]

Ok thanks Yichao.  I'll have to think on all this a little while to suggest
changes to the documentation.

Back to the original post... I heard a rumor that there is discussion
underway about making changes to how packages and METADATA work.  I've only
been involved on the periphery... are there issues or PRs where future
METADATA design is being discussed?

On Fri, Oct 30, 2015 at 12:55 PM, Yichao Yu  wrote:

> On Fri, Oct 30, 2015 at 12:26 PM, Tom Breloff  wrote:
> > Huh... that's something I didn't know.  What's the environment
> variable?  Is
> > that documented?
>
> It is documented here[1]. It is a little hard to find  (I didn't
> remember that it was and figured out by checking the pkg.jl test in
> base julia.). Suggestions or PR about how to make it more
> discoverable are welcome.
>
> [1]
> http://julia.readthedocs.org/en/latest/stdlib/pkg/?highlight=julia_pkgdir
>
> >
> > On Fri, Oct 30, 2015 at 12:24 PM, Yichao Yu  wrote:
> >>
> >> On Fri, Oct 30, 2015 at 12:13 PM, Tom Breloff  wrote:
> >> > In this case, Plots doesn't actually depend on Gadfly at all... it's
> an
> >> > optional dependency.  (I only added it to the require to test what
> might
> >> > happen)  However in the general case it's really tricky if the only
> >> > "real"
> >> > solution is "fix the package so the restriction isn't necessary".
> >> >
> >> > What if a user installs a package that requires an old version of
> >> > StatsBase
> >> > (say, before some change to the interface).  Then if the user has 10
> >> > other
> >> > packages which all expect a more recent version of StatsBase, they
> will
> >> > all
> >> > break (or Pkg will generate an error if any of the version
> dependencies
> >> > in
> >> > REQUIRE were properly written).  The user may never use those packages
> >> > in
> >> > the same julia session, but because the package states are shared
> among
> >> > all
> >> > 0.4 versions of Julia (there's only one ~/.julia/v0.4 directory),
> he/she
> >> > cannot keep that package installed.  There's got to be a better
> >> > solution.
> >>
> >> You can change this directory with environment variable
> >>
> >> >
> >> > Of course, a better error message would be helpful too.
> >> >
> >> > On Fri, Oct 30, 2015 at 11:50 AM, Yichao Yu 
> wrote:
> >> >>
> >> >> On Fri, Oct 30, 2015 at 11:30 AM, Tom Breloff 
> wrote:
> >> >> > Ok, I tried that out, and you're right that I get an error (it
> didn't
> >> >> > fallback to an older version, unless maybe that would happen with
> >> >> > Pkg.update()?)
> >> >> >
> >> >> >
> >> >> > julia> Pkg.resolve()
> >> >> > ERROR: unsatisfiable package requirements detected: no feasible
> >> >> > version
> >> >> > could be found for package: Gadfly
> >> >> >  in error at ./error.jl:21
> >> >> >  in resolve at ./pkg/resolve.jl:37
> >> >> >  in resolve at ./pkg/entry.jl:422
> >> >> >  in resolve at pkg/entry.jl:404
> >> >> >  in anonymous at pkg/dir.jl:31
> >> >> >  in cd at file.jl:22
> >> >> >  in cd at pkg/dir.jl:31
> >> >> >  in resolve at pkg.jl:46
> >> >> >
> >> >> > julia>
> >> >> > [tom@tomoffice Plots]$ cat REQUIRE
> >> >> > julia 0.3
> >> >> >
> >> >> > Colors
> >> >> > Reexport
> >> >> > Compat
> >> >> > Gadfly 0.3.18
> >> >> >
> >> >> > How should I go about rectifying this error?  In this case I know
> >> >> > that
> >> >> > the
> >> >> > requirement clash is with Immerse (which has "Gadfly 0.3.16 0.3.17"
> >> >> > in
> >> >> > its
> >> >> > require file), but if a user sees this error they would likely be
> >> >> > lost.
> >> >> > I
> >> >> > fear that there's not a good solution once a single package has
> >> >> > special
> >> >> > requirements.
> >> >> >
> >> >>
> >> >> We could probably print out the actual conflicting requirements and
> >> >> where they are coming from. This should help the user to know where
> to
> >> >> look (or which package to blame)
> >> >>
> >> >> IMHO, for this particular conflict, the best solution would be to fix
> >> >> Immerse to work with newer version of Gadfly. Or if you need it now,
> >> >> maybe try to pin Plots down to an earlier version that doesn't
> require
> >> >> Gadfly 0.3.18 (if it has one of course).
> >> >>
> >> >> >
> >> >> > On Friday, October 30, 2015 at 11:15:52 AM UTC-4, Yichao Yu wrote:
> >> >> >>
> >> >> >> On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu 
> >> >> >> wrote:
> >> >> >> > On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff  >
> >> >> >> > wrote:
> >> >> >> >> Thanks... after reading through that again, let me adjust my
> >> >> >> >> scenario:
> >> >> >> >>
> >> >> >> >> Package A's require:
> >> >> >> >>
> >> >> >> >> julia 0.4
> >> >> >> >> C 0.1 0.2-
> >> >> >> >>
> >> >> >> >> Package B's require:
> >> >> >> >>
> >> >> >> >> julia 0.4
> >> >> >> >> C 0.3
> >> >> >> >>
> >> >> >> >> What version of C is installed?  Package A want any version
> >> >> >> >> 0.1.x,
> >> >> >> >> Package B
> >> >> >> >> wants any version 0.3.x or greater.  Who "wins"?
> >> >> >>
> >> >> >> Or fallback to an older version of one of them th

Re: [julia-users] Does anyone have a fork/branch of Sundials.jl that works on 0.4/0.5?

[Jonathan Goldfarb]

For anyone following along at home, the branch in question is now updated 
with wrapper functions recreated so the tests should now pass.

Regards,

Max

On Wednesday, October 28, 2015 at 8:30:09 AM UTC-4, Alex wrote:
>
> Hi Simon,
>
> Christian Haargaard just created a PR (
> https://github.com/JuliaLang/Sundials.jl/pull/56), which means that there 
> is now (or should be) a working branch.
>
> May I ask what you mean by "minor API differences"? 
>
> Best,
>
> Alex.
>
> On Saturday, 17 October 2015 10:58:10 UTC+2, Simon Frost wrote:
>
>> Dear Mauro,
>>
>> I think the fixes, at least for cvode, have already been done in one of 
>> the branches, but there isn't a PR yet. Apart from some minor API 
>> differences, which hopefully will be ironed out in the future, cvode in 
>> Sundials.jl is a lot faster than ode23s in ODE.jl.
>>
>> Best
>> Simon
>>
>

Re: [julia-users] Package requirements and pinning

[Yichao Yu]

On Fri, Oct 30, 2015 at 12:26 PM, Tom Breloff  wrote:
> Huh... that's something I didn't know.  What's the environment variable?  Is
> that documented?

It is documented here[1]. It is a little hard to find  (I didn't
remember that it was and figured out by checking the pkg.jl test in
base julia.). Suggestions or PR about how to make it more
discoverable are welcome.

[1] http://julia.readthedocs.org/en/latest/stdlib/pkg/?highlight=julia_pkgdir

>
> On Fri, Oct 30, 2015 at 12:24 PM, Yichao Yu  wrote:
>>
>> On Fri, Oct 30, 2015 at 12:13 PM, Tom Breloff  wrote:
>> > In this case, Plots doesn't actually depend on Gadfly at all... it's an
>> > optional dependency.  (I only added it to the require to test what might
>> > happen)  However in the general case it's really tricky if the only
>> > "real"
>> > solution is "fix the package so the restriction isn't necessary".
>> >
>> > What if a user installs a package that requires an old version of
>> > StatsBase
>> > (say, before some change to the interface).  Then if the user has 10
>> > other
>> > packages which all expect a more recent version of StatsBase, they will
>> > all
>> > break (or Pkg will generate an error if any of the version dependencies
>> > in
>> > REQUIRE were properly written).  The user may never use those packages
>> > in
>> > the same julia session, but because the package states are shared among
>> > all
>> > 0.4 versions of Julia (there's only one ~/.julia/v0.4 directory), he/she
>> > cannot keep that package installed.  There's got to be a better
>> > solution.
>>
>> You can change this directory with environment variable
>>
>> >
>> > Of course, a better error message would be helpful too.
>> >
>> > On Fri, Oct 30, 2015 at 11:50 AM, Yichao Yu  wrote:
>> >>
>> >> On Fri, Oct 30, 2015 at 11:30 AM, Tom Breloff  wrote:
>> >> > Ok, I tried that out, and you're right that I get an error (it didn't
>> >> > fallback to an older version, unless maybe that would happen with
>> >> > Pkg.update()?)
>> >> >
>> >> >
>> >> > julia> Pkg.resolve()
>> >> > ERROR: unsatisfiable package requirements detected: no feasible
>> >> > version
>> >> > could be found for package: Gadfly
>> >> >  in error at ./error.jl:21
>> >> >  in resolve at ./pkg/resolve.jl:37
>> >> >  in resolve at ./pkg/entry.jl:422
>> >> >  in resolve at pkg/entry.jl:404
>> >> >  in anonymous at pkg/dir.jl:31
>> >> >  in cd at file.jl:22
>> >> >  in cd at pkg/dir.jl:31
>> >> >  in resolve at pkg.jl:46
>> >> >
>> >> > julia>
>> >> > [tom@tomoffice Plots]$ cat REQUIRE
>> >> > julia 0.3
>> >> >
>> >> > Colors
>> >> > Reexport
>> >> > Compat
>> >> > Gadfly 0.3.18
>> >> >
>> >> > How should I go about rectifying this error?  In this case I know
>> >> > that
>> >> > the
>> >> > requirement clash is with Immerse (which has "Gadfly 0.3.16 0.3.17"
>> >> > in
>> >> > its
>> >> > require file), but if a user sees this error they would likely be
>> >> > lost.
>> >> > I
>> >> > fear that there's not a good solution once a single package has
>> >> > special
>> >> > requirements.
>> >> >
>> >>
>> >> We could probably print out the actual conflicting requirements and
>> >> where they are coming from. This should help the user to know where to
>> >> look (or which package to blame)
>> >>
>> >> IMHO, for this particular conflict, the best solution would be to fix
>> >> Immerse to work with newer version of Gadfly. Or if you need it now,
>> >> maybe try to pin Plots down to an earlier version that doesn't require
>> >> Gadfly 0.3.18 (if it has one of course).
>> >>
>> >> >
>> >> > On Friday, October 30, 2015 at 11:15:52 AM UTC-4, Yichao Yu wrote:
>> >> >>
>> >> >> On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu 
>> >> >> wrote:
>> >> >> > On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff 
>> >> >> > wrote:
>> >> >> >> Thanks... after reading through that again, let me adjust my
>> >> >> >> scenario:
>> >> >> >>
>> >> >> >> Package A's require:
>> >> >> >>
>> >> >> >> julia 0.4
>> >> >> >> C 0.1 0.2-
>> >> >> >>
>> >> >> >> Package B's require:
>> >> >> >>
>> >> >> >> julia 0.4
>> >> >> >> C 0.3
>> >> >> >>
>> >> >> >> What version of C is installed?  Package A want any version
>> >> >> >> 0.1.x,
>> >> >> >> Package B
>> >> >> >> wants any version 0.3.x or greater.  Who "wins"?
>> >> >>
>> >> >> Or fallback to an older version of one of them that don't conflict.
>> >> >>
>> >> >> >
>> >> >> > I'd be surprised if you don't get an error.
>> >> >> >
>> >> >> >>
>> >> >> >> On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu 
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff 
>> >> >> >>> wrote:
>> >> >> >>> > I'm very confused about how Pkg resolution works in 0.4, and I
>> >> >> >>> > couldn't
>> >> >> >>> > find
>> >> >> >>> > a definitive source of details.  If package A has the REQUIRE
>> >> >> >>> > file:
>> >> >> >>> >
>> >> >> >>> > julia 0.4
>> >> >> >>> > C 0.1
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>> This means version 0.1 or higher for C
>> >> >> >>>
>> >> >> >>> >
>> >> 

Re: [julia-users] Re: A grateful scientist

[Jonathan Malmaud]

Thanks Eric!

On Thu, Oct 29, 2015 at 9:31 PM Eric Forgy  wrote:

> Hi Jonathan,
>
> I'm in the same boat as a grateful scientist/entrepreneur and thank all
> the Julia developers, but since we're at it, I want to say a special "Thank
> you" to YOU for all the work you've done on JuliaWeb. Requests.jl, in
> particular, is making my life much easier. It's become an invaluable tool
> for my team for testing our APIs (and I've learned a lot by watching the
> incremental improvements). We are still building up our Julia skills and
> hope we can start contributing back as well.
>
> On Wednesday, October 28, 2015 at 8:26:07 AM UTC+8, Jonathan Malmaud wrote:
>>
>> As someone who volunteers my free time to developing Julia, it means a
>> lot to hear that.
>
>

Re: [julia-users] Package requirements and pinning

[Tom Breloff]

Huh... that's something I didn't know.  What's the environment variable?
Is that documented?

On Fri, Oct 30, 2015 at 12:24 PM, Yichao Yu  wrote:

> On Fri, Oct 30, 2015 at 12:13 PM, Tom Breloff  wrote:
> > In this case, Plots doesn't actually depend on Gadfly at all... it's an
> > optional dependency.  (I only added it to the require to test what might
> > happen)  However in the general case it's really tricky if the only
> "real"
> > solution is "fix the package so the restriction isn't necessary".
> >
> > What if a user installs a package that requires an old version of
> StatsBase
> > (say, before some change to the interface).  Then if the user has 10
> other
> > packages which all expect a more recent version of StatsBase, they will
> all
> > break (or Pkg will generate an error if any of the version dependencies
> in
> > REQUIRE were properly written).  The user may never use those packages in
> > the same julia session, but because the package states are shared among
> all
> > 0.4 versions of Julia (there's only one ~/.julia/v0.4 directory), he/she
> > cannot keep that package installed.  There's got to be a better solution.
>
> You can change this directory with environment variable
>
> >
> > Of course, a better error message would be helpful too.
> >
> > On Fri, Oct 30, 2015 at 11:50 AM, Yichao Yu  wrote:
> >>
> >> On Fri, Oct 30, 2015 at 11:30 AM, Tom Breloff  wrote:
> >> > Ok, I tried that out, and you're right that I get an error (it didn't
> >> > fallback to an older version, unless maybe that would happen with
> >> > Pkg.update()?)
> >> >
> >> >
> >> > julia> Pkg.resolve()
> >> > ERROR: unsatisfiable package requirements detected: no feasible
> version
> >> > could be found for package: Gadfly
> >> >  in error at ./error.jl:21
> >> >  in resolve at ./pkg/resolve.jl:37
> >> >  in resolve at ./pkg/entry.jl:422
> >> >  in resolve at pkg/entry.jl:404
> >> >  in anonymous at pkg/dir.jl:31
> >> >  in cd at file.jl:22
> >> >  in cd at pkg/dir.jl:31
> >> >  in resolve at pkg.jl:46
> >> >
> >> > julia>
> >> > [tom@tomoffice Plots]$ cat REQUIRE
> >> > julia 0.3
> >> >
> >> > Colors
> >> > Reexport
> >> > Compat
> >> > Gadfly 0.3.18
> >> >
> >> > How should I go about rectifying this error?  In this case I know that
> >> > the
> >> > requirement clash is with Immerse (which has "Gadfly 0.3.16 0.3.17" in
> >> > its
> >> > require file), but if a user sees this error they would likely be
> lost.
> >> > I
> >> > fear that there's not a good solution once a single package has
> special
> >> > requirements.
> >> >
> >>
> >> We could probably print out the actual conflicting requirements and
> >> where they are coming from. This should help the user to know where to
> >> look (or which package to blame)
> >>
> >> IMHO, for this particular conflict, the best solution would be to fix
> >> Immerse to work with newer version of Gadfly. Or if you need it now,
> >> maybe try to pin Plots down to an earlier version that doesn't require
> >> Gadfly 0.3.18 (if it has one of course).
> >>
> >> >
> >> > On Friday, October 30, 2015 at 11:15:52 AM UTC-4, Yichao Yu wrote:
> >> >>
> >> >> On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu 
> wrote:
> >> >> > On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff 
> >> >> > wrote:
> >> >> >> Thanks... after reading through that again, let me adjust my
> >> >> >> scenario:
> >> >> >>
> >> >> >> Package A's require:
> >> >> >>
> >> >> >> julia 0.4
> >> >> >> C 0.1 0.2-
> >> >> >>
> >> >> >> Package B's require:
> >> >> >>
> >> >> >> julia 0.4
> >> >> >> C 0.3
> >> >> >>
> >> >> >> What version of C is installed?  Package A want any version 0.1.x,
> >> >> >> Package B
> >> >> >> wants any version 0.3.x or greater.  Who "wins"?
> >> >>
> >> >> Or fallback to an older version of one of them that don't conflict.
> >> >>
> >> >> >
> >> >> > I'd be surprised if you don't get an error.
> >> >> >
> >> >> >>
> >> >> >> On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu 
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff 
> >> >> >>> wrote:
> >> >> >>> > I'm very confused about how Pkg resolution works in 0.4, and I
> >> >> >>> > couldn't
> >> >> >>> > find
> >> >> >>> > a definitive source of details.  If package A has the REQUIRE
> >> >> >>> > file:
> >> >> >>> >
> >> >> >>> > julia 0.4
> >> >> >>> > C 0.1
> >> >> >>> >
> >> >> >>>
> >> >> >>> This means version 0.1 or higher for C
> >> >> >>>
> >> >> >>> >
> >> >> >>> > and package B has the REQUIRE file:
> >> >> >>> >
> >> >> >>> > julia 0.4
> >> >> >>> > C 0.2
> >> >> >>> >
> >> >> >>>
> >> >> >>> This means version 0.2 or higher for C
> >> >> >>>
> >> >> >>> >
> >> >> >>> > which version of C is installed?  Does it change if you do a
> >> >> >>> > Pkg.add("C")?
> >> >> >>> > What determines which package "wins"?
> >> >> >>>
> >> >> >>> The latest available that is compatible with everything else.
> >> >> >>>
> >> >> >>> Note to specify the upper bound, use `C lower_version
> >> >> >>> upper_version`
> >> >> >>>
> >

Re: [julia-users] Re: Order of multiple for-loops

[Tom Breloff]

Preference for row ordering is more related to the way people view tabular
data, I think.  For many applications/data, there are many more rows than
columns (think of database tables or csv files), and it's slightly
unnatural to read those into a transposed data structure for analysis.
Putting a time series into a TxN matrix is natural (that's likely how the
data is stored), but inefficient if data access is sequentially through
time.  Without a "TransposeView" or similar, we're forced to make a choice
between poor performance or an unintuitive representation of the data.

I can appreciate that matrix operations could be more natural with column
ordering, but in my experience practical applications favor row ordering.

On Fri, Oct 30, 2015 at 11:44 AM, John Gibson  wrote:

> Agreed w Glenn H here. "math being column major" is because the range of a
> matrix being the span of its columns, and consequently most linear algebra
> algorithms are naturally expressed as operations on the columns of the
> matrix, for example QR decomp via Gramm-Schmidt or Householder, LU without
> pivoting, all Krylov subspace methods. An exception would be LU with full
> or partial row pivoting.
>
> I think preference for row-ordering comes from the fact that the textbook
> presentation of matrix-vector multiply is given as computing y(i)= sum_j
> A(i,j) x(j) for each value of i. Ordering the operations that way would
> make row-ordering of A cache-friendly. But if instead you understand
> mat-vec mult as forming a linear combination of the columns of A, and you
> do the computation via y = sum_j A(:,j) x(j), column-ordering is
> cache-friendly. And it's the latter version that generalizes into all the
> important linear algebra algorithms.
>
> John
>
>
> On Friday, October 30, 2015 at 10:46:36 AM UTC-4, Glen H wrote:
>>
>>
>> On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski wrote:
>>>
>>> Yes, this is an unfortunate consequence of mathematics being
>>> column-major – oh how I wish it weren't so. The storage order is actually
>>> largely irrelevant, the whole issue stems from the fact that the element in
>>> the ith row and the jth column of a matrix is indexes as A[i,j]. If it were
>>> A[j,i] then these would agree (and many things would be simpler). I like
>>> your explanation of "an index closer to the expression to be evaluated
>>> runs faster" – that's a really good way to remember/explain it.
>>>
>>>
>> To help understand, is "math being column major" referring to matrix
>> operations in math textbooks are done by columns?  For example:
>>
>>
>> http://eli.thegreenplace.net/2015/visualizing-matrix-multiplication-as-a-linear-combination/
>>
>> While the order is by convention (eg not that is has to be that way),
>> this is how people are taught.
>>
>> Glen
>>
>

Re: [julia-users] Package requirements and pinning

[Yichao Yu]

On Fri, Oct 30, 2015 at 12:13 PM, Tom Breloff  wrote:
> In this case, Plots doesn't actually depend on Gadfly at all... it's an
> optional dependency.  (I only added it to the require to test what might
> happen)  However in the general case it's really tricky if the only "real"
> solution is "fix the package so the restriction isn't necessary".
>
> What if a user installs a package that requires an old version of StatsBase
> (say, before some change to the interface).  Then if the user has 10 other
> packages which all expect a more recent version of StatsBase, they will all
> break (or Pkg will generate an error if any of the version dependencies in
> REQUIRE were properly written).  The user may never use those packages in
> the same julia session, but because the package states are shared among all
> 0.4 versions of Julia (there's only one ~/.julia/v0.4 directory), he/she
> cannot keep that package installed.  There's got to be a better solution.

You can change this directory with environment variable

>
> Of course, a better error message would be helpful too.
>
> On Fri, Oct 30, 2015 at 11:50 AM, Yichao Yu  wrote:
>>
>> On Fri, Oct 30, 2015 at 11:30 AM, Tom Breloff  wrote:
>> > Ok, I tried that out, and you're right that I get an error (it didn't
>> > fallback to an older version, unless maybe that would happen with
>> > Pkg.update()?)
>> >
>> >
>> > julia> Pkg.resolve()
>> > ERROR: unsatisfiable package requirements detected: no feasible version
>> > could be found for package: Gadfly
>> >  in error at ./error.jl:21
>> >  in resolve at ./pkg/resolve.jl:37
>> >  in resolve at ./pkg/entry.jl:422
>> >  in resolve at pkg/entry.jl:404
>> >  in anonymous at pkg/dir.jl:31
>> >  in cd at file.jl:22
>> >  in cd at pkg/dir.jl:31
>> >  in resolve at pkg.jl:46
>> >
>> > julia>
>> > [tom@tomoffice Plots]$ cat REQUIRE
>> > julia 0.3
>> >
>> > Colors
>> > Reexport
>> > Compat
>> > Gadfly 0.3.18
>> >
>> > How should I go about rectifying this error?  In this case I know that
>> > the
>> > requirement clash is with Immerse (which has "Gadfly 0.3.16 0.3.17" in
>> > its
>> > require file), but if a user sees this error they would likely be lost.
>> > I
>> > fear that there's not a good solution once a single package has special
>> > requirements.
>> >
>>
>> We could probably print out the actual conflicting requirements and
>> where they are coming from. This should help the user to know where to
>> look (or which package to blame)
>>
>> IMHO, for this particular conflict, the best solution would be to fix
>> Immerse to work with newer version of Gadfly. Or if you need it now,
>> maybe try to pin Plots down to an earlier version that doesn't require
>> Gadfly 0.3.18 (if it has one of course).
>>
>> >
>> > On Friday, October 30, 2015 at 11:15:52 AM UTC-4, Yichao Yu wrote:
>> >>
>> >> On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu  wrote:
>> >> > On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff 
>> >> > wrote:
>> >> >> Thanks... after reading through that again, let me adjust my
>> >> >> scenario:
>> >> >>
>> >> >> Package A's require:
>> >> >>
>> >> >> julia 0.4
>> >> >> C 0.1 0.2-
>> >> >>
>> >> >> Package B's require:
>> >> >>
>> >> >> julia 0.4
>> >> >> C 0.3
>> >> >>
>> >> >> What version of C is installed?  Package A want any version 0.1.x,
>> >> >> Package B
>> >> >> wants any version 0.3.x or greater.  Who "wins"?
>> >>
>> >> Or fallback to an older version of one of them that don't conflict.
>> >>
>> >> >
>> >> > I'd be surprised if you don't get an error.
>> >> >
>> >> >>
>> >> >> On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu 
>> >> >> wrote:
>> >> >>>
>> >> >>> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff 
>> >> >>> wrote:
>> >> >>> > I'm very confused about how Pkg resolution works in 0.4, and I
>> >> >>> > couldn't
>> >> >>> > find
>> >> >>> > a definitive source of details.  If package A has the REQUIRE
>> >> >>> > file:
>> >> >>> >
>> >> >>> > julia 0.4
>> >> >>> > C 0.1
>> >> >>> >
>> >> >>>
>> >> >>> This means version 0.1 or higher for C
>> >> >>>
>> >> >>> >
>> >> >>> > and package B has the REQUIRE file:
>> >> >>> >
>> >> >>> > julia 0.4
>> >> >>> > C 0.2
>> >> >>> >
>> >> >>>
>> >> >>> This means version 0.2 or higher for C
>> >> >>>
>> >> >>> >
>> >> >>> > which version of C is installed?  Does it change if you do a
>> >> >>> > Pkg.add("C")?
>> >> >>> > What determines which package "wins"?
>> >> >>>
>> >> >>> The latest available that is compatible with everything else.
>> >> >>>
>> >> >>> Note to specify the upper bound, use `C lower_version
>> >> >>> upper_version`
>> >> >>>
>> >> >>> >
>> >> >>> > Bonus question: can someone point me to documentation on exactly
>> >> >>> > what
>> >> >>> > the
>> >> >>> > plus/minus mean?  What's the difference between `0.1`, `0.1-`,
>> >> >>> > and
>> >> >>> > `0.1+`?
>> >> >>>
>> >> >>> - and + are for prerelease and build
>> >> >>>
>> >> >>> ```
>> >> >>> julia> v"0.1-2+3".prerelease
>> >> >>> (2,)
>> >> >>>
>> >> >>> julia> v"0.1-2+3".build
>> >> >>> (3,)
>> >> >

Re: [julia-users] Package requirements and pinning

[Tom Breloff]

In this case, Plots doesn't actually depend on Gadfly at all... it's an
optional dependency.  (I only added it to the require to test what might
happen)  However in the general case it's really tricky if the only "real"
solution is "fix the package so the restriction isn't necessary".

What if a user installs a package that requires an old version of StatsBase
(say, before some change to the interface).  Then if the user has 10 other
packages which all expect a more recent version of StatsBase, they will all
break (or Pkg will generate an error if any of the version dependencies in
REQUIRE were properly written).  The user may never use those packages in
the same julia session, but because the package states are shared among all
0.4 versions of Julia (there's only one ~/.julia/v0.4 directory), he/she
cannot keep that package installed.  There's got to be a better solution.

Of course, a better error message would be helpful too.

On Fri, Oct 30, 2015 at 11:50 AM, Yichao Yu  wrote:

> On Fri, Oct 30, 2015 at 11:30 AM, Tom Breloff  wrote:
> > Ok, I tried that out, and you're right that I get an error (it didn't
> > fallback to an older version, unless maybe that would happen with
> > Pkg.update()?)
> >
> >
> > julia> Pkg.resolve()
> > ERROR: unsatisfiable package requirements detected: no feasible version
> > could be found for package: Gadfly
> >  in error at ./error.jl:21
> >  in resolve at ./pkg/resolve.jl:37
> >  in resolve at ./pkg/entry.jl:422
> >  in resolve at pkg/entry.jl:404
> >  in anonymous at pkg/dir.jl:31
> >  in cd at file.jl:22
> >  in cd at pkg/dir.jl:31
> >  in resolve at pkg.jl:46
> >
> > julia>
> > [tom@tomoffice Plots]$ cat REQUIRE
> > julia 0.3
> >
> > Colors
> > Reexport
> > Compat
> > Gadfly 0.3.18
> >
> > How should I go about rectifying this error?  In this case I know that
> the
> > requirement clash is with Immerse (which has "Gadfly 0.3.16 0.3.17" in
> its
> > require file), but if a user sees this error they would likely be lost.
> I
> > fear that there's not a good solution once a single package has special
> > requirements.
> >
>
> We could probably print out the actual conflicting requirements and
> where they are coming from. This should help the user to know where to
> look (or which package to blame)
>
> IMHO, for this particular conflict, the best solution would be to fix
> Immerse to work with newer version of Gadfly. Or if you need it now,
> maybe try to pin Plots down to an earlier version that doesn't require
> Gadfly 0.3.18 (if it has one of course).
>
> >
> > On Friday, October 30, 2015 at 11:15:52 AM UTC-4, Yichao Yu wrote:
> >>
> >> On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu  wrote:
> >> > On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff 
> wrote:
> >> >> Thanks... after reading through that again, let me adjust my
> scenario:
> >> >>
> >> >> Package A's require:
> >> >>
> >> >> julia 0.4
> >> >> C 0.1 0.2-
> >> >>
> >> >> Package B's require:
> >> >>
> >> >> julia 0.4
> >> >> C 0.3
> >> >>
> >> >> What version of C is installed?  Package A want any version 0.1.x,
> >> >> Package B
> >> >> wants any version 0.3.x or greater.  Who "wins"?
> >>
> >> Or fallback to an older version of one of them that don't conflict.
> >>
> >> >
> >> > I'd be surprised if you don't get an error.
> >> >
> >> >>
> >> >> On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu 
> wrote:
> >> >>>
> >> >>> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff 
> >> >>> wrote:
> >> >>> > I'm very confused about how Pkg resolution works in 0.4, and I
> >> >>> > couldn't
> >> >>> > find
> >> >>> > a definitive source of details.  If package A has the REQUIRE
> file:
> >> >>> >
> >> >>> > julia 0.4
> >> >>> > C 0.1
> >> >>> >
> >> >>>
> >> >>> This means version 0.1 or higher for C
> >> >>>
> >> >>> >
> >> >>> > and package B has the REQUIRE file:
> >> >>> >
> >> >>> > julia 0.4
> >> >>> > C 0.2
> >> >>> >
> >> >>>
> >> >>> This means version 0.2 or higher for C
> >> >>>
> >> >>> >
> >> >>> > which version of C is installed?  Does it change if you do a
> >> >>> > Pkg.add("C")?
> >> >>> > What determines which package "wins"?
> >> >>>
> >> >>> The latest available that is compatible with everything else.
> >> >>>
> >> >>> Note to specify the upper bound, use `C lower_version upper_version`
> >> >>>
> >> >>> >
> >> >>> > Bonus question: can someone point me to documentation on exactly
> >> >>> > what
> >> >>> > the
> >> >>> > plus/minus mean?  What's the difference between `0.1`, `0.1-`, and
> >> >>> > `0.1+`?
> >> >>>
> >> >>> - and + are for prerelease and build
> >> >>>
> >> >>> ```
> >> >>> julia> v"0.1-2+3".prerelease
> >> >>> (2,)
> >> >>>
> >> >>> julia> v"0.1-2+3".build
> >> >>> (3,)
> >> >>> ```
> >> >>>
> >> >>> >
> >> >>> > Bonus question: how does the logic change with the new package
> >> >>> > manager?
> >> >>> > (if
> >> >>> > at all)
> >> >>>
> >> >>> nothing
> >> >>>
> >> >>> >
> >> >>> > Bonus question: is there an open issue/PR that discusses potential
> >> >>> > future
> >> >>> > changes to METADA

Re: [julia-users] Package requirements and pinning

[Yichao Yu]

On Fri, Oct 30, 2015 at 11:30 AM, Tom Breloff  wrote:
> Ok, I tried that out, and you're right that I get an error (it didn't
> fallback to an older version, unless maybe that would happen with
> Pkg.update()?)
>
>
> julia> Pkg.resolve()
> ERROR: unsatisfiable package requirements detected: no feasible version
> could be found for package: Gadfly
>  in error at ./error.jl:21
>  in resolve at ./pkg/resolve.jl:37
>  in resolve at ./pkg/entry.jl:422
>  in resolve at pkg/entry.jl:404
>  in anonymous at pkg/dir.jl:31
>  in cd at file.jl:22
>  in cd at pkg/dir.jl:31
>  in resolve at pkg.jl:46
>
> julia>
> [tom@tomoffice Plots]$ cat REQUIRE
> julia 0.3
>
> Colors
> Reexport
> Compat
> Gadfly 0.3.18
>
> How should I go about rectifying this error?  In this case I know that the
> requirement clash is with Immerse (which has "Gadfly 0.3.16 0.3.17" in its
> require file), but if a user sees this error they would likely be lost.  I
> fear that there's not a good solution once a single package has special
> requirements.
>

We could probably print out the actual conflicting requirements and
where they are coming from. This should help the user to know where to
look (or which package to blame)

IMHO, for this particular conflict, the best solution would be to fix
Immerse to work with newer version of Gadfly. Or if you need it now,
maybe try to pin Plots down to an earlier version that doesn't require
Gadfly 0.3.18 (if it has one of course).

>
> On Friday, October 30, 2015 at 11:15:52 AM UTC-4, Yichao Yu wrote:
>>
>> On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu  wrote:
>> > On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff  wrote:
>> >> Thanks... after reading through that again, let me adjust my scenario:
>> >>
>> >> Package A's require:
>> >>
>> >> julia 0.4
>> >> C 0.1 0.2-
>> >>
>> >> Package B's require:
>> >>
>> >> julia 0.4
>> >> C 0.3
>> >>
>> >> What version of C is installed?  Package A want any version 0.1.x,
>> >> Package B
>> >> wants any version 0.3.x or greater.  Who "wins"?
>>
>> Or fallback to an older version of one of them that don't conflict.
>>
>> >
>> > I'd be surprised if you don't get an error.
>> >
>> >>
>> >> On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu  wrote:
>> >>>
>> >>> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff 
>> >>> wrote:
>> >>> > I'm very confused about how Pkg resolution works in 0.4, and I
>> >>> > couldn't
>> >>> > find
>> >>> > a definitive source of details.  If package A has the REQUIRE file:
>> >>> >
>> >>> > julia 0.4
>> >>> > C 0.1
>> >>> >
>> >>>
>> >>> This means version 0.1 or higher for C
>> >>>
>> >>> >
>> >>> > and package B has the REQUIRE file:
>> >>> >
>> >>> > julia 0.4
>> >>> > C 0.2
>> >>> >
>> >>>
>> >>> This means version 0.2 or higher for C
>> >>>
>> >>> >
>> >>> > which version of C is installed?  Does it change if you do a
>> >>> > Pkg.add("C")?
>> >>> > What determines which package "wins"?
>> >>>
>> >>> The latest available that is compatible with everything else.
>> >>>
>> >>> Note to specify the upper bound, use `C lower_version upper_version`
>> >>>
>> >>> >
>> >>> > Bonus question: can someone point me to documentation on exactly
>> >>> > what
>> >>> > the
>> >>> > plus/minus mean?  What's the difference between `0.1`, `0.1-`, and
>> >>> > `0.1+`?
>> >>>
>> >>> - and + are for prerelease and build
>> >>>
>> >>> ```
>> >>> julia> v"0.1-2+3".prerelease
>> >>> (2,)
>> >>>
>> >>> julia> v"0.1-2+3".build
>> >>> (3,)
>> >>> ```
>> >>>
>> >>> >
>> >>> > Bonus question: how does the logic change with the new package
>> >>> > manager?
>> >>> > (if
>> >>> > at all)
>> >>>
>> >>> nothing
>> >>>
>> >>> >
>> >>> > Bonus question: is there an open issue/PR that discusses potential
>> >>> > future
>> >>> > changes to METADATA and package management?
>> >>> >
>> >>> > Thanks!
>> >>>
>> >>> Ref
>> >>>
>> >>> http://julia.readthedocs.org/en/latest/manual/packages/#require-speaks-for-itself
>> >>
>> >>

Re: [julia-users] Re: Order of multiple for-loops

[John Gibson]

Agreed w Glenn H here. "math being column major" is because the range of a 
matrix being the span of its columns, and consequently most linear algebra 
algorithms are naturally expressed as operations on the columns of the 
matrix, for example QR decomp via Gramm-Schmidt or Householder, LU without 
pivoting, all Krylov subspace methods. An exception would be LU with full 
or partial row pivoting. 

I think preference for row-ordering comes from the fact that the textbook 
presentation of matrix-vector multiply is given as computing y(i)= sum_j 
A(i,j) x(j) for each value of i. Ordering the operations that way would 
make row-ordering of A cache-friendly. But if instead you understand 
mat-vec mult as forming a linear combination of the columns of A, and you 
do the computation via y = sum_j A(:,j) x(j), column-ordering is 
cache-friendly. And it's the latter version that generalizes into all the 
important linear algebra algorithms.

John


On Friday, October 30, 2015 at 10:46:36 AM UTC-4, Glen H wrote:
>
>
> On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski wrote:
>>
>> Yes, this is an unfortunate consequence of mathematics being column-major 
>> – oh how I wish it weren't so. The storage order is actually largely 
>> irrelevant, the whole issue stems from the fact that the element in the ith 
>> row and the jth column of a matrix is indexes as A[i,j]. If it were A[j,i] 
>> then these would agree (and many things would be simpler). I like your 
>> explanation of "an index closer to the expression to be evaluated runs 
>> faster" – that's a really good way to remember/explain it.
>>
>>
> To help understand, is "math being column major" referring to matrix 
> operations in math textbooks are done by columns?  For example:
>
>
> http://eli.thegreenplace.net/2015/visualizing-matrix-multiplication-as-a-linear-combination/
>
> While the order is by convention (eg not that is has to be that way), this 
> is how people are taught.
>
> Glen
>

Re: [julia-users] Package requirements and pinning

[Tom Breloff]

Ok, I tried that out, and you're right that I get an error (it didn't 
fallback to an older version, unless maybe that would happen with 
Pkg.update()?)


julia> Pkg.resolve()
ERROR: unsatisfiable package requirements detected: no feasible version 
could be found for package: Gadfly
 in error at ./error.jl:21
 in resolve at ./pkg/resolve.jl:37
 in resolve at ./pkg/entry.jl:422
 in resolve at pkg/entry.jl:404
 in anonymous at pkg/dir.jl:31
 in cd at file.jl:22
 in cd at pkg/dir.jl:31
 in resolve at pkg.jl:46

julia> 
[tom@tomoffice Plots]$ cat REQUIRE 
julia 0.3

Colors
Reexport
Compat
Gadfly 0.3.18

How should I go about rectifying this error?  In this case I know that the 
requirement clash is with Immerse (which has "Gadfly 0.3.16 0.3.17" in its 
require file), but if a user sees this error they would likely be lost.  I 
fear that there's not a good solution once a single package has special 
requirements.


On Friday, October 30, 2015 at 11:15:52 AM UTC-4, Yichao Yu wrote:
>
> On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu  > wrote: 
> > On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff  > wrote: 
> >> Thanks... after reading through that again, let me adjust my scenario: 
> >> 
> >> Package A's require: 
> >> 
> >> julia 0.4 
> >> C 0.1 0.2- 
> >> 
> >> Package B's require: 
> >> 
> >> julia 0.4 
> >> C 0.3 
> >> 
> >> What version of C is installed?  Package A want any version 0.1.x, 
> Package B 
> >> wants any version 0.3.x or greater.  Who "wins"? 
>
> Or fallback to an older version of one of them that don't conflict. 
>
> > 
> > I'd be surprised if you don't get an error. 
> > 
> >> 
> >> On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu  > wrote: 
> >>> 
> >>> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff  > wrote: 
> >>> > I'm very confused about how Pkg resolution works in 0.4, and I 
> couldn't 
> >>> > find 
> >>> > a definitive source of details.  If package A has the REQUIRE file: 
> >>> > 
> >>> > julia 0.4 
> >>> > C 0.1 
> >>> > 
> >>> 
> >>> This means version 0.1 or higher for C 
> >>> 
> >>> > 
> >>> > and package B has the REQUIRE file: 
> >>> > 
> >>> > julia 0.4 
> >>> > C 0.2 
> >>> > 
> >>> 
> >>> This means version 0.2 or higher for C 
> >>> 
> >>> > 
> >>> > which version of C is installed?  Does it change if you do a 
> >>> > Pkg.add("C")? 
> >>> > What determines which package "wins"? 
> >>> 
> >>> The latest available that is compatible with everything else. 
> >>> 
> >>> Note to specify the upper bound, use `C lower_version upper_version` 
> >>> 
> >>> > 
> >>> > Bonus question: can someone point me to documentation on exactly 
> what 
> >>> > the 
> >>> > plus/minus mean?  What's the difference between `0.1`, `0.1-`, and 
> >>> > `0.1+`? 
> >>> 
> >>> - and + are for prerelease and build 
> >>> 
> >>> ``` 
> >>> julia> v"0.1-2+3".prerelease 
> >>> (2,) 
> >>> 
> >>> julia> v"0.1-2+3".build 
> >>> (3,) 
> >>> ``` 
> >>> 
> >>> > 
> >>> > Bonus question: how does the logic change with the new package 
> manager? 
> >>> > (if 
> >>> > at all) 
> >>> 
> >>> nothing 
> >>> 
> >>> > 
> >>> > Bonus question: is there an open issue/PR that discusses potential 
> >>> > future 
> >>> > changes to METADATA and package management? 
> >>> > 
> >>> > Thanks! 
> >>> 
> >>> Ref 
> >>> 
> http://julia.readthedocs.org/en/latest/manual/packages/#require-speaks-for-itself
>  
> >> 
> >> 
>

Re: [julia-users] Package requirements and pinning

[Yichao Yu]

On Fri, Oct 30, 2015 at 11:14 AM, Yichao Yu  wrote:
> On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff  wrote:
>> Thanks... after reading through that again, let me adjust my scenario:
>>
>> Package A's require:
>>
>> julia 0.4
>> C 0.1 0.2-
>>
>> Package B's require:
>>
>> julia 0.4
>> C 0.3
>>
>> What version of C is installed?  Package A want any version 0.1.x, Package B
>> wants any version 0.3.x or greater.  Who "wins"?

Or fallback to an older version of one of them that don't conflict.

>
> I'd be surprised if you don't get an error.
>
>>
>> On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu  wrote:
>>>
>>> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff  wrote:
>>> > I'm very confused about how Pkg resolution works in 0.4, and I couldn't
>>> > find
>>> > a definitive source of details.  If package A has the REQUIRE file:
>>> >
>>> > julia 0.4
>>> > C 0.1
>>> >
>>>
>>> This means version 0.1 or higher for C
>>>
>>> >
>>> > and package B has the REQUIRE file:
>>> >
>>> > julia 0.4
>>> > C 0.2
>>> >
>>>
>>> This means version 0.2 or higher for C
>>>
>>> >
>>> > which version of C is installed?  Does it change if you do a
>>> > Pkg.add("C")?
>>> > What determines which package "wins"?
>>>
>>> The latest available that is compatible with everything else.
>>>
>>> Note to specify the upper bound, use `C lower_version upper_version`
>>>
>>> >
>>> > Bonus question: can someone point me to documentation on exactly what
>>> > the
>>> > plus/minus mean?  What's the difference between `0.1`, `0.1-`, and
>>> > `0.1+`?
>>>
>>> - and + are for prerelease and build
>>>
>>> ```
>>> julia> v"0.1-2+3".prerelease
>>> (2,)
>>>
>>> julia> v"0.1-2+3".build
>>> (3,)
>>> ```
>>>
>>> >
>>> > Bonus question: how does the logic change with the new package manager?
>>> > (if
>>> > at all)
>>>
>>> nothing
>>>
>>> >
>>> > Bonus question: is there an open issue/PR that discusses potential
>>> > future
>>> > changes to METADATA and package management?
>>> >
>>> > Thanks!
>>>
>>> Ref
>>> http://julia.readthedocs.org/en/latest/manual/packages/#require-speaks-for-itself
>>
>>

Re: [julia-users] Package requirements and pinning

[Yichao Yu]

On Fri, Oct 30, 2015 at 11:05 AM, Tom Breloff  wrote:
> Thanks... after reading through that again, let me adjust my scenario:
>
> Package A's require:
>
> julia 0.4
> C 0.1 0.2-
>
> Package B's require:
>
> julia 0.4
> C 0.3
>
> What version of C is installed?  Package A want any version 0.1.x, Package B
> wants any version 0.3.x or greater.  Who "wins"?

I'd be surprised if you don't get an error.

>
> On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu  wrote:
>>
>> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff  wrote:
>> > I'm very confused about how Pkg resolution works in 0.4, and I couldn't
>> > find
>> > a definitive source of details.  If package A has the REQUIRE file:
>> >
>> > julia 0.4
>> > C 0.1
>> >
>>
>> This means version 0.1 or higher for C
>>
>> >
>> > and package B has the REQUIRE file:
>> >
>> > julia 0.4
>> > C 0.2
>> >
>>
>> This means version 0.2 or higher for C
>>
>> >
>> > which version of C is installed?  Does it change if you do a
>> > Pkg.add("C")?
>> > What determines which package "wins"?
>>
>> The latest available that is compatible with everything else.
>>
>> Note to specify the upper bound, use `C lower_version upper_version`
>>
>> >
>> > Bonus question: can someone point me to documentation on exactly what
>> > the
>> > plus/minus mean?  What's the difference between `0.1`, `0.1-`, and
>> > `0.1+`?
>>
>> - and + are for prerelease and build
>>
>> ```
>> julia> v"0.1-2+3".prerelease
>> (2,)
>>
>> julia> v"0.1-2+3".build
>> (3,)
>> ```
>>
>> >
>> > Bonus question: how does the logic change with the new package manager?
>> > (if
>> > at all)
>>
>> nothing
>>
>> >
>> > Bonus question: is there an open issue/PR that discusses potential
>> > future
>> > changes to METADATA and package management?
>> >
>> > Thanks!
>>
>> Ref
>> http://julia.readthedocs.org/en/latest/manual/packages/#require-speaks-for-itself
>
>

Re: [julia-users] Package requirements and pinning

[Tom Breloff]

Thanks... after reading through that again, let me adjust my scenario:

Package A's require:

julia 0.4
C 0.1 0.2-

Package B's require:

julia 0.4
C 0.3

What version of C is installed?  Package A want any version 0.1.x, Package
B wants any version 0.3.x or greater.  Who "wins"?

On Fri, Oct 30, 2015 at 10:28 AM, Yichao Yu  wrote:

> On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff  wrote:
> > I'm very confused about how Pkg resolution works in 0.4, and I couldn't
> find
> > a definitive source of details.  If package A has the REQUIRE file:
> >
> > julia 0.4
> > C 0.1
> >
>
> This means version 0.1 or higher for C
>
> >
> > and package B has the REQUIRE file:
> >
> > julia 0.4
> > C 0.2
> >
>
> This means version 0.2 or higher for C
>
> >
> > which version of C is installed?  Does it change if you do a
> Pkg.add("C")?
> > What determines which package "wins"?
>
> The latest available that is compatible with everything else.
>
> Note to specify the upper bound, use `C lower_version upper_version`
>
> >
> > Bonus question: can someone point me to documentation on exactly what the
> > plus/minus mean?  What's the difference between `0.1`, `0.1-`, and
> `0.1+`?
>
> - and + are for prerelease and build
>
> ```
> julia> v"0.1-2+3".prerelease
> (2,)
>
> julia> v"0.1-2+3".build
> (3,)
> ```
>
> >
> > Bonus question: how does the logic change with the new package manager?
> (if
> > at all)
>
> nothing
>
> >
> > Bonus question: is there an open issue/PR that discusses potential future
> > changes to METADATA and package management?
> >
> > Thanks!
>
> Ref
> http://julia.readthedocs.org/en/latest/manual/packages/#require-speaks-for-itself
>

[julia-users] Re: IDE for Julia

[Tomas Mikoviny]

maybe someone with more javascript insight can get inspired by this python 
IDE one day :)

https://github.com/yhat/rodeo
 

On Thursday, August 27, 2015 at 5:12:22 AM UTC+2, Deb Midya wrote:
>
> Hi,
>
> Thanks in advance.
>
> I am new to Julia and using Julia-0.3.7 on Windows 8.
>
> I am looking for an IDE for Julia (like RStudio in R).
>
> Once again, thank you very much for the time you have given..
>
> Regards,
>
> Deb
>

Re: [julia-users] Re: Order of multiple for-loops

[Glen H]

On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski wrote:
>
> Yes, this is an unfortunate consequence of mathematics being column-major 
> – oh how I wish it weren't so. The storage order is actually largely 
> irrelevant, the whole issue stems from the fact that the element in the ith 
> row and the jth column of a matrix is indexes as A[i,j]. If it were A[j,i] 
> then these would agree (and many things would be simpler). I like your 
> explanation of "an index closer to the expression to be evaluated runs 
> faster" – that's a really good way to remember/explain it.
>
>
To help understand, is "math being column major" referring to matrix 
operations in math textbooks are done by columns?  For example:

http://eli.thegreenplace.net/2015/visualizing-matrix-multiplication-as-a-linear-combination/

While the order is by convention (eg not that is has to be that way), this 
is how people are taught.

Glen

Re: [julia-users] Package requirements and pinning

[Yichao Yu]

On Fri, Oct 30, 2015 at 10:18 AM, Tom Breloff  wrote:
> I'm very confused about how Pkg resolution works in 0.4, and I couldn't find
> a definitive source of details.  If package A has the REQUIRE file:
>
> julia 0.4
> C 0.1
>

This means version 0.1 or higher for C

>
> and package B has the REQUIRE file:
>
> julia 0.4
> C 0.2
>

This means version 0.2 or higher for C

>
> which version of C is installed?  Does it change if you do a Pkg.add("C")?
> What determines which package "wins"?

The latest available that is compatible with everything else.

Note to specify the upper bound, use `C lower_version upper_version`

>
> Bonus question: can someone point me to documentation on exactly what the
> plus/minus mean?  What's the difference between `0.1`, `0.1-`, and `0.1+`?

- and + are for prerelease and build

```
julia> v"0.1-2+3".prerelease
(2,)

julia> v"0.1-2+3".build
(3,)
```

>
> Bonus question: how does the logic change with the new package manager? (if
> at all)

nothing

>
> Bonus question: is there an open issue/PR that discusses potential future
> changes to METADATA and package management?
>
> Thanks!

Ref 
http://julia.readthedocs.org/en/latest/manual/packages/#require-speaks-for-itself

[julia-users] Re: array of empty arrays and data types

[David P. Sanders]

El viernes, 30 de octubre de 2015, 7:12:39 (UTC-6), Cameron Zachreson 
escribió:
>
> Hello, 
>
> Just started using Julia and I've come across an issue trying to create 
> and append values to arrays of empty arrays. 
>

If you specify a bit more precisely what you are trying to do, it will be 
easier to help you.

Note that performance will be terrible unless you completely specify the 
types of the objects -- just writing Array 
leaves some of the types unspecified, as denoted by the {T,N} when you write

julia> Array[]
0-element Array{Array{T,N},1}

The simplest solution is something like

julia> v = Vector{Int}[]
0-element Array{Array{Int64,1},1}

This specifies an empty array (the [ ] part) that contains vectors (i.e. 1D 
arrays) of Ints  (the Vector{Int} part).

You can then add vectors of integers to it with

julia> push!(v, [1, 2])
1-element Array{Array{Int64,1},1}:
 [1,2]

julia> push!(v, [3, 4, 5])
2-element Array{Array{Int64,1},1}:
 [1,2]  
 [3,4,5]
 

>
> What I want to do is create a grid of empty arrays that can be filled with 
> values associated with particle IDs for a molecular dynamics-style 
> simulation. The trouble I'm having is that it does not seem possible to 
> initialize the arrays so that they can be iteratively filled. 
>
> here is an example of the problem:
>
> julia> bins = Array(Array, 5, 5)
>
>
> 5x5 Array{Array{T,N},2}:
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>
> julia> bins[1, 1] = 0
>
>
> ERROR: MethodError: `convert` has no method matching 
> convert(::Type{Array{T,N}}, ::Int64)
>
> This may have arisen from a call to the constructor Array{T,N}(...),
>
> since type constructors fall back to convert methods.
>
> Closest candidates are:
>
>   call{T}(::Type{T}, ::Any)
>
>   convert(::Type{Array{T,N}}, ::SharedArray{T,N})
>
>   convert{T,N}(::Type{Array{T,N}}, ::AbstractArray{T,N})
>
>   ...
>
>  in setindex! at array.jl:314
>
> I don't understand what the error message means, I have tried initializing 
> with different datatypes, but it does not work. Any help would be 
> appreciated. 
>
> Cam
>
>
>
>

Re: [julia-users] Re: Order of multiple for-loops

[Tamas Papp]

On Fri, Oct 30 2015, Steven G. Johnson  wrote:

> However, if Julia had chosen row-major, it would have been possible with a 
> little care to call LAPACK and other column-major libraries without making 
> a copy of any data, basically because for every linear-algebra operation 
> there is an equivalent operation on the transpose of the matrix.

Not in every case. I implemented a LAPACK bindings in Common Lisp [1]
which is row-major, and had to jump through a lot of hoops, occasionally
resorting to a transpose.

> Probably too late to revisit this decision now, in any case.   It wouldn't 
> matter much except that people have a natural tendency to write loops in 
> row-major order, and Fortran compilers have had to fight against this for 
> years.  (Sometimes they can detect and rearrange the loop order.)

For better or worse, the majority scientific code is column major. I am
glad that Julia made this choice, a lot fewer headaches than
row-major. There is nothing intrinsically better about column-major, and
probably in an alternate universe everyone is using it, and they use a
different convention for electric charge [2], etc, but in this one it is
better to follow predominant conventions.

Best,

Tamas

[1] https://github.com/tpapp/lla
[2] https://xkcd.com/567/

[julia-users] Package requirements and pinning

[Tom Breloff]

I'm very confused about how Pkg resolution works in 0.4, and I couldn't 
find a definitive source of details.  If package A has the REQUIRE file:

julia 0.4
C 0.1


and package B has the REQUIRE file:

julia 0.4
C 0.2


which version of C is installed?  Does it change if you do a Pkg.add("C")? 
 What determines which package "wins"?

Bonus question: can someone point me to documentation on exactly what the 
plus/minus mean?  What's the difference between `0.1`, `0.1-`, and `0.1+`?

Bonus question: how does the logic change with the new package manager? (if 
at all)

Bonus question: is there an open issue/PR that discusses potential future 
changes to METADATA and package management?

Thanks!

Re: [julia-users] Deprecation warnings using julia on Atom

[Jonathan Malmaud]

I'm not totally sure if this is what you mean by 'compilation in editor',
but there is a limitation now that Atom will kill a Julia process that is
taking a while to precompile a module. So currently people trigger the
precompilation of large modules in the terminal REPL instead.


On Fri, Oct 30, 2015 at 10:05 AM endowdly  wrote:

> Colin,
>
> Correct, that was a typo. Juno and jewel are working well for me with 0.4
> and I wasn't aware M Innes would be switching to Atom. I still haven't been
> able to get Atom to work well with Julia; I get the same depreciation
> warnings as you, but I also get some errors that prevent compilation in
> editor. Maybe in time, we'll get it straightened out. I currently think
> it's just a simple communication error between Atom and the REPL but I
> haven't played with them much.
>
> Thanks!
> /R
>
>
> On Thursday, October 29, 2015 at 6:30:09 PM UTC-4, Colin Bowers wrote:
>
>> I've not heard of lightbox. Do you mean LightTable? I used to use
>> LightTable with Mike Innes Juno package, but made the switch to Atom
>> because my understanding is that from v0.4 onwards, Mike will be
>> concentrating his efforts there. To be honest, I'm really happy with Atom
>> and the Julia packages. I think Mike has already got it as friendly and
>> feature-rich as Juno was (as long as you're on the Master branch of the
>> packages, that is). And the deprecation warnings are not a deal-breaker -
>> more a minor inconvenience.
>>
>> Cheers,
>>
>> Colin
>>
>
>> On 29 October 2015 at 03:45, endowdly  wrote:
>>
>>> Have you tried using lightbox?
>>>
>>> I ran into similar problems with atom, which I prefer due to speed. I
>>> could get lightbox to play well with the repl, however and "using jewel".
>>>
>>> On Tuesday, October 27, 2015 at 10:03:15 PM UTC-4, colint...@gmail.com
>>> wrote:

 Done. Precompilation occurred at the REPL, and I didn't have to do it
 within Atom. Verified packages are all on Master. Unfortunately, I'm still
 getting all of the original deprecation warnings when evaluating from the
 editor in Atom.

 I'm happy to pursue this further, but am equally happy to wait it out
 if you're running short on ideas or time.

 Cheers and thanks,

 Colin

 On Wednesday, 28 October 2015 12:24:38 UTC+11, Spencer Russell wrote:
>
> You’re running into another known issue:
> https://github.com/JuliaLang/julia/issues/12941
>
> Try opening a normal REPL in the terminal and run “using Atom” to
> trigger the precompilation, then it shouldn’t need to happen when you run
> from Atom.
>
> -s
>
>
> On Oct 27, 2015, at 9:09 PM, colint...@gmail.com wrote:
>
> Ah... understood. Many thanks.
>
> I'm afraid I'm still not getting the desired result however. After
> running checkout on "Atom", "CodeTools" and "JuliaParser" I run
> Pkg.status() and can verify I'm on the master branch for all 3. So I fire
> up Atom again, try to evaluate in the editor, and get the following error:
>
> INFO: Recompiling stale cache file
> /home/colin/.julia/lib/v0.4/JuliaParser.ji
> Julia has stopped: 1, null
>
> So I close down Atom, open it again, and try to evaluate in the editor
> again. This time I get:
>
> INFO: Recompiling stale cache file
> /home/colin/.julia/lib/v0.4/CodeTools.ji
> Julia has stopped: 1, null
>
> Close down Atom one more time, re-open it and try again. Now I get:
>
> INFO: Recompiling stale cache file /home/colin/.julia/lib/v0.4/Atom.ji
>
> but everything is now working fine. Problem solved? Unfortunately not.
> I restart Atom again and I'm back to all the deprecation warnings, even
> though Pkg.status() indicates I'm still on the master branch for Atom,
> CodeTools, and JuliaParser.
>
> Apologies for the long message. Also, if this is one of those things
> that will resolve itself over the next couple of weeks as changes from
> master are pushed to the more stable branches, then I'm happy to ignore 
> the
> warnings for the time being and not waste anyone's time any further with
> what is essentially a minor inconvenience.
>
> Cheers,
>
> Colin
>
>
>
>
> On Wednesday, 28 October 2015 11:37:21 UTC+11, Spencer Russell wrote:
>>
>> `Pkg.checkout(…)` operates an an already-installed package, so it
>> must be run after `Pkg.add(…)`.
>>
>> -s
>>
>> On Oct 27, 2015, at 8:31 PM, colint...@gmail.com wrote:
>>
>> I suppose I could clone the master branch. Is that a bad idea?
>>
>> On Wednesday, 28 October 2015 11:30:43 UTC+11, colint...@gmail.com
>> wrote:
>>>
>>> Thanks for responding.
>>>
>>> Pkg.checkout("Atom") gives me the error:
>>>
>>> ERROR: Atom is not a git repo
>>>  in checkout at pkg/entry.jl:203
>>>  in anonymous at pkg/dir.jl:31
>>>  in cd at

Re: [julia-users] Deprecation warnings using julia on Atom

[endowdly]

Colin,

Correct, that was a typo. Juno and jewel are working well for me with 0.4 
and I wasn't aware M Innes would be switching to Atom. I still haven't been 
able to get Atom to work well with Julia; I get the same depreciation 
warnings as you, but I also get some errors that prevent compilation in 
editor. Maybe in time, we'll get it straightened out. I currently think 
it's just a simple communication error between Atom and the REPL but I 
haven't played with them much. 

Thanks!
/R

On Thursday, October 29, 2015 at 6:30:09 PM UTC-4, Colin Bowers wrote:
>
> I've not heard of lightbox. Do you mean LightTable? I used to use 
> LightTable with Mike Innes Juno package, but made the switch to Atom 
> because my understanding is that from v0.4 onwards, Mike will be 
> concentrating his efforts there. To be honest, I'm really happy with Atom 
> and the Julia packages. I think Mike has already got it as friendly and 
> feature-rich as Juno was (as long as you're on the Master branch of the 
> packages, that is). And the deprecation warnings are not a deal-breaker - 
> more a minor inconvenience.
>
> Cheers,
>
> Colin
>
> On 29 October 2015 at 03:45, endowdly > 
> wrote:
>
>> Have you tried using lightbox? 
>>
>> I ran into similar problems with atom, which I prefer due to speed. I 
>> could get lightbox to play well with the repl, however and "using jewel". 
>>
>> On Tuesday, October 27, 2015 at 10:03:15 PM UTC-4, colint...@gmail.com 
>> wrote:
>>>
>>> Done. Precompilation occurred at the REPL, and I didn't have to do it 
>>> within Atom. Verified packages are all on Master. Unfortunately, I'm still 
>>> getting all of the original deprecation warnings when evaluating from the 
>>> editor in Atom.
>>>
>>> I'm happy to pursue this further, but am equally happy to wait it out if 
>>> you're running short on ideas or time.
>>>
>>> Cheers and thanks,
>>>
>>> Colin
>>>
>>> On Wednesday, 28 October 2015 12:24:38 UTC+11, Spencer Russell wrote:

 You’re running into another known issue: 
 https://github.com/JuliaLang/julia/issues/12941

 Try opening a normal REPL in the terminal and run “using Atom” to 
 trigger the precompilation, then it shouldn’t need to happen when you run 
 from Atom.

 -s


 On Oct 27, 2015, at 9:09 PM, colint...@gmail.com wrote:

 Ah... understood. Many thanks.

 I'm afraid I'm still not getting the desired result however. After 
 running checkout on "Atom", "CodeTools" and "JuliaParser" I run 
 Pkg.status() and can verify I'm on the master branch for all 3. So I fire 
 up Atom again, try to evaluate in the editor, and get the following error:

 INFO: Recompiling stale cache file 
 /home/colin/.julia/lib/v0.4/JuliaParser.ji
 Julia has stopped: 1, null

 So I close down Atom, open it again, and try to evaluate in the editor 
 again. This time I get:

 INFO: Recompiling stale cache file 
 /home/colin/.julia/lib/v0.4/CodeTools.ji
 Julia has stopped: 1, null

 Close down Atom one more time, re-open it and try again. Now I get:

 INFO: Recompiling stale cache file /home/colin/.julia/lib/v0.4/Atom.ji

 but everything is now working fine. Problem solved? Unfortunately not. 
 I restart Atom again and I'm back to all the deprecation warnings, even 
 though Pkg.status() indicates I'm still on the master branch for Atom, 
 CodeTools, and JuliaParser.

 Apologies for the long message. Also, if this is one of those things 
 that will resolve itself over the next couple of weeks as changes from 
 master are pushed to the more stable branches, then I'm happy to ignore 
 the 
 warnings for the time being and not waste anyone's time any further with 
 what is essentially a minor inconvenience.

 Cheers,

 Colin




 On Wednesday, 28 October 2015 11:37:21 UTC+11, Spencer Russell wrote:
>
> `Pkg.checkout(…)` operates an an already-installed package, so it must 
> be run after `Pkg.add(…)`.
>
> -s
>
> On Oct 27, 2015, at 8:31 PM, colint...@gmail.com wrote:
>
> I suppose I could clone the master branch. Is that a bad idea?
>
> On Wednesday, 28 October 2015 11:30:43 UTC+11, colint...@gmail.com 
> wrote:
>>
>> Thanks for responding.
>>
>> Pkg.checkout("Atom") gives me the error:
>>
>> ERROR: Atom is not a git repo
>>  in checkout at pkg/entry.jl:203
>>  in anonymous at pkg/dir.jl:31
>>  in cd at file.jl:22
>>  in cd at pkg/dir.jl:31
>>  in checkout at pkg.jl:37
>>
>> (I originally did try using Pkg.checkout as per the instructions, but 
>> got this error, and so went with Pkg.add instead).
>>
>> Any thoughts or is this a bug?
>>
>> Cheers,
>>
>> Colin
>>
>>
>> On Wednesday, 28 October 2015 11:23:30 UTC+11, Jonathan Malmaud wrote:
>>>
>>> You want to be on

Re: [julia-users] Re: Communicate thru COM Ports (Serial)

[endowdly]

Ah thank you Isaiah, that was exactly the package I was searching for! 

Re: [julia-users] Re: Order of multiple for-loops

[Brendan Tracey]

On Thursday, October 29, 2015 at 9:11:27 PM UTC-6, Steven G. Johnson wrote:
>
>
>
> On Thursday, October 29, 2015 at 1:24:23 PM UTC-4, Stefan Karpinski wrote:
>>
>> Yes, this is an unfortunate consequence of mathematics being column-major 
>> – oh how I wish it weren't so. 
>>
>
> I'm not sure what you mean by "mathematics being column major".  Fortran 
> is column-major, and a lot of the linear-algebra libraries (LAPACK etc.) 
> are column-major in consequence, and Matlab is column-major.
>
> However, if Julia had chosen row-major, it would have been possible with a 
> little care to call LAPACK and other column-major libraries without making 
> a copy of any data, basically because for every linear-algebra operation 
> there is an equivalent operation on the transpose of the matrix.
>

It's not that simple. QR decomposition (dqeqrf) does not allow you to 
specify the transpose of the matrix directly.  Sure, you can compute A^T 
instead, but then it's trickier to use the result to do the follow-on 
operations like linear solving and computing the condition number.

[julia-users] Re: array of empty arrays and data types

[Tom Breloff]

Maybe this is what you're looking for:


julia> bins = Array[[] for i=1:5,j=1:5]
5x5 Array{Array{T,N},2}:
 Any[]  Any[]  Any[]  Any[]  Any[]
 Any[]  Any[]  Any[]  Any[]  Any[]
 Any[]  Any[]  Any[]  Any[]  Any[]
 Any[]  Any[]  Any[]  Any[]  Any[]
 Any[]  Any[]  Any[]  Any[]  Any[]


julia> push!(bins[1,1], 0)
1-element Array{Any,1}:
 0


julia> bins
5x5 Array{Array{T,N},2}:
 Any[0]  Any[]  Any[]  Any[]  Any[]
 Any[]   Any[]  Any[]  Any[]  Any[]
 Any[]   Any[]  Any[]  Any[]  Any[]
 Any[]   Any[]  Any[]  Any[]  Any[]
 Any[]   Any[]  Any[]  Any[]  Any[]




On Friday, October 30, 2015 at 9:12:39 AM UTC-4, Cameron Zachreson wrote:
>
> Hello, 
>
> Just started using Julia and I've come across an issue trying to create 
> and append values to arrays of empty arrays. 
>
> What I want to do is create a grid of empty arrays that can be filled with 
> values associated with particle IDs for a molecular dynamics-style 
> simulation. The trouble I'm having is that it does not seem possible to 
> initialize the arrays so that they can be iteratively filled. 
>
> here is an example of the problem:
>
> julia> bins = Array(Array, 5, 5)
>
>
> 5x5 Array{Array{T,N},2}:
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>
> julia> bins[1, 1] = 0
>
>
> ERROR: MethodError: `convert` has no method matching 
> convert(::Type{Array{T,N}}, ::Int64)
>
> This may have arisen from a call to the constructor Array{T,N}(...),
>
> since type constructors fall back to convert methods.
>
> Closest candidates are:
>
>   call{T}(::Type{T}, ::Any)
>
>   convert(::Type{Array{T,N}}, ::SharedArray{T,N})
>
>   convert{T,N}(::Type{Array{T,N}}, ::AbstractArray{T,N})
>
>   ...
>
>  in setindex! at array.jl:314
>
> I don't understand what the error message means, I have tried initializing 
> with different datatypes, but it does not work. Any help would be 
> appreciated. 
>
> Cam
>
>
>
>

[julia-users] Re: array of empty arrays and data types

[Kristoffer Carlsson]

You are trying to put a 0 into an array which expects Arrays as its 
elements.

julia> bins = Array(Array, 5, 5)
5x5 Array{Array{T,N},2}:
 #undef  #undef  #undef  #undef  #undef
 #undef  #undef  #undef  #undef  #undef
 #undef  #undef  #undef  #undef  #undef
 #undef  #undef  #undef  #undef  #undef
 #undef  #undef  #undef  #undef  #undef

julia> bins[1,1] = rand(2)
2-element Array{Float64,1}:
 0.644859
 0.549012

julia> bins
5x5 Array{Array{T,N},2}:
[0.644859323090488,0.5490118374607151]  #undef  #undef  #undef  #undef
 #undef #undef  #undef  #undef  #undef
 #undef #undef  #undef  #undef  #undef
 #undef #undef  #undef  #undef  #undef
 #undef #undef  #undef  #undef  #undef



On Friday, October 30, 2015 at 2:12:39 PM UTC+1, Cameron Zachreson wrote:
>
> Hello, 
>
> Just started using Julia and I've come across an issue trying to create 
> and append values to arrays of empty arrays. 
>
> What I want to do is create a grid of empty arrays that can be filled with 
> values associated with particle IDs for a molecular dynamics-style 
> simulation. The trouble I'm having is that it does not seem possible to 
> initialize the arrays so that they can be iteratively filled. 
>
> here is an example of the problem:
>
> julia> bins = Array(Array, 5, 5)
>
>
> 5x5 Array{Array{T,N},2}:
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>  #undef  #undef  #undef  #undef  #undef
>
>
> julia> bins[1, 1] = 0
>
>
> ERROR: MethodError: `convert` has no method matching 
> convert(::Type{Array{T,N}}, ::Int64)
>
> This may have arisen from a call to the constructor Array{T,N}(...),
>
> since type constructors fall back to convert methods.
>
> Closest candidates are:
>
>   call{T}(::Type{T}, ::Any)
>
>   convert(::Type{Array{T,N}}, ::SharedArray{T,N})
>
>   convert{T,N}(::Type{Array{T,N}}, ::AbstractArray{T,N})
>
>   ...
>
>  in setindex! at array.jl:314
>
> I don't understand what the error message means, I have tried initializing 
> with different datatypes, but it does not work. Any help would be 
> appreciated. 
>
> Cam
>
>
>
>

[julia-users] Re: parallel and PyCall

[Matthew Pearce]

So I got something working for my pylab example. 

julia> import PyCall

julia> PyCall.@pyimport pylab

julia> @everywhere import PyCall

julia> @everywhere PyCall.@pyimport pylab

julia> @everywhere A = pylab.cumsum(collect(1:10))*1.

julia> fetch(@spawnat remotes[1] A)
10-element Array{Float64,1}:
  1.0
  3.0
  6.0
 10.0
 15.0
 21.0
 28.0
 36.0
 45.0
 55.0




No luck with the math module I'm afraid. Two different types of errors 
depending on style:

julia> @spawnat remotes[1] PyCall.@pyimport math as pymath
RemoteRef{Channel{Any}}(2,1,305)

julia> fetch(@spawnat remotes[1] (pymath.sin(pymath.pi / 4) - sin(pymath.pi 
/ 4)) )
ERROR: On worker 2:
UndefVarError: pymath not defined
 in anonymous at multi.jl:1330
 in anonymous at multi.jl:889
 in run_work_thunk at multi.jl:645
 in run_work_thunk at multi.jl:654
 in anonymous at task.jl:54
 in remotecall_fetch at multi.jl:731
 [inlined code] from multi.jl:368
 in call_on_owner at multi.jl:776
 in fetch at multi.jl:784

julia> @everywhere PyCall.@pyimport math as pymath

julia> fetch(@spawnat remotes[1] (pymath.sin(pymath.pi / 4) - sin(pymath.pi 
/ 4)) )
Worker 2 terminated.srun: error: mrc-bsu-tesla1: task 0: Exited with exit 
code 1
ERROR: ProcessExitedException()
 in yieldto at ./task.jl:67
 in wait at ./task.jl:367
 in wait at ./task.jl:282
 in wait at ./channels.jl:97
 in take! at ./channels.jl:84
 in take! at ./multi.jl:792
 in remotecall_fetch at multi.jl:729
 [inlined code] from multi.jl:368
 in call_on_owner at multi.jl:776
 in fetch at multi.jl:784


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





On Friday, October 30, 2015 at 1:28:21 AM UTC, Yakir Gagnon wrote:
>
> @Matthew: did you find a solution? 
>  
> On Tuesday, October 27, 2015 at 8:44:53 AM UTC+10, Yakir Gagnon wrote:
>>
>> Yea, right? So what’s the answer? How can we if at all do any PyCalls 
>> parallely? 
>>
>> On Monday, October 26, 2015 at 11:49:35 PM UTC+10, Matthew Pearce wrote:
>>
>> Thought I had an idea about this, I was wrong:
>>>
>>> ```julia
>>>
>>> julia> @everywhere using PyCall
>>>
>>> julia> @everywhere @pyimport pylab
>>>
>>> julia> remotecall_fetch(pylab.cumsum, 5, collect(1:10))
>>> ERROR: cannot serialize a pointer
>>>  [inlined code] from error.jl:21
>>>  in serialize at serialize.jl:420
>>>  [inlined code] from dict.jl:372
>>>  in serialize at serialize.jl:428
>>>  in serialize at serialize.jl:310
>>>  in serialize at serialize.jl:420 (repeats 2 times)
>>>  in serialize at serialize.jl:302
>>>  in serialize at serialize.jl:420
>>>  [inlined code] from dict.jl:372
>>>  in serialize at serialize.jl:428
>>>  in serialize at serialize.jl:310
>>>  in serialize at serialize.jl:420 (repeats 2 times)
>>>  in serialize at serialize.jl:302
>>>  in serialize at serialize.jl:420
>>>  [inlined code] from dict.jl:372
>>>  in send_msg_ at multi.jl:222
>>>  [inlined code] from multi.jl:177
>>>  in remotecall_fetch at multi.jl:728
>>>  [inlined code] from multi.jl:368
>>>  in remotecall_fetch at multi.jl:734
>>>
>>> julia> pylab.cumsum(collect(1:10))
>>> 10-element Array{Int64,1}:
>>>   1
>>>   3
>>>   6
>>>  10
>>>  15
>>>  21
>>>  28
>>>  36
>>>  45
>>>  55
>>>
>>> ```
>>>
>> ​
>>
>

Re: [julia-users] Enums in Julia

[Mauro]

I don't quite understand what you fail to achieve.  Using other values
than integers for the enum does not work, if that is the question.

If you just try to make your custom enum, then it cannot be used with
the @enum macro.

immutable MyEnum
field1::Type1
filed2::Type2
end

# no need/use for @enum:
enum1 = MyEnum(f11,f12)
enum2 = MyEnum(f21,f22)

But it seems a bit strange to have an enumeration which uses two values,
as an enumeration suggests that there is a mapping to the integers!

Mauro

On Fri, 2015-10-30 at 09:37, Eric Forgy  wrote:
> I am thinking about making an Enum type MyEnum, but each MyEnum is a
> composite immutable type. Is that possible (recommended) and how could I do
> that?
>
> I've looked at
>
>- https://github.com/JuliaLang/julia/pull/10168
>- And the @enum section of Docs
>
> but it still isn't obvious to me yet how to do it or if it is even
> possible/recommended.
>
> In psuedo-code, I'd like something like this:
>
> @enum MyEnum enum1 enum2 enum3
>
> but each enum[i] is a composite immutable type. How would I construct them?
>
> I thought of something like:
>
> immutable MyEnum
> field1::Type1
> filed2::Type2
> end
>
> @enum MyEnum enum1 = MyEnum(f11,f12) enum2 = MyEnum(f21,f22)
>
> but I don't think that will work.
>
> Any ideas?
>
> Thank you.
>
>
> On Tuesday, January 27, 2015 at 4:55:18 AM UTC+8, Reid Atcheson wrote:
>>
>> Ok now that you have put it there, the comments in the documentation make
>> more sense to me. It looks like both yours and mine are essentially
>> equivalent, but yours is simpler. I was aiming for the following behavior
>> with my implementation:
>>
>> - different enum types won't typecheck (can't do "if e1::EnumType1 ==
>> e2::EnumType2" without error).
>> - Array of enum type values contiguous in memory, for easy passing to C.
>> (immutable should do this)
>> - referring to enum fields by name, not by their numbering.
>>
>> I will switch to what you have written, it looks like it hits all of my
>> points while not simultaneously abusing the type system.
>>
>> On Monday, January 26, 2015 at 2:16:33 PM UTC-6, Mauro wrote:
>>>
>>> There is a FAQ entry on this which suggests not to use types each of
>>> elements of the enum (if I recall correctly).
>>>
>>> I recently did a enum like this:
>>>
>>> export nonstiff, mildlystiff, stiff
>>> abstract Enum
>>> immutable Stiff <: Enum
>>> val::Int
>>> function Stiff(i::Integer)
>>> @assert 0<=i<=2
>>> new(i)
>>> end
>>> end
>>> const nonstiff = Stiff(0)
>>> const mildlystiff = Stiff(1)
>>> const stiff = Stiff(2)
>>>
>>> Then you can just do
>>> if someflag==nonstiff
>>>do_something
>>> end
>>>
>>> So no need either to refer to the numeral value.  But I'm not sure
>>> whether this is better or not.
>>>
>>> On Mon, 2015-01-26 at 19:49, Reid Atcheson  wrote:
>>> > Hey all. I have frequently been in the position of wanting enumerations
>>> in
>>> > Julia. I have finally settled on the implementation linked below which
>>> lets
>>> > me refer to flags
>>> > in a named way and only specify their underlying numbering once. Is
>>> this
>>> > the best way, or are there better ways I haven't figured out?
>>> >
>>> > https://github.com/ReidAtcheson/EnumsInJulia
>>>
>>>

[julia-users] array of empty arrays and data types

[Cameron Zachreson]

Hello, 

Just started using Julia and I've come across an issue trying to create and 
append values to arrays of empty arrays. 

What I want to do is create a grid of empty arrays that can be filled with 
values associated with particle IDs for a molecular dynamics-style 
simulation. The trouble I'm having is that it does not seem possible to 
initialize the arrays so that they can be iteratively filled. 

here is an example of the problem:

julia> bins = Array(Array, 5, 5)


5x5 Array{Array{T,N},2}:

 #undef  #undef  #undef  #undef  #undef

 #undef  #undef  #undef  #undef  #undef

 #undef  #undef  #undef  #undef  #undef

 #undef  #undef  #undef  #undef  #undef

 #undef  #undef  #undef  #undef  #undef


julia> bins[1, 1] = 0


ERROR: MethodError: `convert` has no method matching 
convert(::Type{Array{T,N}}, ::Int64)

This may have arisen from a call to the constructor Array{T,N}(...),

since type constructors fall back to convert methods.

Closest candidates are:

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

  convert(::Type{Array{T,N}}, ::SharedArray{T,N})

  convert{T,N}(::Type{Array{T,N}}, ::AbstractArray{T,N})

  ...

 in setindex! at array.jl:314

I don't understand what the error message means, I have tried initializing 
with different datatypes, but it does not work. Any help would be 
appreciated. 

Cam

[julia-users] Challenge..: Distributing cross-platform [Julia] programs using a polyglot [not quote off-topic..]

[Páll Haraldsson]

"Builds an executable that doesn't require any julia source code":

[great that this is possible..]

https://github.com/JuliaLang/julia/blob/master/contrib/build_executable.jl


I see from:

" is an LLVM cpu target to build the system image against"

that, as expected, your executable will no longer be cross-platform.


It is very desirable to distribute source code (some might want to hide it, 
that is another issue) and can still expect your code to run (at full 
speed).


A. Now, you have either that or binaries (I haven't really checked out that 
option), but wander if you could get both at the same time with a polyglot 
that works with (I guess) Powershell (or whatever you can expect to be 
installed on Windows by default. Are there good other options?) and 
whatever scripting language/shell you can except by default on Linux/OS 
X/Unix-like.

B. Possibly the polyglot would run wget or whatever else that does the same 
thing on Windows to download the right binary runtime Julia. What would 
external default command in Windows would that be? A showstopper or an 
inbuilt one in Powershell? Would a better option be to include the runtime 
as machine code [on Windows or at least code to download it]? Allow both 
options? They both have pros and cons..


Anyone know if something like this has been done before for some non-Julia 
project as it isn't strictly a "Julia issue"? Any pointers/where to ask 
about? Anyone think this is impossible..? Or not worth trying/too brittle? 
A bonus would be if this would work on Android.. (or other than the default 
three/four? platforms) but not really a priority..


[JavaScript/the web is the only cross-platform scripting language I know, 
but would not work as you would have to break out of the sandbox and that 
would be a security issue.. Still, targeting [compiling Julia to] 
JavaScript for running in a browser is also an interesting alternative to 
run Julia programs, but not the idea here and has some cons..]


https://en.wikipedia.org/wiki/Polyglot_(computing)

"The term is sometimes applied to programs that are valid in more than one 
language, but do not strictly perform the same function in each. One use 
for this form is a file that runs as a DOS batch file, then re-runs itself 
in Perl:

@rem = ' --PERL--
@echo off
perl "%~dpnx0" %*
goto endofperl
@rem ';
#!perl
print "Hello, world!\n";
__END__
:endofperl

This allows creating Perl scripts that can be run on DOS systems with 
minimal effort."



Something like this where you have to compile is a non-starter/not what I 
had in mind (but still interesting):

http://ideology.com.au/polyglot/

You compile it with your favorite compiler and run it. It says:

hello polyglots

It supports the following languages:

COBOL (ANSI)
Pascal (ISO)
Fortran (ANSI, f77)
C (ANSI-ish)
PostScript
Linux/Unix shell script (bash, sh, csh)
x86 machine language (MS-DOS, Win32)
Perl (version 5)


There are some example on the first page up to 16 languages (but not it 
seems targeting the right scripting languages):

A polyglot in 16 different languages
https://raw.githubusercontent.com/mauke/poly.poly/master/poly.poly
I can see at least in the source code:

I'm a Literate Haskell program
I'm a Python program
I'm a HTML page
[I'm a] horrible HTML [page]
JavaScript
I'm a Perl6 program

-- 
Palli.

Re: [julia-users] Re: typealias vs. const

[Yichao Yu]

On Fri, Oct 30, 2015 at 8:29 AM, FANG Colin  wrote:
> I have got the same confusion. Any ideas?
>
> I have even seen usage of A = T (no const)
> (http://docs.julialang.org/en/release-0.4/manual/types/#type-unions), is it
> supposed to be bad (slow) because it is a global variable?
>

no const will have performance issue since it's a global.
`const A = T` is what `typealias A T` lowered to when it doesn't have
type parameters. In this case, it's just a matter of style. Being
consistent within a file is probably better but you can pick whichever
you prefer.

>
>
> On Thursday, November 6, 2014 at 3:38:41 PM UTC, Steven G. Johnson wrote:
>>
>> Given a type T, what is the difference in practice between
>>  typealias A T
>> and
>>  const A = T
>> ?
>>
>> There seems to be some disagreement over which one to use (e.g.
>> https://github.com/JuliaLang/Compat.jl/commit/8211e38ac7d8448298a2bb3ab36d6f0b6398b577).
>>
>> My impression is that there is no difference, and that the only advantage
>> of a typealias is that it can be parameterized.  Is that right?
>>
>> If they are equivalent, what is the Julian style?  Even in Julia Base it
>> doesn't seem to be entirely consistent.

[julia-users] Re: typealias vs. const

[FANG Colin]

I have got the same confusion. Any ideas?

I have even seen usage of A = T (no const) 
(http://docs.julialang.org/en/release-0.4/manual/types/#type-unions), is it 
supposed to be bad (slow) because it is a global variable?



On Thursday, November 6, 2014 at 3:38:41 PM UTC, Steven G. Johnson wrote:
>
> Given a type T, what is the difference in practice between
>  typealias A T
> and 
>  const A = T
> ?
>
> There seems to be some disagreement over which one to use (e.g. 
> https://github.com/JuliaLang/Compat.jl/commit/8211e38ac7d8448298a2bb3ab36d6f0b6398b577
> ).
>
> My impression is that there is no difference, and that the only advantage 
> of a typealias is that it can be parameterized.  Is that right?
>
> If they are equivalent, what is the Julian style?  Even in Julia Base it 
> doesn't seem to be entirely consistent.
>

Re: [julia-users] Enums in Julia

[Eric Forgy]

I am thinking about making an Enum type MyEnum, but each MyEnum is a 
composite immutable type. Is that possible (recommended) and how could I do 
that?

I've looked at

   - https://github.com/JuliaLang/julia/pull/10168
   - And the @enum section of Docs

but it still isn't obvious to me yet how to do it or if it is even 
possible/recommended.

In psuedo-code, I'd like something like this:

@enum MyEnum enum1 enum2 enum3

but each enum[i] is a composite immutable type. How would I construct them?

I thought of something like:

immutable MyEnum
field1::Type1
filed2::Type2
end

@enum MyEnum enum1 = MyEnum(f11,f12) enum2 = MyEnum(f21,f22)

but I don't think that will work.

Any ideas?

Thank you.


On Tuesday, January 27, 2015 at 4:55:18 AM UTC+8, Reid Atcheson wrote:
>
> Ok now that you have put it there, the comments in the documentation make 
> more sense to me. It looks like both yours and mine are essentially 
> equivalent, but yours is simpler. I was aiming for the following behavior 
> with my implementation:
>
> - different enum types won't typecheck (can't do "if e1::EnumType1 == 
> e2::EnumType2" without error).
> - Array of enum type values contiguous in memory, for easy passing to C. 
> (immutable should do this)
> - referring to enum fields by name, not by their numbering.
>
> I will switch to what you have written, it looks like it hits all of my 
> points while not simultaneously abusing the type system.
>
> On Monday, January 26, 2015 at 2:16:33 PM UTC-6, Mauro wrote:
>>
>> There is a FAQ entry on this which suggests not to use types each of 
>> elements of the enum (if I recall correctly). 
>>
>> I recently did a enum like this: 
>>
>> export nonstiff, mildlystiff, stiff 
>> abstract Enum 
>> immutable Stiff <: Enum 
>> val::Int 
>> function Stiff(i::Integer) 
>> @assert 0<=i<=2 
>> new(i) 
>> end 
>> end 
>> const nonstiff = Stiff(0) 
>> const mildlystiff = Stiff(1) 
>> const stiff = Stiff(2) 
>>
>> Then you can just do 
>> if someflag==nonstiff 
>>do_something 
>> end 
>>
>> So no need either to refer to the numeral value.  But I'm not sure 
>> whether this is better or not. 
>>
>> On Mon, 2015-01-26 at 19:49, Reid Atcheson  wrote: 
>> > Hey all. I have frequently been in the position of wanting enumerations 
>> in 
>> > Julia. I have finally settled on the implementation linked below which 
>> lets 
>> > me refer to flags 
>> > in a named way and only specify their underlying numbering once. Is 
>> this 
>> > the best way, or are there better ways I haven't figured out? 
>> > 
>> > https://github.com/ReidAtcheson/EnumsInJulia 
>>
>>

[julia-users] Re: ANN: CloudArray.jl: Easy Big Data programming in the Cloud

[Charles Novaes de Santana]

That is just amazing!!! Thanks, Andre!! And congratulations!! I definetly
need to try it!

Charles

On Friday, October 30, 2015, André Lage  wrote:

> PS: Here it goes a IJulia Notebook with some examples to use at
> http://cloudarraybox.cloudapp.net:
>
> https://github.com/gsd-ufal/CloudArray.jl/blob/master/docs/cloudarray.ipynb
>
>
> André Lage.
>
> On Fri, Oct 30, 2015 at 12:13 AM, André Lage  > wrote:
>
>> Dear Julia community,
>>
>> We are proud to announce the very first release of *CloudArray.jl*
>> , a programming support that
>> eases big data programming in the cloud. CloudArray loads data from files
>> and books the right amount of virtual machines (VMs) able to process it.
>> Data loading and VM management are entirely automatic and performed
>> on-demand.
>>
>> CloudArray builds on top of Julia DistributedArrays. Indeed, a CloudArray
>> is a DistributedArray whose data and VM managements are automatic: data
>> load, resource booking and allocation. Therefore, existent codes that use
>> DistributedArrays don't need to be adapted in order to use CloudArray: just
>> use CloudArray and configure your cloud authentication settings.
>>
>> If you are interested in CloudArray, please *try it for free at our
>> Azure VMs *. If you need any help,
>> you can write to this list or send me an e-mail (prof.alage at gmail.com)
>> that we'll be glad to help you in developing your distributed application
>> in the cloud with CloudArray.
>>
>> CloudArray and CloudArrayBox are research prototypes which intend to be a
>> contribution to DistributedArrays and JuliaBox, not a replacement of them
>> at all. We intend in the future to pull requests to JuliaBox and Julia
>> Parallel communities as CloudArray code evolves. We also would like to
>> thank Julia developers and community for the great work. It's amazing how
>> Julia puts together high-level programming and efficiency, Julia really
>> inspired us in designing and implementing CloudArray.
>>
>> Moreover, we are open to work with Julia community, so please fell free
>> to propose any improvements or to pull requests to CloudArray code. 
>> CloudArray
>> roadmap 
>> includes interesting features such as: support for Amazon EC2, OpenStack;
>> allow to set a price threshold; provide different QoS (SLA).
>>
>> We are looking forward to getting feedback from you.
>>
>> Sincerely,
>>
>>
>> André Lage.
>> Ph.D. in Computer Science
>> https://sites.google.com/a/ic.ufal.br/andrelage/home/cv
>>
>
>

-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles