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