> (3) Cool given knowledge about P. However the ::T syntax is not for > declarations. Only annotations/assertions. If I try to run > > P = [1,2,3,4] > N::Int = sqrt(length(P)) > > I get a variable not defined error (julia 0.3.7). If I write instead > > P = [1,2,3,4] > N = sqrt(length(P))::Int > > the assertion fails, as sqrt returns a floating point type.
No, it works as Andrei coded it. This is because :: behaves differently depending on whether it is in a value or variable context and whether it's at the REPL or in a local scope: http://docs.julialang.org/en/latest/manual/types/#type-declarations julia> n::Int = 5.0 ERROR: UndefVarError: n not defined in eval at no file julia> f() = (n::Int = 5.0; n) f (generic function with 1 method) julia> f() 5 with this gotcha: julia> f() = n::Int = 5.0 f (generic function with 1 method) julia> f() 5.0 > (4) Got it, I think. As I can't quite see why the particular branching > sequence is the right one though (could there, in principle, be fewer > elseif statements?) I would again suggest that perhaps a pattern matching > syntax could help clarify whats going on here. > > Yes I was referring to the gauge parameter. I can't quite remember > specifically what my offhand comment was about now. Although I think the > problem is still interesting! > > Anyway, my reply only has a bit of substance this time, but hopefully it > can help. > > On Monday, April 13, 2015 at 9:23:42 AM UTC-4, Andrei Berceanu wrote: >> >> Hi Gabriel, thanks a lot for your reply! >> >> (1) I use the WaveFunction type inside the Spectrum type, which as you can >> see is a collection of wavefunctions. For a typical usage case, have a look >> at >> >> http://nbviewer.ipython.org/github/berceanu/topo-photon/blob/master/anc/exploratory.ipynb >> I am not quite sure what you mean with defining a methods for the "int" >> attribute. >> (2) As you can see, the gauge is an attribute of the Spectrum type, which >> is what I use in practice so I didn't see much point in storing it inside >> every wavefunction. Do you have a suggestion for a better implementation? >> In fact there are only these 2 gauge choices, landau and symmetric. >> (3) P should be a Vector of length N^2, and I thought that declaring N to >> be an int means implicit conversion as well - is that not so? >> (4) genspmat generates the (sparse) matrix of the Hamiltonian, so >> countnonzeros() simply counts beforehand how many nonzero elements there >> will be in this sparse matrix. If you think of an NxN 2D lattice, >> countnonzeros() simply counts the number of neighbours of each site (4 for >> a center site, 3 for an edge site and 2 for a corner site). >> >> What do you mean by irrelevant in this case? Are you refering to the gauge >> parameter? >> >> On Sunday, April 12, 2015 at 11:28:48 PM UTC+2, Gabriel Mitchell wrote: >>> >>> Hi Andrei. I am not really Julia expert, but I do have a couple of high >>> level questions about your code, which might help anyone that feels >>> inclined to contribute a review. >>> >>> (1) Why have you made the WaveFunction type in the first place? In >>> particular, is there any reason that you just don't use alias >>> Vector{Complex{Float64}} >>> and define a methods for the "int" attribute? >>> (2) the outer construction seems to allow for the option for different >>> gauges (which, in my unsophisticated mindset, I think of as alternative >>> parameterizations). Since different gauge choices in some sense imply >>> different semantics for the values in Psi (although presumably not other >>> function invariant to the gauge choice), it would seem that the user (or a >>> function naive to the gauge choice) would want a means to inspect this >>> change in the object. In other words why is the gauge not an attribute of >>> the WaveFunction object, assuming you actually want this type? A related >>> question would be how many different gauges choices does one expect the >>> user to want to use. Just these two? These two plus a few more? All of them? >>> (3) Line 17 asserts that N is an integer, but sqrt(length(P)) could be >>> non-integral. >>> (4) I don't really understand what is going on with countnonzeros, but >>> maybe a pattern matching syntax ala Match.jl could help to make a more >>> declarative version of this function? >>> >>> As a side note, I think the problem of how to describe and take advantage >>> of irrelevant degrees of freedom in numerical computations is pretty >>> interesting and certainly has applications in all kids of fields, so it >>> would be cool if you had some ideas about how to systematically approach >>> this problem. >>> >>> >>> On Sunday, April 12, 2015 at 10:06:10 PM UTC+2, Andrei Berceanu wrote: >>>> >>>> Hi Mauro, I realised after posting this that I should have been much >>>> more specific. >>>> I apologise for that! >>>> >>>> Anyway, thanks for you reply. Not sure what you mean by OO programming, >>>> as I thought Julia uses multiple dispatch and not OO. >>>> >>>> PS: You're the first person I see that also uses runbox, that makes us >>>> "email brothers" I guess :p >>>> >>>> On Sunday, April 12, 2015 at 8:29:44 PM UTC+2, Mauro wrote: >>>>> >>>>> Hi Andrei, >>>>> >>>>> just a general note, unless someone is actually interested in using >>>>> your >>>>> code, a code review might be too much to ask of people. Thus the lack >>>>> in responses. See: >>>>> >>>>> https://groups.google.com/forum/#!searchin/julia-users/karpinski$20reivew/julia-users/C5cVjAuGA8U/HLV5rAjIuLMJ >>>>> >>>>> >>>>> The way to get most feedback, is to condense your problem into a small >>>>> snippet which can just be run with copy-paste (you're gists fails >>>>> there) >>>>> and ask something specific. An exception seem to be questions of the >>>>> kind "I ported this from C/Fortran/... and it is 100x slower, where did >>>>> I go wrong", which seem to regularly attract much feedback. >>>>> >>>>> I didn't look into the code in detail: >>>>> >>>>> > It's the first time I try to use Julia constructors properly (or >>>>> > improperly?!) so I need your opinion on a couple of points. >>>>> >>>>> Use of constructors seem to be fine. >>>>> >>>>> > 1. On Julia's IRC channel I was told that using AbstractArray instead >>>>> of >>>>> > e.g. Matrix/Vector might yield a performance boost - is that the >>>>> case? >>>>> >>>>> No, I don't think so. Did you read the Performance section of the >>>>> manual? There it also tells you how to profile your code. >>>>> >>>>> > 2. Can you spot any major performance killers in my code? >>>>> > 3. Coming from Python, I am used to things like enumerate etc, but >>>>> perhaps >>>>> > that is not very "Julian"? :) So this last aspect concerns more the >>>>> coding >>>>> > style, I guess. >>>>> >>>>> Using enumerate is totally fine. Just don't do object-oriented >>>>> programming. >>>>> >>>>> Looks all good to me! >>>>> >>>>
