Re: [julia-users] Help needed with creating Julia package
Firstly, GMP 5 is currently a drop-in replacement for MPIR for us. We prefer to use MPIR since I am the maintainer of the latter, and significant work has gone into making various features faster. If the reverse is true, and MPIR would be a drop-in replacement for GMP for Julia, then it could also be a possibility that Julia could try to use MPIR instead of GMP in the future. I'm not aware of the specific differences other than MPIR intends to be more compatible with MSVC, and compiling Julia with MSVC is an ongoing experiment that I've done a fair amount of work on. Having the maintainer of a dependency library happen to be a user of Julia might be convenient for... reasons. For flint we definitely require the latest bleeding edge git version. Even the last official release from us, flint-2.4.4, will not work with Nemo. We can experiment with bleeding edge git instead. We'll have to see how many more changes will be needed. Presumably you can tag a release of flint once we're happy things are working? The CP text file is absolutely enormous (nearly a megabyte). Encoding it as a string is certainly out of the question (we strictly adhere to the ANSI standard, which limits strings to something like 750 bytes). We've discussed many other ways of handling it, and numerous people have tried various things. It's a major pain in the backside, but totally necessary to have it (mathematically speaking). Currently it is not too bad in that once flint is installed, so is the file, in a location with a fixed offset from the library (which will have been specified by --prefix). If the user chooses to build flint in the source tree, it is located in a fixed location within the source tree which flint can also find it. This is all fine, so long as nothing gets moved after compilation and installation, which is the usual case, it seems. So is the path a relative path between the library and the text file, or an absolute path to the text file? When installing from a binary we can keep the relative path consistent pretty easily, absolute path definitely not. If it's an absolute path, would it be feasible to check the compile-time defined path first by default (as is done currently), but fall back to using an environment variable or other runtime path initialization method if the default location fails? The problem with linking against Julia's GMP and MPFR was as follows. We can tell Julia where to find flint by pushing to DL_LOAD_PATH. But this only tells Julia where to find flint. The system linker is the one that tries to subsequently link flint with MPIR and MPFR, and it hasn't got a clue where to find them. What we push on DL_LOAD_PATH is irrelevant, as only Julia knows about that. This actually causes Julia to report that it can't find flint. I spent many, many hours figuring that one out. I'm not proposing to push anything to DL_LOAD_PATH for GMP or MPFR. Rather we tell flint's build system at compile time where to find Julia's GMP and MPFR via -L. Those libraries will always be either at a consistent relative path vs JULIA_HOME, or in standard system library paths if the user (or package manager) built Julia against system GMP/MPFR. I think it would be safe to check if joinpath(JULIA_HOME,..,lib,libgmp.$(sys.dlext)) is openable via dlopen_e, and if not then falling back to find_library([libgmp]). Now it occurs to me that perhaps if we build flint against Julia's GMP and MPFR (assuming GMP is version 5 and MPFR version 3.1), then because Julia's libs are placed in the path by Julia, the system linker might just find them. That hadn't occurred to me as a possibility. The obvious problem is GMP is not MPIR and we are limited to using whatever version of GMP Julia chooses. Actually, maybe the git version of flint already supports GMP 6 nowadays too. For Julia 0.3.0, GMP is version 5.1.3, MPFR is version 3.1.2. Check https://github.com/JuliaLang/julia/blob/768187890c2709bf2ff06818f40e1cdc79bd44b0/deps/Versions.make for the default version numbers used. On Julia master, GMP has been bumped to 6.0.0. Also, flint uses libgcc_s and pthreads (and libm). We've currently set it up to statically build libgcc_s into flint, but we can't do that with pthreads. Initially at least we could disable pthreads when building flint (there is an option for it) but I guess in the long run we won't want to do that. I guess we can for now, but it seems like a compromise. You don't need to do this if you use WinRPM. If libgcc_s and/or pthreads are dynamically linked, the RPM packaging scripts on the build service detect that and mark the dll's as dependencies, so they get correctly downloaded when you install the package. Linking dynamically will make your binaries smaller, and many other things also link to these same libraries. Regarding licenses, I would guess the GPL v3 and LGPL v3 license texts need to be distributed with Julia binaries, along with a
Re: [julia-users] Re: dispatch based on expression head
We've actually discussed changing our expression representation to use types instead of the more lisp-like symbols for distinguishing expression types. That would allow dispatch on expression types and be more compact. It would, however, break almost all macros that do any kind of expression inspection. On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcalh...@iastate.edu wrote: On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson wrote: On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun wrote: Are there better ways to do this in general? For this kind of expression-matching code, you may find the Match.jl package handy (https://github.com/kmsquire/Match.jl), to get ML- or Scala-like symbolic pattern-matching. Thanks, that's pretty cool. For simple cases like I'm using, do you know if there are advantages (or disadvantages) to using Match.jl, or should I just view it as a nicer syntax? (Obviously, when things get more complicated Match.jl looks very appealing).
Re: [julia-users] Does Julia have something similar to Python's documentation string?
On Thu, Sep 11, 2014 at 4:24 PM, Steven G. Johnson stevenj@gmail.com wrote: I really think that embedding documentation in comments is a mistake. Documentation needs to be a part of the language, included in a semantically meaningful way, not an add-on that is semantically meaningless (comments). Either the documentation affects the meaning of the code or it doesn't. Type annotations give us a lot of functional documentation, with the advantage that it can't be out of sync with the code since it *is* the code. I'm in favor of having as much of this kind of documentation as possible. There will always, however, be more documentation that doesn't affect the behavior of the code. I'm not even sure what it means for that kind of documentation to be semantically meaningful – you mean that it has a specified format means something? I'm not sure why that has anything to do with whether this is in comments or not. How is a string that you parse and associate with a function more or less meaningful than a comment that you parse and associate with a function? To me the only difference is that I really don't want to write @doc commentary function ... whereas I already write things along the lines of # commentary function ... all the time. All the extra syntax makes this kind of documentation feel heavy and awkward instead of light and natural. In my experience, heavy, awkward things tend not to get used while light natural things tend to get used.
Re: [julia-users] Re: Type parameter trouble (bug?)
Thanks! I guess this was actually about me not thinking about this the right way (perhaps having my metaprogramming notions colored by C++ … *ugh* … and not being quite used to the blend of type-based compilation with execution). I don't actually need dispatch on this – I just wanted to ensure that types got composed correctly – but I see that I can use the same approach as in Image https://github.com/timholy/Images.jl/blob/master/src/core.jl. That is, explode the composite type parameter (and extract the component type parameters) during constructor execution. The only thing that I'm sort of missing now is a case where I have *two* composite type parameters, and I want to make sure one/some of their type parameters match. Conceptually, this could be, say, to array types, and I want to make sure they have the same number of dimensions, and this should end up as a type parameter (exploded as before). An example would be if one wanted to extend Image to, say, contain two AbstractArrays (image overlay, or something?), and they should have the same dimensions. How would I handle that in a natural manner? I see some possibilities: 1. Don't. Use duck typing and cross your fingers. (Fine by me, I guess. I'm used to Python, after all.) 2. Simply extract the dimensions and add an @assert to the constructor. 3. Extract the dimensions from one and use a type assert with the appropriate type parameter on the other (sort of similar). I just wonder if there is some way to do this with the type system, so that it's more compiler-friendly (so it can all ideally be optimized away)?
Re: [julia-users] Does Julia have something similar to Python's documentation string?
To me the only difference is that I ` really don't want to write @doc commentary function ... whereas I already write things along the lines of # commentary function ... doc function doc function ... is already better, and then let's get rid of even the doc keyword. It would be kind of less breaking a change, as currently comments are mainly written for developpers consumption and not meant for documenting public API and would need to be fixed all at once. As both developper comments and API documentation are needed, I find it useful to have two distincts means: comments and strings.
[julia-users] Re: Definition of function with keywoed arguments via macro
Ok, it should be: macro myDef3(name) return esc(:( $name(x; y=3) = return (x*y) )) end @myDef3 f3 f3(4) # now gives 12, as expected f3(4, y=5) #now gives 20, as expected The return must be explicitly written. But why? I find this very confusing. On Monday, September 8, 2014 9:58:24 PM UTC+2, Jonas Hagen wrote: Hello! I'm trying to define a function using a macro. But I just dont get it. Look at the following Examples: Using default arguments, everything works as expected: macro myDef2(name) return esc(:( $name(x, y=3) = x*y )) end @myDef2 f2 f2(4) # gives 12, as expected f2(4, 5) #gives 20, as expected So, I assumed the same would work for keyword arguments, but it doesn't: macro myDef3(name) return esc(:( $name(x; y=3) = x*y )) end @myDef3 f3 f3(4) # gives 3 but 12 expected f3(4, y=5) #gives 5 but 20 expected Even more strange: macro myDef4(name) return esc(:( $name(x; y=3) = x )) # not using y here! end @myDef4 f4 # gives ERROR: syntax: malformed expression Am I doing something wrong or is this a bug? Maybe I just don't understand what esc() does or how to define functions in macros, I'm new to Julia. I'm using Version 0.3.0 (2014-08-20 20:43 UTC). - Jonas
Re: [julia-users] Re: Definition of function with keywoed arguments via macro
You might want to file this as an issue. https://github.com/JuliaLang/julia/issues --Tim On Saturday, September 13, 2014 05:10:08 AM Jonas Hagen wrote: Ok, it should be: macro myDef3(name) return esc(:( $name(x; y=3) = return (x*y) )) end @myDef3 f3 f3(4) # now gives 12, as expected f3(4, y=5) #now gives 20, as expected The return must be explicitly written. But why? I find this very confusing. On Monday, September 8, 2014 9:58:24 PM UTC+2, Jonas Hagen wrote: Hello! I'm trying to define a function using a macro. But I just dont get it. Look at the following Examples: Using default arguments, everything works as expected: macro myDef2(name) return esc(:( $name(x, y=3) = x*y )) end @myDef2 f2 f2(4) # gives 12, as expected f2(4, 5) #gives 20, as expected So, I assumed the same would work for keyword arguments, but it doesn't: macro myDef3(name) return esc(:( $name(x; y=3) = x*y )) end @myDef3 f3 f3(4) # gives 3 but 12 expected f3(4, y=5) #gives 5 but 20 expected Even more strange: macro myDef4(name) return esc(:( $name(x; y=3) = x )) # not using y here! end @myDef4 f4 # gives ERROR: syntax: malformed expression Am I doing something wrong or is this a bug? Maybe I just don't understand what esc() does or how to define functions in macros, I'm new to Julia. I'm using Version 0.3.0 (2014-08-20 20:43 UTC). - Jonas
Re: [julia-users] Does Julia have something similar to Python's documentation string?
How about using a colon at the end of a doc string? It would signifying that the string belongs to the object following and it is light on the eye. This would look like: Function documentation, blah: f(x) = 2x and A longer function documentation. - blah - blah : f(x) = 2x (Also, maybe the syntax could require for the documented object to follow without an empty line.) On Sat, 2014-09-13 at 12:02, Rafael Fourquet fourquet.raf...@gmail.com wrote: To me the only difference is that I ` really don't want to write @doc commentary function ... whereas I already write things along the lines of # commentary function ... doc function doc function ... is already better, and then let's get rid of even the doc keyword. It would be kind of less breaking a change, as currently comments are mainly written for developpers consumption and not meant for documenting public API and would need to be fixed all at once. As both developper comments and API documentation are needed, I find it useful to have two distincts means: comments and strings. --
Re: [julia-users] Does Julia have something similar to Python's documentation string?
And one on front might work too for one liners: x = 5 :this is #5 f(x) = 2x :double me Others will have to comment on whether that would not conflict with other colon syntax. On Sat, 2014-09-13 at 15:04, Mauro mauro...@runbox.com wrote: How about using a colon at the end of a doc string? It would signifying that the string belongs to the object following and it is light on the eye. This would look like: Function documentation, blah: f(x) = 2x and A longer function documentation. - blah - blah : f(x) = 2x (Also, maybe the syntax could require for the documented object to follow without an empty line.) On Sat, 2014-09-13 at 12:02, Rafael Fourquet fourquet.raf...@gmail.com wrote: To me the only difference is that I ` really don't want to write @doc commentary function ... whereas I already write things along the lines of # commentary function ... doc function doc function ... is already better, and then let's get rid of even the doc keyword. It would be kind of less breaking a change, as currently comments are mainly written for developpers consumption and not meant for documenting public API and would need to be fixed all at once. As both developper comments and API documentation are needed, I find it useful to have two distincts means: comments and strings. --
Re: [julia-users] Re: dispatch based on expression head
That'd be bad news for Lint... On Saturday, September 13, 2014 3:22:04 PM UTC+7, Stefan Karpinski wrote: We've actually discussed changing our expression representation to use types instead of the more lisp-like symbols for distinguishing expression types. That would allow dispatch on expression types and be more compact. It would, however, break almost all macros that do any kind of expression inspection. On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu javascript: wrote: On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson wrote: On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun wrote: Are there better ways to do this in general? For this kind of expression-matching code, you may find the Match.jl package handy (https://github.com/kmsquire/Match.jl), to get ML- or Scala-like symbolic pattern-matching. Thanks, that's pretty cool. For simple cases like I'm using, do you know if there are advantages (or disadvantages) to using Match.jl, or should I just view it as a nicer syntax? (Obviously, when things get more complicated Match.jl looks very appealing).
Re: [julia-users] Re: dispatch based on expression head
We've actually discussed changing our expression representation to use
types instead of the more lisp-like symbols for distinguishing expression
types. That would allow dispatch on expression types and be more compact.
It would, however, break almost all macros that do any kind of expression
inspection.
Hmm, interesting. I guess the Expr type would then be Expr{:head} with
getindex / setindex overloaded to manipulate the arguments? This would be
a nice change as for many nodes you would not have to allocate an args
array which could be a performance win (i guess the serialized ast's would
be more compact as well). Can't comment on whether it would be enough of a
win to justify such a massively breaking change.
On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu wrote:
On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson
wrote:
On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun wrote:
Are there better ways to do this in general?
For this kind of expression-matching code, you may find the Match.jl
package handy (https://github.com/kmsquire/Match.jl), to get ML- or
Scala-like symbolic pattern-matching.
Thanks, that's pretty cool. For simple cases like I'm using, do you know
if there are advantages (or disadvantages) to using Match.jl, or should I
just view it as a nicer syntax? (Obviously, when things get more
complicated Match.jl looks very appealing).
Re: [julia-users] constants environment
Macros are useful for this sort of thing. ``` macro allconst(args...) exp = Expr(:block) args[1].head == :block for a in args[1].args a.head == :(=) push!(exp.args, Expr(:const, Base.esc(a) )) end exp end @allconst begin a = 1 b = 2 end ``` (see the Metaprogramming section in the manual for more information) On Sat, Sep 13, 2014 at 8:37 AM, Yakir Gagnon 12.ya...@gmail.com wrote: I often define a bunch of constants at the beginning of a program. Wouldn't it be nice if we could start an environment of constants to avoid writing `const` before every one of the rows at the beginning of a program? Kind of like: ```Julia begin const a = 1 b = 2 c = neverChange end ``` instead of: ```Julia const a = 1 const b = 2 const c = neverChange ```
Re: [julia-users] Re: dispatch based on expression head
I would expect the Expr type to be abstract, with different concrete
subtypes for each current value of head. Each value of head indicates a
specific structure in args, and this can just be reflected in the
definition of the subtypes. (Then you can dispatch on Expr type, use
subtypes(Expr) to see all possible kinds of Expr, etc.)
-- Leah
On Sat, Sep 13, 2014 at 10:47 AM, Jake Bolewski jakebolew...@gmail.com
wrote:
We've actually discussed changing our expression representation to use
types instead of the more lisp-like symbols for distinguishing expression
types. That would allow dispatch on expression types and be more compact.
It would, however, break almost all macros that do any kind of expression
inspection.
Hmm, interesting. I guess the Expr type would then be Expr{:head} with
getindex / setindex overloaded to manipulate the arguments? This would be
a nice change as for many nodes you would not have to allocate an args
array which could be a performance win (i guess the serialized ast's would
be more compact as well). Can't comment on whether it would be enough of a
win to justify such a massively breaking change.
On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu
wrote:
On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson
wrote:
On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun
wrote:
Are there better ways to do this in general?
For this kind of expression-matching code, you may find the Match.jl
package handy (https://github.com/kmsquire/Match.jl), to get ML- or
Scala-like symbolic pattern-matching.
Thanks, that's pretty cool. For simple cases like I'm using, do you
know if there are advantages (or disadvantages) to using Match.jl, or
should I just view it as a nicer syntax? (Obviously, when things get more
complicated Match.jl looks very appealing).
Re: [julia-users] Values vs. Bindings: making sense of things
On Friday, September 12, 2014 8:33:03 AM UTC+3, John Myles White wrote:
For future reference, I'd really appreciate you not referring to my
writing as quite erroneous when the claims made are in fact correct.
My apologies, the error is certainly on my part, I misread the === for a
==. I really appreciate all your blog posts and follow them keenly.
-- John
On Sep 11, 2014, at 2:38 PM, Mohammed El-Beltagy mohammed@gmail.com
javascript: wrote:
In a recent blog by John Myles White
http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/
it was suggested that Julia make strong distinction between values and
binding. For example
a = [1, 2, 3]
function foo!(a)
a[1] = 10
return
end
a
Would give an output
3-element Array{Int64,1}:
10
2
3
But subsequently running
function bar!(a)
a = [1, 2]
return
end
a
would give an output of
3-element Array{Int64,1}:
10
2
3
The reason why the variable a was not changed in the case of boo!, but
was changed in the case of foo! has to do with the fact values are the
same their binding.
However to illustrate that point, the examples given in the blog are quite
erroneous. For example
[1,2,3]==[1,2,3]
would yield an out of true, whereas the blog post indicated that is
should be false. This the because the == operator unpacks the values in
the binding and does and element wise comparison.
A better was illustrate that problem is make use of julia's object_id
function. For example
a=[1,2,3]
@printf(Object ID in outerscope 0x%x\n, object_id(a))
function bar!(a)
@printf(Object ID in \!bar and before assignment 0x%x\n, object_id(a
))
a = [1, 2]
@printf(Object ID in \!bar after assignment 0x%x\n, object_id(a))
return
end
bar!(a)
@printf(Object ID in outerscope after \!bar is 0x%x\n, object_id(a))
a
The output will be
Object ID in outerscope 0xa19caeb70115d4f0
Object ID in !bar and before assignment 0xa19caeb70115d4f0
Object ID in !bar after assignment 0x782193112dfbbbd5
Object ID in outerscope after !bar is 0xa19caeb70115d4f0
Out[1]:
3-element Array{Int64,1}:
1
2
3
This would mean the when calling a function in Julia the following is true:
- The binding of the argument to the function can never change, though
the values of that binding might.
- The binding can be overridden locally in the scope of the function,
but that is only valid in inside the function's scope
A modification to the above code that does not attempt to override the
original binding, shown below would not change the object id.
a=[1,2,3]
@printf(Object ID in outerscope 0x%x\n, object_id(a))
function bar!(a)
@printf(Object ID in \!bar and before assignment 0x%x\n, object_id(a
))
empty!(a)
push!(a,[1, 2]...)
@printf(Object ID in \!bar after assignment 0x%x\n, object_id(a))
return
end
bar!(a)
@printf(Object ID in outerscope after \!bar is 0x%x\n, object_id(a))
a
Is this how julia handles values and bindings, or it there more to this
picture?
Re: [julia-users] Values vs. Bindings: making sense of things
On Friday, September 12, 2014 8:33:03 AM UTC+3, John Myles White wrote: For future reference, I'd really appreciate you not referring to my writing as quite erroneous when the claims made are in fact correct. My apologies, the error is certainly on my part, I misread the === for a ==. I really appreciate all your blog posts and follow them keenly.
Re: [julia-users] Values vs. Bindings: making sense of things
No worries. I'm glad you enjoy my blog posts. -- John On Sep 13, 2014, at 11:32 AM, Mohammed El-Beltagy mohammed.elbelt...@gmail.com wrote: On Friday, September 12, 2014 8:33:03 AM UTC+3, John Myles White wrote: For future reference, I'd really appreciate you not referring to my writing as quite erroneous when the claims made are in fact correct. My apologies, the error is certainly on my part, I misread the === for a ==. I really appreciate all your blog posts and follow them keenly.
[julia-users] immutable types with array fields
Hi everyone I was wondering (since it seems that we are allowed to use array fields inside immutable types) if there are problems or any loose on the benefits of using immutable types if I do one of the following: 1. Have an array field that is going to maintain its size but not the values of its entries once the immutable is instantiated. 2. Have an array field of variable size. 3. Have an array field that will be unchanged. I can't think of more scenarios for now, but I am curious of what could happen in general by using arrays as fields of immutables. May be I shouldn't be doing it at all. Does anybody know?
[julia-users] Lint.jl status update
Fellow Julians,
I think it is time to post an update on Lint.jl
https://github.com/tonyhffong/Lint.jl, as it has improved quite a bit
from the initial version I started about 3 months ago.
Notable new features
- Local variable type tracking, which enables a range of features, such
as
- Variable type stability warning within a function scope.
- Incompatibility between type assertion and assignment
- Omission of returning the constructed object in a type constructor
- Check the call signature of a selected set of methods with
collection (push!, append!, etc.)
- More function checks, such as
- repeated arguments
- wrong signatures, e.g. f( x::Array{Number,1} )
- Mispelled constructor (calls new but the function name doesn't
match the enclosing type)
- Ability to silence lint warning via lintpragma() function, e.g.
- lintpragma( Ignore unstable type variable [variable name] )
- lintpragma( Ignore Unused [variable name] )
Also, there is now quite a range of test scripts showing sample codes with
lint problems, so it's easy to grep your own lint warnings in that folder
and see a distilled version of the issue.
Again, please let me know about gaps and false positives.
Tony
[julia-users] Re: Benchmark julia is 10x slower than fortran. Should I be happy?
now i am pretty impressed. On Saturday, September 13, 2014 4:12:07 PM UTC-4, Noah Brenowitz wrote: I just replaced u = u0, with u = complex128(u0) in the julia code. Now it is only 2x as slow as fortran.
Re: [julia-users] dispatch based on expression head
While this would greatly affect Match.jl, it would be a very welcome change!
Cheers,
Kevin
On Saturday, September 13, 2014, Leah Hanson astriea...@gmail.com wrote:
I would expect the Expr type to be abstract, with different concrete
subtypes for each current value of head. Each value of head indicates a
specific structure in args, and this can just be reflected in the
definition of the subtypes. (Then you can dispatch on Expr type, use
subtypes(Expr) to see all possible kinds of Expr, etc.)
-- Leah
On Sat, Sep 13, 2014 at 10:47 AM, Jake Bolewski jakebolew...@gmail.com
javascript:_e(%7B%7D,'cvml','jakebolew...@gmail.com'); wrote:
We've actually discussed changing our expression representation to use
types instead of the more lisp-like symbols for distinguishing expression
types. That would allow dispatch on expression types and be more compact.
It would, however, break almost all macros that do any kind of expression
inspection.
Hmm, interesting. I guess the Expr type would then be Expr{:head} with
getindex / setindex overloaded to manipulate the arguments? This would be
a nice change as for many nodes you would not have to allocate an args
array which could be a performance win (i guess the serialized ast's would
be more compact as well). Can't comment on whether it would be enough of a
win to justify such a massively breaking change.
On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu
wrote:
On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson
wrote:
On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun
wrote:
Are there better ways to do this in general?
For this kind of expression-matching code, you may find the Match.jl
package handy (https://github.com/kmsquire/Match.jl), to get ML- or
Scala-like symbolic pattern-matching.
Thanks, that's pretty cool. For simple cases like I'm using, do you
know if there are advantages (or disadvantages) to using Match.jl, or
should I just view it as a nicer syntax? (Obviously, when things get more
complicated Match.jl looks very appealing).
Re: [julia-users] Re: dispatch based on expression head
Surely not in any lasting sense? With a.b syntax overloading we could actually make the transition pretty smooth. On Sep 13, 2014, at 4:47 PM, Tony Fong tony.hf.f...@gmail.com wrote: That'd be bad news for Lint... On Saturday, September 13, 2014 3:22:04 PM UTC+7, Stefan Karpinski wrote: We've actually discussed changing our expression representation to use types instead of the more lisp-like symbols for distinguishing expression types. That would allow dispatch on expression types and be more compact. It would, however, break almost all macros that do any kind of expression inspection. On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu wrote: On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson wrote: On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun wrote: Are there better ways to do this in general? For this kind of expression-matching code, you may find the Match.jl package handy (https://github.com/kmsquire/Match.jl), to get ML- or Scala-like symbolic pattern-matching. Thanks, that's pretty cool. For simple cases like I'm using, do you know if there are advantages (or disadvantages) to using Match.jl, or should I just view it as a nicer syntax? (Obviously, when things get more complicated Match.jl looks very appealing).
[julia-users] immutable types with array fields
FWIW, I've done that before (immutable types, with array fields that change size and mutate entries) and i didn't run into any problems. I wasn't sure that I needed the immutability but I used it just for convenience. In particular I wanted to get an error if I accidentally tried to rebind a field. Moreover, I figured it couldn't hurt the speed. I'll be interested to hear from others if I was doing something risky, confusing or non-idiomatic.
Re: [julia-users] immutable types with array fields
Having an array as a field of an immutable is fine. It will be variable size and heap allocated, just like if you had the array by itself without the immutable. At some point we will tackle fixed-size arrays (and the associated performance benefits) both mutable and immutable. On Sat, Sep 13, 2014 at 4:44 PM, Ethan Anderes ethanande...@gmail.com wrote: FWIW, I've done that before (immutable types, with array fields that change size and mutate entries) and i didn't run into any problems. I wasn't sure that I needed the immutability but I used it just for convenience. In particular I wanted to get an error if I accidentally tried to rebind a field. Moreover, I figured it couldn't hurt the speed. I'll be interested to hear from others if I was doing something risky, confusing or non-idiomatic.
Re: [julia-users] Re: dispatch based on expression head
No please don't mind me. I was just over-excited after pushing out a bunch of commits. On Sunday, September 14, 2014 3:28:25 AM UTC+7, Stefan Karpinski wrote: Surely not in any lasting sense? With a.b syntax overloading we could actually make the transition pretty smooth. On Sep 13, 2014, at 4:47 PM, Tony Fong tony.h...@gmail.com javascript: wrote: That'd be bad news for Lint... On Saturday, September 13, 2014 3:22:04 PM UTC+7, Stefan Karpinski wrote: We've actually discussed changing our expression representation to use types instead of the more lisp-like symbols for distinguishing expression types. That would allow dispatch on expression types and be more compact. It would, however, break almost all macros that do any kind of expression inspection. On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu wrote: On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson wrote: On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun wrote: Are there better ways to do this in general? For this kind of expression-matching code, you may find the Match.jl package handy (https://github.com/kmsquire/Match.jl), to get ML- or Scala-like symbolic pattern-matching. Thanks, that's pretty cool. For simple cases like I'm using, do you know if there are advantages (or disadvantages) to using Match.jl, or should I just view it as a nicer syntax? (Obviously, when things get more complicated Match.jl looks very appealing).
Re: [julia-users] Re: Benchmark julia is 10x slower than fortran. Should I be happy?
Lint.jl is also good for checking that, depending on how much time you want to spend learning to read the output of code_typed. On Sat, Sep 13, 2014 at 3:27 PM, Elliot Saba staticfl...@gmail.com wrote: A good way to track down performance issues like this is to use @code_typed to output the typed code in your function and look for places where type inference doesn't know what to do; e.g. large type unions, Any types, etc This is often caused by a variable taking on multiple separate types over its lifetime within the function and can cause slowdowns inside inner loops. -E On Sat, Sep 13, 2014 at 1:13 PM, Noah Brenowitz nbre...@gmail.com wrote: now i am pretty impressed. On Saturday, September 13, 2014 4:12:07 PM UTC-4, Noah Brenowitz wrote: I just replaced u = u0, with u = complex128(u0) in the julia code. Now it is only 2x as slow as fortran.
Re: [julia-users] Re: Benchmark julia is 10x slower than fortran. Should I be happy?
`crandn() = complex128(randn(),randn())/sqrt(2.)` should get you even closer to fortran. -Mike On Sat, Sep 13, 2014 at 5:01 PM, Leah Hanson astriea...@gmail.com wrote: Lint.jl is also good for checking that, depending on how much time you want to spend learning to read the output of code_typed. On Sat, Sep 13, 2014 at 3:27 PM, Elliot Saba staticfl...@gmail.com wrote: A good way to track down performance issues like this is to use @code_typed to output the typed code in your function and look for places where type inference doesn't know what to do; e.g. large type unions, Any types, etc This is often caused by a variable taking on multiple separate types over its lifetime within the function and can cause slowdowns inside inner loops. -E On Sat, Sep 13, 2014 at 1:13 PM, Noah Brenowitz nbre...@gmail.com wrote: now i am pretty impressed. On Saturday, September 13, 2014 4:12:07 PM UTC-4, Noah Brenowitz wrote: I just replaced u = u0, with u = complex128(u0) in the julia code. Now it is only 2x as slow as fortran.
Re: [julia-users] Re: Benchmark julia is 10x slower than fortran. Should I be happy?
On Sat, Sep 13, 2014 at 11:06 PM, Mike Nolta m...@nolta.net wrote: `crandn() = complex128(randn(),randn())/sqrt(2.)` should get you even closer to fortran. This does indeed generate significantly simpler code for crandn().
[julia-users] How to trace execution?
I want to trace the execution of a Julia program to find out where an error occurs. Is there something like a @trace macro, similar to @time or @profile? -erik
Re: [julia-users] How to trace execution?
Unfortunately, `@profile` is the closest we have now. You could conceivably call `@profile` from within a `try` so that you can print out the profile results at the end. -E On Sat, Sep 13, 2014 at 12:13 PM, Erik Schnetter schnet...@gmail.com wrote: I want to trace the execution of a Julia program to find out where an error occurs. Is there something like a @trace macro, similar to @time or @profile? -erik
Re: [julia-users] Re: Benchmark julia is 10x slower than fortran. Should I be happy?
Mike's modification made the code almost twice as fast on my machine. It worked the fastest of all the things I tried. I also noticed the compiler generally works faster when you do not have a variable outside the scope of a function. For example rootof2=sqrt(2) crandn() = complex128(randn() ,randn() /rootof2) runs slower than const rootof2=sqrt(2) crandn() = complex128(randn() ,randn() /rootof2) or crandn(rootof2) = complex128(randn() ,randn() /rootof2) . . . u = F * u + sig * crandn(sqrt(2)) I initially thought that pre calculating sqrt(2) would save the a few compute cycles by not have to call the sqrt function at each iteration. It seems that compiler does some pretty neat optimization that makes that hand tunning attempts futile. On Sunday, September 14, 2014 12:06:43 AM UTC+3, Mike Nolta wrote: `crandn() = complex128(randn(),randn())/sqrt(2.)` should get you even closer to fortran. -Mike On Sat, Sep 13, 2014 at 5:01 PM, Leah Hanson astri...@gmail.com javascript: wrote: Lint.jl is also good for checking that, depending on how much time you want to spend learning to read the output of code_typed. On Sat, Sep 13, 2014 at 3:27 PM, Elliot Saba stati...@gmail.com javascript: wrote: A good way to track down performance issues like this is to use @code_typed to output the typed code in your function and look for places where type inference doesn't know what to do; e.g. large type unions, Any types, etc This is often caused by a variable taking on multiple separate types over its lifetime within the function and can cause slowdowns inside inner loops. -E On Sat, Sep 13, 2014 at 1:13 PM, Noah Brenowitz nbr...@gmail.com javascript: wrote: now i am pretty impressed. On Saturday, September 13, 2014 4:12:07 PM UTC-4, Noah Brenowitz wrote: I just replaced u = u0, with u = complex128(u0) in the julia code. Now it is only 2x as slow as fortran.
Re: [julia-users] dispatch based on expression head
It would be probably be lasting, because most Exprs would no longer want to
have an args field with a Vector{Any}
On Saturday, September 13, 2014, Stefan Karpinski
stefan.karpin...@gmail.com wrote:
Surely not in any lasting sense? With a.b syntax overloading we could
actually make the transition pretty smooth.
On Sep 13, 2014, at 4:47 PM, Tony Fong tony.hf.f...@gmail.com
javascript:_e(%7B%7D,'cvml','tony.hf.f...@gmail.com'); wrote:
That'd be bad news for Lint...
On Saturday, September 13, 2014 3:22:04 PM UTC+7, Stefan Karpinski wrote:
We've actually discussed changing our expression representation to use
types instead of the more lisp-like symbols for distinguishing expression
types. That would allow dispatch on expression types and be more compact.
It would, however, break almost all macros that do any kind of expression
inspection.
On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu
wrote:
On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson
wrote:
On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun wrote:
Are there better ways to do this in general?
For this kind of expression-matching code, you may find the Match.jl
package handy (https://github.com/kmsquire/Match.jl), to get ML- or
Scala-like symbolic pattern-matching.
Thanks, that's pretty cool. For simple cases like I'm using, do you know
if there are advantages (or disadvantages) to using Match.jl, or should I
just view it as a nicer syntax? (Obviously, when things get more
complicated Match.jl looks very appealing).
Re: [julia-users] dispatch based on expression head
I'm not sure how that makes linting impossible.
On Sat, Sep 13, 2014 at 11:56 PM, Jameson Nash vtjn...@gmail.com wrote:
It would be probably be lasting, because most Exprs would no longer want
to have an args field with a Vector{Any}
On Saturday, September 13, 2014, Stefan Karpinski
stefan.karpin...@gmail.com wrote:
Surely not in any lasting sense? With a.b syntax overloading we could
actually make the transition pretty smooth.
On Sep 13, 2014, at 4:47 PM, Tony Fong tony.hf.f...@gmail.com wrote:
That'd be bad news for Lint...
On Saturday, September 13, 2014 3:22:04 PM UTC+7, Stefan Karpinski wrote:
We've actually discussed changing our expression representation to use
types instead of the more lisp-like symbols for distinguishing expression
types. That would allow dispatch on expression types and be more compact.
It would, however, break almost all macros that do any kind of expression
inspection.
On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu
wrote:
On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson
wrote:
On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun
wrote:
Are there better ways to do this in general?
For this kind of expression-matching code, you may find the Match.jl
package handy (https://github.com/kmsquire/Match.jl), to get ML- or
Scala-like symbolic pattern-matching.
Thanks, that's pretty cool. For simple cases like I'm using, do you
know if there are advantages (or disadvantages) to using Match.jl, or
should I just view it as a nicer syntax? (Obviously, when things get more
complicated Match.jl looks very appealing).
Re: [julia-users] dispatch based on expression head
I wonder whether it would really have much of a performance advantage. Usually
expressions are nested, and so an Expr{:headA} contains among its args an
Expr{:headB}. But you don't know until runtime what type it is, so runtime
lookup would have to be faster than
isa(arg, Expr) (arg::Expr).head == :headB ...`
I don't actually know, but I would be a bit surprised if it would help that
much.
Before someone thinks about tackling this, it would make sense to mock it up;
make a MyExpr{:headsym}, nest a bunch of them based on real expressions, and
then see if you get any real benefit from having the head as a type parameter.
The other negative is it would add to compilation time---currently one version
of a function handles all expressions, but with this change you'd have to
compile a version for each parametric expression type. That means yet slower
startup of any packages that do expression-parsing, and startup speed is
already a pretty big problem.
--Tim
On Saturday, September 13, 2014 01:17:00 PM Kevin Squire wrote:
While this would greatly affect Match.jl, it would be a very welcome change!
Cheers,
Kevin
On Saturday, September 13, 2014, Leah Hanson astriea...@gmail.com wrote:
I would expect the Expr type to be abstract, with different concrete
subtypes for each current value of head. Each value of head indicates a
specific structure in args, and this can just be reflected in the
definition of the subtypes. (Then you can dispatch on Expr type, use
subtypes(Expr) to see all possible kinds of Expr, etc.)
-- Leah
On Sat, Sep 13, 2014 at 10:47 AM, Jake Bolewski jakebolew...@gmail.com
javascript:_e(%7B%7D,'cvml','jakebolew...@gmail.com'); wrote:
We've actually discussed changing our expression representation to use
types instead of the more lisp-like symbols for distinguishing
expression
types. That would allow dispatch on expression types and be more
compact.
It would, however, break almost all macros that do any kind of
expression
inspection.
Hmm, interesting. I guess the Expr type would then be Expr{:head} with
getindex / setindex overloaded to manipulate the arguments? This would
be
a nice change as for many nodes you would not have to allocate an args
array which could be a performance win (i guess the serialized ast's
would
be more compact as well). Can't comment on whether it would be enough of
a
win to justify such a massively breaking change.
On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu
wrote:
On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G. Johnson
wrote:
On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun
wrote:
Are there better ways to do this in general?
For this kind of expression-matching code, you may find the Match.jl
package handy (https://github.com/kmsquire/Match.jl), to get ML- or
Scala-like symbolic pattern-matching.
Thanks, that's pretty cool. For simple cases like I'm using, do you
know if there are advantages (or disadvantages) to using Match.jl, or
should I just view it as a nicer syntax? (Obviously, when things get
more
complicated Match.jl looks very appealing).
Re: [julia-users] Lint.jl status update
Wow, this is really impressive. I'm going to have to take a close look again.
What do you mean below about wrong signatures? That signature looks correct
to me, albeit not very useful and probably not what the programmer intended.
--Tim
On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote:
Fellow Julians,
I think it is time to post an update on Lint.jl
https://github.com/tonyhffong/Lint.jl, as it has improved quite a bit
from the initial version I started about 3 months ago.
Notable new features
- Local variable type tracking, which enables a range of features, such
as
- Variable type stability warning within a function scope.
- Incompatibility between type assertion and assignment
- Omission of returning the constructed object in a type constructor
- Check the call signature of a selected set of methods with
collection (push!, append!, etc.)
- More function checks, such as
- repeated arguments
- wrong signatures, e.g. f( x::Array{Number,1} )
- Mispelled constructor (calls new but the function name doesn't
match the enclosing type)
- Ability to silence lint warning via lintpragma() function, e.g.
- lintpragma( Ignore unstable type variable [variable name] )
- lintpragma( Ignore Unused [variable name] )
Also, there is now quite a range of test scripts showing sample codes with
lint problems, so it's easy to grep your own lint warnings in that folder
and see a distilled version of the issue.
Again, please let me know about gaps and false positives.
Tony
Re: [julia-users] How to trace execution?
I take it you're not getting a useful backtrace from your error? That fact alone would be worth reporting, if you have a simple test case. If you run into troubles by not getting enough samples, you can always decrease the delay down to 10 microseconds or so. The default setting of 1 ms is designed to avoid any substantive performance impact, but for tracing you might prefer more samples. --Tim On Saturday, September 13, 2014 02:38:53 PM Elliot Saba wrote: Unfortunately, `@profile` is the closest we have now. You could conceivably call `@profile` from within a `try` so that you can print out the profile results at the end. -E On Sat, Sep 13, 2014 at 12:13 PM, Erik Schnetter schnet...@gmail.com wrote: I want to trace the execution of a Julia program to find out where an error occurs. Is there something like a @trace macro, similar to @time or @profile? -erik
[julia-users] Re: How to free memory from ImageView display.
While fixing something else, I happened to stumble across a way to solve this problem. In your update command below, change it to ImageView.view(canvas(canv1), img, interactive=false) Somehow, creating the callbacks is preventing memory from being freed properly. For this to work, you'll have to do Pkg.update() first. Sorry it took so long to track this down. --Tim On Friday, July 11, 2014 12:27:36 PM UTC-5, David A. wrote: How can we free up memory after displaying an image using ImageView module? To show the image I'm doing: img = imread(path) canv1, imageslice = ImageView.view(img) And to update it: ImageView.view(canvas(canv1), img) Memory usage keeps growing with each update. After trying the destroy() function the memory remains used. It only frees up that memory after closing the REPL window.
Re: [julia-users] dispatch based on expression head
Performance would come from reducing the allocation of unnecessary Any[]
arrays for a handful of expression nodes, which has some overhead.
Serialization / deserialization of the AST could potentially be faster
under a more compact representation as we know that hitting the gc is a
performance bottleneck when doing large amounts of (de)serialization.
These two factors have some impact on startup time as well.
One version of a function could handle all parametric expression types, it
would just have to do runtime lookup similar to what you would have to do
now,
so isa(arg, Expr) (arg::Expr).head === :headB would then just become
isa(arg, Expr{:headB}).
I wouldn't suspect this optimization to have a large impact on performance,
but it could make things a some % faster (you hope).
On Saturday, September 13, 2014 6:06:02 PM UTC-4, Tim Holy wrote:
I wonder whether it would really have much of a performance advantage.
Usually
expressions are nested, and so an Expr{:headA} contains among its args an
Expr{:headB}. But you don't know until runtime what type it is, so runtime
lookup would have to be faster than
isa(arg, Expr) (arg::Expr).head == :headB ...`
I don't actually know, but I would be a bit surprised if it would help
that
much.
Before someone thinks about tackling this, it would make sense to mock it
up;
make a MyExpr{:headsym}, nest a bunch of them based on real expressions,
and
then see if you get any real benefit from having the head as a type
parameter.
The other negative is it would add to compilation time---currently one
version
of a function handles all expressions, but with this change you'd have to
compile a version for each parametric expression type. That means yet
slower
startup of any packages that do expression-parsing, and startup speed is
already a pretty big problem.
--Tim
On Saturday, September 13, 2014 01:17:00 PM Kevin Squire wrote:
While this would greatly affect Match.jl, it would be a very welcome
change!
Cheers,
Kevin
On Saturday, September 13, 2014, Leah Hanson astri...@gmail.com
javascript: wrote:
I would expect the Expr type to be abstract, with different concrete
subtypes for each current value of head. Each value of head indicates
a
specific structure in args, and this can just be reflected in the
definition of the subtypes. (Then you can dispatch on Expr type, use
subtypes(Expr) to see all possible kinds of Expr, etc.)
-- Leah
On Sat, Sep 13, 2014 at 10:47 AM, Jake Bolewski jakebo...@gmail.com
javascript:
javascript:_e(%7B%7D,'cvml','jakebolew...@gmail.com javascript:');
wrote:
We've actually discussed changing our expression representation to
use
types instead of the more lisp-like symbols for distinguishing
expression
types. That would allow dispatch on expression types and be more
compact.
It would, however, break almost all macros that do any kind of
expression
inspection.
Hmm, interesting. I guess the Expr type would then be Expr{:head}
with
getindex / setindex overloaded to manipulate the arguments? This
would
be
a nice change as for many nodes you would not have to allocate an
args
array which could be a performance win (i guess the serialized ast's
would
be more compact as well). Can't comment on whether it would be
enough of
a
win to justify such a massively breaking change.
On Sat, Sep 13, 2014 at 2:48 AM, Gray Calhoun gcal...@iastate.edu
wrote:
On Wednesday, September 10, 2014 11:50:44 AM UTC-5, Steven G.
Johnson
wrote:
On Wednesday, September 10, 2014 12:20:59 PM UTC-4, Gray Calhoun
wrote:
Are there better ways to do this in general?
For this kind of expression-matching code, you may find the
Match.jl
package handy (https://github.com/kmsquire/Match.jl), to get ML-
or
Scala-like symbolic pattern-matching.
Thanks, that's pretty cool. For simple cases like I'm using, do
you
know if there are advantages (or disadvantages) to using Match.jl,
or
should I just view it as a nicer syntax? (Obviously, when things
get
more
complicated Match.jl looks very appealing).
Re: [julia-users] dispatch based on expression head
On Saturday, September 13, 2014 03:52:11 PM Jake Bolewski wrote:
One version of a function could handle all parametric expression types, it
would just have to do runtime lookup similar to what you would have to do
now,
so isa(arg, Expr) (arg::Expr).head === :headB would then just become
isa(arg, Expr{:headB}).
But wouldn't a function like
function find_ref_expr(ex::Expr)
if ex.head == :ref
# found it!
else
for i = 1:length(ex.args)
find_ref_expr(ex.args[i])
end
end
end
end up being specialized for each different type of expression head? I'm not
saying that specialization would not ever be useful, but I do wonder about the
cost of compiling 20 different variants when all you care about might be a
single head type.
Anyway, just thought I'd raise one potential reason to perhaps contemplate
_not_ making a breaking change. In any case, it would probably good to try to
get a sense for what the performance tradeoff would be before tackling such a
project.
Best,
--Tim
Re: [julia-users] dispatch based on expression head
On Saturday, September 13, 2014 5:52:11 PM UTC-5, Jake Bolewski wrote:
One version of a function could handle all parametric expression types, it
would just have to do runtime lookup similar to what you would have to do
now,
so isa(arg, Expr) (arg::Expr).head === :headB would then just become
isa(arg, Expr{:headB}).
I think not enough people know about Base.Meta.isexpr(). This can already
be written isexpr(arg, :headB)--and if the implementation of Expr changes,
you're still covered.
Re: [julia-users] constants environment
Wah! Right, I can't even read that. I'll try and learn more about the metaprogramming. Thanks! On Sunday, September 14, 2014 2:06:25 AM UTC+10, Isaiah wrote: Macros are useful for this sort of thing. ``` macro allconst(args...) exp = Expr(:block) args[1].head == :block for a in args[1].args a.head == :(=) push!(exp.args, Expr(:const, Base.esc(a) )) end exp end @allconst begin a = 1 b = 2 end ``` (see the Metaprogramming section in the manual for more information) On Sat, Sep 13, 2014 at 8:37 AM, Yakir Gagnon 12.y...@gmail.com javascript: wrote: I often define a bunch of constants at the beginning of a program. Wouldn't it be nice if we could start an environment of constants to avoid writing `const` before every one of the rows at the beginning of a program? Kind of like: ```Julia begin const a = 1 b = 2 c = neverChange end ``` instead of: ```Julia const a = 1 const b = 2 const c = neverChange ```
[julia-users] Change field value of a composite type when name of the field is in a variable
Hi All, Suppose I have a composite type and an instance of it: type myType numLines::Int avgLength::Float64 end inst = myType(10, 8.5) I want to change, say numLines of inst1 to 20. I know I can do inst.numLines = 20 However, suppose the field that has to be changed is determined by the program. Say, I have, varToChange = numLines How can I use *varToChange* to change the value of *numLines* in *inst*? Thank you.
[julia-users] Re: Change field value of a composite type when name of the field is in a variable
setfield!(inst, symbol(varToChange), 20) On Saturday, September 13, 2014 4:47:46 PM UTC-7, curiou...@gmail.com wrote: Hi All, Suppose I have a composite type and an instance of it: type myType numLines::Int avgLength::Float64 end inst = myType(10, 8.5) I want to change, say numLines of inst1 to 20. I know I can do inst.numLines = 20 However, suppose the field that has to be changed is determined by the program. Say, I have, varToChange = numLines How can I use *varToChange* to change the value of *numLines* in *inst*? Thank you.
[julia-users] constants and containers
I understand the difference between variables that are constant and containers that are constants, but how do you get a container of constants? Say I have a custom type. I initiate an instance of said type. But I want that instance to be constant, including its fields. Is that possible?
Re: [julia-users] constants environment
On Saturday, September 13, 2014 11:06:25 AM UTC-5, Isaiah wrote: Macros are useful for this sort of thing. I'm on an isexpr() evangelism mission. Also going to use if statements for additional exposition. using Base.Meta macro allconst(args...) exp = Expr(:block) if isexpr(args[1], :block) for a in args[1].args if isexpr(a, :(=)) push!(exp.args, Expr(:const, Base.esc(a))) end end end exp end ``` macro allconst(args...) exp = Expr(:block) args[1].head == :block for a in args[1].args a.head == :(=) push!(exp.args, Expr(:const, Base.esc(a) )) end exp end @allconst begin a = 1 b = 2 end ``` (see the Metaprogramming section in the manual for more information) On Sat, Sep 13, 2014 at 8:37 AM, Yakir Gagnon 12.ya...@gmail.com wrote: I often define a bunch of constants at the beginning of a program. Wouldn't it be nice if we could start an environment of constants to avoid writing `const` before every one of the rows at the beginning of a program? Kind of like: ```Julia begin const a = 1 b = 2 c = neverChange end ``` instead of: ```Julia const a = 1 const b = 2 const c = neverChange ```
Re: [julia-users] Lint.jl status update
I think a container type with a non-leaf eltype won't match anything. The
right way to declare such a function should be instead
function f{T:Number}( x::Array{T,1} )
...
end
On Sunday, September 14, 2014 5:09:39 AM UTC+7, Tim Holy wrote:
Wow, this is really impressive. I'm going to have to take a close look
again.
What do you mean below about wrong signatures? That signature looks
correct
to me, albeit not very useful and probably not what the programmer
intended.
--Tim
On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote:
Fellow Julians,
I think it is time to post an update on Lint.jl
https://github.com/tonyhffong/Lint.jl, as it has improved quite a bit
from the initial version I started about 3 months ago.
Notable new features
- Local variable type tracking, which enables a range of features,
such
as
- Variable type stability warning within a function scope.
- Incompatibility between type assertion and assignment
- Omission of returning the constructed object in a type
constructor
- Check the call signature of a selected set of methods with
collection (push!, append!, etc.)
- More function checks, such as
- repeated arguments
- wrong signatures, e.g. f( x::Array{Number,1} )
- Mispelled constructor (calls new but the function name doesn't
match the enclosing type)
- Ability to silence lint warning via lintpragma() function, e.g.
- lintpragma( Ignore unstable type variable [variable name] )
- lintpragma( Ignore Unused [variable name] )
Also, there is now quite a range of test scripts showing sample codes
with
lint problems, so it's easy to grep your own lint warnings in that
folder
and see a distilled version of the issue.
Again, please let me know about gaps and false positives.
Tony
Re: [julia-users] Lint.jl status update
It's callable, but probably not what you want:
julia f(A::Vector{Number}) = println(A)
f (generic function with 1 method)
julia f(Number[1.0; 1])
Number[1.0,1]
On Sat, Sep 13, 2014 at 9:51 PM, Tony Fong tony.hf.f...@gmail.com wrote:
I think a container type with a non-leaf eltype won't match anything. The
right way to declare such a function should be instead
function f{T:Number}( x::Array{T,1} )
...
end
On Sunday, September 14, 2014 5:09:39 AM UTC+7, Tim Holy wrote:
Wow, this is really impressive. I'm going to have to take a close look
again.
What do you mean below about wrong signatures? That signature looks
correct
to me, albeit not very useful and probably not what the programmer
intended.
--Tim
On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote:
Fellow Julians,
I think it is time to post an update on Lint.jl
https://github.com/tonyhffong/Lint.jl, as it has improved quite a bit
from the initial version I started about 3 months ago.
Notable new features
- Local variable type tracking, which enables a range of features,
such
as
- Variable type stability warning within a function scope.
- Incompatibility between type assertion and assignment
- Omission of returning the constructed object in a type
constructor
- Check the call signature of a selected set of methods with
collection (push!, append!, etc.)
- More function checks, such as
- repeated arguments
- wrong signatures, e.g. f( x::Array{Number,1} )
- Mispelled constructor (calls new but the function name doesn't
match the enclosing type)
- Ability to silence lint warning via lintpragma() function, e.g.
- lintpragma( Ignore unstable type variable [variable name] )
- lintpragma( Ignore Unused [variable name] )
Also, there is now quite a range of test scripts showing sample codes
with
lint problems, so it's easy to grep your own lint warnings in that
folder
and see a distilled version of the issue.
Again, please let me know about gaps and false positives.
Tony
Re: [julia-users] Lint.jl status update
Right, the correct way to say this should be Array{Number,1} in a function
signature would not match an input of Array{Int,1} etc. so in your example
if I do
julia f( [1,2] )
ERROR: `f` has no method matching f(::Array{Int64,1})
Anyway, Lint catches that.
On Sunday, September 14, 2014 8:55:02 AM UTC+7, Keno Fischer wrote:
It's callable, but probably not what you want:
julia f(A::Vector{Number}) = println(A)
f (generic function with 1 method)
julia f(Number[1.0; 1])
Number[1.0,1]
On Sat, Sep 13, 2014 at 9:51 PM, Tony Fong tony.h...@gmail.com
javascript: wrote:
I think a container type with a non-leaf eltype won't match anything.
The
right way to declare such a function should be instead
function f{T:Number}( x::Array{T,1} )
...
end
On Sunday, September 14, 2014 5:09:39 AM UTC+7, Tim Holy wrote:
Wow, this is really impressive. I'm going to have to take a close look
again.
What do you mean below about wrong signatures? That signature looks
correct
to me, albeit not very useful and probably not what the programmer
intended.
--Tim
On Saturday, September 13, 2014 12:34:44 PM Tony Fong wrote:
Fellow Julians,
I think it is time to post an update on Lint.jl
https://github.com/tonyhffong/Lint.jl, as it has improved quite a
bit
from the initial version I started about 3 months ago.
Notable new features
- Local variable type tracking, which enables a range of features,
such
as
- Variable type stability warning within a function scope.
- Incompatibility between type assertion and assignment
- Omission of returning the constructed object in a type
constructor
- Check the call signature of a selected set of methods with
collection (push!, append!, etc.)
- More function checks, such as
- repeated arguments
- wrong signatures, e.g. f( x::Array{Number,1} )
- Mispelled constructor (calls new but the function name
doesn't
match the enclosing type)
- Ability to silence lint warning via lintpragma() function, e.g.
- lintpragma( Ignore unstable type variable [variable name] )
- lintpragma( Ignore Unused [variable name] )
Also, there is now quite a range of test scripts showing sample codes
with
lint problems, so it's easy to grep your own lint warnings in that
folder
and see a distilled version of the issue.
Again, please let me know about gaps and false positives.
Tony
[julia-users] Re: immutable types with array fields
I see. Yeah, I wasn't sure if there was already some work done on fixed-size arrays. But it is great to know there are plans of working on it. Thanks, for the answer.
Re: [julia-users] Lint.jl status update
Any comments on how Lint.jl and @astrieanna's also-awesome TypeCheck.jl
relate? Are you two working together, or are there different use cases for
the two libraries?
peace,
s
On Sat, Sep 13, 2014 at 3:34 PM, Tony Fong tony.hf.f...@gmail.com wrote:
Fellow Julians,
I think it is time to post an update on Lint.jl
https://github.com/tonyhffong/Lint.jl, as it has improved quite a bit
from the initial version I started about 3 months ago.
Notable new features
- Local variable type tracking, which enables a range of features,
such as
- Variable type stability warning within a function scope.
- Incompatibility between type assertion and assignment
- Omission of returning the constructed object in a type constructor
- Check the call signature of a selected set of methods with
collection (push!, append!, etc.)
- More function checks, such as
- repeated arguments
- wrong signatures, e.g. f( x::Array{Number,1} )
- Mispelled constructor (calls new but the function name doesn't
match the enclosing type)
- Ability to silence lint warning via lintpragma() function, e.g.
- lintpragma( Ignore unstable type variable [variable name] )
- lintpragma( Ignore Unused [variable name] )
Also, there is now quite a range of test scripts showing sample codes with
lint problems, so it's easy to grep your own lint warnings in that folder
and see a distilled version of the issue.
Again, please let me know about gaps and false positives.
Tony
Re: [julia-users] Copy a BigFloat?
Do you mean independent for the purposes of editing, or just specifically for the equality operators? copy and deepcopy both work for editing purposes: ~~~ julia a=with_bigfloat_precision(()-BigFloat(0.1),64) 1.0001e-01 with 64 bits of precision julia z=copy(a) 1.0001e-01 with 64 bits of precision julia z += 2 2.100013552527156068805425093160010874271392822265625e+00 with 256 bits of precision julia a 1.0001e-01 with 64 bits of precision julia z 2.100013552527156068805425093160010874271392822265625e+00 with 256 bits of precision julia z=deepcopy(a) 1.0001e-01 with 64 bits of precision julia z += 2 2.100013552527156068805425093160010874271392822265625e+00 with 256 bits of precision julia a 1.0001e-01 with 64 bits of precision ~~~ I believe that BigFloats, like other numeric values types, are immutable. This means that you can't tell the difference between instances of the same value using `==` or even `===`. Every time there is a change a or z, it acts as if it is just changing the binding to point to a new BigFloat [vs. modifying the current value]. (I am not sure of the specific implementation details of BigFloat at this time.) On Sat, Sep 13, 2014 at 6:56 PM, Rick Graham rickhg1...@gmail.com wrote: Might be a silly question, but how do you copy a BigFloat so that it is independent of the original? julia a=with_bigfloat_precision(()-BigFloat(0.1),64) 1.0001e-01 with 64 bits of precision julia z=copy(a) 1.0001e-01 with 64 bits of precision julia a.d==z.d true julia z=deepcopy(a) 1.0001e-01 with 64 bits of precision julia a.d==z.d true
[julia-users] Why does this function incur so much garbage collection (and how can I make faster) ?
Hi all,
I've implemented a time delay neural network module and have been trying to
optimize it now. This function is for propagating the error backwards
through the network.
The deltas.d is just a container for holding the errors so I can do things
in place and don't have to keep initializing arrays. w and d are
collections of weights and errors respectively for different time lags.
This function gets called many many times and according to profiling, there
is a lot of garbage collection being induced by the fourth line,
specifically within multidimensional.jl getindex and setindex! and array.jl
+
function errprop!(w::Array{Float32,3}, d::Array{Float32,3}, deltas)
deltas.d[:] = 0.
for ti=1:size(w,3), ti2 = 1:size(d,3)
deltas.d[:,:,ti+ti2-1] += w[:,:,ti]'*d[:,:,ti2];
end
deltas.d
end
Any advice would be much appreciated!
Best,
Michael
[julia-users] Re: Copy a BigFloat?
You could try using a trivial expression, such as a+0 or -(-a) julia a=with_bigfloat_precision(()-BigFloat(0.1),64) 1.0001e-01 with 64 bits of precision julia z=a+0 1.00013552527156068805425093160010874271392822265625e-01 with 256 bits of precision julia z-a 0e+00 with 256 bits of precision julia z===a false On Sunday, September 14, 2014 9:56:32 AM UTC+10, Rick Graham wrote: Might be a silly question, but how do you copy a BigFloat so that it is independent of the original? julia a=with_bigfloat_precision(()-BigFloat(0.1),64) 1.0001e-01 with 64 bits of precision julia z=copy(a) 1.0001e-01 with 64 bits of precision julia a.d==z.d true julia z=deepcopy(a) 1.0001e-01 with 64 bits of precision julia a.d==z.d true
[julia-users] Re: Why does this function incur so much garbage collection (and how can I make faster) ?
The garbage is generated from the indexing operations. In 0.4, we should
have array views that should solve this problem. For now, you can either
manually devectorize the inner loop, or use the @devectorize macros in the
Devectorize package, if they work out in this case.
-viral
On Sunday, September 14, 2014 10:34:45 AM UTC+5:30, Michael Oliver wrote:
Hi all,
I've implemented a time delay neural network module and have been trying
to optimize it now. This function is for propagating the error backwards
through the network.
The deltas.d is just a container for holding the errors so I can do things
in place and don't have to keep initializing arrays. w and d are
collections of weights and errors respectively for different time lags.
This function gets called many many times and according to profiling,
there is a lot of garbage collection being induced by the fourth line,
specifically within multidimensional.jl getindex and setindex! and array.jl
+
function errprop!(w::Array{Float32,3}, d::Array{Float32,3}, deltas)
deltas.d[:] = 0.
for ti=1:size(w,3), ti2 = 1:size(d,3)
deltas.d[:,:,ti+ti2-1] += w[:,:,ti]'*d[:,:,ti2];
end
deltas.d
end
Any advice would be much appreciated!
Best,
Michael
Re: [julia-users] Copy a BigFloat?
BigFloats are indeed immutable in spirit but not really: julia BigFloat.mutable == isimmutable(big(0.1)) true So copy is a no-op (returns its argument as for every number), and deepopy returns a new instance (deepcopy(a) === a is false), but then there is no public API to mutate a or its copy. So there is no use for deepcopy on BigFloats in client code, they behave as Float64.
Re: [julia-users] Re: self dot product of all columns in a matrix: Julia vs. Octave
I wonder if we should provide access to DSFMT's random array generation, so that one can use an array generator. The requirements are that one has to generate at least 384 random numbers at a time or more, and the size of the array must necessarily be even. We should not allow this with the global seed, and it can be through a randarray!() function. We can even avoid exporting this function by default, since there are lots of conditions it needs, but it gives really high performance. -viral On Friday, September 12, 2014 6:56:39 PM UTC+5:30, Ján Dolinský wrote: Yes, 6581 sounds like it. Thanks for the clarification. Jan Dňa piatok, 12. septembra 2014 14:12:46 UTC+2 Andreas Noack napísal(-a): I think the reason for the slow down in rand since 2.1 is this https://github.com/JuliaLang/julia/pull/6581 Right now we are filling the array one by one which is not efficient, but unfortunately it is our best option right now. In applications where you draw one random variate at a time there shouldn't be difference. Med venlig hilsen Andreas Noack 2014-09-12 4:46 GMT-04:00 Ján Dolinský: Finally, I found that Octave has an equivalent to sumabs2() called sumsq(). Just for sake of completeness here are the timings: Octave X = rand(7000); tic; sumsq(X); toc; Elapsed time is 0.0616651 seconds. Julia v0.3 @time X = rand(7000,7000); elapsed time: 0.285218597 seconds (392000160 bytes allocated) @time sumabs2(X, 1); elapsed time: 0.05705666 seconds (56496 bytes allocated) Essentially speed is about the same with Julia being a little faster. It was however interesting to observe that @time X = rand(7000,7000); is about 2.5 times slower in Julia 0.3 than it was in Julia 0.2 ... in Julia (v0.2.1): @time X = rand(7000,7000); elapsed time: 0.114418731 seconds (392000128 bytes allocated) Jan Dňa utorok, 9. septembra 2014 17:06:59 UTC+2 Ján Dolinský napísal(-a): Hello Andreas, Thanks for the tip. I'll check it out. Thumbs up for the 0.4! Jan On 09.09.2014 17:04, Andreas Noack wrote: If you need the speed now you can try one of the package ArrayViews or ArrayViewsAPL. It is something similar to the functionality in these packages that we are trying to include in base. Med venlig hilsen Andreas Noack 2014-09-09 9:38 GMT-04:00 Ján Dolinský: OK, so basically there is nothing wrong with the syntax X[:,1001:end] ? d = sumabs2(X[:,1001:end], 1); and I should just wait until v0.4 is available (perhaps available soon in Julia Nightlies PPA). I did the benchmark with the floating point power function based on Simon's comment. Here are my results (after couple of repetitive iterations): @time X.^2; elapsed time: 0.511988142 seconds (392000256 bytes allocated, 2.52% gc time) @time X.^2.0; elapsed time: 0.411791612 seconds (392000256 bytes allocated, 3.12% gc time) Thanks, Jan Dolinsky On 09.09.2014 14:06, Andreas Noack wrote: The problem is that right now X[:,1001,end] makes a copy of the array. However, in 0.4 this will instead be a view of the original matrix and therefore the computing time should be almost the same. It might also be worth repeating Simon's comment that the floating point power function has special handling of 2. The result is that julia @time A.^2; elapsed time: 1.402791357 seconds (20256 bytes allocated, 5.90% gc time) julia @time A.^2.0; elapsed time: 0.554241105 seconds (20256 bytes allocated, 15.04% gc time) I tend to agree with Simon that special casing of integer 2 would be reasonable. Med venlig hilsen Andreas Noack 2014-09-09 4:24 GMT-04:00 Ján Dolinský: Hello guys, Thanks a lot for the lengthy discussions. It helped me a lot to get a feeling on what is Julia like. I did some more performance comparisons as suggested by first two posts (thanks a lot for the tips). In the mean time I upgraded to v0.3. X = rand(7000,7000); @time d = sum(X.^2, 1); elapsed time: 0.573125833 seconds (392056672 bytes allocated, 2.25% gc time) @time d = sum(X.*X, 1); elapsed time: 0.178715901 seconds (392057080 bytes allocated, 14.06% gc time) @time d = sumabs2(X, 1); elapsed time: 0.067431808 seconds (56496 bytes allocated) In Octave then X = rand(7000); tic; d = sum(X.^2); toc; Elapsed time is 0.167578 seconds. So the ultimate solution is the sumabs2 function which is a blast. I am comming from Matlab/Octave and I would expect X.^2 to be fast out of the box but nevertheless if I can get an excellent performance by learning some new paradigms I will go for it. The above tests lead me to another question. I often need to calculate the self dot product over a portion of a matrix, e.g. @time d = sumabs2(X[:,1001:end], 1); elapsed time: 0.17566 seconds (336048688 bytes allocated, 7.01% gc time) Apparently this is not a way to do it in Julia because working on a smaller matrix of 7000x6000 gives more
Re: [julia-users] Lint.jl status update
That's a good question. They can be used together, obviously. I can easily
speak for Lint. The key trade-off made in Lint is that it does not strive
for very in-depth type analysis. The focus is finding dodgy AST, where it
is located in the source file, and with a bit of explanation around issues.
The analyses are done recursively in a very small neighborhood around each
node in the AST, although the locality issue has improved somewhat with the
new type-tracking ability. The type guessing and tracking could leverage
Typecheck.jl, only possible since about last week (with the new features),
and it's a very exciting prospect.
Lint already provides functionality to return an array of lint messages
(from a file, a code snippet, or a module), so it could be used in IDE
integration I suppose.
Tony
On Sunday, September 14, 2014 10:08:09 AM UTC+7, Spencer Russell wrote:
Any comments on how Lint.jl and @astrieanna's also-awesome TypeCheck.jl
relate? Are you two working together, or are there different use cases for
the two libraries?
peace,
s
On Sat, Sep 13, 2014 at 3:34 PM, Tony Fong tony.h...@gmail.com
javascript: wrote:
Fellow Julians,
I think it is time to post an update on Lint.jl
https://github.com/tonyhffong/Lint.jl, as it has improved quite a bit
from the initial version I started about 3 months ago.
Notable new features
- Local variable type tracking, which enables a range of features,
such as
- Variable type stability warning within a function scope.
- Incompatibility between type assertion and assignment
- Omission of returning the constructed object in a type
constructor
- Check the call signature of a selected set of methods with
collection (push!, append!, etc.)
- More function checks, such as
- repeated arguments
- wrong signatures, e.g. f( x::Array{Number,1} )
- Mispelled constructor (calls new but the function name doesn't
match the enclosing type)
- Ability to silence lint warning via lintpragma() function, e.g.
- lintpragma( Ignore unstable type variable [variable name] )
- lintpragma( Ignore Unused [variable name] )
Also, there is now quite a range of test scripts showing sample codes
with lint problems, so it's easy to grep your own lint warnings in that
folder and see a distilled version of the issue.
Again, please let me know about gaps and false positives.
Tony
Re: [julia-users] Copy a BigFloat?
I wanted an easy way to do nextfloat(a), taking into account that 'a' doesn't have the global BigFloat precision. I.e., what's the nextfloat of the 64-bit precision (in this case) BigFloat and return a 64-bit precision BigFloat. I could write a function that does this, but I thought that there might be something easier than having to extract the precision of each BigFloat and nextfloat'ing with that global BigFloat precision.
