@Mauro- thanks for the correction. @Thomas- thanks for the explanation!
On Friday, April 24, 2015 at 4:51:49 AM UTC-4, Tomas Lycken wrote: > > It might be worthwhile to point out *why* the last example acts in a > seemingly unintuitive way: all assignments return their right-hand sides, > so both n = 5.0 and n::Int = 5.0 return 5.0 - the latter will assign 5 to > the value of n, but it is not n that is returned in either case. > > I very rarely find a need for the ::T syntax other than to provide > methods to multiple dispatch; if I need to make sure that I assign n an > integer, I use n = convert(Int, 5.0) instead. It’s slightly more verbose, > but its return value will also be an integer (or throw an InexactError, > in which case I need to decide *how* to convert to integer and use a > function from the round/ceil/floor family instead…). > > // T > > On Friday, April 24, 2015 at 10:40:40 AM UTC+2, Mauro wrote: > > > (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! >> >>>>> >> >>>> >> >> >
