[julia-users] why so much faster with a global than a local vec?
In the local case, it is having to allocate, populate, and then at some point garbage collect that array. That is why using a const is much faster.
[julia-users] DefaultDict unexpected behaviour?
Hi,
I have the following code:
using DataStrucures
d= DefaultDict(ASCIIString,Array{Int64},Array{Int64}(0))
push!(d[A],2)
push!(d[B],3)
d
DataStructures.DefaultDict{ASCIIString,Array{Int64,N},Array{Int64,1}} with
2 entries:
B = [2,3]
A = [2,3]
Isn't it unexpected that when I push to any key, the value is pushed to all
the other keys as well?
Thanks :)
Re: [julia-users] Re: Call function from a string with its name
You want to pass the symbol into the macro or convert before the quote block: ~~~julia macro create_function(name::String) n = symbol(name) return quote (x) - ($n)(x) + 7 end end ~~~ Or you can just add some parens: ~~~julia macro create_function(name::String) return quote (x) - ($(symbol(name)))(x) + 7 end end ~~~ You want to convert from string to symbol *in macro context*, not at run time. That way the code a run-time has a symbol that it will understand as a function call. -- Leah On Fri, Jul 3, 2015 at 3:26 PM, amik...@gmail.com wrote: I meant inside the macro. Le vendredi 3 juillet 2015 15:26:01 UTC+2, ami...@gmail.com a écrit : Ok, it seems eval(parse($name)) inside the function does the trick...
Re: [julia-users] DefaultDict unexpected behaviour?
Thank you. What would be the work around? How can I push values
to defaultdict without changing any other value?
On Friday, July 3, 2015 at 3:35:39 PM UTC+2, Yichao Yu wrote:
On Fri, Jul 3, 2015 at 9:29 AM, Ali Rezaee arv@gmail.com
javascript: wrote:
Hi,
I have the following code:
using DataStrucures
d= DefaultDict(ASCIIString,Array{Int64},Array{Int64}(0))
push!(d[A],2)
push!(d[B],3)
d
DataStructures.DefaultDict{ASCIIString,Array{Int64,N},Array{Int64,1}}
with 2
entries:
B = [2,3]
A = [2,3]
Isn't it unexpected that when I push to any key, the value is pushed to
all
the other keys as well?
Yes, pretty much. Because the default value is stored by reference and
you are mutating it with `push!`
See the last paragraph of the corresponding section in the
DataStructures.jl README[1]
[1]
https://github.com/JuliaLang/DataStructures.jl#defaultdict-and-defaultordereddict
Thanks :)
[julia-users] Julia binary goes in infinite wait on Ubuntu 14.10 (ppc64le)
Hi All, I am working on building/porting Julia on ppc64le architecture. I am using Ubuntu 14.10 on top of ppc64le hardware and I am able to build/compile Julia master branch on it. When I execute julia binary, it goes into indefinite wait and I am not able to view julia prompt .Any pointer on this strange behavior would be great help. Below is some background information which will help to understand/ resolve a problem. 1. Machine details : test@pts00433-vm1:~/Mahesh/julia/julia$ uname -a Linux pts00433-vm1 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux test@pts00433-vm1:~/Mahesh/julia/julia$ 2. Content of Make.user file test@pts00433-vm1:~/Mahesh/julia/julia$ cat Make.user include /home/test/Mahesh/julia/julia/Make.powerpc # __PPC64__ defined but __ppc64__ is not! CFLAGS += -D__ppc64__ CXXFLAGS += -D__ppc64__ LDFLAGS = -llzma VERBOSE = 1 test@pts00433-vm1:~/Mahesh/julia/julia$ 3. Content of Make.powerpc file test@pts00433-vm1:~/Mahesh/julia/julia$ cat Make.powerpc # This Make.ppc script should help you get started building Julia on a PowerPC machine # $ echo include $(JULIAHOME)/Make.powerpc Make.user # most of our dependencies these contain m4 scripts that are too old (specifically libtool.m4) to know about ppc64le # so for now, we must use the system ones USE_SYSTEM_FFTW=1 USE_SYSTEM_PCRE=0 USE_SYSTEM_ARPACK=1 USE_SYSTEM_GMP=1 USE_SYSTEM_MPFR=1 # openblas doesn't know about ld version 2 assembly PROLOGUE syntax USE_SYSTEM_BLAS=1 # it's not optimized, and we trust the system libm USE_SYSTEM_LIBM=1 # this one doesn't seem to be able to compile for assembly code USE_SYSTEM_LIBUNWIND=1 # this one takes awhile to build, but it's generally worthwhile -- your choice USE_SYSTEM_LLVM?=0 ifeq ($(USE_SYSTEM_LLVM),1) LLVM_CONFIG=llvm-config-3.5 else LLVM_ASSERTIONS=1 LLVM_VER=3.6.0 LLVM_ASSERTIONS=1 endif # On a newly allocated machine, you'll need the following dependencies: # build essentials: # $ sudo apt-get install git g++ gfortran make cmake libedit-dev zlib1g-dev libssl-dev # system lib replacements: # $ sudo apt-get install libfftw3-dev libunwind8-dev libllvm3.5 libblas3 libarpack2-dev libedit-dev libpcre3-dev libgmp-dev libmpfr-dev # autogen essentials: # $ sudo apt-get install libtool autoconf test@pts00433-vm1:~/Mahesh/julia/julia$ 4. While compiling below code snippet I was getting segmentation fault. For resolving segmentation fault I made changes in ‘options.h’ file, I turn on ‘MEMDEBUG’ flag in ‘options.h’ file. julia/usr/bin/julia -C native --output-o /home/test/Mahesh/julia/julia/usr/lib/julia/inference0.o -f coreimg.jl diff of ‘options.h’ file, test@pts00433-vm1:~/Mahesh/julia/julia$ git diff src/options.h diff --git a/src/options.h b/src/options.h index 23540ae..e2318cb 100644 --- a/src/options.h +++ b/src/options.h @@ -40,7 +40,7 @@ // with MEMDEBUG, every object is allocated explicitly with malloc, and // filled with 0xbb before being freed. this helps tools like valgrind // catch invalid accesses. -// #define MEMDEBUG +#define MEMDEBUG // GC_VERIFY force a full verification gc along with every quick gc to ensure no // reachable memory is freed test@pts00433-vm1:~/Mahesh/julia/julia$ 5. I attached gdb to Julia and try to find out the reason why I am not getting Julia command prompt. Below is stacktrace of gdb. test@pts00433-vm1:~/Mahesh/julia/julia$ gdb ./julia (gdb) r Starting program: /home/test/Mahesh/julia/julia/julia [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/powerpc64le-linux-gnu/libthread_db.so.1. _ _ _ _(_)_ | A fresh approach to technical computing (_) | (_) (_)| Documentation: http://docs.julialang.org _ _ _| |_ __ _ | Type help() for help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 0.4.0-dev+5769 (2015-07-03 04:36 UTC) _/ |\__'_|_|_|\__'_| | Commit 2c1ac18* (0 days old master) |__/ | powerpc64le-linux-gnu ^C Program received signal SIGINT, Interrupt. 0x3fffb6a138fc in __pause_nocancel () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x3fffb6a138fc in __pause_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x3fffb4f5fb10 in julia_wait_18019 () at task.jl:302 #2 0x3fffb4f69bc4 in julia_wait_18197 (c=optimized out) at task.jl:225 #3 0x3fffb6c00330 in jl_apply (nargs=1, args=0x3fffef38, f=0x12c5e370) at julia.h:1260 #4 jl_trampoline (F=0x12c5e370, args=0x3fffef38, nargs=optimized out) at builtins.c:975 #5 0x3fffb6bf1b00 in jl_apply (nargs=1, args=0x3fffef38, f=optimized out) at julia.h:1260 #6 jl_apply_generic (F=0x12c59b00, args=0x3fffef38, nargs=optimized out) at gf.c:1632 #7 0x3fffb2c60088 in julia_anonymous_24015 () #8 0x3fffb6c00330 in jl_apply (nargs=0, args=0x0, f=0x12a77d30) at julia.h:1260 #9 jl_trampoline (F=0x12a77d30, args=0x0,
[julia-users] Re: Possible ways to avoid confusability issues with using superscripts in variable names
I would rather have them as well defined operators, rather than allowed as parts of identifiers, which would have been more consistent with other things in Julia, like sqrt() and cbrt() using the Unicode symbols as prefix operators, however, the reactions included things like pry them from my cold, dead hands, plus other people pointed out other cases where the superscript wasn't really doing a ^2 or ^3 operation. That's why I was trying to brainstorm on ways the language could be made tighter, and at least warn about some of the potential cases of programming errors due to the confusion this can cause, without prying the beloved superscripts from their identifiers. The documentation part is already happening (@Ismael-VC seems to be absolutely full of energy!) On Friday, July 3, 2015 at 9:39:48 AM UTC-4, Tom Breloff wrote: I think I've flipped my position back and forth 6 times in the last few minutes while thinking about this. The mathematician in me wants those special characters to be well defined operators with the expected precedence, but the computer scientist in me thinks that's a horribly stupid idea for reasons that Scott and others have pointed out. The sad thing is that, whatever the decision, it needs to be done in the core parsing for it to be useful, so it can't practically be a user-defined decision (unless of course it becomes a flag you can set when making or running Julia). On that last point... how hard would it be to define certain operators like the square, etc, that sit within #ifdef blocks in the parser? I guess even with that ability, you'd potentially be mixing code of both forms which would be confusing at the very best so I guess we have to choose one. At a minimum... gotta document! On Thursday, July 2, 2015 at 11:25:00 PM UTC-4, Scott Jones wrote: Starting in https://github.com/JuliaLang/julia/pull/11927#issuecomment-117374003 and continuing on in https://github.com/JuliaLang/julia/issues/11966#issuecomment-118212265, I had raised an issue that can cause confusion to newcomers to Julia, and potentially lead to programming errors if one isn't careful. There is also the issue of inconsistency within Julia, where certain mathematical operations are actually treated as operations, and others that look like taking something to a power, i.e. with superscripts, are treated as identifiers. I am *not* suggesting that this should be changed in Julia (people got a bit upset with that idea), but rather trying to propose ways that the use of superscripts as part of variable names can be made much safer in practice. For example: julia cube(x) = x³ cube (generic function with 1 method) julia cube(3) # Silly me, I think I'll get 27 ERROR: UndefVarError: x³ not defined in cube at none:1 julia x³ = 4242 julia cube(3)42 julia ∛x³ 3.4760266448864496 Besides documenting this, as @Ismael-VC has suggested, I think that it might be useful for the compiler to try to catch some of the cases that could actually lead to programming errors. In the above case, the compiler could detect that a variable of global scope was being used, along with a local variable that is the same except for trailing superscript(s), and give a warning. Another possible programming error that can occur if one mistakenly thought that `³` was performing a cube operation, is that the variable x is updated, but the cached cube value in the variable `x³` is not. That could also be caught by the compiler. What do people think? Are there any other things that could be done besides documentation, to help make using these types of identifiers easier and not error-prone?
[julia-users] What happened to Timer?
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.10-pre+4 (2015-06-04 13:19 UTC)
_/ |\__'_|_|_|\__'_| | Commit c8804e8* (29 days old release-0.3)
|__/ | x86_64-linux-gnu
julia function a1()
display(0.33)
end
a1 (generic function with 1 method)
julia u1 = Timer(u1 - a1(),0.1)
ERROR: `Timer` has no method matching Timer(::Function, ::Float64)
while in v0.4
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.4.0-dev+5702 (2015-06-30 12:53 UTC)
_/ |\__'_|_|_|\__'_| | Commit 8a49356* (3 days old master)
|__/ | x86_64-linux-gnu
julia function a1()
display(0.33)
end
a1 (generic function with 1 method)
julia u1 = Timer(u1 - a1(),0.1)
Timer0.(33Ptr
{Void} @0x,Condition(Any[]),false)
but this doesn't seem to start.
Re: [julia-users] why so much faster with a global than a local vec?
The first one creates a new array object every time it runs. It's a fairly sophisticated analysis to prove that the array never escapes and is never modified and can therefore be reused. On Fri, Jul 3, 2015 at 2:21 PM, Jeffrey Sarnoff jeffrey.sarn...@gmail.com wrote: I wrote a range limited isa_leapyear(year) good in 1800..2200. Your look is appreciated; I do not understand this: The first version runs 50x more slowly than the second version. The first is better practice, is there a way to make it behave? They differ only in placing the bit table (local vs const global). I ran both through code_typed(), the function code is the same. this is the way of the snail: function is_proximal_leapyear(year::Int) LeapYearBitTbl = [ 0xfdfe, 0x, 0xf7ff, 0x000f ] y400 = convert(Uint32, year-1800) y100 = y400 2 mask = one(Uint32) (y100 0x000f) indx = 1 + (y100 5) ((LeapYearBitTbl[indx] $ mask) + (y400 0x0003)) === zero(Uint32) end this way is lovely fast: const LeapYearBitTable = [ 0xfdfe, 0x, 0xf7ff, 0x000f ]; function isa_proximal_leapyear(year::Int) y400 = convert(Uint32, year-1800) y100 = y400 2 mask = one(Uint32) (y100 0x000f) indx = 1 + (y100 5) ((LeapYearBitTable[indx] $ mask) + (y400 0x0003)) === zero(Uint32) end
[julia-users] Re: Possible ways to avoid confusability issues with using superscripts in variable names
I think I've flipped my position back and forth 6 times in the last few minutes while thinking about this. The mathematician in me wants those special characters to be well defined operators with the expected precedence, but the computer scientist in me thinks that's a horribly stupid idea for reasons that Scott and others have pointed out. The sad thing is that, whatever the decision, it needs to be done in the core parsing for it to be useful, so it can't practically be a user-defined decision (unless of course it becomes a flag you can set when making or running Julia). On that last point... how hard would it be to define certain operators like the square, etc, that sit within #ifdef blocks in the parser? I guess even with that ability, you'd potentially be mixing code of both forms which would be confusing at the very best so I guess we have to choose one. At a minimum... gotta document! On Thursday, July 2, 2015 at 11:25:00 PM UTC-4, Scott Jones wrote: Starting in https://github.com/JuliaLang/julia/pull/11927#issuecomment-117374003 and continuing on in https://github.com/JuliaLang/julia/issues/11966#issuecomment-118212265, I had raised an issue that can cause confusion to newcomers to Julia, and potentially lead to programming errors if one isn't careful. There is also the issue of inconsistency within Julia, where certain mathematical operations are actually treated as operations, and others that look like taking something to a power, i.e. with superscripts, are treated as identifiers. I am *not* suggesting that this should be changed in Julia (people got a bit upset with that idea), but rather trying to propose ways that the use of superscripts as part of variable names can be made much safer in practice. For example: julia cube(x) = x³ cube (generic function with 1 method) julia cube(3) # Silly me, I think I'll get 27 ERROR: UndefVarError: x³ not defined in cube at none:1 julia x³ = 4242 julia cube(3)42 julia ∛x³ 3.4760266448864496 Besides documenting this, as @Ismael-VC has suggested, I think that it might be useful for the compiler to try to catch some of the cases that could actually lead to programming errors. In the above case, the compiler could detect that a variable of global scope was being used, along with a local variable that is the same except for trailing superscript(s), and give a warning. Another possible programming error that can occur if one mistakenly thought that `³` was performing a cube operation, is that the variable x is updated, but the cached cube value in the variable `x³` is not. That could also be caught by the compiler. What do people think? Are there any other things that could be done besides documentation, to help make using these types of identifiers easier and not error-prone?
[julia-users] why so much faster with a global than a local vec?
I wrote a range limited isa_leapyear(year) good in 1800..2200. Your look is appreciated; I do not understand this: The first version runs 50x more slowly than the second version. The first is better practice, is there a way to make it behave? They differ only in placing the bit table (local vs const global). I ran both through code_typed(), the function code is the same. this is the way of the snail: function is_proximal_leapyear(year::Int) LeapYearBitTbl = [ 0xfdfe, 0x, 0xf7ff, 0x000f ] y400 = convert(Uint32, year-1800) y100 = y400 2 mask = one(Uint32) (y100 0x000f) indx = 1 + (y100 5) ((LeapYearBitTbl[indx] $ mask) + (y400 0x0003)) === zero(Uint32) end this way is lovely fast: const LeapYearBitTable = [ 0xfdfe, 0x, 0xf7ff, 0x000f ]; function isa_proximal_leapyear(year::Int) y400 = convert(Uint32, year-1800) y100 = y400 2 mask = one(Uint32) (y100 0x000f) indx = 1 + (y100 5) ((LeapYearBitTable[indx] $ mask) + (y400 0x0003)) === zero(Uint32) end
[julia-users] Re: why so much faster with a global than a local vec?
Thanks to all. On Friday, July 3, 2015 at 8:21:53 AM UTC-4, Jeffrey Sarnoff wrote: I wrote a range limited isa_leapyear(year) good in 1800..2200. Your look is appreciated; I do not understand this: The first version runs 50x more slowly than the second version. The first is better practice, is there a way to make it behave? They differ only in placing the bit table (local vs const global). I ran both through code_typed(), the function code is the same. this is the way of the snail: function is_proximal_leapyear(year::Int) LeapYearBitTbl = [ 0xfdfe, 0x, 0xf7ff, 0x000f ] y400 = convert(Uint32, year-1800) y100 = y400 2 mask = one(Uint32) (y100 0x000f) indx = 1 + (y100 5) ((LeapYearBitTbl[indx] $ mask) + (y400 0x0003)) === zero(Uint32) end this way is lovely fast: const LeapYearBitTable = [ 0xfdfe, 0x, 0xf7ff, 0x000f ]; function isa_proximal_leapyear(year::Int) y400 = convert(Uint32, year-1800) y100 = y400 2 mask = one(Uint32) (y100 0x000f) indx = 1 + (y100 5) ((LeapYearBitTable[indx] $ mask) + (y400 0x0003)) === zero(Uint32) end
[julia-users] Re: Call function from a string with its name
I meant inside the macro. Le vendredi 3 juillet 2015 15:26:01 UTC+2, ami...@gmail.com a écrit : Ok, it seems eval(parse($name)) inside the function does the trick...
[julia-users] Re: Escher/Compose/Gadfly for heavy visualization
That's great Rohit... looking forward to it! Keep us posted, and let me know if there are areas you could use collaboration. On Friday, July 3, 2015 at 9:35:16 AM UTC-4, Rohit Thankachan wrote: On Thursday, 2 July 2015 20:04:20 UTC+5:30, Tom Breloff wrote: *Compose3D* I came across this after my first post... seems to be on the right track... implementing a compose-like framework based in WebGL. Are there other similar efforts? Might there be a Gadfly3D which uses Compose3D as a backend? Are there any other similar efforts that haven't been mentioned that I should keep an eye on? Thanks for all your thoughts. I'm working on Compose3D as part of JSoC now. Right now there isn't a Gadfly3D, but by the end of the summer I hope to have a basic Gadfly3D up!
[julia-users] Re: Call function from a string with its name
Ok, it seems eval(parse($name)) inside the function does the trick...
[julia-users] Re: Escher/Compose/Gadfly for heavy visualization
On Thursday, 2 July 2015 20:04:20 UTC+5:30, Tom Breloff wrote: *Compose3D* I came across this after my first post... seems to be on the right track... implementing a compose-like framework based in WebGL. Are there other similar efforts? Might there be a Gadfly3D which uses Compose3D as a backend? Are there any other similar efforts that haven't been mentioned that I should keep an eye on? Thanks for all your thoughts. I'm working on Compose3D as part of JSoC now. Right now there isn't a Gadfly3D, but by the end of the summer I hope to have a basic Gadfly3D up!
Re: [julia-users] DefaultDict unexpected behaviour?
On Fri, Jul 3, 2015 at 9:29 AM, Ali Rezaee arv.ka...@gmail.com wrote:
Hi,
I have the following code:
using DataStrucures
d= DefaultDict(ASCIIString,Array{Int64},Array{Int64}(0))
push!(d[A],2)
push!(d[B],3)
d
DataStructures.DefaultDict{ASCIIString,Array{Int64,N},Array{Int64,1}} with 2
entries:
B = [2,3]
A = [2,3]
Isn't it unexpected that when I push to any key, the value is pushed to all
the other keys as well?
Yes, pretty much. Because the default value is stored by reference and
you are mutating it with `push!`
See the last paragraph of the corresponding section in the
DataStructures.jl README[1]
[1]
https://github.com/JuliaLang/DataStructures.jl#defaultdict-and-defaultordereddict
Thanks :)
Re: [julia-users] DefaultDict unexpected behaviour?
On Fri, Jul 3, 2015 at 9:42 AM, Ali Rezaee arv.ka...@gmail.com wrote:
Thank you. What would be the work around? How can I push values to
defaultdict without changing any other value?
The README I linked is exactly about that.
On Friday, July 3, 2015 at 3:35:39 PM UTC+2, Yichao Yu wrote:
On Fri, Jul 3, 2015 at 9:29 AM, Ali Rezaee arv@gmail.com wrote:
Hi,
I have the following code:
using DataStrucures
d= DefaultDict(ASCIIString,Array{Int64},Array{Int64}(0))
push!(d[A],2)
push!(d[B],3)
d
DataStructures.DefaultDict{ASCIIString,Array{Int64,N},Array{Int64,1}}
with 2
entries:
B = [2,3]
A = [2,3]
Isn't it unexpected that when I push to any key, the value is pushed to
all
the other keys as well?
Yes, pretty much. Because the default value is stored by reference and
you are mutating it with `push!`
See the last paragraph of the corresponding section in the
DataStructures.jl README[1]
[1]
https://github.com/JuliaLang/DataStructures.jl#defaultdict-and-defaultordereddict
Thanks :)
Re: [julia-users] DefaultDict unexpected behaviour?
On Fri, Jul 3, 2015 at 10:40 AM, Yichao Yu yyc1...@gmail.com wrote:
On Fri, Jul 3, 2015 at 9:42 AM, Ali Rezaee arv.ka...@gmail.com wrote:
Thank you. What would be the work around? How can I push values to
defaultdict without changing any other value?
The README I linked is exactly about that.
And quote it here for future reference:
Note that in the last example, we need to use a function to create each new
`DefaultDict`. If we forget, we will end up using the same `DefaultDict` for
all default values:
In their case, the value of a parent DefaultDict is also a DefaultDict
so it might be a little confusing. You can pretty much replace the
DefaultDict above by `Array` and it will apply to your case directly.
On Friday, July 3, 2015 at 3:35:39 PM UTC+2, Yichao Yu wrote:
On Fri, Jul 3, 2015 at 9:29 AM, Ali Rezaee arv@gmail.com wrote:
Hi,
I have the following code:
using DataStrucures
d= DefaultDict(ASCIIString,Array{Int64},Array{Int64}(0))
push!(d[A],2)
push!(d[B],3)
d
DataStructures.DefaultDict{ASCIIString,Array{Int64,N},Array{Int64,1}}
with 2
entries:
B = [2,3]
A = [2,3]
Isn't it unexpected that when I push to any key, the value is pushed to
all
the other keys as well?
Yes, pretty much. Because the default value is stored by reference and
you are mutating it with `push!`
See the last paragraph of the corresponding section in the
DataStructures.jl README[1]
[1]
https://github.com/JuliaLang/DataStructures.jl#defaultdict-and-defaultordereddict
Thanks :)
Re: [julia-users] why so much faster with a global than a local vec?
On Fri, Jul 3, 2015 at 8:37 AM, Stefan Karpinski ste...@karpinski.org wrote: The first one creates a new array object every time it runs. It's a fairly sophisticated analysis to prove that the array never escapes and is never modified and can therefore be reused. Also, in general, a global constant is faster than a local variable. On Fri, Jul 3, 2015 at 2:21 PM, Jeffrey Sarnoff jeffrey.sarn...@gmail.com wrote: I wrote a range limited isa_leapyear(year) good in 1800..2200. Your look is appreciated; I do not understand this: The first version runs 50x more slowly than the second version. The first is better practice, is there a way to make it behave? They differ only in placing the bit table (local vs const global). I ran both through code_typed(), the function code is the same. this is the way of the snail: function is_proximal_leapyear(year::Int) LeapYearBitTbl = [ 0xfdfe, 0x, 0xf7ff, 0x000f ] y400 = convert(Uint32, year-1800) y100 = y400 2 mask = one(Uint32) (y100 0x000f) indx = 1 + (y100 5) ((LeapYearBitTbl[indx] $ mask) + (y400 0x0003)) === zero(Uint32) end this way is lovely fast: const LeapYearBitTable = [ 0xfdfe, 0x, 0xf7ff, 0x000f ]; function isa_proximal_leapyear(year::Int) y400 = convert(Uint32, year-1800) y100 = y400 2 mask = one(Uint32) (y100 0x000f) indx = 1 + (y100 5) ((LeapYearBitTable[indx] $ mask) + (y400 0x0003)) === zero(Uint32) end
[julia-users] Call function from a string with its name
Hi everyone, Here's a quite simple code: macro create_function(name::String) return quote (x) - symbol($name)(x) + 7 end end f = (x) - 2 * x g = @create_function(f) println(g(3.0)) I create a macro to construct a function from another one. The problem is that symbol($name) is considered as, well, what it is, a symbol, and not a function. Hence the following error that I get when I run the code: ERROR: type: anonymous: in apply, expected Function, got Symbol Would there be a way to make this piece of code work, what would be perfect would be someting like: function_call(symbol(function_name),arg) Thanks a lot,
Re: [julia-users] Possible ways to avoid confusability issues with using superscripts in variable names
Lint.jl would be a good place to add appropriate warnings. Cheers, Kevin On Friday, July 3, 2015, Scott Jones scott.paul.jo...@gmail.com wrote: I would rather have them as well defined operators, rather than allowed as parts of identifiers, which would have been more consistent with other things in Julia, like sqrt() and cbrt() using the Unicode symbols as prefix operators, however, the reactions included things like pry them from my cold, dead hands, plus other people pointed out other cases where the superscript wasn't really doing a ^2 or ^3 operation. That's why I was trying to brainstorm on ways the language could be made tighter, and at least warn about some of the potential cases of programming errors due to the confusion this can cause, without prying the beloved superscripts from their identifiers. The documentation part is already happening (@Ismael-VC seems to be absolutely full of energy!) On Friday, July 3, 2015 at 9:39:48 AM UTC-4, Tom Breloff wrote: I think I've flipped my position back and forth 6 times in the last few minutes while thinking about this. The mathematician in me wants those special characters to be well defined operators with the expected precedence, but the computer scientist in me thinks that's a horribly stupid idea for reasons that Scott and others have pointed out. The sad thing is that, whatever the decision, it needs to be done in the core parsing for it to be useful, so it can't practically be a user-defined decision (unless of course it becomes a flag you can set when making or running Julia). On that last point... how hard would it be to define certain operators like the square, etc, that sit within #ifdef blocks in the parser? I guess even with that ability, you'd potentially be mixing code of both forms which would be confusing at the very best so I guess we have to choose one. At a minimum... gotta document! On Thursday, July 2, 2015 at 11:25:00 PM UTC-4, Scott Jones wrote: Starting in https://github.com/JuliaLang/julia/pull/11927#issuecomment-117374003 and continuing on in https://github.com/JuliaLang/julia/issues/11966#issuecomment-118212265, I had raised an issue that can cause confusion to newcomers to Julia, and potentially lead to programming errors if one isn't careful. There is also the issue of inconsistency within Julia, where certain mathematical operations are actually treated as operations, and others that look like taking something to a power, i.e. with superscripts, are treated as identifiers. I am *not* suggesting that this should be changed in Julia (people got a bit upset with that idea), but rather trying to propose ways that the use of superscripts as part of variable names can be made much safer in practice. For example: julia cube(x) = x³ cube (generic function with 1 method) julia cube(3) # Silly me, I think I'll get 27 ERROR: UndefVarError: x³ not defined in cube at none:1 julia x³ = 4242 julia cube(3)42 julia ∛x³ 3.4760266448864496 Besides documenting this, as @Ismael-VC has suggested, I think that it might be useful for the compiler to try to catch some of the cases that could actually lead to programming errors. In the above case, the compiler could detect that a variable of global scope was being used, along with a local variable that is the same except for trailing superscript(s), and give a warning. Another possible programming error that can occur if one mistakenly thought that `³` was performing a cube operation, is that the variable x is updated, but the cached cube value in the variable `x³` is not. That could also be caught by the compiler. What do people think? Are there any other things that could be done besides documentation, to help make using these types of identifiers easier and not error-prone?
Re: [julia-users] What happened to Timer?
If you need to support both versions, see also
https://github.com/JuliaLang/Compat.jl/pull/103
On Fri, Jul 3, 2015 at 11:37 AM, Isaiah Norton isaiah.nor...@gmail.com
wrote:
https://github.com/JuliaLang/julia/pull/11669
On Fri, Jul 3, 2015 at 11:18 AM, Andreas Lobinger lobing...@gmail.com
wrote:
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.10-pre+4 (2015-06-04 13:19 UTC)
_/ |\__'_|_|_|\__'_| | Commit c8804e8* (29 days old release-0.3)
|__/ | x86_64-linux-gnu
julia function a1()
display(0.33)
end
a1 (generic function with 1 method)
julia u1 = Timer(u1 - a1(),0.1)
ERROR: `Timer` has no method matching Timer(::Function, ::Float64)
while in v0.4
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.4.0-dev+5702 (2015-06-30 12:53 UTC)
_/ |\__'_|_|_|\__'_| | Commit 8a49356* (3 days old master)
|__/ | x86_64-linux-gnu
julia function a1()
display(0.33)
end
a1 (generic function with 1 method)
julia u1 = Timer(u1 - a1(),0.1)
Timer0.(33Ptr
{Void} @0x,Condition(Any[]),false)
but this doesn't seem to start.
Re: [julia-users] Possible ways to avoid confusability issues with using superscripts in variable names
Not sure. Your best bet is to open up an issue in Lint.jl. Tony (the maintainer) is usually quite responsive. Cheers, Kevin On Fri, Jul 3, 2015 at 8:39 AM, Scott Jones scott.paul.jo...@gmail.com wrote: Yes, on GitHub, I'd already suggested that (and was pilloried for being off-topic on an issue that had been raised because of me in the first place. Will Lint.jl be able to detect all of the cases that I pointed out? (I haven't tried it yet, been meaning to) On Friday, July 3, 2015 at 11:27:34 AM UTC-4, Kevin Squire wrote: Lint.jl would be a good place to add appropriate warnings. Cheers, Kevin On Friday, July 3, 2015, Scott Jones scott.pa...@gmail.com wrote: I would rather have them as well defined operators, rather than allowed as parts of identifiers, which would have been more consistent with other things in Julia, like sqrt() and cbrt() using the Unicode symbols as prefix operators, however, the reactions included things like pry them from my cold, dead hands, plus other people pointed out other cases where the superscript wasn't really doing a ^2 or ^3 operation. That's why I was trying to brainstorm on ways the language could be made tighter, and at least warn about some of the potential cases of programming errors due to the confusion this can cause, without prying the beloved superscripts from their identifiers. The documentation part is already happening (@Ismael-VC seems to be absolutely full of energy!) On Friday, July 3, 2015 at 9:39:48 AM UTC-4, Tom Breloff wrote: I think I've flipped my position back and forth 6 times in the last few minutes while thinking about this. The mathematician in me wants those special characters to be well defined operators with the expected precedence, but the computer scientist in me thinks that's a horribly stupid idea for reasons that Scott and others have pointed out. The sad thing is that, whatever the decision, it needs to be done in the core parsing for it to be useful, so it can't practically be a user-defined decision (unless of course it becomes a flag you can set when making or running Julia). On that last point... how hard would it be to define certain operators like the square, etc, that sit within #ifdef blocks in the parser? I guess even with that ability, you'd potentially be mixing code of both forms which would be confusing at the very best so I guess we have to choose one. At a minimum... gotta document! On Thursday, July 2, 2015 at 11:25:00 PM UTC-4, Scott Jones wrote: Starting in https://github.com/JuliaLang/julia/pull/11927#issuecomment-117374003 and continuing on in https://github.com/JuliaLang/julia/issues/11966#issuecomment-118212265 , I had raised an issue that can cause confusion to newcomers to Julia, and potentially lead to programming errors if one isn't careful. There is also the issue of inconsistency within Julia, where certain mathematical operations are actually treated as operations, and others that look like taking something to a power, i.e. with superscripts, are treated as identifiers. I am *not* suggesting that this should be changed in Julia (people got a bit upset with that idea), but rather trying to propose ways that the use of superscripts as part of variable names can be made much safer in practice. For example: julia cube(x) = x³ cube (generic function with 1 method) julia cube(3) # Silly me, I think I'll get 27 ERROR: UndefVarError: x³ not defined in cube at none:1 julia x³ = 4242 julia cube(3)42 julia ∛x³ 3.4760266448864496 Besides documenting this, as @Ismael-VC has suggested, I think that it might be useful for the compiler to try to catch some of the cases that could actually lead to programming errors. In the above case, the compiler could detect that a variable of global scope was being used, along with a local variable that is the same except for trailing superscript(s), and give a warning. Another possible programming error that can occur if one mistakenly thought that `³` was performing a cube operation, is that the variable x is updated, but the cached cube value in the variable `x³` is not. That could also be caught by the compiler. What do people think? Are there any other things that could be done besides documentation, to help make using these types of identifiers easier and not error-prone?
Re: [julia-users] Re: Juliacon 2015 videos?
Indeed I would like to translate the videos to Spanish. How are the videos licensed? El jueves, 2 de julio de 2015, 9:00:28 (UTC-5), Scott Jones escribió: There are also Spanish speaking volunteers (David Sander's great Julia community in Mexico) waiting to get the videos (and permission) to subtitle some (or hopefully all) of the talks. Same thing here, all of the talks I went to were wonderful, but I had to miss a number of them that were also of interest to me. On Thursday, July 2, 2015 at 5:11:52 AM UTC-4, Stefan Karpinski wrote: The AV crew was actually paid and they're actively working on the videos, so that should be done soonish. Will let everyone know once it's done, of course. I'm eager to see them too since the conference was 1.5 track and I couldn't see all of the talks! On Wed, Jul 1, 2015 at 8:52 AM, Randy Zwitch randy@fuqua.duke.edu wrote: They were all recorded. Be patient, everyone is a volunteer :) On Wednesday, July 1, 2015 at 8:07:18 AM UTC-4, Hans-Peter wrote: Will there be videos of the 2015 Juliacon? Where... :-) Thanks.
Re: [julia-users] Re: is it possible to return an array (or any other variable) name as a symbol?
On Fri, Jul 3, 2015 at 8:37 PM, Kevin Owens kevin.j.ow...@gmail.com wrote: Yes, you're right, that won't work. I got to thinking about this from this part of the DataFrames documentation: http://dataframesjl.readthedocs.org/en/latest/getting_started.html#the-dataframe-type df = DataFrame(A = 1:4, B = [M, F, F, M]) and this code df = DataFrame() df[:A] = 1:8 df[:B] = [M, F, F, M, F, M, M, F] df If I already had arrays A and B (or an arbitrary number of them) it would be nice to be able to do df = DataFrame(A, B) and then df would have column names :A and :B. And that's exactly what I guessed what you wanted (because I've done sth similar in python sometime ago :P) The right way to do this is to specify the name of the variable because a variable is always bound to a single object while a object can be bound to multiple varialbles. The way I did it in python was using eval. However, in Julia, the eval function is working in the global (module) scope (otherwise the compiler cannot reason anything about local variables) so you cannot use it to get the value of a variable. One way to do this in julia is using macros What you want is basically to write sth like: ``` some magic(A, B) ``` to achieve the effect of ``` DataFrame(A=A, B=B) ``` Well, this is a simple code transformation. (untested code below) ``` macro dataframe(args...) :(DataFrame($([Expr(:kw, arg, arg) for arg in args]...))) end ``` If you would like to figure out how to write a macro, the general procedure is to see the input and output AST with `Meta.show_sexpr` (which is better than `show` for this because some symbols are parsed differently in different context) and then write a program to do the transformation. On Friday, July 3, 2015 at 7:24:55 PM UTC-5, Yichao Yu wrote: On Fri, Jul 3, 2015 at 8:21 PM, Kevin Owens kevin@gmail.com wrote: Gah, nevermind: function as_symbol(x) :(print(x)).args[2] end This is almost certainly not what you want unless you just want a function that returns `:x`, in which case, you would be better off to just return that. Can you elaborate on what exactly you would like to do? Depending on what you really want, there are different ways to implement. (using print() so that it works regardless of the type) On Friday, July 3, 2015 at 7:16:38 PM UTC-5, Kevin Owens wrote: Say you have an array x = rand(5) or just any variable y = abc How would I write a function that I would call like foo(x) and would return the symbol :x?
Re: [julia-users] What happened to Timer?
https://github.com/JuliaLang/julia/pull/11669
On Fri, Jul 3, 2015 at 11:18 AM, Andreas Lobinger lobing...@gmail.com
wrote:
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.10-pre+4 (2015-06-04 13:19 UTC)
_/ |\__'_|_|_|\__'_| | Commit c8804e8* (29 days old release-0.3)
|__/ | x86_64-linux-gnu
julia function a1()
display(0.33)
end
a1 (generic function with 1 method)
julia u1 = Timer(u1 - a1(),0.1)
ERROR: `Timer` has no method matching Timer(::Function, ::Float64)
while in v0.4
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_)| Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type help() for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.4.0-dev+5702 (2015-06-30 12:53 UTC)
_/ |\__'_|_|_|\__'_| | Commit 8a49356* (3 days old master)
|__/ | x86_64-linux-gnu
julia function a1()
display(0.33)
end
a1 (generic function with 1 method)
julia u1 = Timer(u1 - a1(),0.1)
Timer0.(33Ptr
{Void} @0x,Condition(Any[]),false)
but this doesn't seem to start.
Re: [julia-users] DefaultDict unexpected behaviour?
Thank you. It solved my problem
On Friday, July 3, 2015 at 5:54:12 PM UTC+2, Kevin Squire wrote:
I updated the README with another example based on this discussion.
Cheers!
Kevin
On Fri, Jul 3, 2015 at 7:51 AM, Yichao Yu yyc...@gmail.com javascript:
wrote:
On Fri, Jul 3, 2015 at 10:40 AM, Yichao Yu yyc...@gmail.com
javascript: wrote:
On Fri, Jul 3, 2015 at 9:42 AM, Ali Rezaee arv@gmail.com
javascript: wrote:
Thank you. What would be the work around? How can I push values to
defaultdict without changing any other value?
The README I linked is exactly about that.
And quote it here for future reference:
Note that in the last example, we need to use a function to create each
new `DefaultDict`. If we forget, we will end up using the same
`DefaultDict` for all default values:
In their case, the value of a parent DefaultDict is also a DefaultDict
so it might be a little confusing. You can pretty much replace the
DefaultDict above by `Array` and it will apply to your case directly.
On Friday, July 3, 2015 at 3:35:39 PM UTC+2, Yichao Yu wrote:
On Fri, Jul 3, 2015 at 9:29 AM, Ali Rezaee arv@gmail.com wrote:
Hi,
I have the following code:
using DataStrucures
d= DefaultDict(ASCIIString,Array{Int64},Array{Int64}(0))
push!(d[A],2)
push!(d[B],3)
d
DataStructures.DefaultDict{ASCIIString,Array{Int64,N},Array{Int64,1}}
with 2
entries:
B = [2,3]
A = [2,3]
Isn't it unexpected that when I push to any key, the value is
pushed to
all
the other keys as well?
Yes, pretty much. Because the default value is stored by reference and
you are mutating it with `push!`
See the last paragraph of the corresponding section in the
DataStructures.jl README[1]
[1]
https://github.com/JuliaLang/DataStructures.jl#defaultdict-and-defaultordereddict
Thanks :)
[julia-users] Getting Errors / messages from an external program.
Hi, I want to run an external command in Julia. Should a command fail I want to get the message from the external command. I know failed commands raise a general exception that can be caught: *run(`dat hi`)* dat: hi is not a valid command *ERROR: failed process: Process(`dat hi`, ProcessExited(1)) [1]* * in run at ./process.jl:490* I see that a message is printed out by the external program: dat: hi is not a valid command. However readall() does not get this message and return it as a string: *readall(`dat hi`)* dat: hi is not a valid command *ERROR: failed process: Process(`dat hi`, ProcessExited(1)) [1]* * in readbytes at process.jl:474* * in readall at process.jl:479* Is there a way I can capture this message at all and report it back to the user as part of a try-catch upon catching of the ProcessExited(1) exception? Thanks, Ben.
Re: [julia-users] Re: is it possible to return an array (or any other variable) name as a symbol?
On Fri, Jul 3, 2015 at 11:04 PM, Yichao Yu yyc1...@gmail.com wrote: On Fri, Jul 3, 2015 at 8:37 PM, Kevin Owens kevin.j.ow...@gmail.com wrote: Yes, you're right, that won't work. I got to thinking about this from this part of the DataFrames documentation: http://dataframesjl.readthedocs.org/en/latest/getting_started.html#the-dataframe-type df = DataFrame(A = 1:4, B = [M, F, F, M]) and this code df = DataFrame() df[:A] = 1:8 df[:B] = [M, F, F, M, F, M, M, F] df If I already had arrays A and B (or an arbitrary number of them) it would be nice to be able to do df = DataFrame(A, B) and then df would have column names :A and :B. And that's exactly what I guessed what you wanted (because I've done sth similar in python sometime ago :P) The right way to do this is to specify the name of the variable because a variable is always bound to a single object while a object can be bound to multiple varialbles. The way I did it in python was using eval. However, in Julia, the eval function is working in the global (module) scope (otherwise the compiler cannot reason anything about local variables) so you cannot use it to get the value of a variable. One way to do this in julia is using macros What you want is basically to write sth like: ``` some magic(A, B) ``` to achieve the effect of ``` DataFrame(A=A, B=B) ``` Well, this is a simple code transformation. (untested code below) Not untested anymore ``` julia macro dataframe(args...) :(DataFrame($([Expr(:kw, arg, arg) for arg in args]...))) end julia macroexpand(:(@dataframe(A, B))) :(DataFrame(A=A,B=B)) julia Meta.show_sexpr(macroexpand(:(@dataframe(A, B (:call, :DataFrame, (:kw, :A, :A), (:kw, :B, :B)) julia Meta.show_sexpr(:(DataFrame(A=A, B=B))) (:call, :DataFrame, (:kw, :A, :A), (:kw, :B, :B)) ``` ``` macro dataframe(args...) :(DataFrame($([Expr(:kw, arg, arg) for arg in args]...))) end ``` If you would like to figure out how to write a macro, the general procedure is to see the input and output AST with `Meta.show_sexpr` (which is better than `show` for this because some symbols are parsed differently in different context) and then write a program to do the transformation. On Friday, July 3, 2015 at 7:24:55 PM UTC-5, Yichao Yu wrote: On Fri, Jul 3, 2015 at 8:21 PM, Kevin Owens kevin@gmail.com wrote: Gah, nevermind: function as_symbol(x) :(print(x)).args[2] end This is almost certainly not what you want unless you just want a function that returns `:x`, in which case, you would be better off to just return that. Can you elaborate on what exactly you would like to do? Depending on what you really want, there are different ways to implement. (using print() so that it works regardless of the type) On Friday, July 3, 2015 at 7:16:38 PM UTC-5, Kevin Owens wrote: Say you have an array x = rand(5) or just any variable y = abc How would I write a function that I would call like foo(x) and would return the symbol :x?
[julia-users] How do I add to REQUIRE an unregistered package?
Hi! How do I add to REQUIRE a package which isn't in METADATA? ... https://github.com/diegozea/ROC.jl for example. Best,
Re: [julia-users] Re: is it possible to return an array (or any other variable) name as a symbol?
On Fri, Jul 3, 2015 at 8:21 PM, Kevin Owens kevin.j.ow...@gmail.com wrote: Gah, nevermind: function as_symbol(x) :(print(x)).args[2] end This is almost certainly not what you want unless you just want a function that returns `:x`, in which case, you would be better off to just return that. Can you elaborate on what exactly you would like to do? Depending on what you really want, there are different ways to implement. (using print() so that it works regardless of the type) On Friday, July 3, 2015 at 7:16:38 PM UTC-5, Kevin Owens wrote: Say you have an array x = rand(5) or just any variable y = abc How would I write a function that I would call like foo(x) and would return the symbol :x?
Re: [julia-users] Re: is it possible to return an array (or any other variable) name as a symbol?
Yes, you're right, that won't work. I got to thinking about this from this part of the DataFrames documentation: http://dataframesjl.readthedocs.org/en/latest/getting_started.html#the-dataframe-type df = DataFrame(A = 1:4, B = [M, F, F, M]) and this code df = DataFrame() df[:A] = 1:8 df[:B] = [M, F, F, M, F, M, M, F] df If I already had arrays A and B (or an arbitrary number of them) it would be nice to be able to do df = DataFrame(A, B) and then df would have column names :A and :B. On Friday, July 3, 2015 at 7:24:55 PM UTC-5, Yichao Yu wrote: On Fri, Jul 3, 2015 at 8:21 PM, Kevin Owens kevin@gmail.com javascript: wrote: Gah, nevermind: function as_symbol(x) :(print(x)).args[2] end This is almost certainly not what you want unless you just want a function that returns `:x`, in which case, you would be better off to just return that. Can you elaborate on what exactly you would like to do? Depending on what you really want, there are different ways to implement. (using print() so that it works regardless of the type) On Friday, July 3, 2015 at 7:16:38 PM UTC-5, Kevin Owens wrote: Say you have an array x = rand(5) or just any variable y = abc How would I write a function that I would call like foo(x) and would return the symbol :x?
[julia-users] is it possible to return an array (or any other variable) name as a symbol?
Say you have an array x = rand(5) or just any variable y = abc How would I write a function that I would call like foo(x) and would return the symbol :x?
[julia-users] Re: is it possible to return an array (or any other variable) name as a symbol?
Gah, nevermind: function as_symbol(x) :(print(x)).args[2] end (using print() so that it works regardless of the type) On Friday, July 3, 2015 at 7:16:38 PM UTC-5, Kevin Owens wrote: Say you have an array x = rand(5) or just any variable y = abc How would I write a function that I would call like foo(x) and would return the symbol :x?
Re: [julia-users] array concatenation without copying?
Closest I know of is https://github.com/tanmaykm/ChainedVectors.jl --Tim On Friday, July 03, 2015 01:06:31 PM Tom Breloff wrote: I'm interested in being able to do zero-copy concatenation of AbstractArrays, with something similar to ArrayViews, but in reverse: x = rand(4,2) y = rand(4,2) z = hcatview(x,y) # view that is able to index into hcat(x,y) without creating the temporary matrix x[1,1] = 10.0 @assert z[1,1] == x[1,1] Does this exist already somewhere? If I was to build it, should I submit a PR to somewhere (ArrayViews?) or start a new package? One of many uses is to generate a large block matrix, potentially composed of both dense and sparse matrices. Bonus points if I can get a ContiguousView when view(z, 1:3, 4:5) refers to a range that is totally encapsulated by a dense child matrix.
[julia-users] array concatenation without copying?
I'm interested in being able to do zero-copy concatenation of AbstractArrays, with something similar to ArrayViews, but in reverse: x = rand(4,2) y = rand(4,2) z = hcatview(x,y) # view that is able to index into hcat(x,y) without creating the temporary matrix x[1,1] = 10.0 @assert z[1,1] == x[1,1] Does this exist already somewhere? If I was to build it, should I submit a PR to somewhere (ArrayViews?) or start a new package? One of many uses is to generate a large block matrix, potentially composed of both dense and sparse matrices. Bonus points if I can get a ContiguousView when view(z, 1:3, 4:5) refers to a range that is totally encapsulated by a dense child matrix.
Re: [julia-users] Re: Short-circuit evaluation for multiplication
My aim is to write a Hamiltonian MCMC sampler that samples bound and drift
parameter posteriors for bounded diffusion models while assuming some
parametric form for how these bounds and the drift change over time. This
requires the first and second derivative of the first-passage densities
that are computed in
https://github.com/jdrugo/DiffModels.jl/blob/master/src/fpt.jl#L153. For
certain parametrization of drift and bound, partial derivatives will be one
or zero, which would make some parts of the code computing the full
derivatives drop out. To make this have an impact on performance, I thought
of two approaches:
- Write specialised functions for different parameterizations. This is
the safe approach but would introduce many functions, as there are many
possible combinations of drift and bound parameterizations. Also, it would
not handle cases that I haven't thought of.
- Write a generic function that only evaluates the parts of the code
that influence the final result. Currently, it seems that macros are the
best way to achieve this. The advantages would be that it only requires me
to write the function once, avoiding code replication and associated bugs.
Also, it should be able to handle cases that I haven't thought of.
Note that the code linked above currently does not compute the derivatives.
Due to several exp(.), the code that computes the derivatives will be
significantly longer, such that not evaluating parts of it should lead to
faster execution (not in the big-O sense, but reducing the constant).
Jan
On Friday, 3 July 2015 01:51:19 UTC+2, Stefan Karpinski wrote:
Can you elaborate on why that kind of code needs this unusual evaluation?
It looks pretty reasonable as is to me.
On Thu, Jul 2, 2015 at 5:20 PM, Jan Drugowitsch jdr...@gmail.com
javascript: wrote:
Is this a toy reduction of a concept that you want to apply in a much
more complex way?
Yes, it was just meant to illustrate the concept.
It should be applied to a function that has roughly the complexity of
https://github.com/jdrugo/DiffModels.jl/blob/master/src/fpt.jl#L153
(in fact, it would be the first and second derivative of this function
with respect to parameters of drift and bounds).
Jan
On Thu, Jul 2, 2015 at 11:09 AM, Jan Drugowitsch jdr...@gmail.com
wrote:
On Thursday, 2 July 2015 16:55:33 UTC+2, Yichao Yu wrote:
On Thu, Jul 2, 2015 at 10:48 AM, Tom Breloff t...@breloff.com
wrote:
Just curious... is there a reason simply checking for non-zero isn't
enough?
Readability? Performance?
f(a,b,c) = (Bool(a) ? a * (b + c) : 0.0)
I'm guessing he want all code that gets his type automatically gets
this behavior? If yes, I don't think there's anyway you can do that.
If not, then just writing the branch or having a macro to rewrite that
in your own code is probably the best solution.
Indeed, the reason why I don't want to check for zeros and ones
explicitly is that some of these appear in inner loops and would reduce
performance.
I already thought of macros as a possible solution, but I was wondering
if the same could be achieved in a more implicit/elegant way.
Thanks,
Jan
On Thursday, July 2, 2015 at 9:47:59 AM UTC-4, Jan Drugowitsch
wrote:
Dear Julia users,
I am implementing an algorithm to solve a specific type of Volterra
integral equation, and that simplifies significantly if some of its
parameters are set to zero or one. The function implementing the
algorithm
takes quite a few arguments, such that writing specific versions
for
different arguments being zero/one would lead to too many different
functions, which I would like to avoid. What I would rather like to
do is to
write one generic function and let the compiler prune different
parts of the
function, depending on the argument types.
A minimal example of what I would like to do is
immutable Zero : Number; end
const _zero = Zero()
Base.promote_rule{T:Number}(::Type{Zero}, ::Type{T}) = T
Base.convert{T:Number}(::Type{T}, ::Zero) = zero(T)
*(::Zero, ::Zero) = _zero
*(::Zero, ::Bool) = _zero
*(::Bool, ::Zero) = _zero
*(::Zero, ::Number) = _zero
*(::Number, ::Zero) = _zero
f(a, b, c) = a * (println(summing b + c); b + c)
println(Evaluating f(0, 1, 2))
f(0, 1, 2)
println(Evaluating f(_zero, 1, 2))
f(_zero, 1, 2)
(with Zero defined similar to
https://groups.google.com/forum/#!topic/julia-users/0ab30bE8q6c)
Running the above results in
Evaluating f(0, 1, 2)
summing b + c
Evaluating f(_zero, 1, 2)
summing b + c
even though the result of the second summing b + c is discarded,
and
therefore wouldn't need to be evaluated. This is no surprise, as
*(.,.) is a
standard function that evaluates its operands before applying the
function.
Is there any way to change this behavior and turn *(.,.) into a
function
Re: [julia-users] Re: Short-circuit evaluation for multiplication
If the zeros are known at compile time, LLVM may optimise away some
unnecessary operations:
julia foo(x) = x + 0*(x*x + 2)
foo (generic function with 1 method)
julia @code_llvm foo(1)
define i64 @julia_foo_21664(i64) {
top:
ret i64 %0
}
Unfortunately, this doesn't work as is with floating point numbers:
julia @code_llvm foo(1.0)
define double @julia_foo_21665(double) {
top:
%1 = fmul double %0, %0
%2 = fadd double %1, 2.00e+00
%3 = fmul double %2, 0.00e+00
%4 = fadd double %3, %0
ret double %4
}
The problem here is that there are a few special values that may not give
the correct answer, e.g. Inf. However we can use the @fastmath macro to
tell LLVM to ignore these cases:
julia foo(x) = @fastmath x + 0*(x*x + 2)
foo (generic function with 1 method)
julia @code_llvm foo(1.0)
define double @julia_foo_21656(double) {
top:
ret double %0
}
Unfortunately, this doesn't work correctly for more general functions (such
as exp), as LLVM doesn't know these don't have side-effects
(see https://github.com/JuliaLang/julia/issues/414).
-Simon
On Friday, 3 July 2015 07:47:28 UTC+1, Jan Drugowitsch wrote:
My aim is to write a Hamiltonian MCMC sampler that samples bound and drift
parameter posteriors for bounded diffusion models while assuming some
parametric form for how these bounds and the drift change over time. This
requires the first and second derivative of the first-passage densities
that are computed in
https://github.com/jdrugo/DiffModels.jl/blob/master/src/fpt.jl#L153. For
certain parametrization of drift and bound, partial derivatives will be one
or zero, which would make some parts of the code computing the full
derivatives drop out. To make this have an impact on performance, I thought
of two approaches:
- Write specialised functions for different parameterizations. This is
the safe approach but would introduce many functions, as there are many
possible combinations of drift and bound parameterizations. Also, it would
not handle cases that I haven't thought of.
- Write a generic function that only evaluates the parts of the code
that influence the final result. Currently, it seems that macros are the
best way to achieve this. The advantages would be that it only requires me
to write the function once, avoiding code replication and associated bugs.
Also, it should be able to handle cases that I haven't thought of.
Note that the code linked above currently does not compute the
derivatives. Due to several exp(.), the code that computes the derivatives
will be significantly longer, such that not evaluating parts of it should
lead to faster execution (not in the big-O sense, but reducing the
constant).
Jan
On Friday, 3 July 2015 01:51:19 UTC+2, Stefan Karpinski wrote:
Can you elaborate on why that kind of code needs this unusual evaluation?
It looks pretty reasonable as is to me.
On Thu, Jul 2, 2015 at 5:20 PM, Jan Drugowitsch jdr...@gmail.com wrote:
Is this a toy reduction of a concept that you want to apply in a much
more complex way?
Yes, it was just meant to illustrate the concept.
It should be applied to a function that has roughly the complexity of
https://github.com/jdrugo/DiffModels.jl/blob/master/src/fpt.jl#L153
(in fact, it would be the first and second derivative of this function
with respect to parameters of drift and bounds).
Jan
On Thu, Jul 2, 2015 at 11:09 AM, Jan Drugowitsch jdr...@gmail.com
wrote:
On Thursday, 2 July 2015 16:55:33 UTC+2, Yichao Yu wrote:
On Thu, Jul 2, 2015 at 10:48 AM, Tom Breloff t...@breloff.com
wrote:
Just curious... is there a reason simply checking for non-zero
isn't enough?
Readability? Performance?
f(a,b,c) = (Bool(a) ? a * (b + c) : 0.0)
I'm guessing he want all code that gets his type automatically gets
this behavior? If yes, I don't think there's anyway you can do that.
If not, then just writing the branch or having a macro to rewrite
that
in your own code is probably the best solution.
Indeed, the reason why I don't want to check for zeros and ones
explicitly is that some of these appear in inner loops and would reduce
performance.
I already thought of macros as a possible solution, but I was
wondering if the same could be achieved in a more implicit/elegant way.
Thanks,
Jan
On Thursday, July 2, 2015 at 9:47:59 AM UTC-4, Jan Drugowitsch
wrote:
Dear Julia users,
I am implementing an algorithm to solve a specific type of
Volterra
integral equation, and that simplifies significantly if some of
its
parameters are set to zero or one. The function implementing the
algorithm
takes quite a few arguments, such that writing specific versions
for
different arguments being zero/one would lead to too many
different
functions, which I would like to avoid. What I would rather like
to do is to
write one generic function and let
