Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Julia v0.6 [Initial Build] #4

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Add support for Julia v0.6 [Initial Build] #4

wants to merge 13 commits into from

Conversation

TestSubjector
Copy link

@TestSubjector TestSubjector commented Apr 17, 2017

So, this library hasn't been updated in quite a while.
Meanwhile Julia has moved from v0.3 to v0.6, with several breaking changes and redesigns to the language. With reference to Issue #2 , the package was failing to run on Julia v0.4 itself back then.

Hence this PR is an initial attempt to get the library running on Julia v0.6 (skipping 0.4 and 0.5). Included are fixes to deprecated keywords, functions and more. Almost all of the features of the library run with this PR, except the following -

  • Multi-line support
  • Operators as functions(macros)
  • Changes in documentation
  • A few deprecation warnings remain and perhaps possible reversion of some changes in the code design I've made

I've kinda gotten stuck on how to fix the above and would like suggestions and/or commits on how to proceed further.

Base.scale and Base.scale! were deprecated in v0.5 and removed in
v0.6-pre.alpha.  Removing their import permits use on v0.6-
May require a look in the future.
The lowercase symbol function has been deprecated in favor of the Symbol constructor (#16154)
New normalize and normalize! convenience functions were introduced for normalizing vectors (#13681)
This created ambiguity with QuDirac's normalize and normalize! Fix for that

In addition, used Symbol constructor to convert Expr objects to Symbol
…oving from v0.3 to v0.6

The keywords used to define types have changed (#19157, #20418) of JuliaLang/julia.
"abstract changes to abstract type ... end", fix for the same.

The typealias keyword is deprecated, and should be replaced with Vector{T} = Array{T,1} or a const assignment (#20500) of JuliaLang/julia.
Fix for the same

Changed Base.(operator) to Base.operator to fix deprecation warnings. Note, this should be replaced in the future
as one no longer defines methods for .* etcetera due to (#17623) of JuliaLang/julia.
* "Inner constructor" syntax for parametric types is deprecated. (#11310) of JuliaLang/julia. Fix for the same
* @test_approx_eq x y has been deprecated in favor of @test isapprox(x,y) or @test x ≈ y (#4615) of JuliaLang/julia. Partial fix for the same
* Removed enclosing comments from error-prone code
* Fixed method matching error for matrep( cannot be tested till str_macros' errors are resolved)
@jrevels
Copy link
Contributor

jrevels commented Apr 25, 2017

Hi @TestSubjector! This is quite the endeavor, I commend you for tackling it. I've not really paid much attention to QuDirac since the days of Julia v0.3, and didn't even realize anybody was still interested in using it.

At this point, a large number of drastic changes would be necessary to turn this into a high quality Julia package for v0.6. This is both because of all the new Julia features and conventions that have been added/adopted since v0.3, and because this was my first real Julia package (so it has some noobish design warts).

Unfortunately, I don't have the time these days to work on QuDirac, so you'd have to work mostly on your own. Sorry about that! If you're still interested in working on it, though, I can at least do quick code reviews for this and future PRs. Let me know what you think.

@TestSubjector
Copy link
Author

Thanks. And yes, I'd definitely like to work on this.

My semester ends in about a month and I've a few task to complete in the upcoming vacation. But besides that, I'd hopefully be able to contribute to this in my free time.

I guess the first priority would be to get the current code up and running. After that, the modifications and new features to be implemented should be focused on.
One thing I'd like to know is, what was the future road-map for QuDirac? For examples I saw references to closure redesign and interface implementation in #2. What else was in the works?

Also, feel free to give any recommendations on how I should proceed from here on.

end

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole warning should probably go away, any version handling should just go into the REQUIRE anyway


Base.hash(i::InnerProduct) = hash(blabel(i), hash(klabel(i)))
Base.hash(i::InnerProduct, h::Uint64) = hash(hash(i), h)
Base.hash(i::InnerProduct, h::UInt64) = hash(hash(i), h)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be UInt instead of UInt64 (to accommodate 32-bit systems)

@@ -75,15 +75,15 @@ same_num(iex::InnerExpr, n::Number) = iex == InnerExpr(n)
same_num(n::Number, iex::InnerExpr) = iex == n

Base.hash(iex::InnerExpr) = hash(iex.ex)
Base.hash(iex::InnerExpr, h::Uint64) = hash(hash(iex), h)
Base.hash(iex::InnerExpr, h::UInt64) = hash(hash(iex), h)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here - UInt64 --> UInt

StateLabel(label::NTuple{N}, h::Uint64) = new(label, h)
hash::UInt64
StateLabel{N}(label::NTuple{N}) where N = new(label, hash(label))
StateLabel{N}(label::NTuple{N}, h::UInt64) where N = new(label, h)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more UInt64 --> UInt situations. It seems there are a bunch of these - they should all get fixed, but I'll just stop commenting on them.

normalize(s::DiracState) = (1/norm(s))*s
normalize!(s::DiracState) = scale!(1/norm(s), s)
QuDirac.normalize(s::DiracState) = (1/norm(s))*s
QuDirac.normalize!(s::DiracState) = scale!(1/norm(s), s)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

QuDirac. --> Base., since Base defines normalize/normalize! these days.

end

OpDefExpr(ods::OpDefStr) = OpDefExpr(symbol(ods.op_name), parse(ods.label_args), symbol(ods.lhs_type), parse(ods.rhs))
OpDefExpr(ods::OpDefStr) = OpDefExpr(Symbol(ods.op_name), Symbol(parse(ods.label_args)), Symbol(ods.lhs_type), Symbol(parse(ods.rhs)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm...why force these to be Symbols, when before they could be Symbols or Exprs?

@jrevels
Copy link
Contributor

jrevels commented May 23, 2017

One thing I'd like to know is, what was the future road-map for QuDirac? For examples I saw references to closure redesign and interface implementation in #2. What else was in the works?

Julia has changed so much since I thought about this package that I'm not even sure what a redesign would entail anymore. Likely, a complete rewrite of the package. Here are things I can think of off the top of my head:

  • Documentation should be completely rewritten using in-source docstrings + Documenter.jl
  • The whole default_inner_product thing can be done more elegantly now that automatic recompilation of dependent functions JuliaLang/julia#265 is fixed (I think I have a note in the code about this).
  • The various state/operator types defined here could probably redesigned with trait-based dispatch in mind. For example, you could implement a generic DiracSum type representing sums of "like" objects, and dispatching on operator-ness/ket-ness/bra-ness could be done via traits instead of subtype relations.
  • I recall feeling that a lot of loop-based code could be rewritten more cleanly with map calls, but was afraid of over-using closures/anonymous functions at the time due to the performance problems.
  • The whole InnerExpr thing could probably use another pass.

Also, folks have done a lot of work on CASes in Julia by now (e.g. Nemo.jl). At this point, it might be the case that all or part of QuDirac should just be rebuilt as a domain-specific package on top of one of these systems instead.

Anyway, I'll give you commit access here since I'm not going to be available to help most of the time. Feel free to merge PRs, open/close issues, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants