[julia-users] Re: Using Distance Package for knn Weight Matrix

[Patrick O'Leary]

(/me removes Julia hat, replaces with navigation hat)

That distance measurement probably isn't going to do quite what you want it 
to do, particularly over such a large area. It's an okay approximation in 
CONUS, but biased--1 degree latitude isn't the same distance as 1 degree 
longitude. For points further north this gets worse. You have a few options 
for more accuracy:

You can put all of your coordinates in a local level frame. All the 
necessary formulas and constants are conveniently provided in MATLAB's 
Aerospace Blockset documentation: 
http://www.mathworks.com/help/aeroblks/llatoflatearth.html. Choose 
something like the centroid lat/lon as the "initial" values, which will act 
as the origin of the reference frame. Note that lat/lon will need to be 
converted to radians.

For longer distances, you will get better results with something like the 
haversine formula, which accounts for the curvature of the earth 
(https://en.wikipedia.org/wiki/Haversine_formula). That would probably make 
for a decent contribution to Distance.jl, and is pretty easy to implement.

For (substantial!) extra credit, you could implement a version that 
accounts for the flattening of the ellipsoid 
(https://en.wikipedia.org/wiki/Geodesics_on_an_ellipsoid, 
https://en.wikipedia.org/wiki/Vincenty%27s_formulae). That would probably 
not be accepted by Distance.jl, and is unlikely to be worthwhile for your 
application.

On Wednesday, July 2, 2014 7:05:21 PM UTC-5, Donald Lacombe wrote:
>
> Actually, another issue with the type information.
>
> Instead of using random coordinates, I used actual latitude and longitude 
> coordinates from a CSV file like so:
>
> data = readcsv("ct_coord.csv");
>
> temp = [xc';yc']
>
> 2x8 Array{Any,2}:
>
>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>
>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>
>
> Now, the type here is {Any,2} and this seems to be giving the Distance 
> package problems:
>
>
>
> R = pairwise(Euclidean(),temp)
>
> MethodError(fptype,(Any,))
>
>
> Julia seems to be unhappy with this type but I'm not sure how to correct this 
> which would seem to require that the data being read in are of Float type.
>
>
> Again, thank you for all of the help.
>
>
> Don
>
>
>
> On Wednesday, July 2, 2014 7:10:09 PM UTC-4, Donald Lacombe wrote:
>>
>> Patrick,
>>
>> Thank you for the reply! I will try your suggestion and hopefully get a 
>> better grasp of these issues.
>>
>> Thank you all gain for all of the help. It cannot be stressed enough that 
>> the friendly and truly helpful comments will help the Julia community grow.
>>
>> Don
>>
>> On Wednesday, July 2, 2014 5:31:55 PM UTC-4, Patrick O'Leary wrote:
>>>
>>> The second parameter to the Array type is the number of dimensions of 
>>> the array. "Row vectors" are implemented with 2-dimensional arrays (a.k.a., 
>>> "matrices"), since Vectors (a.k.a. Array{T, 1} for all types T) are 
>>> interpreted as columns.
>>>
>>> Since pairwise() generates all of the distances simultaneously, you'll 
>>> need to slice its results to use it in sortperm(), following your original 
>>> loop implementation. Each slice will need to be a Vector. If you slice 
>>> columns, you get Vector slices for free. If you slice rows, the shape will 
>>> be maintained, so you get a row back. You can flatten this to a Vector with 
>>> the vec() function.
>>>
>>> Hope this helps!
>>>
>>> On Wednesday, July 2, 2014 4:23:52 PM UTC-5, Donald Lacombe wrote:

 After thinking about this issue, another couple of question came to 
 mind.

 When I create a row vector, say xc = randn(1,5), the results indicate 
 that the vector is e.g.

 xc = rand(1,5)

 1x5 Array{Float64,2}:

  0.989421  0.718148  0.499914  0.13024  0.939856


 The type is {Float64,2}.


 Questions:


 1) What does the "2" mean in {Float64,2}? If I create xc = rand(5) the 
 type is {Float64,1}.


 2) The sortperm function only seems to accept {Float64,1} types. The 
 Euclidean distance code create types of {Float64,2} but I need {Float64,1} 
 for the sortperm function. Do I need to convert these before using this 
 command?


 I'm probably missing something really basic so apologies for the query.


 Thanks,

 Don


 On Wednesday, July 2, 2014 4:20:55 PM UTC-4, Donald Lacombe wrote:
>
> Greetings, part 2...
>
> After doing some tests, I found that this code works just fine:
>
> julia> using Distance
>
> Warning: could not import Base.foldl into NumericExtensions
>
> Warning: could not import Base.foldr into NumericExtensions
>
> Warning: could not import Base.sum! into NumericExtensions
>
> Warning: could not import Base.maximum! into NumericExtensions
>
> Warning: could not import Base.minimum! into NumericExtensions
>
>
>
>>

Re: [julia-users] How do I declare a baremodule in a macro?

[Jameson Nash]

macro modcreate(name)
Expr(:module, false, esc(name::Symbol), Expr(:begin))
end


On Thu, Jul 3, 2014 at 12:00 AM, Eric Davies  wrote:

> Hi all,
>
> I'm working on a multipass configuration file package and I'm having
> difficulty executing my ideas (I'm not great at the metaprogramming stuff
> yet). I want to create a baremodule in a macro and have it available to the
> scope containing the macro. I want to be able to pass the name of the
> baremodule as an argument to the macro. Unfortunately, every (probably
> terrible) strategy I try seems to give the error "name not defined" (where
> name is the argument to the macro containing the desired module name).
>
> I want it to work like this (toy example):
>
> julia> @modcreate foo
>
> julia> typeof(foo)
> Module
>
> Can anyone suggest possible contents for the macro that might produce the
> above behaviour?
>
> Thanks,
> Eric
>

Re: [julia-users] Re: more questions about sorted associative array

[Tim Holy]

On Wednesday, July 02, 2014 02:59:02 PM vava...@uwaterloo.ca wrote:
>  So my question to the forum is whether my tree code 
> can detect whether the user has put an @inbounds declaration in his/her 
> code when it invokes my routines.

Not yet. This is a very desirable feature, but it hasn't really had much 
discussion yet. Since you know C++, you can see how current @inbounds works by 
looking at codegen.cpp and cgutils.cpp (among others, but these are the main 
ones).

--Tim

[julia-users] How do I declare a baremodule in a macro?

[Eric Davies]

Hi all,

I'm working on a multipass configuration file package and I'm having 
difficulty executing my ideas (I'm not great at the metaprogramming stuff 
yet). I want to create a baremodule in a macro and have it available to the 
scope containing the macro. I want to be able to pass the name of the 
baremodule as an argument to the macro. Unfortunately, every (probably 
terrible) strategy I try seems to give the error "name not defined" (where 
name is the argument to the macro containing the desired module name).

I want it to work like this (toy example):

julia> @modcreate foo

julia> typeof(foo)
Module

Can anyone suggest possible contents for the macro that might produce the 
above behaviour?

Thanks,
Eric

[julia-users] Tagging a package

[Ben Ward]

Hi,

I'm trying to update a package for the first time with the new package 
manager commands like tag and so on:

*julia> **Pkg.publish()*

*INFO: Validating METADATA*

*INFO: Pushing Phylogenetics permanent tags: v0.0.2*

Permission denied (publickey).

fatal: Could not read from remote repository.



Please make sure you have the correct access rights

and the repository exists.

*ERROR: failed process: Process(`git 
--work-tree=/Users/axolotlfan9250/.julia/v0.3/Phylogenetics 
--git-dir=/Users/axolotlfan9250/.julia/v0.3/Phylogenetics/.git push -q 
origin refs/tags/v0.0.2:refs/tags/v0.0.2`, ProcessExited(128)) [128]*

* in wait at ./task.jl:279*

* in wait at ./task.jl:189*

* in wait at task.jl:48*

* in sync_end at ./task.jl:306*

* in publish at pkg/entry.jl:314*

* in anonymous at pkg/dir.jl:28*

* in cd at file.jl:20*

* in cd at pkg/dir.jl:28*

* in publish at pkg.jl:57*



I'm not 100% sure why I'm getting this, shouldn't it just send a PR to 
METADATA? I'm not 100% clear on how this works - do I need a fork of 
METADATA still? The process that fails looks like it's trying to push 
something to ward9250/Phylogenetics.jl? In which case I wonder if it's a 
naming issue Phylogenetics in .julia/v0.3/ and Phylogenetics.jl for the 
repo?

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Tony Kelman]

If you know all of the data in the csv file is numerical, you can provide a 
result type to readcsv, say readcsv("ct_coord.csv", Float64). See 
help(readdlm) for additional options for things like removing header rows, 
etc. If the data is of mixed types, then you may find readtable in the 
DataFrames package more capable.


On Wednesday, July 2, 2014 5:05:21 PM UTC-7, Donald Lacombe wrote:
>
> Actually, another issue with the type information.
>
> Instead of using random coordinates, I used actual latitude and longitude 
> coordinates from a CSV file like so:
>
> data = readcsv("ct_coord.csv");
>
> temp = [xc';yc']
>
> 2x8 Array{Any,2}:
>
>  -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999
>
>   41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488
>
>
> Now, the type here is {Any,2} and this seems to be giving the Distance 
> package problems:
>
>
>
> R = pairwise(Euclidean(),temp)
>
> MethodError(fptype,(Any,))
>
>
> Julia seems to be unhappy with this type but I'm not sure how to correct this 
> which would seem to require that the data being read in are of Float type.
>
>
> Again, thank you for all of the help.
>
>
> Don
>
>
>
> On Wednesday, July 2, 2014 7:10:09 PM UTC-4, Donald Lacombe wrote:
>>
>> Patrick,
>>
>> Thank you for the reply! I will try your suggestion and hopefully get a 
>> better grasp of these issues.
>>
>> Thank you all gain for all of the help. It cannot be stressed enough that 
>> the friendly and truly helpful comments will help the Julia community grow.
>>
>> Don
>>
>> On Wednesday, July 2, 2014 5:31:55 PM UTC-4, Patrick O'Leary wrote:
>>>
>>> The second parameter to the Array type is the number of dimensions of 
>>> the array. "Row vectors" are implemented with 2-dimensional arrays (a.k.a., 
>>> "matrices"), since Vectors (a.k.a. Array{T, 1} for all types T) are 
>>> interpreted as columns.
>>>
>>> Since pairwise() generates all of the distances simultaneously, you'll 
>>> need to slice its results to use it in sortperm(), following your original 
>>> loop implementation. Each slice will need to be a Vector. If you slice 
>>> columns, you get Vector slices for free. If you slice rows, the shape will 
>>> be maintained, so you get a row back. You can flatten this to a Vector with 
>>> the vec() function.
>>>
>>> Hope this helps!
>>>
>>> On Wednesday, July 2, 2014 4:23:52 PM UTC-5, Donald Lacombe wrote:

 After thinking about this issue, another couple of question came to 
 mind.

 When I create a row vector, say xc = randn(1,5), the results indicate 
 that the vector is e.g.

 xc = rand(1,5)

 1x5 Array{Float64,2}:

  0.989421  0.718148  0.499914  0.13024  0.939856


 The type is {Float64,2}.


 Questions:


 1) What does the "2" mean in {Float64,2}? If I create xc = rand(5) the 
 type is {Float64,1}.


 2) The sortperm function only seems to accept {Float64,1} types. The 
 Euclidean distance code create types of {Float64,2} but I need {Float64,1} 
 for the sortperm function. Do I need to convert these before using this 
 command?


 I'm probably missing something really basic so apologies for the query.


 Thanks,

 Don


 On Wednesday, July 2, 2014 4:20:55 PM UTC-4, Donald Lacombe wrote:
>
> Greetings, part 2...
>
> After doing some tests, I found that this code works just fine:
>
> julia> using Distance
>
> Warning: could not import Base.foldl into NumericExtensions
>
> Warning: could not import Base.foldr into NumericExtensions
>
> Warning: could not import Base.sum! into NumericExtensions
>
> Warning: could not import Base.maximum! into NumericExtensions
>
> Warning: could not import Base.minimum! into NumericExtensions
>
>
>
> julia> xc = rand(8)'
>
> 1x8 Array{Float64,2}:
>
>  0.30107  0.479169  0.230607  0.65126  0.386921  0.455316  0.921496  
> 0.244873
>
>
> julia> yc = rand(8)'
>
> 1x8 Array{Float64,2}:
>
>  0.866199  0.767794  0.76163  0.262925  …  0.742765  0.980952  0.424966
>
>
> julia> temp = [xc ; yc]
>
> 2x8 Array{Float64,2}:
>
>  0.30107   0.479169  0.230607  0.65126   …  0.455316  0.921496  0.244873
>
>  0.866199  0.767794  0.76163   0.262925 0.742765  0.980952  0.424966
>
>
> julia> R = pairwise(Euclidean(),temp)
>
> 8x8 Array{Float64,2}:
>
>  0.0   0.203477   0.126094  0.697548  …  0.197554   0.630949  0.444797
>
>  0.203477  0.00.248638  0.533393 0.0345751  0.491009  0.415241
>
>  0.126094  0.248638   0.0   0.652423 0.225499   0.724865  0.336966
>
>  0.697548  0.533393   0.652423  0.0  0.518306   0.767196  0.437502
>
>  0.376201  0.283308   0.304834  0.355027 0.252287   0.719136  0.160613
>
>  0.1

Re: [julia-users] Re: Decreasing range, should it work?

[Stefan Karpinski]

It changes the meaning of a:b in a capricious way based on their values,
which, while often appealing for the immediate situation – and thus rampant
in dynamic languages – is almost always terrible for writing predictable,
reliable code.


On Wed, Jul 2, 2014 at 1:07 PM, Jay Kickliter 
wrote:

> I assume that when I wake up at 5 AM to finish some DSP code. Really, it
> was just a stupid mistake. From a non-programmer's perspective (me), it
> seemed like it should have work. If you think that would be dangerous, I'll
> take your word for it.
>
>
> On Wednesday, July 2, 2014 8:26:10 AM UTC-6, Stefan Karpinski wrote:
>
>> Why would one assume that the default step size is -1 when the start is
>> bigger than the stop? The documentation for ranges clearly says that the
>> default step size is 1 unconditionally, not that it is sign(stop-start).
>> That would, by the way, be a very dangerous behavior. Perhaps a sidebar on
>> the colon syntax is warranted in the manual control flow section on for
>> loops, including examples of empty ranges and ranges that count downwards.
>>
>>
>> On Wed, Jul 2, 2014 at 9:53 AM, Jay Kickliter 
>> wrote:
>>
>>> I just realized that it works if I rewrite the range as 10:-1:1. It
>>> seems to me that either big:small should work with a default step size of
>>> -1, or the documentation needs a note.
>>>
>>>
>>> On Wednesday, July 2, 2014 7:32:10 AM UTC-6, Jay Kickliter wrote:

 Are they meant to work? I could only find one meaning of them not
 working (issue 5778 ).

 Here's an example:

 julia> for i = 1:10

println(i)

end

 1

 2

 3

 4

 5

 6

 7

 8

 9

 10


 julia> for i = 10:1

println(i)

end


 julia>

>>>
>>

Re: [julia-users] Re: Lowering the (mostly social/psychological) barriers to sharing packages?

[Sam L]

+1 for "Theme Parks"

On Wednesday, July 2, 2014 5:12:10 PM UTC-7, Hans W Borchers wrote:
>
> What about building something similar as the "task views" in R? (I don't 
> know what a better term there could be for it, perhaps "theme parks"?)
>
> Task views as Github projects could be expanded by the community easily. 
> The list of task views could be pointed to in the main menu of Julia's home 
> page. Each task view would have a maintainer, not an organization, because 
> there would be many more views than organizations. The maintainer can 
> decide whether he wants to include work in progress, etc.
>
>
> On Wednesday, July 2, 2014 11:15:20 PM UTC+2, Iain Dunning wrote:
>>
>> Great suggestions/discussion everyone. I think without a stronger vote of 
>> confidence in the idea there isn't much reason to proceed.
>>
>> Re: svaksha's list, it is good, and I'd be curious how much traffic it 
>> gets. Its kinda chaotic though and has some errors, mainly because its 
>> pretty hard to be an expert in everything (and thus able to describe and 
>> categorize them). Plus there is the whole problem of the many pieces of 
>> code that get mentioned on the list but are unmaintained - testing related 
>> packages being my personal favourite.
>>
>> I've got some ideas for changes to pkg.julialang.org that would raise 
>> the prominence of organizations, who I think should be the ones leading 
>> discoverability of the packages in their realm as they know their area 
>> best. I'm also thinking of more ways to indicate package 
>> "quality"/development level for integration in the UI (see the Github stars 
>> I added recently). I'm going to collect a bunch of metrics and mash them 
>> together - we can then discuss the weightings.
>>
>> Hans: understandable you wouldn't have heard about CVX.jl yet, its not 
>> ready for public consumption. Should be ready by end of summer, at least a 
>> first pass. As for BlackBoxOptim, I'm not sure if you are implying some 
>> effort by myself or others to exclude it from JuliaOpt or METADATA, but 
>> that isn't the case - the author just hasn't done the work to list it. I've 
>> just reached out to him again, but if you are interested in it, then you 
>> should help out - this is open source after all, and we are all busy with 
>> other things.
>>
>> On Wednesday, July 2, 2014 2:31:32 AM UTC-4, Hans W Borchers wrote:
>>>
>>> Thanks for the hint to this very helpful list of (mostly) not-metadated 
>>> packages. I started a list of Numerical Math packages for Julia myself, 
>>> because I did not find categorized or compiled information like here. Only 
>>> I am missing more information on optimization and simulation packages out 
>>> there.
>>>
>>> I think it is not so much a question of whether a package has enough 
>>> quality to be listed as a registered package. There will be package 
>>> developments going on for one or two years before they will appear on the 
>>> 'official' list, but I would still like to know about them.
>>>
>>> For example, I learned only from John Miles White's report on JuliaCon 
>>> about the CVX.jl package, though I had made a request about "convex 
>>> programming" on the julia-opt list some weeks ago.
>>>
>>> There is a useful BlackBoxOptim.jl package for global optimization that 
>>> has made it neither on the METADATA list nor on JuliaOpt page. I don't know 
>>> the reason, but the author seemed highly interested to see it there.
>>>
>>> Maybe, on the list of registered packages there should only appear 
>>> "recommended packages" (in the sense R adds them to the base installation). 
>>> And yes, information about other available packages needs to be improved -- 
>>> but perhaps this is more the task of the community, not of the core 
>>> developers, in the form of blogs or more pages like Svaksha's.
>>>
>>>
>>> On Wednesday, July 2, 2014 4:51:03 AM UTC+2, Isaiah wrote:

 On the discoverability side, svaksha's curated collection really 
 deserves more attention - it is categorized and provides short summaries 
 of 
 code ranging from listed packages to useful fragments that never showed up 
 on the mailing lists.

 http://svaksha.github.io/Julia.jl/

  
>>>
>>

Re: [julia-users] Re: Lowering the (mostly social/psychological) barriers to sharing packages?

[Hans W Borchers]

What about building something similar as the "task views" in R? (I don't 
know what a better term there could be for it, perhaps "theme parks"?)

Task views as Github projects could be expanded by the community easily. 
The list of task views could be pointed to in the main menu of Julia's home 
page. Each task view would have a maintainer, not an organization, because 
there would be many more views than organizations. The maintainer can 
decide whether he wants to include work in progress, etc.


On Wednesday, July 2, 2014 11:15:20 PM UTC+2, Iain Dunning wrote:
>
> Great suggestions/discussion everyone. I think without a stronger vote of 
> confidence in the idea there isn't much reason to proceed.
>
> Re: svaksha's list, it is good, and I'd be curious how much traffic it 
> gets. Its kinda chaotic though and has some errors, mainly because its 
> pretty hard to be an expert in everything (and thus able to describe and 
> categorize them). Plus there is the whole problem of the many pieces of 
> code that get mentioned on the list but are unmaintained - testing related 
> packages being my personal favourite.
>
> I've got some ideas for changes to pkg.julialang.org that would raise the 
> prominence of organizations, who I think should be the ones leading 
> discoverability of the packages in their realm as they know their area 
> best. I'm also thinking of more ways to indicate package 
> "quality"/development level for integration in the UI (see the Github stars 
> I added recently). I'm going to collect a bunch of metrics and mash them 
> together - we can then discuss the weightings.
>
> Hans: understandable you wouldn't have heard about CVX.jl yet, its not 
> ready for public consumption. Should be ready by end of summer, at least a 
> first pass. As for BlackBoxOptim, I'm not sure if you are implying some 
> effort by myself or others to exclude it from JuliaOpt or METADATA, but 
> that isn't the case - the author just hasn't done the work to list it. I've 
> just reached out to him again, but if you are interested in it, then you 
> should help out - this is open source after all, and we are all busy with 
> other things.
>
> On Wednesday, July 2, 2014 2:31:32 AM UTC-4, Hans W Borchers wrote:
>>
>> Thanks for the hint to this very helpful list of (mostly) not-metadated 
>> packages. I started a list of Numerical Math packages for Julia myself, 
>> because I did not find categorized or compiled information like here. Only 
>> I am missing more information on optimization and simulation packages out 
>> there.
>>
>> I think it is not so much a question of whether a package has enough 
>> quality to be listed as a registered package. There will be package 
>> developments going on for one or two years before they will appear on the 
>> 'official' list, but I would still like to know about them.
>>
>> For example, I learned only from John Miles White's report on JuliaCon 
>> about the CVX.jl package, though I had made a request about "convex 
>> programming" on the julia-opt list some weeks ago.
>>
>> There is a useful BlackBoxOptim.jl package for global optimization that 
>> has made it neither on the METADATA list nor on JuliaOpt page. I don't know 
>> the reason, but the author seemed highly interested to see it there.
>>
>> Maybe, on the list of registered packages there should only appear 
>> "recommended packages" (in the sense R adds them to the base installation). 
>> And yes, information about other available packages needs to be improved -- 
>> but perhaps this is more the task of the community, not of the core 
>> developers, in the form of blogs or more pages like Svaksha's.
>>
>>
>> On Wednesday, July 2, 2014 4:51:03 AM UTC+2, Isaiah wrote:
>>>
>>> On the discoverability side, svaksha's curated collection really 
>>> deserves more attention - it is categorized and provides short summaries of 
>>> code ranging from listed packages to useful fragments that never showed up 
>>> on the mailing lists.
>>>
>>> http://svaksha.github.io/Julia.jl/
>>>
>>>  
>>
>

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Actually, another issue with the type information.

Instead of using random coordinates, I used actual latitude and longitude 
coordinates from a CSV file like so:

data = readcsv("ct_coord.csv");

temp = [xc';yc']

2x8 Array{Any,2}:

 -73.3712  -72.1065  -73.2453  -71.9876  …  -72.7328  -72.5231  -72.8999

  41.22541.4667   41.7925   41.8341.8064   41.4354   41.3488


Now, the type here is {Any,2} and this seems to be giving the Distance package 
problems:



R = pairwise(Euclidean(),temp)

MethodError(fptype,(Any,))


Julia seems to be unhappy with this type but I'm not sure how to correct this 
which would seem to require that the data being read in are of Float type.


Again, thank you for all of the help.


Don



On Wednesday, July 2, 2014 7:10:09 PM UTC-4, Donald Lacombe wrote:
>
> Patrick,
>
> Thank you for the reply! I will try your suggestion and hopefully get a 
> better grasp of these issues.
>
> Thank you all gain for all of the help. It cannot be stressed enough that 
> the friendly and truly helpful comments will help the Julia community grow.
>
> Don
>
> On Wednesday, July 2, 2014 5:31:55 PM UTC-4, Patrick O'Leary wrote:
>>
>> The second parameter to the Array type is the number of dimensions of the 
>> array. "Row vectors" are implemented with 2-dimensional arrays (a.k.a., 
>> "matrices"), since Vectors (a.k.a. Array{T, 1} for all types T) are 
>> interpreted as columns.
>>
>> Since pairwise() generates all of the distances simultaneously, you'll 
>> need to slice its results to use it in sortperm(), following your original 
>> loop implementation. Each slice will need to be a Vector. If you slice 
>> columns, you get Vector slices for free. If you slice rows, the shape will 
>> be maintained, so you get a row back. You can flatten this to a Vector with 
>> the vec() function.
>>
>> Hope this helps!
>>
>> On Wednesday, July 2, 2014 4:23:52 PM UTC-5, Donald Lacombe wrote:
>>>
>>> After thinking about this issue, another couple of question came to mind.
>>>
>>> When I create a row vector, say xc = randn(1,5), the results indicate 
>>> that the vector is e.g.
>>>
>>> xc = rand(1,5)
>>>
>>> 1x5 Array{Float64,2}:
>>>
>>>  0.989421  0.718148  0.499914  0.13024  0.939856
>>>
>>>
>>> The type is {Float64,2}.
>>>
>>>
>>> Questions:
>>>
>>>
>>> 1) What does the "2" mean in {Float64,2}? If I create xc = rand(5) the type 
>>> is {Float64,1}.
>>>
>>>
>>> 2) The sortperm function only seems to accept {Float64,1} types. The 
>>> Euclidean distance code create types of {Float64,2} but I need {Float64,1} 
>>> for the sortperm function. Do I need to convert these before using this 
>>> command?
>>>
>>>
>>> I'm probably missing something really basic so apologies for the query.
>>>
>>>
>>> Thanks,
>>>
>>> Don
>>>
>>>
>>> On Wednesday, July 2, 2014 4:20:55 PM UTC-4, Donald Lacombe wrote:

 Greetings, part 2...

 After doing some tests, I found that this code works just fine:

 julia> using Distance

 Warning: could not import Base.foldl into NumericExtensions

 Warning: could not import Base.foldr into NumericExtensions

 Warning: could not import Base.sum! into NumericExtensions

 Warning: could not import Base.maximum! into NumericExtensions

 Warning: could not import Base.minimum! into NumericExtensions



 julia> xc = rand(8)'

 1x8 Array{Float64,2}:

  0.30107  0.479169  0.230607  0.65126  0.386921  0.455316  0.921496  
 0.244873


 julia> yc = rand(8)'

 1x8 Array{Float64,2}:

  0.866199  0.767794  0.76163  0.262925  …  0.742765  0.980952  0.424966


 julia> temp = [xc ; yc]

 2x8 Array{Float64,2}:

  0.30107   0.479169  0.230607  0.65126   …  0.455316  0.921496  0.244873

  0.866199  0.767794  0.76163   0.262925 0.742765  0.980952  0.424966


 julia> R = pairwise(Euclidean(),temp)

 8x8 Array{Float64,2}:

  0.0   0.203477   0.126094  0.697548  …  0.197554   0.630949  0.444797

  0.203477  0.00.248638  0.533393 0.0345751  0.491009  0.415241

  0.126094  0.248638   0.0   0.652423 0.225499   0.724865  0.336966

  0.697548  0.533393   0.652423  0.0  0.518306   0.767196  0.437502

  0.376201  0.283308   0.304834  0.355027 0.252287   0.719136  0.160613

  0.197554  0.0345751  0.225499  0.518306  …  0.00.523505  0.381159

  0.630949  0.491009   0.724865  0.767196 0.523505   0.0   0.87575 

  0.444797  0.415241   0.336966  0.437502 0.381159   0.87575   0.0 


 As expected, the diagonal elements are 0 and everything seems to work 
 fine although I did not test other distance formulas.

 I'm posing this so others can see the results and possibly make use of 
 this themselves.

 Is there a central repository for user submitted solutions or examples? 
 If 

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Patrick,

Thank you for the reply! I will try your suggestion and hopefully get a 
better grasp of these issues.

Thank you all gain for all of the help. It cannot be stressed enough that 
the friendly and truly helpful comments will help the Julia community grow.

Don

On Wednesday, July 2, 2014 5:31:55 PM UTC-4, Patrick O'Leary wrote:
>
> The second parameter to the Array type is the number of dimensions of the 
> array. "Row vectors" are implemented with 2-dimensional arrays (a.k.a., 
> "matrices"), since Vectors (a.k.a. Array{T, 1} for all types T) are 
> interpreted as columns.
>
> Since pairwise() generates all of the distances simultaneously, you'll 
> need to slice its results to use it in sortperm(), following your original 
> loop implementation. Each slice will need to be a Vector. If you slice 
> columns, you get Vector slices for free. If you slice rows, the shape will 
> be maintained, so you get a row back. You can flatten this to a Vector with 
> the vec() function.
>
> Hope this helps!
>
> On Wednesday, July 2, 2014 4:23:52 PM UTC-5, Donald Lacombe wrote:
>>
>> After thinking about this issue, another couple of question came to mind.
>>
>> When I create a row vector, say xc = randn(1,5), the results indicate 
>> that the vector is e.g.
>>
>> xc = rand(1,5)
>>
>> 1x5 Array{Float64,2}:
>>
>>  0.989421  0.718148  0.499914  0.13024  0.939856
>>
>>
>> The type is {Float64,2}.
>>
>>
>> Questions:
>>
>>
>> 1) What does the "2" mean in {Float64,2}? If I create xc = rand(5) the type 
>> is {Float64,1}.
>>
>>
>> 2) The sortperm function only seems to accept {Float64,1} types. The 
>> Euclidean distance code create types of {Float64,2} but I need {Float64,1} 
>> for the sortperm function. Do I need to convert these before using this 
>> command?
>>
>>
>> I'm probably missing something really basic so apologies for the query.
>>
>>
>> Thanks,
>>
>> Don
>>
>>
>> On Wednesday, July 2, 2014 4:20:55 PM UTC-4, Donald Lacombe wrote:
>>>
>>> Greetings, part 2...
>>>
>>> After doing some tests, I found that this code works just fine:
>>>
>>> julia> using Distance
>>>
>>> Warning: could not import Base.foldl into NumericExtensions
>>>
>>> Warning: could not import Base.foldr into NumericExtensions
>>>
>>> Warning: could not import Base.sum! into NumericExtensions
>>>
>>> Warning: could not import Base.maximum! into NumericExtensions
>>>
>>> Warning: could not import Base.minimum! into NumericExtensions
>>>
>>>
>>>
>>> julia> xc = rand(8)'
>>>
>>> 1x8 Array{Float64,2}:
>>>
>>>  0.30107  0.479169  0.230607  0.65126  0.386921  0.455316  0.921496  
>>> 0.244873
>>>
>>>
>>> julia> yc = rand(8)'
>>>
>>> 1x8 Array{Float64,2}:
>>>
>>>  0.866199  0.767794  0.76163  0.262925  …  0.742765  0.980952  0.424966
>>>
>>>
>>> julia> temp = [xc ; yc]
>>>
>>> 2x8 Array{Float64,2}:
>>>
>>>  0.30107   0.479169  0.230607  0.65126   …  0.455316  0.921496  0.244873
>>>
>>>  0.866199  0.767794  0.76163   0.262925 0.742765  0.980952  0.424966
>>>
>>>
>>> julia> R = pairwise(Euclidean(),temp)
>>>
>>> 8x8 Array{Float64,2}:
>>>
>>>  0.0   0.203477   0.126094  0.697548  …  0.197554   0.630949  0.444797
>>>
>>>  0.203477  0.00.248638  0.533393 0.0345751  0.491009  0.415241
>>>
>>>  0.126094  0.248638   0.0   0.652423 0.225499   0.724865  0.336966
>>>
>>>  0.697548  0.533393   0.652423  0.0  0.518306   0.767196  0.437502
>>>
>>>  0.376201  0.283308   0.304834  0.355027 0.252287   0.719136  0.160613
>>>
>>>  0.197554  0.0345751  0.225499  0.518306  …  0.00.523505  0.381159
>>>
>>>  0.630949  0.491009   0.724865  0.767196 0.523505   0.0   0.87575 
>>>
>>>  0.444797  0.415241   0.336966  0.437502 0.381159   0.87575   0.0 
>>>
>>>
>>> As expected, the diagonal elements are 0 and everything seems to work 
>>> fine although I did not test other distance formulas.
>>>
>>> I'm posing this so others can see the results and possibly make use of 
>>> this themselves.
>>>
>>> Is there a central repository for user submitted solutions or examples? 
>>> If so I'd like to post this so others can see or alternatively someone else 
>>> is free to use this (and the original code I posted) for future reference.
>>>
>>> Thank you all again for your help! I'm going to be coding some models 
>>> this summer and will probably be back to bug everyone again.
>>>
>>> Thanks,
>>> Don
>>>
>>> On Wednesday, July 2, 2014 10:22:58 AM UTC-4, Donald Lacombe wrote:

 Greetings!

 I am a new Julia user and have the following issue. I am writing code 
 to calculate a knn spatial weight matrix to estimate a spatial econometric 
 model. Using the MATLAB code from Jim LeSage's Econometrics Toolbox, I 
 converted that code into Julia as follows:

 xc = rand(8);

 yc = rand(8);

 n = length(xc);

 k = 2;

 distance = zeros(n);

 nnlist = zeros(n,k);

 tempw = zeros(n,n);


 for i=1:n;

 xi = xc[i,1];

   

[julia-users] Re: more questions about sorted associative array

[vavasis]

Dear Kevin,

Thanks for the responses!  I will look into using the 'state' for the 
iterator that can be later dereferenced.  Indeed, one has to be careful 
that the iterator could point to a data item that has been changed or 
deleted.  In C++, for each container operation there is a specification of 
whether iterators are invalidated by the operation.

As for multiple ways to index, the example I have in mind is as follows: if 
m is the associative map, (k,v) is a key-value pair, and i is an iterator 
(the pointer kind, like in C++) to (k,v), then m[k] should return v, while 
m[i] should return (k,v).  But I am asking the forum whether a distinctive 
syntax is available for the second variant.

Finally, with regard to the third issue, perhaps I didn't express my 
question well.  Suppose someone uses my 2-3 trees and has a statement in 
his/her code such as 
  i = next(m,i)
where m is the map and i is an iterator (of the pointer kind).  This 
statement is supposed to advance to the next item according to the 
sort-order of keys.  My routine that gets invoked is as follows:

function nextloc{K,D}(t::BalancedTree{K,D}, i::Int)
if i == 2
error("Attempt to advance past end of balanced tree")
end
ii = i
p = t.data[i].parent
while true
newp, newii = nextloc0(t, p, ii)
if newii == 2 || t.data[newii].parent > 0
return newii
end
p, ii = newp, newii
end
end

Now, suppose instead the user writes:

@inbounds i = next(m,i)

Then I would want a different (faster, less safe) version of 'nextloc' 
invoked.  In the different version, the preliminary safety-test whether 
i==2 is omitted, and the array subscript operations within my code are all 
prefixed by @inbounds.  So my question to the forum is whether my tree code 
can detect whether the user has put an @inbounds declaration in his/her 
code when it invokes my routines.

Thanks,
Steve


P.S. If you want to look at my code, please 
see: https://www.dropbox.com/s/021yc196j55d5yd/baltree.jl  This code is 
very preliminary and has not even been executed, except for insert and 
next.  (See the test routine test2(), which seems to work.)  The 'delete' 
code is currently a hack, and I need to write a proper delete code that 
shrinks the tree.

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Patrick O'Leary]

The second parameter to the Array type is the number of dimensions of the 
array. "Row vectors" are implemented with 2-dimensional arrays (a.k.a., 
"matrices"), since Vectors (a.k.a. Array{T, 1} for all types T) are 
interpreted as columns.

Since pairwise() generates all of the distances simultaneously, you'll need 
to slice its results to use it in sortperm(), following your original loop 
implementation. Each slice will need to be a Vector. If you slice columns, 
you get Vector slices for free. If you slice rows, the shape will be 
maintained, so you get a row back. You can flatten this to a Vector with 
the vec() function.

Hope this helps!

On Wednesday, July 2, 2014 4:23:52 PM UTC-5, Donald Lacombe wrote:
>
> After thinking about this issue, another couple of question came to mind.
>
> When I create a row vector, say xc = randn(1,5), the results indicate that 
> the vector is e.g.
>
> xc = rand(1,5)
>
> 1x5 Array{Float64,2}:
>
>  0.989421  0.718148  0.499914  0.13024  0.939856
>
>
> The type is {Float64,2}.
>
>
> Questions:
>
>
> 1) What does the "2" mean in {Float64,2}? If I create xc = rand(5) the type 
> is {Float64,1}.
>
>
> 2) The sortperm function only seems to accept {Float64,1} types. The 
> Euclidean distance code create types of {Float64,2} but I need {Float64,1} 
> for the sortperm function. Do I need to convert these before using this 
> command?
>
>
> I'm probably missing something really basic so apologies for the query.
>
>
> Thanks,
>
> Don
>
>
> On Wednesday, July 2, 2014 4:20:55 PM UTC-4, Donald Lacombe wrote:
>>
>> Greetings, part 2...
>>
>> After doing some tests, I found that this code works just fine:
>>
>> julia> using Distance
>>
>> Warning: could not import Base.foldl into NumericExtensions
>>
>> Warning: could not import Base.foldr into NumericExtensions
>>
>> Warning: could not import Base.sum! into NumericExtensions
>>
>> Warning: could not import Base.maximum! into NumericExtensions
>>
>> Warning: could not import Base.minimum! into NumericExtensions
>>
>>
>>
>> julia> xc = rand(8)'
>>
>> 1x8 Array{Float64,2}:
>>
>>  0.30107  0.479169  0.230607  0.65126  0.386921  0.455316  0.921496  0.244873
>>
>>
>> julia> yc = rand(8)'
>>
>> 1x8 Array{Float64,2}:
>>
>>  0.866199  0.767794  0.76163  0.262925  …  0.742765  0.980952  0.424966
>>
>>
>> julia> temp = [xc ; yc]
>>
>> 2x8 Array{Float64,2}:
>>
>>  0.30107   0.479169  0.230607  0.65126   …  0.455316  0.921496  0.244873
>>
>>  0.866199  0.767794  0.76163   0.262925 0.742765  0.980952  0.424966
>>
>>
>> julia> R = pairwise(Euclidean(),temp)
>>
>> 8x8 Array{Float64,2}:
>>
>>  0.0   0.203477   0.126094  0.697548  …  0.197554   0.630949  0.444797
>>
>>  0.203477  0.00.248638  0.533393 0.0345751  0.491009  0.415241
>>
>>  0.126094  0.248638   0.0   0.652423 0.225499   0.724865  0.336966
>>
>>  0.697548  0.533393   0.652423  0.0  0.518306   0.767196  0.437502
>>
>>  0.376201  0.283308   0.304834  0.355027 0.252287   0.719136  0.160613
>>
>>  0.197554  0.0345751  0.225499  0.518306  …  0.00.523505  0.381159
>>
>>  0.630949  0.491009   0.724865  0.767196 0.523505   0.0   0.87575 
>>
>>  0.444797  0.415241   0.336966  0.437502 0.381159   0.87575   0.0 
>>
>>
>> As expected, the diagonal elements are 0 and everything seems to work 
>> fine although I did not test other distance formulas.
>>
>> I'm posing this so others can see the results and possibly make use of 
>> this themselves.
>>
>> Is there a central repository for user submitted solutions or examples? 
>> If so I'd like to post this so others can see or alternatively someone else 
>> is free to use this (and the original code I posted) for future reference.
>>
>> Thank you all again for your help! I'm going to be coding some models 
>> this summer and will probably be back to bug everyone again.
>>
>> Thanks,
>> Don
>>
>> On Wednesday, July 2, 2014 10:22:58 AM UTC-4, Donald Lacombe wrote:
>>>
>>> Greetings!
>>>
>>> I am a new Julia user and have the following issue. I am writing code to 
>>> calculate a knn spatial weight matrix to estimate a spatial econometric 
>>> model. Using the MATLAB code from Jim LeSage's Econometrics Toolbox, I 
>>> converted that code into Julia as follows:
>>>
>>> xc = rand(8);
>>>
>>> yc = rand(8);
>>>
>>> n = length(xc);
>>>
>>> k = 2;
>>>
>>> distance = zeros(n);
>>>
>>> nnlist = zeros(n,k);
>>>
>>> tempw = zeros(n,n);
>>>
>>>
>>> for i=1:n;
>>>
>>> xi = xc[i,1];
>>>
>>> yi = yc[i,1];
>>>
>>> distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2
>>>
>>> temp = sortperm(distance)
>>>
>>> nnlist[i,1:k] = temp[2:k+1,1]';
>>>
>>> end
>>>
>>>
>>> for i=1:n
>>>
>>> tempw[i,nnlist[i,:]] = 1;
>>>
>>> end
>>>
>>>
>>> W = tempw/k;
>>>
>>>
>>> This is a "toy" example and I was wondering if I can use the Distance 
>>> package to simplify the distance = (xc - xi*ones(n)).^2 + (yc - 
>>> yi*ones(n)).^2 formula. I tried using the pairwise option like so:
>>>
>>>
>>> R = pairwise(E

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

After thinking about this issue, another couple of question came to mind.

When I create a row vector, say xc = randn(1,5), the results indicate that 
the vector is e.g.

xc = rand(1,5)

1x5 Array{Float64,2}:

 0.989421  0.718148  0.499914  0.13024  0.939856


The type is {Float64,2}.


Questions:


1) What does the "2" mean in {Float64,2}? If I create xc = rand(5) the type is 
{Float64,1}.


2) The sortperm function only seems to accept {Float64,1} types. The Euclidean 
distance code create types of {Float64,2} but I need {Float64,1} for the 
sortperm function. Do I need to convert these before using this command?


I'm probably missing something really basic so apologies for the query.


Thanks,

Don


On Wednesday, July 2, 2014 4:20:55 PM UTC-4, Donald Lacombe wrote:
>
> Greetings, part 2...
>
> After doing some tests, I found that this code works just fine:
>
> julia> using Distance
>
> Warning: could not import Base.foldl into NumericExtensions
>
> Warning: could not import Base.foldr into NumericExtensions
>
> Warning: could not import Base.sum! into NumericExtensions
>
> Warning: could not import Base.maximum! into NumericExtensions
>
> Warning: could not import Base.minimum! into NumericExtensions
>
>
>
> julia> xc = rand(8)'
>
> 1x8 Array{Float64,2}:
>
>  0.30107  0.479169  0.230607  0.65126  0.386921  0.455316  0.921496  0.244873
>
>
> julia> yc = rand(8)'
>
> 1x8 Array{Float64,2}:
>
>  0.866199  0.767794  0.76163  0.262925  …  0.742765  0.980952  0.424966
>
>
> julia> temp = [xc ; yc]
>
> 2x8 Array{Float64,2}:
>
>  0.30107   0.479169  0.230607  0.65126   …  0.455316  0.921496  0.244873
>
>  0.866199  0.767794  0.76163   0.262925 0.742765  0.980952  0.424966
>
>
> julia> R = pairwise(Euclidean(),temp)
>
> 8x8 Array{Float64,2}:
>
>  0.0   0.203477   0.126094  0.697548  …  0.197554   0.630949  0.444797
>
>  0.203477  0.00.248638  0.533393 0.0345751  0.491009  0.415241
>
>  0.126094  0.248638   0.0   0.652423 0.225499   0.724865  0.336966
>
>  0.697548  0.533393   0.652423  0.0  0.518306   0.767196  0.437502
>
>  0.376201  0.283308   0.304834  0.355027 0.252287   0.719136  0.160613
>
>  0.197554  0.0345751  0.225499  0.518306  …  0.00.523505  0.381159
>
>  0.630949  0.491009   0.724865  0.767196 0.523505   0.0   0.87575 
>
>  0.444797  0.415241   0.336966  0.437502 0.381159   0.87575   0.0 
>
>
> As expected, the diagonal elements are 0 and everything seems to work fine 
> although I did not test other distance formulas.
>
> I'm posing this so others can see the results and possibly make use of 
> this themselves.
>
> Is there a central repository for user submitted solutions or examples? If 
> so I'd like to post this so others can see or alternatively someone else is 
> free to use this (and the original code I posted) for future reference.
>
> Thank you all again for your help! I'm going to be coding some models this 
> summer and will probably be back to bug everyone again.
>
> Thanks,
> Don
>
> On Wednesday, July 2, 2014 10:22:58 AM UTC-4, Donald Lacombe wrote:
>>
>> Greetings!
>>
>> I am a new Julia user and have the following issue. I am writing code to 
>> calculate a knn spatial weight matrix to estimate a spatial econometric 
>> model. Using the MATLAB code from Jim LeSage's Econometrics Toolbox, I 
>> converted that code into Julia as follows:
>>
>> xc = rand(8);
>>
>> yc = rand(8);
>>
>> n = length(xc);
>>
>> k = 2;
>>
>> distance = zeros(n);
>>
>> nnlist = zeros(n,k);
>>
>> tempw = zeros(n,n);
>>
>>
>> for i=1:n;
>>
>> xi = xc[i,1];
>>
>> yi = yc[i,1];
>>
>> distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2
>>
>> temp = sortperm(distance)
>>
>> nnlist[i,1:k] = temp[2:k+1,1]';
>>
>> end
>>
>>
>> for i=1:n
>>
>> tempw[i,nnlist[i,:]] = 1;
>>
>> end
>>
>>
>> W = tempw/k;
>>
>>
>> This is a "toy" example and I was wondering if I can use the Distance 
>> package to simplify the distance = (xc - xi*ones(n)).^2 + (yc - 
>> yi*ones(n)).^2 formula. I tried using the pairwise option like so:
>>
>>
>> R = pairwise(Euclidean(),xc,yc) but received the following message:
>>
>>
>> R = pairwise(Euclidean(),xc,yc)
>>
>> MethodError(pairwise,(Euclidean(),[0.05961066617957589,0.018538084399339905,0.39282193332224646,0.7006919213133509,0.5099836895629475,0.8448415935222402,0.2985674570217043,0.8022287058003177],[0.5808687231553928,0.9655167324458858,0.026306556019434435,0.6565373244339141,0.11927452074471412,0.11873635450496622,0.6271632933770979,0.7081439899673692]))
>>
>> I'd like to be able to utilize the Distance package but am a bit stumped. 
>> The code as written works but it's bugging me that I cannot seem to get the 
>> above command to work. I also get the following error when loading Distance:
>>
>>
>> using Distance
>>
>> Warning: could not import Base.foldl into NumericExtensions
>>
>> Warning: could not import Base.foldr into NumericExtensions
>>
>> Warning: could not import Base.sum! into NumericExtension

Re: [julia-users] Re: Lowering the (mostly social/psychological) barriers to sharing packages?

[Iain Dunning]

Great suggestions/discussion everyone. I think without a stronger vote of 
confidence in the idea there isn't much reason to proceed.

Re: svaksha's list, it is good, and I'd be curious how much traffic it 
gets. Its kinda chaotic though and has some errors, mainly because its 
pretty hard to be an expert in everything (and thus able to describe and 
categorize them). Plus there is the whole problem of the many pieces of 
code that get mentioned on the list but are unmaintained - testing related 
packages being my personal favourite.

I've got some ideas for changes to pkg.julialang.org that would raise the 
prominence of organizations, who I think should be the ones leading 
discoverability of the packages in their realm as they know their area 
best. I'm also thinking of more ways to indicate package 
"quality"/development level for integration in the UI (see the Github stars 
I added recently). I'm going to collect a bunch of metrics and mash them 
together - we can then discuss the weightings.

Hans: understandable you wouldn't have heard about CVX.jl yet, its not 
ready for public consumption. Should be ready by end of summer, at least a 
first pass. As for BlackBoxOptim, I'm not sure if you are implying some 
effort by myself or others to exclude it from JuliaOpt or METADATA, but 
that isn't the case - the author just hasn't done the work to list it. I've 
just reached out to him again, but if you are interested in it, then you 
should help out - this is open source after all, and we are all busy with 
other things.

On Wednesday, July 2, 2014 2:31:32 AM UTC-4, Hans W Borchers wrote:
>
> Thanks for the hint to this very helpful list of (mostly) not-metadated 
> packages. I started a list of Numerical Math packages for Julia myself, 
> because I did not find categorized or compiled information like here. Only 
> I am missing more information on optimization and simulation packages out 
> there.
>
> I think it is not so much a question of whether a package has enough 
> quality to be listed as a registered package. There will be package 
> developments going on for one or two years before they will appear on the 
> 'official' list, but I would still like to know about them.
>
> For example, I learned only from John Miles White's report on JuliaCon 
> about the CVX.jl package, though I had made a request about "convex 
> programming" on the julia-opt list some weeks ago.
>
> There is a useful BlackBoxOptim.jl package for global optimization that 
> has made it neither on the METADATA list nor on JuliaOpt page. I don't know 
> the reason, but the author seemed highly interested to see it there.
>
> Maybe, on the list of registered packages there should only appear 
> "recommended packages" (in the sense R adds them to the base installation). 
> And yes, information about other available packages needs to be improved -- 
> but perhaps this is more the task of the community, not of the core 
> developers, in the form of blogs or more pages like Svaksha's.
>
>
> On Wednesday, July 2, 2014 4:51:03 AM UTC+2, Isaiah wrote:
>>
>> On the discoverability side, svaksha's curated collection really deserves 
>> more attention - it is categorized and provides short summaries of code 
>> ranging from listed packages to useful fragments that never showed up on 
>> the mailing lists.
>>
>> http://svaksha.github.io/Julia.jl/
>>
>>  
>

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Greetings, part 2...

After doing some tests, I found that this code works just fine:

julia> using Distance

Warning: could not import Base.foldl into NumericExtensions

Warning: could not import Base.foldr into NumericExtensions

Warning: could not import Base.sum! into NumericExtensions

Warning: could not import Base.maximum! into NumericExtensions

Warning: could not import Base.minimum! into NumericExtensions



julia> xc = rand(8)'

1x8 Array{Float64,2}:

 0.30107  0.479169  0.230607  0.65126  0.386921  0.455316  0.921496  0.244873


julia> yc = rand(8)'

1x8 Array{Float64,2}:

 0.866199  0.767794  0.76163  0.262925  …  0.742765  0.980952  0.424966


julia> temp = [xc ; yc]

2x8 Array{Float64,2}:

 0.30107   0.479169  0.230607  0.65126   …  0.455316  0.921496  0.244873

 0.866199  0.767794  0.76163   0.262925 0.742765  0.980952  0.424966


julia> R = pairwise(Euclidean(),temp)

8x8 Array{Float64,2}:

 0.0   0.203477   0.126094  0.697548  …  0.197554   0.630949  0.444797

 0.203477  0.00.248638  0.533393 0.0345751  0.491009  0.415241

 0.126094  0.248638   0.0   0.652423 0.225499   0.724865  0.336966

 0.697548  0.533393   0.652423  0.0  0.518306   0.767196  0.437502

 0.376201  0.283308   0.304834  0.355027 0.252287   0.719136  0.160613

 0.197554  0.0345751  0.225499  0.518306  …  0.00.523505  0.381159

 0.630949  0.491009   0.724865  0.767196 0.523505   0.0   0.87575 

 0.444797  0.415241   0.336966  0.437502 0.381159   0.87575   0.0 


As expected, the diagonal elements are 0 and everything seems to work fine 
although I did not test other distance formulas.

I'm posing this so others can see the results and possibly make use of this 
themselves.

Is there a central repository for user submitted solutions or examples? If 
so I'd like to post this so others can see or alternatively someone else is 
free to use this (and the original code I posted) for future reference.

Thank you all again for your help! I'm going to be coding some models this 
summer and will probably be back to bug everyone again.

Thanks,
Don

On Wednesday, July 2, 2014 10:22:58 AM UTC-4, Donald Lacombe wrote:
>
> Greetings!
>
> I am a new Julia user and have the following issue. I am writing code to 
> calculate a knn spatial weight matrix to estimate a spatial econometric 
> model. Using the MATLAB code from Jim LeSage's Econometrics Toolbox, I 
> converted that code into Julia as follows:
>
> xc = rand(8);
>
> yc = rand(8);
>
> n = length(xc);
>
> k = 2;
>
> distance = zeros(n);
>
> nnlist = zeros(n,k);
>
> tempw = zeros(n,n);
>
>
> for i=1:n;
>
> xi = xc[i,1];
>
> yi = yc[i,1];
>
> distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2
>
> temp = sortperm(distance)
>
> nnlist[i,1:k] = temp[2:k+1,1]';
>
> end
>
>
> for i=1:n
>
> tempw[i,nnlist[i,:]] = 1;
>
> end
>
>
> W = tempw/k;
>
>
> This is a "toy" example and I was wondering if I can use the Distance package 
> to simplify the distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2 
> formula. I tried using the pairwise option like so:
>
>
> R = pairwise(Euclidean(),xc,yc) but received the following message:
>
>
> R = pairwise(Euclidean(),xc,yc)
>
> MethodError(pairwise,(Euclidean(),[0.05961066617957589,0.018538084399339905,0.39282193332224646,0.7006919213133509,0.5099836895629475,0.8448415935222402,0.2985674570217043,0.8022287058003177],[0.5808687231553928,0.9655167324458858,0.026306556019434435,0.6565373244339141,0.11927452074471412,0.11873635450496622,0.6271632933770979,0.7081439899673692]))
>
> I'd like to be able to utilize the Distance package but am a bit stumped. The 
> code as written works but it's bugging me that I cannot seem to get the above 
> command to work. I also get the following error when loading Distance:
>
>
> using Distance
>
> Warning: could not import Base.foldl into NumericExtensions
>
> Warning: could not import Base.foldr into NumericExtensions
>
> Warning: could not import Base.sum! into NumericExtensions
>
> Warning: could not import Base.maximum! into NumericExtensions
>
> Warning: could not import Base.minimum! into NumericExtensions
>
>
> If there is anyone who can address this I'd greatly appreciate it. 
> Incidentally, the help on this group is one reason I am making the change.
>
>
> Don
>
>
>
>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[John Myles White]

Matrix multiplication is almost never commutative.

 -- John

On Jul 2, 2014, at 1:16 PM, Samuel Colvin  wrote:

> humm, I'm tempted to say multiplication is generally (if not always) 
> commutative too.
> 
> Anyway, some very interesting discussions, surely the point is that there 
> should be a concise explanation about string concatenation in the docs 
> somewhere, something like:
> 
> "you can do "hello"*"world" which is the same as string("hello", "world"), 
> the reason we don't use + is ..., for performance you should use IOBuffer for 
> repeated string concatenation, example..."
> 
> Also a more instructive error on "hello"+"world" would make since.
> 
> On Wednesday, 2 July 2014 20:48:26 UTC+1, John Myles White wrote:
> String concatenation is not commutative. Addition is generally used for 
> commutative operations. So if you're a mathematician, using addition for 
> string concatentation seems very wrong.
> 
>  -- John
> 
> On Jul 2, 2014, at 12:45 PM, Ivar Nesje  wrote:
> 
>> Not everybody is convinced there is a good reason. See some discussion about 
>> it in https://github.com/JuliaLang/julia/issues/1771
>> 
>> kl. 21:17:25 UTC+2 onsdag 2. juli 2014 skrev Samuel Colvin følgende:
>> There's no method +(s1::String, s2::String) instead string concatenation has 
>> to be done with
>> 
>>   a="hello "*"world
>> 
>> This is pretty unusual and unintuitive, so I'm guessing there a really good 
>> reason for it? 
> 

Re: [julia-users] Re: Why is string concatenation done with * not +

[Samuel Colvin]

humm, I'm tempted to say multiplication is generally (if not 
always) commutative too.

Anyway, some very interesting discussions, surely the point is that there 
should be a concise explanation about string concatenation in the docs 
somewhere, something like:

"you can do "hello"*"world" which is the same as string("hello", "world"), 
the reason we don't use + is ..., for performance you should use IOBuffer 
for repeated string concatenation, example..."

Also a more instructive error on "hello"+"world" would make since.

On Wednesday, 2 July 2014 20:48:26 UTC+1, John Myles White wrote:
>
> String concatenation is not commutative. Addition is generally used for 
> commutative operations. So if you're a mathematician, using addition for 
> string concatentation seems very wrong.
>
>  -- John
>
> On Jul 2, 2014, at 12:45 PM, Ivar Nesje > 
> wrote:
>
> Not everybody is convinced there is a good reason. See some discussion 
> about it in https://github.com/JuliaLang/julia/issues/1771
>
> kl. 21:17:25 UTC+2 onsdag 2. juli 2014 skrev Samuel Colvin følgende:
>>
>> There's no method +(s1::String, s2::String) instead string concatenation 
>> has to be done with
>>
>>   a="hello "*"world
>>
>> This is pretty unusual and unintuitive, so I'm guessing there a really 
>> good reason for it? 
>>
>
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[John Myles White]

String concatenation is not commutative. Addition is generally used for 
commutative operations. So if you're a mathematician, using addition for string 
concatentation seems very wrong.

 -- John

On Jul 2, 2014, at 12:45 PM, Ivar Nesje  wrote:

> Not everybody is convinced there is a good reason. See some discussion about 
> it in https://github.com/JuliaLang/julia/issues/1771
> 
> kl. 21:17:25 UTC+2 onsdag 2. juli 2014 skrev Samuel Colvin følgende:
> There's no method +(s1::String, s2::String) instead string concatenation has 
> to be done with
> 
>   a="hello "*"world
> 
> This is pretty unusual and unintuitive, so I'm guessing there a really good 
> reason for it? 

[julia-users] Re: Why is string concatenation done with * not +

[Ivar Nesje]

Not everybody is convinced there is a good reason. See some discussion 
about it in https://github.com/JuliaLang/julia/issues/1771

kl. 21:17:25 UTC+2 onsdag 2. juli 2014 skrev Samuel Colvin følgende:
>
> There's no method +(s1::String, s2::String) instead string concatenation 
> has to be done with
>
>   a="hello "*"world
>
> This is pretty unusual and unintuitive, so I'm guessing there a really 
> good reason for it? 
>

Re: [julia-users] Re: Why is string concatenation done with * not +

[Spencer Russell]

It's a bit tricky to track down the relevant discussions, but this one
seems like one of the most to-the-point:

https://groups.google.com/forum/#!msg/julia-dev/4K6S7tWnuEs/RF6x-f59IaoJ

peace,
s


On Wed, Jul 2, 2014 at 3:40 PM, Patrick O'Leary 
wrote:

> On Wednesday, July 2, 2014 2:17:25 PM UTC-5, Samuel Colvin wrote:
>>
>> There's no method +(s1::String, s2::String) instead string concatenation
>> has to be done with
>>
>>   a="hello "*"world
>>
>> This is pretty unusual and unintuitive, so I'm guessing there a really
>> good reason for it?
>>
>
> There's a theoretical motivation, which I'm no good at explaining, but it
> does generalize nicely:
>
> "hello, "^3 == "hello, hello, hello, "
>
> You can search the list (and I think also Github issues) a bit for
> Stefan's deeper explanations on the topic.
>

[julia-users] Re: Why is string concatenation done with * not +

[Patrick O'Leary]

On Wednesday, July 2, 2014 2:17:25 PM UTC-5, Samuel Colvin wrote:
>
> There's no method +(s1::String, s2::String) instead string concatenation 
> has to be done with
>
>   a="hello "*"world
>
> This is pretty unusual and unintuitive, so I'm guessing there a really 
> good reason for it? 
>

There's a theoretical motivation, which I'm no good at explaining, but it 
does generalize nicely:

"hello, "^3 == "hello, hello, hello, "

You can search the list (and I think also Github issues) a bit for Stefan's 
deeper explanations on the topic.

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Patrick O'Leary]

On Wednesday, July 2, 2014 9:22:58 AM UTC-5, Donald Lacombe wrote:
>
> R = pairwise(Euclidean(),xc,yc) but received the following message:
>

Given your usage, I believe you need to concatenate your xc and yc matrices 
such that each column is a point in your plane, and call the two-argument 
form of pairwise(). You can generate that directly: Xc=rand(2, 8), with the 
first row taken as xc and the second as yc.

The Distance.jl README gets into the sizes and meanings of the input(s) to 
pairwise(): 
https://github.com/JuliaStats/Distance.jl#computing-pairwise-distances

[julia-users] Why is string concatenation done with * not +

[Samuel Colvin]

There's no method +(s1::String, s2::String) instead string concatenation 
has to be done with

  a="hello "*"world

This is pretty unusual and unintuitive, so I'm guessing there a really good 
reason for it? 

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Johan Sigfrids]

I don't know exactly how the Distance functions are to be used but if you 
do methods(pairwise) you see that it is only define if x and y are two 
dimensional. 

On Wednesday, July 2, 2014 5:22:58 PM UTC+3, Donald Lacombe wrote:
>
> Greetings!
>
> I am a new Julia user and have the following issue. I am writing code to 
> calculate a knn spatial weight matrix to estimate a spatial econometric 
> model. Using the MATLAB code from Jim LeSage's Econometrics Toolbox, I 
> converted that code into Julia as follows:
>
> xc = rand(8);
>
> yc = rand(8);
>
> n = length(xc);
>
> k = 2;
>
> distance = zeros(n);
>
> nnlist = zeros(n,k);
>
> tempw = zeros(n,n);
>
>
> for i=1:n;
>
> xi = xc[i,1];
>
> yi = yc[i,1];
>
> distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2
>
> temp = sortperm(distance)
>
> nnlist[i,1:k] = temp[2:k+1,1]';
>
> end
>
>
> for i=1:n
>
> tempw[i,nnlist[i,:]] = 1;
>
> end
>
>
> W = tempw/k;
>
>
> This is a "toy" example and I was wondering if I can use the Distance package 
> to simplify the distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2 
> formula. I tried using the pairwise option like so:
>
>
> R = pairwise(Euclidean(),xc,yc) but received the following message:
>
>
> R = pairwise(Euclidean(),xc,yc)
>
> MethodError(pairwise,(Euclidean(),[0.05961066617957589,0.018538084399339905,0.39282193332224646,0.7006919213133509,0.5099836895629475,0.8448415935222402,0.2985674570217043,0.8022287058003177],[0.5808687231553928,0.9655167324458858,0.026306556019434435,0.6565373244339141,0.11927452074471412,0.11873635450496622,0.6271632933770979,0.7081439899673692]))
>
> I'd like to be able to utilize the Distance package but am a bit stumped. The 
> code as written works but it's bugging me that I cannot seem to get the above 
> command to work. I also get the following error when loading Distance:
>
>
> using Distance
>
> Warning: could not import Base.foldl into NumericExtensions
>
> Warning: could not import Base.foldr into NumericExtensions
>
> Warning: could not import Base.sum! into NumericExtensions
>
> Warning: could not import Base.maximum! into NumericExtensions
>
> Warning: could not import Base.minimum! into NumericExtensions
>
>
> If there is anyone who can address this I'd greatly appreciate it. 
> Incidentally, the help on this group is one reason I am making the change.
>
>
> Don
>
>
>
>
>

Re: [julia-users] equivalent to numpy's fftfreq

[João Felipe Santos]

Oh, we will need a different implementation to support arrays as well as
the Frequencies abstract array. Thanks for reporting this issue, by the way!

--
João Felipe Santos


On Wed, Jul 2, 2014 at 1:38 PM, Andrei Berceanu 
wrote:

> Ok, tnx :)
> But now `fftshift`, which before used to work, gives:
>
> > fftshift(DSP.fftfreq(10))
>
> type: circshift: in typeassert, expected Frequencies, got Array{Float64,1}
>
>
> in circshift at abstractarray.jl:417
>  in fftshift at dsp.jl:145
>
>
> On Wednesday, July 2, 2014 5:01:01 PM UTC+2, João Felipe Santos wrote:
>
>> Hi Andrei,
>>
>> you can use fftfreq in DSP.jl. The syntax is exactly the same as for your
>> function: http://dspjl.readthedocs.org/en/latest/util.html#fftfreq.
>>
>> Best
>>
>> --
>> João Felipe Santos
>>
>>
>> On Wed, Jul 2, 2014 at 9:28 AM, Andrei Berceanu 
>> wrote:
>>
>>> I have written the following function to provide the same functionality
>>> as numpy's fftfreq (http://docs.scipy.org/doc/numpy/reference/generated/
>>> numpy.fft.fftfreq.html)
>>>
>>> ```
>>> function fftfreq(n::Int64, d::Float64)
>>>   N = fld(n-1,2)
>>>   p1 = [0:N]
>>>   p2 = [-fld(n,2):-1]
>>>   return [p1, p2]/(d*n)
>>> end
>>> ```
>>>
>>> From the response on https://github.com/JuliaLang/julia/issues/7317, I
>>> understand that such a function is already implemented in the DSP.jl
>>> package, perhaps using the immutable Frequencies?
>>> I am not quite sure how to use that though, could anyone please provide
>>> a concrete example which reproduces the use of fftfreq? Tnx!
>>>
>>
>>

[julia-users] Re: Using Distance Package for knn Weight Matrix

[Ivar Nesje]

The warnings are (probably) harmless, and is because NumericExtensions 
extends some functions that was added to Julia after 0.2 was released. 
Currently we have some problems with packages that does not properly work 
with the 0.2 version of Julia. The 0.3 version is not far from being 
released, so you should be fine upgrading to the prerelease versions.

I hope someone else answers the Distance.jl related questions.

kl. 16:22:58 UTC+2 onsdag 2. juli 2014 skrev Donald Lacombe følgende:
>
> Greetings!
>
> I am a new Julia user and have the following issue. I am writing code to 
> calculate a knn spatial weight matrix to estimate a spatial econometric 
> model. Using the MATLAB code from Jim LeSage's Econometrics Toolbox, I 
> converted that code into Julia as follows:
>
> xc = rand(8);
>
> yc = rand(8);
>
> n = length(xc);
>
> k = 2;
>
> distance = zeros(n);
>
> nnlist = zeros(n,k);
>
> tempw = zeros(n,n);
>
>
> for i=1:n;
>
> xi = xc[i,1];
>
> yi = yc[i,1];
>
> distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2
>
> temp = sortperm(distance)
>
> nnlist[i,1:k] = temp[2:k+1,1]';
>
> end
>
>
> for i=1:n
>
> tempw[i,nnlist[i,:]] = 1;
>
> end
>
>
> W = tempw/k;
>
>
> This is a "toy" example and I was wondering if I can use the Distance package 
> to simplify the distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2 
> formula. I tried using the pairwise option like so:
>
>
> R = pairwise(Euclidean(),xc,yc) but received the following message:
>
>
> R = pairwise(Euclidean(),xc,yc)
>
> MethodError(pairwise,(Euclidean(),[0.05961066617957589,0.018538084399339905,0.39282193332224646,0.7006919213133509,0.5099836895629475,0.8448415935222402,0.2985674570217043,0.8022287058003177],[0.5808687231553928,0.9655167324458858,0.026306556019434435,0.6565373244339141,0.11927452074471412,0.11873635450496622,0.6271632933770979,0.7081439899673692]))
>
> I'd like to be able to utilize the Distance package but am a bit stumped. The 
> code as written works but it's bugging me that I cannot seem to get the above 
> command to work. I also get the following error when loading Distance:
>
>
> using Distance
>
> Warning: could not import Base.foldl into NumericExtensions
>
> Warning: could not import Base.foldr into NumericExtensions
>
> Warning: could not import Base.sum! into NumericExtensions
>
> Warning: could not import Base.maximum! into NumericExtensions
>
> Warning: could not import Base.minimum! into NumericExtensions
>
>
> If there is anyone who can address this I'd greatly appreciate it. 
> Incidentally, the help on this group is one reason I am making the change.
>
>
> Don
>
>
>
>
>

Re: [julia-users] Julia dispatches to less specific method

[Mauro]

Bill, can you file a bug report for this?

https://github.com/JuliaLang/julia/issues?milestone=7&state=open

On Tue, 2014-07-01 at 09:59, mauro...@runbox.com wrote:
> Yes, this seems odd.  I think it's a bug.  First, this also works:
>
> function scale!{T<:Number}(A::Tridiagonal{T}, x::T)
>Base.scale!(A.dl, x) 
>Base.scale!(A.d,  x)
>Base.scale!(A.du, x)
>return
> end
>
> and is probably what you want as T needs to be a number for this to make
> sense.  Still:
>
> I tried reproducing this with another function, which then gives the
> expected ambiguity warning:
>
> julia> f{T,N}(X::AbstractArray{T,N},s::Number) = 1
> f (generic function with 1 method)
>
> julia> f{T}(X::Tridiagonal{T},s::T) = 1
> Warning: New definition 
> f(Tridiagonal{T},T) at none:1
> is ambiguous with: 
> f(AbstractArray{T,N},Number) at none:1.
> To fix, define 
> f(Tridiagonal{_<:Number},_<:Number)
> before the new definition.
> f (generic function with 2 methods)
>
> julia> f{T<:Number}(X::Tridiagonal{T},s::T) = 1
> f (generic function with 3 methods)
>
> I think you're right, the scale! definition as you tried should give an
> ambiguity warning but it doesn't.  A bug.
>
> Then trying changing the order of above definitions does not give an
> ambiguity warning either.  I would have thought that ambiguities should
> be commutative?
>
> julia> f{T}(X::Tridiagonal{T},s::T) = 1
> f (generic function with 1 method)
>
> julia> A=Tridiagonal(rand(3),rand(4),rand(3));
>
> julia> f(A, 1.)
> 1
>
> julia> f{T,N}(X::AbstractArray{T,N},s::Number) = 2
> f (generic function with 2 methods)
>
> julia> f(A, 1.)
> 1
>
> julia> f(rand(3,3), 1.)
> 2
>
> julia> f{T<:Number}(X::Tridiagonal{T},s::T) = 3
> f (generic function with 3 methods)
>
> julia> f(A, 1.)
> 3
>
>
> On Tue, 2014-07-01 at 06:46, naelcml...@gmail.com wrote:
>> I wanted a scale! method that works for tridiagonal matrices and did the 
>> following.
>>
>> import Base.scale!
>>
>> function scale!{T}(A::Tridiagonal{T}, x::T)
>> Base.scale!(A.dl, x) 
>> Base.scale!(A.d,  x)
>> Base.scale!(A.du, x)
>> return
>> end
>>
>> Doing 
>>
>> methods(scale!)
>>
>> gives the output
>>
>> # 15 methods for generic function "scale!":
>> scale!{T<:Union(Complex{Float64},Float32,Complex{Float32},Float64)}(X::Array{T<:Union(Complex{Float64},Float32,Complex{Float32},Float64),N},s::T<:Union(Complex{Float64},Float32,Complex{Float32},Float64))
>>  
>> at linalg/dense.jl:11
>> ...
>> scale!(X::AbstractArray{T,N},s::Number) at linalg/generic.jl:20
>> ...
>> (A::CholmodSparse{T<:Union(Complex{Float64},Float32,Complex{Float32},Float64),Ti<:Union(Int64,Int32)},b::Array{T<:Union(Complex{Float64},Float32,Complex{Float32},Float64),1})
>>  
>> at linalg/cholmod.jl:907
>> scale!{T}(A::Tridiagonal{T},x::T) at none:2
>>
>> however
>>
>> A=Tridiagonal(rand(3),rand(4),rand(3))
>> 4x4 Tridiagonal{Float64}:
>>  0.342959   0.878001  0.00.0 
>>  0.0359927  0.481333  0.950373   0.0 
>>  0.00.764103  0.0200941  0.84859 
>>  0.00.0   0.220059   0.131956
>>
>> scale!(A,2.0)
>> ERROR: indexing not defined for Tridiagonal{Float64}
>>  in generic_scale! at linalg/generic.jl:16
>>  in scale! at linalg/generic.jl:20
>>
>> We can verify that Julia is not dispatching to the tridiagonal scale! 
>> method:
>>
>> which(scale!, (Tridiagonal{Float64},Float64))
>> scale!(X::AbstractArray{T,N},s::Number) at linalg/generic.jl:20
>>
>> If I change the first line of the function definition to
>>
>> function scale!(A::Tridiagonal,x)
>>
>> then I get some ambiguity warnings:
>>
>> Warning: New definition 
>> scale!(Tridiagonal{T},Any) at none:2
>> is ambiguous with: 
>> scale!(AbstractArray{T,N},Number) at linalg/generic.jl:20.
>> To fix, define 
>> scale!(Tridiagonal{T},Number)
>> before the new definition.
>> Warning: New definition 
>> scale!(Tridiagonal{T},Any) at none:2
>> is ambiguous with: 
>> scale!(AbstractArray{T,2},AbstractArray{T,1}) at linalg/generic.jl:306.
>> To fix, define 
>> scale!(Tridiagonal{T},AbstractArray{T,1})
>> before the new definition.
>> scale! (generic function with 15 methods)
>>
>> Sure enough, defining 
>>
>> function scale!(A::Tridiagonal, x::Number)
>> Base.scale!(A.dl, x)
>> Base.scale!(A.d,  x)
>> Base.scale!(A.du, x)
>> return
>> end
>>
>> works fine. I am a bit mystified by this behaviour.  Why was there no 
>> warning for my first attempt?
>> Is there a problem in general with making a method "too specific"?

Re: [julia-users] more questions about sorted associative array

[Kevin Squire]

Hi Steve,

I'm sorry that you haven't gotten faster responses.  I think the main issue
is that not many people have worked on data structures in Julia, so there
aren't too many people who feel qualified to respond.  You might get a
faster response if you split up your questions among multiple emails/posts.

Some responses inline below.


As mentioned in earlier posts, I'm working on a 2-3 tree implementation of
> sorted associative arrays (analogous to map and multimap in C++).  This is
> like Dict in Julia, except that the key/value pairs can be retrieved in
> sort-order on the keys.
>
> For my preliminary implementation, the timing for a sequence of  10^7
> insert and find operations is encouraging: my Julia 2-3 trees: 10 sec; my
> Julia 2-3 trees with @inbounds everywhere: 8 sec; my C++ 2-3 trees: 20 sec;
> my C++ 2-3 trees with /O2 compilation: 6 sec; native C++ map (red/black
> trees) with /O2 compilation: 5 sec.
>

That is quite encouraging!


> I have a few additional questions.
>
> (1) Iteration: The Julia manual describes a start/next/done formulation
> for iteration in which the iterator returns (key,value) pairs.   However,
> this is not adequate for some uses of maps.  In C++ an iterator is like a
> pointer to the (key,value) pair or like a subscript of an array.  The
> usefulness of this approach is that the iterator itself can be stored in
> another data structure and then dereferenced much later.  I'm wondering
> whether there is a convention in Julia for naming and operating with this
> kind of iterator.  (It could be related to the 'state' data item described
> in 2.1.7 of the manual.)
>

In Julia, it is common to use a separate immutable data type to store the
state of an iterator, and if set up properly, the iterator can be
dereferenced later.  The Iterators.jl package and base/iterators.jl have a
number of examples of this type of iterator, and that's the closest thing
to a Julia convention. (Did we talk about this already?)

The main things to be careful of using that idiom are 1) even if the state
itself is immutable, the referenced values may be types that allow mutation
of their values, 2) the state might point into a container (e.g., an array
location), and may not be valid if the container contents change, or 3) the
state may refer to an object that itself might change or no longer be part
of the datastructure (e.g., a node in a tree).  The object won't be garbage
collected since there's a reference to it, but it won't be useful either.


> (2) Related to the above question: if m is the map and i is the iterator,
> then a second getindex can be implemented so that m[i] returns the
> key-value pair.  However, it is a bit confusing to overload [] in this way
> because of the resemblance to m[k] where k is a key that returns just the
> value.  Does Julia offer the possibility of overloading some other
> subscript notation besides []? For example, maybe Julia could implement a
> syntax like m[. i .] or something that would call getindex2 and setindex2?
>  it seems to me that there will be other cases when a user has a data
> structure that can be indexed in more than one way.  I suppose this must
> already come up with sparse matrices?
>


At this point, there is no direct way to index an item in more than one
way.  For Julia's Associative types, getindex(key) returns the value
associated with that key.  The default iterator returns (key, value) pairs,
and you can just iterate over keys or values with keys(d) or values(d).
 See the associative data structures section of the Standard Library manual
for more information.

I'm curious how else you want to index?  If you have the key, creating the
(key, value) pair is straightforward.  Trees typically don't allow indexing
by position, though it obviously can be done by storing extra information
in the tree.  Is this what you'd like to do?

One way to do this would be to create a hidden wrapper class, which would
allow this.  For example:

myMap = SortedDict({"aardvark"=>"Super Cool!", "armadillo"=>"How Texan!",
"zebra"=>"African Mambo"})
println(arrayview(myMap)[1])   # prints ("aardvark", "Super Cool!")
av = arrayview(myMap)
println(av[end])   # prints ("zebra", "African Mambo")

Here, arrayview would return an array-like view into the dictionary (which
would be implemented as a separate type.

I don't think this has precedent in Julia, though I think that's mostly
because the data structures haven't become that sophisticated yet.  I might
use this idea for OrderedDicts, though.


>
> (3) @inbounds: Is there a way for a user-written data structure to check
> whether @inbounds is active, and if so, to use a different faster version
> of (user-written) getindex and setindex?
>

I believe the answer is no, since bounds checking is inserted as needed
done during compilation.  I think it would probably be a bad idea for user
code to need this level of reasoning.  If you explicitly check bounds
somewhere, your code itself can use `

Re: [julia-users] equivalent to numpy's fftfreq

[Andrei Berceanu]

Ok, tnx :)
But now `fftshift`, which before used to work, gives:

> fftshift(DSP.fftfreq(10))

type: circshift: in typeassert, expected Frequencies, got Array{Float64,1}


in circshift at abstractarray.jl:417
 in fftshift at dsp.jl:145


On Wednesday, July 2, 2014 5:01:01 PM UTC+2, João Felipe Santos wrote:
>
> Hi Andrei,
>
> you can use fftfreq in DSP.jl. The syntax is exactly the same as for your 
> function: http://dspjl.readthedocs.org/en/latest/util.html#fftfreq.
>
> Best
>
> --
> João Felipe Santos
>
>
> On Wed, Jul 2, 2014 at 9:28 AM, Andrei Berceanu  > wrote:
>
>> I have written the following function to provide the same functionality 
>> as numpy's fftfreq (
>> http://docs.scipy.org/doc/numpy/reference/generated/numpy.fft.fftfreq.html
>> )
>>
>> ```
>> function fftfreq(n::Int64, d::Float64)
>>   N = fld(n-1,2)
>>   p1 = [0:N]
>>   p2 = [-fld(n,2):-1]
>>   return [p1, p2]/(d*n)
>> end
>> ```
>>
>> From the response on https://github.com/JuliaLang/julia/issues/7317, I 
>> understand that such a function is already implemented in the DSP.jl 
>> package, perhaps using the immutable Frequencies?
>> I am not quite sure how to use that though, could anyone please provide a 
>> concrete example which reproduces the use of fftfreq? Tnx!
>>
>
>

Re: [julia-users] Re: Capture the output of Julia's console

[Laszlo Hars]

> Does it mean that the problem is in somewhere else, or it will work with 
the next nightly?
Nope, with the current nightly prerelease Julia version console display 
still does not appear in STDOUT. Redefinition of Base.display() to print() 
does not help, either, so the problem is still open. Any more ideas?

On Tuesday, July 1, 2014 2:52:29 PM UTC-7, Laszlo Hars wrote:
>
> >(Steve) juliarc.jl is run before the REPL is initialized
> I thought about that possibility, and tried also manually typing in
> pushdisplay(TextDisplay(STDOUT))
> when the REPL is up and running. There is no difference: the Julia console 
> output just does not appear on my STDOUT
>
> >(Keno) I fixed this so that any display pushed in .juliarc.jl will be on 
> top of the display stack
> Does it mean the the problem is in somewhere else, or it will work with 
> the next nightly?
>
>
> On Tuesday, July 1, 2014 2:14:06 PM UTC-7, Keno Fischer wrote:
>>
>> Actually, I fixed this so that any display pushed in .juliarc.jl will be 
>> on top of the display stack.
>>
>>
>> On Tue, Jul 1, 2014 at 5:12 PM, Steven G. Johnson  
>> wrote:
>>
>>> On Tuesday, July 1, 2014 1:20:25 PM UTC-4, Laszlo Hars wrote:

 This is what I have in my juliarc.jl file
 ~~~
 pushdisplay(TextDisplay(STDOUT)) 

>>>
>>> I think the problem is that .juliarc.jl is run before the REPL is 
>>> initialized, whereas you want to push the display afterwards.  i.e. your 
>>> TextDisplay is no longer on top of the display stack when the REPL runs.
>>>
>>> Why are you using juliarc.jl for this?   It seems more sensible to put 
>>> the script you want into a file myrepl.jl, and then just run julia 
>>> myrepl.jl ... 
>>>
>>
>>

Re: [julia-users] Re: Decreasing range, should it work?

[Jay Kickliter]

I assume that when I wake up at 5 AM to finish some DSP code. Really, it 
was just a stupid mistake. From a non-programmer's perspective (me), it 
seemed like it should have work. If you think that would be dangerous, I'll 
take your word for it.

On Wednesday, July 2, 2014 8:26:10 AM UTC-6, Stefan Karpinski wrote:
>
> Why would one assume that the default step size is -1 when the start is 
> bigger than the stop? The documentation for ranges clearly says that the 
> default step size is 1 unconditionally, not that it is sign(stop-start). 
> That would, by the way, be a very dangerous behavior. Perhaps a sidebar on 
> the colon syntax is warranted in the manual control flow section on for 
> loops, including examples of empty ranges and ranges that count downwards.
>
>
> On Wed, Jul 2, 2014 at 9:53 AM, Jay Kickliter  > wrote:
>
>> I just realized that it works if I rewrite the range as 10:-1:1. It seems 
>> to me that either big:small should work with a default step size of -1, or 
>> the documentation needs a note. 
>>
>>
>> On Wednesday, July 2, 2014 7:32:10 AM UTC-6, Jay Kickliter wrote:
>>>
>>> Are they meant to work? I could only find one meaning of them not 
>>> working (issue 5778 ).
>>>
>>> Here's an example:
>>>
>>> julia> for i = 1:10
>>>
>>>println(i)
>>>
>>>end
>>>
>>> 1
>>>
>>> 2
>>>
>>> 3
>>>
>>> 4
>>>
>>> 5
>>>
>>> 6
>>>
>>> 7
>>>
>>> 8
>>>
>>> 9
>>>
>>> 10
>>>
>>>
>>> julia> for i = 10:1
>>>
>>>println(i)
>>>
>>>end
>>>
>>>
>>> julia> 
>>>
>>
>

Re: [julia-users] Re: A port of Norvig's Sudoku solver to Julia

[Iain Dunning]

I'll submit the PR


On Wed, Jul 2, 2014 at 12:44 PM, andy hayden  wrote:

> Using a single BitArray increases performance by 10x! I've pushed that to
> github. It also feels a much neater solution.
>
> I still can't work out how to strip out the dictionary in solve..
>
> On Tuesday, 1 July 2014 17:28:06 UTC-7, andy hayden wrote:
>>
>> It could be what quinnj's port does https://github.com/
>> attractivechaos/plb/blob/master/sudoku/sudoku_v1.jl. I couldn't get this
>> working to compare...
>>
>>
>>
>> On 1 July 2014 17:13, Iain Dunning  wrote:
>>
>>> Stripping out the dictionary stuff in search and doing it in a single
>>> array pass has knocked me down to
>>> elapsed time: 1.305257143 seconds (183884144 bytes allocated, 3.85% gc
>>> time)
>>>
>>> Changing to bitarrays would be the real fix, and I got halfway, but
>>> converting the code was so painful I might just write my own solver based
>>> on the same bruteforce idea.
>>>
>>> On Tuesday, July 1, 2014 7:58:44 PM UTC-4, andy hayden wrote:

 Ha, I had exactly the same issue (I pushed a perf update with a
 commented out impl), I assumed it was something (very) wrong in my
 understanding of control flow!

 I don't think see how it would rely on anything, ordering (?)...
 perplexing.

 On Tuesday, 1 July 2014 16:45:04 UTC-7, Iain Dunning wrote:
>
> Yeah we changed the example, so best to take it from the one in the
> release version...
>
> I removed the dictionary from search() but its now no longer solving
> all the problems(!) - does the algorithm rely somehow on the way the
> dictionary is constructed?
>
>
> On Tuesday, July 1, 2014 6:59:02 PM UTC-4, andy hayden wrote:
>>
>> I was using Cbc.
>>
>> SolveModel is a copy and paste job from JuMP (from the last release
>> rather than master) so may not work with JuMP from master - I couldn't 
>> get
>> the version from master working since it was incompatible with the JuMP
>> release I had! It'd be great to just be able to just include the file, 
>> but
>> I couldn't get that working so I just pasted it in (I should probably 
>> clean
>> Bench as I made quite a mess, apologies about that.)... so it may be you
>> need to update SolveModel from JuMP master/your version of JuMP to get
>> Bench working.
>>
>> It's amazing how some small tweaks like this go so far, there's a few
>> other bits that are obvious even to me (but I just couldn't get working).
>>
>>
>> On 1 July 2014 15:47, Iain Dunning  wrote:
>>
>>> JuMP won't be getting any faster, its entirely limited by the speed
>>> of the MIP solver. Which one did you use?
>>>
>>>
>>> On Tuesday, July 1, 2014 6:47:04 PM UTC-4, Iain Dunning wrote:

 I was unable to run Bench.jl (ERROR: varzm! not defined), but, on
 my computer just using runtests.jl, a fixed seed, and total time for 
 100
 random

 *Initial
 elapsed time: 1.641434988 seconds (282491732 bytes allocated, 5.99%
 gc time)

 *Change globals to const
 elapsed time: 1.563094028 seconds (261818132 bytes allocated, 6.61%
 gc time)

 * Changing from using a Dict{Int64, *} for the Grid types to just a
 Vector{*}, as well as those other globals
 elapsed time: 1.373703078 seconds (191864592 bytes allocated, 4.91%
 gc time)








 On Tuesday, July 1, 2014 6:27:15 PM UTC-4, andy hayden wrote:
>
> Bench.jl has a bench_compare method which returns a DataFrame of
> times (I then divide the median of Python vs Julia columns), I'll add 
> this
> output to the Bench script as it's useful to see (would be nice to 
> add more
> stats, as it's just a DataFrame of all the solved puzzles in 
> seconds). By
> default it runs a hundred random sudoku's on Julia, Python, and JuMP 
> (the
> same on each)...
>
> Thanks Steven: Making those const makes a huge difference, Julia
> wins (from 20% slower to 10% faster for me with just that change).
> I will have a play and see how your other suggestions play out.
>
> I was also very impressed with JuMP here... and it may be the
> latest is even faster (I'm using the version from the last release 
> rather
> than master, and it has changed since then).
>
>
> On Tuesday, 1 July 2014 15:11:27 UTC-7, Iain Dunning wrote:
>>
>> I'm working on improving this, but I'm not sure how you are
>> measuring that 20% slower - can you be more specific?
>>
>> On Tuesday, July 1, 2014 1:37:00 PM UTC-4, andy hayden wrote:
>>>
>>> I recently ported Norvig's Solve Every Sudoku P

Re: [julia-users] Re: A port of Norvig's Sudoku solver to Julia

[andy hayden]

Using a single BitArray increases performance by 10x! I've pushed that to 
github. It also feels a much neater solution.

I still can't work out how to strip out the dictionary in solve..

On Tuesday, 1 July 2014 17:28:06 UTC-7, andy hayden wrote:
>
> It could be what quinnj's port does 
> https://github.com/attractivechaos/plb/blob/master/sudoku/sudoku_v1.jl. I 
> couldn't get this working to compare...
>
>
>
> On 1 July 2014 17:13, Iain Dunning  wrote:
>
>> Stripping out the dictionary stuff in search and doing it in a single 
>> array pass has knocked me down to 
>> elapsed time: 1.305257143 seconds (183884144 bytes allocated, 3.85% gc 
>> time)
>>
>> Changing to bitarrays would be the real fix, and I got halfway, but 
>> converting the code was so painful I might just write my own solver based 
>> on the same bruteforce idea.
>>
>> On Tuesday, July 1, 2014 7:58:44 PM UTC-4, andy hayden wrote:
>>>
>>> Ha, I had exactly the same issue (I pushed a perf update with a 
>>> commented out impl), I assumed it was something (very) wrong in my 
>>> understanding of control flow!
>>>
>>> I don't think see how it would rely on anything, ordering (?)... 
>>> perplexing.
>>>
>>> On Tuesday, 1 July 2014 16:45:04 UTC-7, Iain Dunning wrote:

 Yeah we changed the example, so best to take it from the one in the 
 release version...

 I removed the dictionary from search() but its now no longer solving 
 all the problems(!) - does the algorithm rely somehow on the way the 
 dictionary is constructed?


 On Tuesday, July 1, 2014 6:59:02 PM UTC-4, andy hayden wrote:
>
> I was using Cbc.
>
> SolveModel is a copy and paste job from JuMP (from the last release 
> rather than master) so may not work with JuMP from master - I couldn't 
> get 
> the version from master working since it was incompatible with the JuMP 
> release I had! It'd be great to just be able to just include the file, 
> but 
> I couldn't get that working so I just pasted it in (I should probably 
> clean 
> Bench as I made quite a mess, apologies about that.)... so it may be you 
> need to update SolveModel from JuMP master/your version of JuMP to get 
> Bench working.
>
> It's amazing how some small tweaks like this go so far, there's a few 
> other bits that are obvious even to me (but I just couldn't get working).
>
>
> On 1 July 2014 15:47, Iain Dunning  wrote:
>
>> JuMP won't be getting any faster, its entirely limited by the speed 
>> of the MIP solver. Which one did you use?
>>
>>
>> On Tuesday, July 1, 2014 6:47:04 PM UTC-4, Iain Dunning wrote:
>>>
>>> I was unable to run Bench.jl (ERROR: varzm! not defined), but, on my 
>>> computer just using runtests.jl, a fixed seed, and total time for 100 
>>> random
>>>
>>> *Initial
>>> elapsed time: 1.641434988 seconds (282491732 bytes allocated, 5.99% 
>>> gc time)
>>>
>>> *Change globals to const
>>> elapsed time: 1.563094028 seconds (261818132 bytes allocated, 6.61% 
>>> gc time)
>>>
>>> * Changing from using a Dict{Int64, *} for the Grid types to just a 
>>> Vector{*}, as well as those other globals
>>> elapsed time: 1.373703078 seconds (191864592 bytes allocated, 4.91% 
>>> gc time)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tuesday, July 1, 2014 6:27:15 PM UTC-4, andy hayden wrote:

 Bench.jl has a bench_compare method which returns a DataFrame of 
 times (I then divide the median of Python vs Julia columns), I'll add 
 this 
 output to the Bench script as it's useful to see (would be nice to add 
 more 
 stats, as it's just a DataFrame of all the solved puzzles in seconds). 
 By 
 default it runs a hundred random sudoku's on Julia, Python, and JuMP 
 (the 
 same on each)...

 Thanks Steven: Making those const makes a huge difference, Julia 
 wins (from 20% slower to 10% faster for me with just that change).
 I will have a play and see how your other suggestions play out.

 I was also very impressed with JuMP here... and it may be the 
 latest is even faster (I'm using the version from the last release 
 rather 
 than master, and it has changed since then).


 On Tuesday, 1 July 2014 15:11:27 UTC-7, Iain Dunning wrote:
>
> I'm working on improving this, but I'm not sure how you are 
> measuring that 20% slower - can you be more specific?
>
> On Tuesday, July 1, 2014 1:37:00 PM UTC-4, andy hayden wrote:
>>
>> I recently ported Norvig's Solve Every Sudoku Puzzle 
>>  to Julia: https://github.com/hayd
>> /Sudoku.jl
>>
>> Some simple benchmarks suggest my Julia implementa

[julia-users] Re: Potential bug in Task/iterators?

[Sebastian Nowozin]

Hi,

on a related note, you can discard the "ERROR: i not defined" error because 
it turned out to be an error in a predicate, unrelated to Task and the 
iterator.
(I am surprised it did not provide line numbers for this but maybe it was 
inlined/optimized.)

The Task/iterators now work from the REPL but the hanging issue files 
remains when I call "julia.exe bug1.jl".

Thanks for your help,
Sebastian


On Tuesday, 1 July 2014 20:05:48 UTC+1, Sebastian Nowozin wrote:
>
>
> Hi everyone,
>
> I followed the pattern proposed at 
> http://slendermeans.org/julia-iterators.html (see the "fibtask" function) 
> in order to define an iterator that is traversing a tree data structure as 
> follows:
>
> function search(rt::Tree)
> function _search(node::InteriorNode)
> for cn in node.children
> _search(cn)
> end
> end
> function _search(node::LeafNode)
> for obj in node.children
> produce(obj.membervar)
> end
> end
> function _search()
> _search(rt.root)
> end
> Task(_search)
> end
>
> This function dispatches based on the type of node (interior or leaf) and 
> iterates over objects stored with each leaf node of the tree (it is a 
> B-tree).  Eventually I would like to write statements such as:
>
>for leaf in search(tree)
>   ...
>end
>
> I tested the above code on both Windows 8.1 with latest 64 bit build as 
> well as on Ubuntu 14.04 git trunk, with code as follows:
>
>S = search(tree)
>L = collect(S)
>
> This yields the following error, with line 25 being the collect statement:
>
> ERROR: i not defined
>  in schedule_and_wait at task.jl:251
>  in consume at task.jl:162
>  in collect at array.jl:233
>  in collect at array.jl:240
>  in include at ./boot.jl:244
>  in include_from_node1 at loading.jl:128
>  in process_options at ./client.jl:285
>  in _start at ./client.jl:354
> while loading test_tree1.jl, in expression starting on line 25
>
> Is the above an invalid use of the Task interface?  If so, what are the 
> constraints on the produce statements, and how to fix the above code?
>
> Any help is appreciated.  If it would help I could open an issue on the 
> Julia issue tracker.
>
> Thanks,
> Sebastian
>
>

Re: [julia-users] compilation of Julia code to shared libraries

[Tom Short]

As more background, see here:

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



On Wed, Jul 2, 2014 at 11:05 AM, Alexander Braumann
 wrote:
> Hi,
>
> I am mainly using R and wanted to know if it was already possible (or when
> it is expected to be possible) to compile Julia code to shared libraries
> which can be loaded and used within R?
>
> I found a rather short discussion about this here:
>
> http://stackoverflow.com/questions/9965747/linking-r-and-julia
>
> The Julia development plan, as I described in this answer is to allow
> compilation of Julia code to shared libraries, callable using the C ABI.
> Once this happens, it will be as easy to call Julia code from R as it is to
> call C/C++ code. There is, however, a fair amount of work required before
> this becomes possible (Stefan Karpinski)
>
> but I couldn't comment there and therefore need to ask in this group.
>
> I am really looking forward to this feature! It would encourage me using
> julia a lot more.
>
>
> cheers,
>
> alex

[julia-users] compilation of Julia code to shared libraries

[Alexander Braumann]

Hi,

I am mainly using R and wanted to know if it was already possible (or when 
it is expected to be possible) to compile Julia code to shared libraries 
which can be loaded and used within R?

I found a rather short discussion about this here:

http://stackoverflow.com/questions/9965747/linking-r-and-julia

*The Julia development plan, as I described in this answer 
 is to allow compilation of 
Julia code to shared libraries, callable using the C ABI. Once this 
happens, it will be as easy to call Julia code from R as it is to call 
C/C++ code. There is, however, a fair amount of work required before this 
becomes possible (*Stefan Karpinski)

but I couldn't comment there and therefore need to ask in this group.

I am really looking forward to this feature! It would encourage me using 
julia a lot more.


cheers,

alex

Re: [julia-users] equivalent to numpy's fftfreq

[João Felipe Santos]

Hi Andrei,

you can use fftfreq in DSP.jl. The syntax is exactly the same as for your
function: http://dspjl.readthedocs.org/en/latest/util.html#fftfreq.

Best

--
João Felipe Santos


On Wed, Jul 2, 2014 at 9:28 AM, Andrei Berceanu 
wrote:

> I have written the following function to provide the same functionality as
> numpy's fftfreq (
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.fft.fftfreq.html
> )
>
> ```
> function fftfreq(n::Int64, d::Float64)
>   N = fld(n-1,2)
>   p1 = [0:N]
>   p2 = [-fld(n,2):-1]
>   return [p1, p2]/(d*n)
> end
> ```
>
> From the response on https://github.com/JuliaLang/julia/issues/7317, I
> understand that such a function is already implemented in the DSP.jl
> package, perhaps using the immutable Frequencies?
> I am not quite sure how to use that though, could anyone please provide a
> concrete example which reproduces the use of fftfreq? Tnx!
>

[julia-users] Re: Potential bug in Task/iterators?

[Sebastian Nowozin]

Hi,

I filed this as an issue with code to reproduce a different behaviour 
(hanging) at
https://github.com/JuliaLang/julia/issues/7498

Best,
Sebastian

On Tuesday, 1 July 2014 20:05:48 UTC+1, Sebastian Nowozin wrote:
>
>
> Hi everyone,
>
> I followed the pattern proposed at 
> http://slendermeans.org/julia-iterators.html (see the "fibtask" function) 
> in order to define an iterator that is traversing a tree data structure as 
> follows:
>
> function search(rt::Tree)
> function _search(node::InteriorNode)
> for cn in node.children
> _search(cn)
> end
> end
> function _search(node::LeafNode)
> for obj in node.children
> produce(obj.membervar)
> end
> end
> function _search()
> _search(rt.root)
> end
> Task(_search)
> end
>
> This function dispatches based on the type of node (interior or leaf) and 
> iterates over objects stored with each leaf node of the tree (it is a 
> B-tree).  Eventually I would like to write statements such as:
>
>for leaf in search(tree)
>   ...
>end
>
> I tested the above code on both Windows 8.1 with latest 64 bit build as 
> well as on Ubuntu 14.04 git trunk, with code as follows:
>
>S = search(tree)
>L = collect(S)
>
> This yields the following error, with line 25 being the collect statement:
>
> ERROR: i not defined
>  in schedule_and_wait at task.jl:251
>  in consume at task.jl:162
>  in collect at array.jl:233
>  in collect at array.jl:240
>  in include at ./boot.jl:244
>  in include_from_node1 at loading.jl:128
>  in process_options at ./client.jl:285
>  in _start at ./client.jl:354
> while loading test_tree1.jl, in expression starting on line 25
>
> Is the above an invalid use of the Task interface?  If so, what are the 
> constraints on the produce statements, and how to fix the above code?
>
> Any help is appreciated.  If it would help I could open an issue on the 
> Julia issue tracker.
>
> Thanks,
> Sebastian
>
>

Re: [julia-users] Re: build from source modifying Make.user on hpc cluster

[Florian Oswald]

it seems you are close. all tests should pass, so there's something wrong.
try to follow those steps:

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

or those

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




On 2 July 2014 15:30, Ollie Laslett  wrote:

> I have been having a very similar issue, whilst trying to build julia in
> my home directory on a cluster. I also had problems building openblas,
> which was solved by using OPENBLAS_DYNAMIC_ARCH=0.
>
> I also have the same errors when running code:
>
> /lib64/libz.so.1: no version information available
>
> On top of that, when I run $make testthe file.jl tests fail on @test
> isreadable(file)  which I find peculiar.
>
> Building from source is such a nightmare sometimes, I didn't quite
> understand your discussion below. Is there anything I can do to rectify
> these issues?
>
> Thanks
>
> On Monday, 30 June 2014 22:50:00 UTC+1, Florian Oswald wrote:
>
>> Hi all,
>>
>> I've got some very basic questions about building Julia from source on an
>> hpc cluster. I got it to build fine a month ago, but now the makefile
>> changed. I was partially  succesful this time as well (my test runs), but
>> some strange things happen and there's a lot of stuff in that makefile I
>> dont' understand.
>>
>>- I can't get Make.user to work. My understanding was that i `cp
>>Make.inc Make.user`, then change the options I want changed, then `make`?
>>Nothing happens. Do I have to delete Make.inc after having made my copy?
>>- I needed to set `JULIA_CPU_TARGET=core2` when I last got it to
>>build. The cluster is built out of several different CPU types, so not
>>setting this resulted in target mismatch errors. I can't find that line
>>anymore in the current Make.inc, so I changed https://github.com/
>>JuliaLang/julia/blob/master/Make.inc#L345
>> from
>>
>>  JULIA_CPU_TARGET ?= native
>> to
>>  JULIA_CPU_TARGET = core2
>>
>>- Is this still recommended practice or should I not touch this at
>>all?
>>- the openblas default build failed. I set this:
>>- OPENBLAS_DYNAMIC_ARCH=0
>>- OPENBLAS_USE_THREAD=0
>>- OPENBLAS_TARGET_ARCH=BARCELONA
>>- It says in the trouble-shooting section on
>>https://github.com/JuliaLang/julia/readme.md
>> that a possibel
>>solution to problems is to set the last variable to BARCELONA for AMD and
>>NEHALEM for Intel. What if I have both CPUs? Does it matter?
>>- With those settings it compiles, and my little test script runs.
>>However, I get this error/warning from all workers:
>>- ./julia: /lib64/libz.so.1: no version information available
>>(required by /data/uctpfos/git/julia/usr/bin/../lib/libjulia.so)
>>- In case this is helpful, my `cat /proc/version` is:
>>- Linux version 2.6.32-279.19.1.el6.x86_64 (mock...@sl6.fnal.gov)
>>(gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Tue Dec 18
>>17:22:54 CST 2012
>>
>>
>>

[julia-users] Using Distance Package for knn Weight Matrix

[Donald Lacombe]

Greetings!

I am a new Julia user and have the following issue. I am writing code to 
calculate a knn spatial weight matrix to estimate a spatial econometric 
model. Using the MATLAB code from Jim LeSage's Econometrics Toolbox, I 
converted that code into Julia as follows:

xc = rand(8);

yc = rand(8);

n = length(xc);

k = 2;

distance = zeros(n);

nnlist = zeros(n,k);

tempw = zeros(n,n);


for i=1:n;

xi = xc[i,1];

yi = yc[i,1];

distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2

temp = sortperm(distance)

nnlist[i,1:k] = temp[2:k+1,1]';

end


for i=1:n

tempw[i,nnlist[i,:]] = 1;

end


W = tempw/k;


This is a "toy" example and I was wondering if I can use the Distance package 
to simplify the distance = (xc - xi*ones(n)).^2 + (yc - yi*ones(n)).^2 formula. 
I tried using the pairwise option like so:


R = pairwise(Euclidean(),xc,yc) but received the following message:


R = pairwise(Euclidean(),xc,yc)

MethodError(pairwise,(Euclidean(),[0.05961066617957589,0.018538084399339905,0.39282193332224646,0.7006919213133509,0.5099836895629475,0.8448415935222402,0.2985674570217043,0.8022287058003177],[0.5808687231553928,0.9655167324458858,0.026306556019434435,0.6565373244339141,0.11927452074471412,0.11873635450496622,0.6271632933770979,0.7081439899673692]))

I'd like to be able to utilize the Distance package but am a bit stumped. The 
code as written works but it's bugging me that I cannot seem to get the above 
command to work. I also get the following error when loading Distance:


using Distance

Warning: could not import Base.foldl into NumericExtensions

Warning: could not import Base.foldr into NumericExtensions

Warning: could not import Base.sum! into NumericExtensions

Warning: could not import Base.maximum! into NumericExtensions

Warning: could not import Base.minimum! into NumericExtensions


If there is anyone who can address this I'd greatly appreciate it. 
Incidentally, the help on this group is one reason I am making the change.


Don

[julia-users] Re: build from source modifying Make.user on hpc cluster

[Ollie Laslett]

I have been having a very similar issue, whilst trying to build julia in my 
home directory on a cluster. I also had problems building openblas, which 
was solved by using OPENBLAS_DYNAMIC_ARCH=0.

I also have the same errors when running code:

/lib64/libz.so.1: no version information available

On top of that, when I run $make testthe file.jl tests fail on @test 
isreadable(file)  which I find peculiar.

Building from source is such a nightmare sometimes, I didn't quite 
understand your discussion below. Is there anything I can do to rectify 
these issues?

Thanks

On Monday, 30 June 2014 22:50:00 UTC+1, Florian Oswald wrote:
>
> Hi all,
>
> I've got some very basic questions about building Julia from source on an 
> hpc cluster. I got it to build fine a month ago, but now the makefile 
> changed. I was partially  succesful this time as well (my test runs), but 
> some strange things happen and there's a lot of stuff in that makefile I 
> dont' understand.
>
>- I can't get Make.user to work. My understanding was that i `cp 
>Make.inc Make.user`, then change the options I want changed, then `make`? 
>Nothing happens. Do I have to delete Make.inc after having made my copy?
>- I needed to set `JULIA_CPU_TARGET=core2` when I last got it to 
>build. The cluster is built out of several different CPU types, so not 
>setting this resulted in target mismatch errors. I can't find that line 
>anymore in the current Make.inc, so I changed 
>https://github.com/JuliaLang/julia/blob/master/Make.inc#L345 from
>
>  JULIA_CPU_TARGET ?= native
> to
>  JULIA_CPU_TARGET = core2
>
>- Is this still recommended practice or should I not touch this at all?
>- the openblas default build failed. I set this:
>- OPENBLAS_DYNAMIC_ARCH=0
>- OPENBLAS_USE_THREAD=0
>- OPENBLAS_TARGET_ARCH=BARCELONA
>- It says in the trouble-shooting section on 
>https://github.com/JuliaLang/julia/readme.md that a possibel solution 
>to problems is to set the last variable to BARCELONA for AMD and NEHALEM 
>for Intel. What if I have both CPUs? Does it matter?
>- With those settings it compiles, and my little test script runs. 
>However, I get this error/warning from all workers:
>- ./julia: /lib64/libz.so.1: no version information available 
>(required by /data/uctpfos/git/julia/usr/bin/../lib/libjulia.so)
>- In case this is helpful, my `cat /proc/version` is:
>- Linux version 2.6.32-279.19.1.el6.x86_64 (mock...@sl6.fnal.gov 
>) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) 
>#1 SMP Tue Dec 18 17:22:54 CST 2012
>
>
>

Re: [julia-users] metaprogramming nested functions

[John Myles White]

What would that macro do? Right now, I’d guess that it would just take its 
input out of quotes.

 — John

On Jul 2, 2014, at 7:41 AM, Bryan A. Knowles  wrote:

> What of we had a macro version of parse? Eg,
> ```julia
>   function foo()
>   foo2(x) = println(x)
>   foo2(1)
>   @parse("foo2(2)")
>   end
> ```

Re: [julia-users] metaprogramming nested functions

[Bryan A. Knowles]

What of we had a macro version of parse? Eg,
```julia
   function foo()
   foo2(x) = println(x)
   foo2(1)
   @parse("foo2(2)")
   end
```

Re: [julia-users] Re: Decreasing range, should it work?

[Stefan Karpinski]

Why would one assume that the default step size is -1 when the start is
bigger than the stop? The documentation for ranges clearly says that the
default step size is 1 unconditionally, not that it is sign(stop-start).
That would, by the way, be a very dangerous behavior. Perhaps a sidebar on
the colon syntax is warranted in the manual control flow section on for
loops, including examples of empty ranges and ranges that count downwards.


On Wed, Jul 2, 2014 at 9:53 AM, Jay Kickliter 
wrote:

> I just realized that it works if I rewrite the range as 10:-1:1. It seems
> to me that either big:small should work with a default step size of -1, or
> the documentation needs a note.
>
>
> On Wednesday, July 2, 2014 7:32:10 AM UTC-6, Jay Kickliter wrote:
>>
>> Are they meant to work? I could only find one meaning of them not working
>> (issue 5778 ).
>>
>> Here's an example:
>>
>> julia> for i = 1:10
>>
>>println(i)
>>
>>end
>>
>> 1
>>
>> 2
>>
>> 3
>>
>> 4
>>
>> 5
>>
>> 6
>>
>> 7
>>
>> 8
>>
>> 9
>>
>> 10
>>
>>
>> julia> for i = 10:1
>>
>>println(i)
>>
>>end
>>
>>
>> julia>
>>
>

[julia-users] Re: ANN: Contour.jl

[Andrei Berceanu]

Great work, congratulations for the package. I have a short question.
Once I get an array of Curve2 type, how can I get a graphical 
representation of it? I mean, in Winston/Gaston/PyPlot/whatever.

On Sunday, June 29, 2014 12:34:28 AM UTC+2, Tomas Lycken wrote:
>
> Huzzah!
>
> We’ve just released Contour.jl , a 
> light-weight package that provides an algorithm to calculate iso-lines of a 
> scalar 2D-field f(x,y), such as those shown on a contour plot. The current 
> implementation uses the Marching Squares 
>  algorithm, and returns 
> the contour lines in an array of ContourLevel instances, that provide an 
> abstraction over the actual implementation of curves as geometrical 
> objects. Currently lists of Vector2s from ImmutableArrays are used to 
> represent curves, but the idea is that if e.g. a package with general 
> geometry items emerges, we can seemlessly switch to that.
>
> Our hopes is that other packages that have use for isolines (e.g. all 
> plotting packages that want to plot contours) use this package instead of 
> each carrying their own implementation, but use cases are of course not 
> limited to plotting. (I wanted to put this together because I needed to 
> calculate volumes inside axisymmetric isosurfaces, and this solved a large 
> part of that problem…)
>
> Please, kick the tires and see what you can do with this! =)
>
> Finally, a big thanks to Darwin Darakananda 
> , who’s done almost all the coding.
>
> // Tomas
> ​
>

[julia-users] Re: Decreasing range, should it work?

[Ivar Nesje]

It is documented 
, 
but it is not obvious (to me) where you would look for that peace of 
information. Maybe here 

?

Ivar

kl. 15:54:21 UTC+2 onsdag 2. juli 2014 skrev Jay Kickliter følgende:
>
> Thanks, I just missed your reply.
>
> On Wednesday, July 2, 2014 7:52:47 AM UTC-6, Ivar Nesje wrote:
>>
>> They work, but you will have to set the step to -1
>>
>> for i = 10:-1:1
>>println(i)
>> end
>>
>> kl. 15:32:10 UTC+2 onsdag 2. juli 2014 skrev Jay Kickliter følgende:
>>>
>>> Are they meant to work? I could only find one meaning of them not 
>>> working (issue 5778 ).
>>>
>>> Here's an example:
>>>
>>> julia> for i = 1:10
>>>
>>>println(i)
>>>
>>>end
>>>
>>> 1
>>>
>>> 2
>>>
>>> 3
>>>
>>> 4
>>>
>>> 5
>>>
>>> 6
>>>
>>> 7
>>>
>>> 8
>>>
>>> 9
>>>
>>> 10
>>>
>>>
>>> julia> for i = 10:1
>>>
>>>println(i)
>>>
>>>end
>>>
>>>
>>> julia> 
>>>
>>

[julia-users] Re: Inconsistent results from linrange

[Matt Bauman]

That's a great solution.  I think the only other alternative would be to 
return an array instead of a range, which would be unfortunate.

On Wednesday, July 2, 2014 9:50:34 AM UTC-4, Ivar Nesje wrote:
>
> Hmm... Everything with floating point ranges is inherently difficult, 
> because we want to give users the full accuracy (not cheat like Matlab 
> does).
>
> In order for the slicing behaviour to be exactly right, it seems to me 
> that we would need to store a start and a step increment, so that the 
> calculation for all the indexed values becomes unchanged when the range is 
> indexed with a range.
>
> Maybe we could have a Offset type that could wrap the FloatRange (and 
> other objects too)
>
> immutable Offset{T}
> itr::T
> start::Int
> step::Int
> end
>
> function getindex(o::Offset, i::Int)
> getindex(o.itr, start+i*step)
> end
>
> Ivar
>
> kl. 15:11:18 UTC+2 onsdag 2. juli 2014 skrev Peter Simon følgende:
>>
>> Thanks.  I had mistakenly thought that linrange would retain the exact 
>> value of its end points, as does linspace.
>>
>> My actual application is to reproduce the functionality of Matlab's 
>> optional histc output: 
>>
>> [n,bin] = histc(x, edges)
>>
>>
>> Here, (using Matlab notation), bin is an integer-valued vector of the 
>> same length as x such that bin(i) indicates which "bin" of edges is 
>> occupied by x(i).  My Julian attempt at reproducing this function used a 
>> range named edges:
>>
>> edges = linrange(minimum(x), maximum(x), 20)
>> bin = [find(edges[1:end-1] .<= t .<= edges[2:end])[1] for t in x]
>>
>>
>>
>> and it failed due to the issue demonstrated in my first post.  I think 
>> that I could use linspace instead of linrange, but for other reasons a 
>> range is preferable in this application.  Do we already have this binning 
>> functionality in some other built-in function?  I checked Julia's hist(), 
>> but it provides only the first output of Matlab's bin.
>>
>> Thanks,
>> --Peter
>>
>> On Tuesday, July 1, 2014 11:59:44 PM UTC-7, Ivar Nesje wrote:
>>>
>>> It is not a shocker to me. The problem is that Floating point numbers 
>>> represent binary fractions, and there is no way for linrange() to actually 
>>> get equidistant values you are looking for. It has to do approximations, 
>>> and thus it will sometimes miss closest possible value. That means equality 
>>> checks on floating point numbers should be used with extreme care.
>>>
>>> Our implementation reuses the old step size when indexing a FloatRange 
>>> with a range, but we could probably do better if we tried to keep the last 
>>> point equal.
>>>
>>> I reopened https://github.com/JuliaLang/julia/issues/7420 to keep track 
>>> of this issue.
>>>
>>> Ivar
>>>
>>> kl. 07:07:25 UTC+2 onsdag 2. juli 2014 skrev Peter Simon følgende:

 The final result below seems really strange to me.  A bug?

 julia> x = linrange(1,10,20)
 1.0:0.47368421052631576:10.0


 julia> 10 .<= x  # Gives expected result
 20-element BitArray{1}:
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
   true

 julia> 10 .<= x[end]  # Gives expected result
 true

 julia> 10 .<= x[2:end]  # The last entry in this result is a shocker 
 to me!
 19-element BitArray{1}:
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false
  false



 Here is the version info:


 julia> versioninfo()
 Julia Version 0.3.0-prerelease+3987
 Commit 7dd97fa (2014-06-30 23:12 UTC)
 Platform Info:
   System: Windows (x86_64-w64-mingw32)
   CPU: Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz
   WORD_SIZE: 64
   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
   LAPACK: libopenblas
   LIBM: libopenlibm

[julia-users] Re: Decreasing range, should it work?

[Jay Kickliter]

Thanks, I just missed your reply.

On Wednesday, July 2, 2014 7:52:47 AM UTC-6, Ivar Nesje wrote:
>
> They work, but you will have to set the step to -1
>
> for i = 10:-1:1
>println(i)
> end
>
> kl. 15:32:10 UTC+2 onsdag 2. juli 2014 skrev Jay Kickliter følgende:
>>
>> Are they meant to work? I could only find one meaning of them not working 
>> (issue 5778 ).
>>
>> Here's an example:
>>
>> julia> for i = 1:10
>>
>>println(i)
>>
>>end
>>
>> 1
>>
>> 2
>>
>> 3
>>
>> 4
>>
>> 5
>>
>> 6
>>
>> 7
>>
>> 8
>>
>> 9
>>
>> 10
>>
>>
>> julia> for i = 10:1
>>
>>println(i)
>>
>>end
>>
>>
>> julia> 
>>
>

[julia-users] Re: Decreasing range, should it work?

[Jay Kickliter]

I just realized that it works if I rewrite the range as 10:-1:1. It seems 
to me that either big:small should work with a default step size of -1, or 
the documentation needs a note. 

On Wednesday, July 2, 2014 7:32:10 AM UTC-6, Jay Kickliter wrote:
>
> Are they meant to work? I could only find one meaning of them not working 
> (issue 5778 ).
>
> Here's an example:
>
> julia> for i = 1:10
>
>println(i)
>
>end
>
> 1
>
> 2
>
> 3
>
> 4
>
> 5
>
> 6
>
> 7
>
> 8
>
> 9
>
> 10
>
>
> julia> for i = 10:1
>
>println(i)
>
>end
>
>
> julia> 
>

[julia-users] Re: Decreasing range, should it work?

[Ivar Nesje]

They work, but you will have to set the step to -1

for i = 10:-1:1
   println(i)
end

kl. 15:32:10 UTC+2 onsdag 2. juli 2014 skrev Jay Kickliter følgende:
>
> Are they meant to work? I could only find one meaning of them not working 
> (issue 5778 ).
>
> Here's an example:
>
> julia> for i = 1:10
>
>println(i)
>
>end
>
> 1
>
> 2
>
> 3
>
> 4
>
> 5
>
> 6
>
> 7
>
> 8
>
> 9
>
> 10
>
>
> julia> for i = 10:1
>
>println(i)
>
>end
>
>
> julia> 
>

[julia-users] Re: Inconsistent results from linrange

[Ivar Nesje]

Hmm... Everything with floating point ranges is inherently difficult, 
because we want to give users the full accuracy (not cheat like Matlab 
does).

In order for the slicing behaviour to be exactly right, it seems to me that 
we would need to store a start and a step increment, so that the 
calculation for all the indexed values becomes unchanged when the range is 
indexed with a range.

Maybe we could have a Offset type that could wrap the FloatRange (and other 
objects too)

immutable Offset{T}
itr::T
start::Int
step::Int
end

function getindex(o::Offset, i::Int)
getindex(o.itr, start+i*step)
end

Ivar

kl. 15:11:18 UTC+2 onsdag 2. juli 2014 skrev Peter Simon følgende:
>
> Thanks.  I had mistakenly thought that linrange would retain the exact 
> value of its end points, as does linspace.
>
> My actual application is to reproduce the functionality of Matlab's 
> optional histc output: 
>
> [n,bin] = histc(x, edges)
>
>
> Here, (using Matlab notation), bin is an integer-valued vector of the same 
> length as x such that bin(i) indicates which "bin" of edges is occupied by 
> x(i).  My Julian attempt at reproducing this function used a range named 
> edges:
>
> edges = linrange(minimum(x), maximum(x), 20)
> bin = [find(edges[1:end-1] .<= t .<= edges[2:end])[1] for t in x]
>
>
>
> and it failed due to the issue demonstrated in my first post.  I think 
> that I could use linspace instead of linrange, but for other reasons a 
> range is preferable in this application.  Do we already have this binning 
> functionality in some other built-in function?  I checked Julia's hist(), 
> but it provides only the first output of Matlab's bin.
>
> Thanks,
> --Peter
>
> On Tuesday, July 1, 2014 11:59:44 PM UTC-7, Ivar Nesje wrote:
>>
>> It is not a shocker to me. The problem is that Floating point numbers 
>> represent binary fractions, and there is no way for linrange() to actually 
>> get equidistant values you are looking for. It has to do approximations, 
>> and thus it will sometimes miss closest possible value. That means equality 
>> checks on floating point numbers should be used with extreme care.
>>
>> Our implementation reuses the old step size when indexing a FloatRange 
>> with a range, but we could probably do better if we tried to keep the last 
>> point equal.
>>
>> I reopened https://github.com/JuliaLang/julia/issues/7420 to keep track 
>> of this issue.
>>
>> Ivar
>>
>> kl. 07:07:25 UTC+2 onsdag 2. juli 2014 skrev Peter Simon følgende:
>>>
>>> The final result below seems really strange to me.  A bug?
>>>
>>> julia> x = linrange(1,10,20)
>>> 1.0:0.47368421052631576:10.0
>>>
>>>
>>> julia> 10 .<= x  # Gives expected result
>>> 20-element BitArray{1}:
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>   true
>>>
>>> julia> 10 .<= x[end]  # Gives expected result
>>> true
>>>
>>> julia> 10 .<= x[2:end]  # The last entry in this result is a shocker to 
>>> me!
>>> 19-element BitArray{1}:
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>
>>>
>>>
>>> Here is the version info:
>>>
>>>
>>> julia> versioninfo()
>>> Julia Version 0.3.0-prerelease+3987
>>> Commit 7dd97fa (2014-06-30 23:12 UTC)
>>> Platform Info:
>>>   System: Windows (x86_64-w64-mingw32)
>>>   CPU: Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>>   LAPACK: libopenblas
>>>   LIBM: libopenlibm
>>>
>>>

[julia-users] Re: Inconsistent results from linrange

[Matt Bauman]

Unfortunately, it is not always possible to construct a range such that the 
exact value of the endpoints is retained.  Matlab cheats here, and changes 
the step size to ensure that the endpoints are retained.  A Julian range, 
however, must always have one unique step.  For more information, see the 
PR where linrange was 
introduced: https://github.com/JuliaLang/julia/pull/6627.  I agree that it 
might make sense to futz with the implementation a bit to ensure that the 
endpoint is always <= the requested one (see my comment).

In Julia:

julia> linrange(.3,.9,3)
0.3:0.30004:0.9001

julia> .3 + .3*2
0.8999

julia> .3 + nextfloat(.3)*2
0.9001

As compared to Matlab:

>> format longE
>> s = linspace(.3,.9,3)
s =
 3.000e-01 6.001e-01 
9.000e-01

>> diff(s)

ans =
 3.001e-01 2.999e-01


On Wednesday, July 2, 2014 9:11:18 AM UTC-4, Peter Simon wrote:
>
> Thanks.  I had mistakenly thought that linrange would retain the exact 
> value of its end points, as does linspace.
>
> My actual application is to reproduce the functionality of Matlab's 
> optional histc output: 
>
> [n,bin] = histc(x, edges)
>
>
> Here, (using Matlab notation), bin is an integer-valued vector of the same 
> length as x such that bin(i) indicates which "bin" of edges is occupied by 
> x(i).  My Julian attempt at reproducing this function used a range named 
> edges:
>
> edges = linrange(minimum(x), maximum(x), 20)
> bin = [find(edges[1:end-1] .<= t .<= edges[2:end])[1] for t in x]
>
>
>
> and it failed due to the issue demonstrated in my first post.  I think 
> that I could use linspace instead of linrange, but for other reasons a 
> range is preferable in this application.  Do we already have this binning 
> functionality in some other built-in function?  I checked Julia's hist(), 
> but it provides only the first output of Matlab's bin.
>
> Thanks,
> --Peter
>
> On Tuesday, July 1, 2014 11:59:44 PM UTC-7, Ivar Nesje wrote:
>>
>> It is not a shocker to me. The problem is that Floating point numbers 
>> represent binary fractions, and there is no way for linrange() to actually 
>> get equidistant values you are looking for. It has to do approximations, 
>> and thus it will sometimes miss closest possible value. That means equality 
>> checks on floating point numbers should be used with extreme care.
>>
>> Our implementation reuses the old step size when indexing a FloatRange 
>> with a range, but we could probably do better if we tried to keep the last 
>> point equal.
>>
>> I reopened https://github.com/JuliaLang/julia/issues/7420 to keep track 
>> of this issue.
>>
>> Ivar
>>
>> kl. 07:07:25 UTC+2 onsdag 2. juli 2014 skrev Peter Simon følgende:
>>>
>>> The final result below seems really strange to me.  A bug?
>>>
>>> julia> x = linrange(1,10,20)
>>> 1.0:0.47368421052631576:10.0
>>>
>>>
>>> julia> 10 .<= x  # Gives expected result
>>> 20-element BitArray{1}:
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>   true
>>>
>>> julia> 10 .<= x[end]  # Gives expected result
>>> true
>>>
>>> julia> 10 .<= x[2:end]  # The last entry in this result is a shocker to 
>>> me!
>>> 19-element BitArray{1}:
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>  false
>>>
>>>
>>>
>>> Here is the version info:
>>>
>>>
>>> julia> versioninfo()
>>> Julia Version 0.3.0-prerelease+3987
>>> Commit 7dd97fa (2014-06-30 23:12 UTC)
>>> Platform Info:
>>>   System: Windows (x86_64-w64-mingw32)
>>>   CPU: Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz
>>>   WORD_SIZE: 64
>>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>>   LAPACK: libopenblas
>>>   LIBM: libopenlibm
>>>
>>>

[julia-users] Decreasing range, should it work?

[Jay Kickliter]

Are they meant to work? I could only find one meaning of them not working 
(issue 5778 ).

Here's an example:

julia> for i = 1:10

   println(i)

   end

1

2

3

4

5

6

7

8

9

10


julia> for i = 10:1

   println(i)

   end


julia> 

[julia-users] equivalent to numpy's fftfreq

[Andrei Berceanu]

I have written the following function to provide the same functionality as 
numpy's fftfreq 
(http://docs.scipy.org/doc/numpy/reference/generated/numpy.fft.fftfreq.html)

```
function fftfreq(n::Int64, d::Float64)
  N = fld(n-1,2)
  p1 = [0:N]
  p2 = [-fld(n,2):-1]
  return [p1, p2]/(d*n)
end
```

>From the response on https://github.com/JuliaLang/julia/issues/7317, I 
understand that such a function is already implemented in the DSP.jl 
package, perhaps using the immutable Frequencies?
I am not quite sure how to use that though, could anyone please provide a 
concrete example which reproduces the use of fftfreq? Tnx!

[julia-users] Re: Inconsistent results from linrange

[Peter Simon]

Thanks.  I had mistakenly thought that linrange would retain the exact 
value of its end points, as does linspace.

My actual application is to reproduce the functionality of Matlab's 
optional histc output: 

[n,bin] = histc(x, edges)


Here, (using Matlab notation), bin is an integer-valued vector of the same 
length as x such that bin(i) indicates which "bin" of edges is occupied by 
x(i).  My Julian attempt at reproducing this function used a range named 
edges:

edges = linrange(minimum(x), maximum(x), 20)
bin = [find(edges[1:end-1] .<= t .<= edges[2:end])[1] for t in x]



and it failed due to the issue demonstrated in my first post.  I think that 
I could use linspace instead of linrange, but for other reasons a range is 
preferable in this application.  Do we already have this binning 
functionality in some other built-in function?  I checked Julia's hist(), 
but it provides only the first output of Matlab's bin.

Thanks,
--Peter

On Tuesday, July 1, 2014 11:59:44 PM UTC-7, Ivar Nesje wrote:
>
> It is not a shocker to me. The problem is that Floating point numbers 
> represent binary fractions, and there is no way for linrange() to actually 
> get equidistant values you are looking for. It has to do approximations, 
> and thus it will sometimes miss closest possible value. That means equality 
> checks on floating point numbers should be used with extreme care.
>
> Our implementation reuses the old step size when indexing a FloatRange 
> with a range, but we could probably do better if we tried to keep the last 
> point equal.
>
> I reopened https://github.com/JuliaLang/julia/issues/7420 to keep track 
> of this issue.
>
> Ivar
>
> kl. 07:07:25 UTC+2 onsdag 2. juli 2014 skrev Peter Simon følgende:
>>
>> The final result below seems really strange to me.  A bug?
>>
>> julia> x = linrange(1,10,20)
>> 1.0:0.47368421052631576:10.0
>>
>>
>> julia> 10 .<= x  # Gives expected result
>> 20-element BitArray{1}:
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>   true
>>
>> julia> 10 .<= x[end]  # Gives expected result
>> true
>>
>> julia> 10 .<= x[2:end]  # The last entry in this result is a shocker to 
>> me!
>> 19-element BitArray{1}:
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>  false
>>
>>
>>
>> Here is the version info:
>>
>>
>> julia> versioninfo()
>> Julia Version 0.3.0-prerelease+3987
>> Commit 7dd97fa (2014-06-30 23:12 UTC)
>> Platform Info:
>>   System: Windows (x86_64-w64-mingw32)
>>   CPU: Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>>   LAPACK: libopenblas
>>   LIBM: libopenlibm
>>
>>

Re: [julia-users] Re: Package list for the latest version

[Ivar Nesje]

It is gone from the git repository (#7204 
), but it seems like 
readthedocs still keeps a cached version around. The link is probably still 
in lots of places, so it we should probably leave a `packagelist.rst` file 
around with a link to the correct site.

Ivar

kl. 14:02:40 UTC+2 onsdag 2. juli 2014 skrev Samuel Colvin følgende:
>
> Surely we need to get rid of the current packages page: 
> http://docs.julialang.org/en/latest/packages/packagelist/
>
> It's still pretty high up google and people are surely going to it and 
> coming away disappointed that a package doesn't exist when actually it does.
>
> It wasn't until I found this thread that I discovered that that list was 
> actually depreciated.
>
> At the very least it should have a "DEPRECIATED, NEW LIST HERE" warning at 
> the top?
>
> On Friday, 2 May 2014 04:32:06 UTC+1, Jacques Rioux wrote:
>>
>> Or may I suggest simply calling Pkg.available() in the Julia REPL 
>> directly. 
>>
>> You get the list right there for you.to browse and inspect.
>>
>> And it is always up to date.
>> On May 1, 2014 3:20 PM, "Iain Dunning"  wrote:
>>
>>> I see. Well, I guess in that case the list at 
>>> https://github.com/JuliaLang/METADATA.jl is probably the way to go.
>>>
>>> I think you are pointing out a more general "discoverability" problem 
>>> though, which we still haven't tackled (some sort of tagging system has 
>>> been thrown around before).
>>>
>>> On Thursday, May 1, 2014 2:57:42 PM UTC-4, Hans W Borchers wrote:

 Sorry for taking so much of your time.

 I mean a simple and easily scrollable list of packages such as is 
 available in the left frame of page http://docs.julialang.org/en/
 release-0.2/packages/packagelist/ . Many package names give a good 
 hint to what they are doing, thus finding things I would not have expected 
 (and therefore could not search for). 

 Without that list I could not have generated the list of Julia packages 
 for numerical math that I posted in the thread "All packages for numerical 
 math" on April 25. I could not have done this with, e.g., 
 http://iainnz.github.io/packages.julialang.org/ .



 On Thursday, May 1, 2014 8:36:13 PM UTC+2, Iain Dunning wrote:
>
> There are over 300 packages so it I'm not really sure how a table of 
> contents would help - could you describe what you'd want one for? The 
> easiest way to find a package is to start typing its name.
>
> On Thursday, May 1, 2014 2:09:42 PM UTC-4, Hans W Borchers wrote:
>>
>> This list is difficult to scroll (because of using large fonts, 
>> probably).
>> I am still missing a "table of contents" like on the package list for 
>> version 0.2.0 !
>>  
>>
>>

Re: [julia-users] Re: Package list for the latest version

[Samuel Colvin]

Surely we need to get rid of the current packages 
page: http://docs.julialang.org/en/latest/packages/packagelist/

It's still pretty high up google and people are surely going to it and 
coming away disappointed that a package doesn't exist when actually it does.

It wasn't until I found this thread that I discovered that that list was 
actually depreciated.

At the very least it should have a "DEPRECIATED, NEW LIST HERE" warning at 
the top?

On Friday, 2 May 2014 04:32:06 UTC+1, Jacques Rioux wrote:
>
> Or may I suggest simply calling Pkg.available() in the Julia REPL 
> directly. 
>
> You get the list right there for you.to browse and inspect.
>
> And it is always up to date.
> On May 1, 2014 3:20 PM, "Iain Dunning" > 
> wrote:
>
>> I see. Well, I guess in that case the list at 
>> https://github.com/JuliaLang/METADATA.jl is probably the way to go.
>>
>> I think you are pointing out a more general "discoverability" problem 
>> though, which we still haven't tackled (some sort of tagging system has 
>> been thrown around before).
>>
>> On Thursday, May 1, 2014 2:57:42 PM UTC-4, Hans W Borchers wrote:
>>>
>>> Sorry for taking so much of your time.
>>>
>>> I mean a simple and easily scrollable list of packages such as is 
>>> available in the left frame of page http://docs.julialang.org/en/
>>> release-0.2/packages/packagelist/ . Many package names give a good hint 
>>> to what they are doing, thus finding things I would not have expected (and 
>>> therefore could not search for). 
>>>
>>> Without that list I could not have generated the list of Julia packages 
>>> for numerical math that I posted in the thread "All packages for numerical 
>>> math" on April 25. I could not have done this with, e.g., 
>>> http://iainnz.github.io/packages.julialang.org/ .
>>>
>>>
>>>
>>> On Thursday, May 1, 2014 8:36:13 PM UTC+2, Iain Dunning wrote:

 There are over 300 packages so it I'm not really sure how a table of 
 contents would help - could you describe what you'd want one for? The 
 easiest way to find a package is to start typing its name.

 On Thursday, May 1, 2014 2:09:42 PM UTC-4, Hans W Borchers wrote:
>
> This list is difficult to scroll (because of using large fonts, 
> probably).
> I am still missing a "table of contents" like on the package list for 
> version 0.2.0 !
>  
>
>

Re: [julia-users] get step size of linspace

[Andrei Berceanu]

Its the `colon` function I was looking for, ty!

On Tuesday, July 1, 2014 6:27:55 PM UTC+2, Sam L wrote:
>
> Vector{Float64} is an just array of floats in memory, and there's no way 
> of knowing without checking that they're sorted in increasing or decreasing 
> order and equally spaced. In order to convert from Vector{Float64} to 
> FloatRange{Float64}, you'd have to assume that this is true or check.  If 
> you already know that should be true, you might as well use a range in the 
> first place.
>
> As Mauro said, they're both AbstractArrays and can be used interchangeably 
> in many cases, so there's not really any good reason to have such a 
> function. It's true that ranges use less memory, but if you already have a 
> vector sitting there you may as well use it, since the memory is already 
> allocated.
>
> If you wanted such a function something like this might* work:
> function vec2range(v::Vector{Float64}) 
>   issorted(v) || error("Not sorted")
>   a = (v[end] - v[1])/(length(v)-1)
>   for i in 2:length(v)
> isapprox(a, v[i]-v[i-1]) || error("Differences are not constant")
>   end
>   colon(v[1], a, v[end])
> end
>
> *Might because floats are weird . See #2333 
> , #5636 
> , and probably others.  It 
> also does not work if length(v) < 2.
>
>
> On Tuesday, July 1, 2014 8:31:21 AM UTC-7, Andrei Berceanu wrote:
>>
>> And isn't there some inverse function to []?
>> I mean, if i have a Vector{Float64} [myrange] and want to convert it into 
>> a FloatRange{Float64} myrange.
>>
>>
>> On Tuesday, July 1, 2014 2:35:03 PM UTC+2, Mauro wrote:
>>>
>>> > Mauro, is that the only difference, the memory allocation? Can I use 
>>> ranges 
>>> > for plotting, for instance? 
>>>
>>> Ranges are basically just 3 numbers: start, step & stop.  Just have a 
>>> look at base/range.jl 
>>>
>>> On whether they can be used instead of arrays depends on the 
>>> implementation of the function in question.  However, generally 
>>> functions are implemented in terms of AbstractArray which Range (as well 
>>> as Array) is a subtype of.  Just try and if it doesn't work turn it into 
>>> an array with [myrange]. 
>>>
>>> > On Tuesday, July 1, 2014 1:33:34 PM UTC+2, Mauro wrote: 
>>> >> 
>>> >> > If I define an array using the syntax 
>>> >> > 
>>> >> > a = [start:step:end] 
>>> >> > 
>>> >> > how can I later recover the step? I tried step(a), but that only 
>>> seems 
>>> >> to 
>>> >> > work for integer ranges. 
>>> >> 
>>> >> Why not keep the range?  It should work just like an array but use 
>>> less 
>>> >> memory: 
>>> >> 
>>> >> a = start:step:end 
>>> >> 
>>> >> and step works for float ranges: 
>>> >> 
>>> >> julia> step(0.5:6.1:40) 
>>> >> 6.1 
>>> >> 
>>>
>>>

[julia-users] Syntax highlighting in the REPL?

[Aerlinger]

It's great having colored answer output in the REPL, but I was wondering if 
there are any plans to add colored syntax highlighting for 
keywords/identifiers as well. Not a critical issue, but would improve 
readability.

[julia-users] Re: Inconsistent results from linrange

[Ivar Nesje]

It is not a shocker to me. The problem is that Floating point numbers 
represent binary fractions, and there is no way for linrange() to actually 
get equidistant values you are looking for. It has to do approximations, 
and thus it will sometimes miss closest possible value. That means equality 
checks on floating point numbers should be used with extreme care.

Our implementation reuses the old step size when indexing a FloatRange with 
a range, but we could probably do better if we tried to keep the last point 
equal.

I reopened https://github.com/JuliaLang/julia/issues/7420 to keep track of 
this issue.

Ivar

kl. 07:07:25 UTC+2 onsdag 2. juli 2014 skrev Peter Simon følgende:
>
> The final result below seems really strange to me.  A bug?
>
> julia> x = linrange(1,10,20)
> 1.0:0.47368421052631576:10.0
>
>
> julia> 10 .<= x  # Gives expected result
> 20-element BitArray{1}:
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>   true
>
> julia> 10 .<= x[end]  # Gives expected result
> true
>
> julia> 10 .<= x[2:end]  # The last entry in this result is a shocker to 
> me!
> 19-element BitArray{1}:
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>  false
>
>
>
> Here is the version info:
>
>
> julia> versioninfo()
> Julia Version 0.3.0-prerelease+3987
> Commit 7dd97fa (2014-06-30 23:12 UTC)
> Platform Info:
>   System: Windows (x86_64-w64-mingw32)
>   CPU: Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>
>