Hello again Andrei, Sorry for the late reply I have been traveling. Actually I have been traveling so much that I may have lots my train of thought on a few points. But with respect to (1) and (2), without thinking too much about sensible implementations (or even exactly what you are doing), I would have expected that an object with a type called "Spectrum" would be concerned with observables, which shouldn't change with the gauge. That is why my first thought was that the gauge be tied only to unobservables, like the wave function.
(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. (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! >>>> >>>
