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! > >>>>> > >>>> > >
