Re: [julia-users] The dark side of types
OK, got it. Keno was right: you're actually redefining the cdCanvas type when calling include(../src/libcd_h.jl). So you have both IUP.cdCanvas and cdCanvas. Shit, I should have been able to find this myself. Thanks a million. I hope to be able to pay back if I ever manage to make something (real) useful out of IUP.jl In Julia 0.4, the fully-qualified names will be printed, which will make this situation obvious. Though I wonder whether it wouldn't be good to also print a warning when creating this kind of conflict, either when loading a package or when defining a new type (whichever happens last). Or at least when using the type. Those type of measures were actually advanced in the first time I step on this type of problems https://groups.google.com/forum/?fromgroups=#!topic/julia-dev/GojOx4nI-xo Regarding 0.4, there currently something steping in the way. See #9739 Thanks again for your effort. Joaquim
[julia-users] Re: Julia cannot compute factorial(21) while Octave can
Is there a way to provide a suggestion with the error? It currently says this, *julia **factorial(21)* *ERROR: OverflowError()* * in factorial_lookup at combinatorics.jl:27* * in factorial at combinatorics.jl:35* Maybe it would be more useful if it said *julia **factorial(21)* *ERROR: OverflowError(perhaps you want factorial(big(21)) instead?)* * in factorial_lookup at combinatorics.jl:27* * in factorial at combinatorics.jl:35* On Wednesday, January 14, 2015 at 11:37:17 AM UTC-7, Viral Shah wrote: I am guessing, that like Matlab, octave uses doubles to represent integers, and hence you can go a bit farther than with integers. That should be the same as factorial(21.0) in julia. Of course, you can also use BigInt and such, which has already been discussed here. -viral On Tuesday, January 13, 2015 at 8:40:06 AM UTC+5:30, Carlos Baptista wrote: I understand that factorial(21) is quite a large number and therefore an OverflowError is perfectly understandable. However, with Octave I can go up to factorial(170) (if I go higher I receive Inf). Is there a way to go beyond factorial(20) in Julia?
Re: [julia-users] The dark side of types
Le mercredi 14 janvier 2015 à 11:59 -0800, J Luis a écrit :
Just a shot in the dark, but if instead of this:
ctgc_l = tCTC_l(C_NULL)
ctgc_l.iup_canvas = t
cdActivate(ctgc_l.iup_canvas)
you do this:
ctgc_l = tCTC_l(t)
cdActivate(ctgc_l.iup_canvas)
does it make any difference?
unfortunately, no (and took care to comment line 129)
(Please copy/paste the output of the Julia console.)
Also, I guess you've made sure you start from a clean
workspace? What
does methods(cdActivate) say?
Yes, I always start from a clean workspace (From the Windows cmd I
call .jl file that calls the code)
adding a @show methods(cdActivate) after line 131
prints
t = Ptr{cdCanvas} @0x21844fe0
ctgc_l.iup_canvas = Ptr{cdCanvas} @0x21844fe0
methods(cdActivate) = # 1 method for generic function cdActivate:
cdActivate(canvas::Ptr{cdCanvas}) at C:\programs\Gits\IUP.jl\src
\libcd.jl:701
ERROR: `cdActivate` has no method matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:134
in cdtest at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:96
in include at boot.jl:245
in include_from_node1 at loading.jl:128
in process_options at client.jl:285
in _start at client.jl:354
while loading C:\programs\Gits\IUP.jl\src\execa.jl
OK, got it. Keno was right: you're actually redefining the cdCanvas type
when calling include(../src/libcd_h.jl). So you have both IUP.cdCanvas
and cdCanvas.
In Julia 0.4, the fully-qualified names will be printed, which will make
this situation obvious. Though I wonder whether it wouldn't be good to
also print a warning when creating this kind of conflict, either when
loading a package or when defining a new type (whichever happens last).
Or at least when using the type.
Regards
[julia-users] 1º reunión de Julians, México D.F.
Hola a todos! Si viven por el D.F. o la zona metropolitana los esperamos este sábado en *KMMX*! Detalles: http://www.meetup.com/julialang-mx Alla nos vemos! :D
[julia-users] Re: 1º reunión de Julians, México D.F.
...también si piensan venir de visita este fin de semana! ;) ### Hello everyone! If you live in Mexico City, the metropolitan area or just plan to visit us this weekend, you are wellcome this saturday at *KMMX*! Details are in spanish, but you are interested, just ask! :D El miércoles, 14 de enero de 2015, 13:11:35 (UTC-6), Ismael VC escribió: Hola a todos! Si viven por el D.F. o la zona metropolitana los esperamos este sábado en *KMMX*! Detalles: http://www.meetup.com/julialang-mx Alla nos vemos! :D
Re: [julia-users] The dark side of types
Le mercredi 14 janvier 2015 à 11:27 -0800, J Luis a écrit :
OK, I've uploaded the code to IUP repo.
What I mean in last message is that if I remove the type assignment in
line 19 of
https://github.com/joa-quim/IUP.jl/blob/master/examples/cdtest_.jl
than the line 133 does not error, otherwise it happens what I
described.
Sorry but don't know how to make a shorter example.
Just a shot in the dark, but if instead of this:
ctgc_l = tCTC_l(C_NULL)
ctgc_l.iup_canvas = t
cdActivate(ctgc_l.iup_canvas)
you do this:
ctgc_l = tCTC_l(t)
cdActivate(ctgc_l.iup_canvas)
does it make any difference?
(Please copy/paste the output of the Julia console.)
Also, I guess you've made sure you start from a clean workspace? What
does methods(cdActivate) say?
Regards
quarta-feira, 14 de Janeiro de 2015 às 18:58:54 UTC, Milan
Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 10:44 -0800, J Luis a écrit :
What I found is if, for simplification, I restrict the type
to (that
is without type assignment)
type tCTC_l
iup_canvas
end
than it works. But if I change it to
type tCTC_l
iup_canvas::Ptr{cdCanvas}
end
it errors again. For curiosity I tried also
type tCTC_l
iup_canvas::Int64
end
and now
t = Ptr{cdCanvas} @0x21c3f4a0
ctgc_l.iup_canvas = 566490272
ERROR: `cdActivate` has no method matching
cdActivate(::Int64)
that is, it converted the Ptr{cdCanvas} (the 't') to Int64,
so it
seams that in the first instance it converted one
Ptr{cdCanvas} to
another Ptr{cdCanvas} ending up with TWO declarations of
the
Ptr{cdCanvas}.
Does it make any sense?
No. I think you should at the very least show us a copy/paste
of the
code you run. Debugging without a reproducible example is hard
enough;
debugging without seeing the commands that triggered the bug
is
impossible.
Regards
quarta-feira, 14 de Janeiro de 2015 às 17:50:51 UTC, J Luis
escreveu:
Yes, an synthetic example would be nice, but I
strongly
suspect that if I was able to create one than it
would because
I had found the problem.
quarta-feira, 14 de Janeiro de 2015 às 16:15:20 UTC,
Milan
Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 07:42 -0800, J
Luis a
écrit :
Well, I can make the current (failing)
code
available in the IUP repo
but to run it implies installing the IUP
lib, and
IUP.jl which
probably no one tested in other than
Windows.
But the problem does not seem to involve IUP
(or via a
nasty memory
corruption bug). You should be able to
reproduce it
with a short
artificial example.
Regards
quarta-feira, 14 de Janeiro de 2015 às
15:30:20 UTC,
Milan Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à
06:54 -0800, J
Luis a écrit :
I already fall in those two
forms of
troubles (double definition and
double inclusion of the file
where the
type is defined) so I'm aware
of it. As much as I can tell
with
grepping, that is not occurring
now.
Maybe a third (unknown to me)
form of this
type of issue?
Would you be able to create a
reproducible
example?
Regards
quarta-feira, 14 de Janeiro de
2015 às
14:41:56 UTC, Keno Fischer
escreveu:
Re: [julia-users] The dark side of types
Just a shot in the dark, but if instead of this:
ctgc_l = tCTC_l(C_NULL)
ctgc_l.iup_canvas = t
cdActivate(ctgc_l.iup_canvas)
you do this:
ctgc_l = tCTC_l(t)
cdActivate(ctgc_l.iup_canvas)
does it make any difference?
unfortunately, no (and took care to comment line 129)
(Please copy/paste the output of the Julia console.)
Also, I guess you've made sure you start from a clean workspace? What
does methods(cdActivate) say?
Yes, I always start from a clean workspace (From the Windows cmd I call .jl
file that calls the code)
adding a @show methods(cdActivate) after line 131
prints
t = Ptr{cdCanvas} @0x21844fe0
ctgc_l.iup_canvas = Ptr{cdCanvas} @0x21844fe0
methods(cdActivate) = # 1 method for generic function cdActivate:
cdActivate(canvas::Ptr{cdCanvas}) at
C:\programs\Gits\IUP.jl\src\libcd.jl:701
ERROR: `cdActivate` has no method matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:134
in cdtest at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:96
in include at boot.jl:245
in include_from_node1 at loading.jl:128
in process_options at client.jl:285
in _start at client.jl:354
while loading C:\programs\Gits\IUP.jl\src\execa.jl
[julia-users] Foro julia-user-es, para discutir acerca de Julia en español.
Foro julia-user-es, para discutir acerca de Julia en español: :D https://groups.google.com/forum/#!forum/julia-users-es
[julia-users] Strange Type Errors
Hi,
I am trying to port following simple Matlab code into Julia to get
*mu*
M=500
m_plus=M*0.2;
m_0=M*0.1;
m_minus=M*0.7;
mu_plus=0.15+0.5*(1:m_plus)/m_plus;
mu_minus=-3*(1:m_minus)/m_minus;
mu_0=zeros(1,m_0);
*mu*=[mu_plus mu_0 mu_minus]
However, with Julia, this is never a simple task because of the too sensitive
type specification.
I have no problem upto line 6 but I had error on line 7 or zeros().
`Array{T,N}` has no method matching Array{T,N}(::Type{Float64}, ::Int64,
::Float64)
while loading In[121], in expression starting on line 1 in zeros at array.jl:170
It worked when I changed 50.0 into 50 in zeros() and I made change in code to
convert float into integer with convert()and ::
convert(Int32,m_0);
m_0= m_0::Int32
but not works
The second error was concatenation.
mu_plus=0.15+0.5*(1:m_plus)/m_plus;
mu_minus=-3*(1:m_minus)/m_minus;
mu_0=zeros(1,50);
mu=[mu_plus mu_0 mu_minus]
number of rows must match while loading In[133], in expression starting on line
4
in hcat at abstractarray.jl:571
This may be the reason of different date type as well.
The type of mu_plus and mu_minus are FloatRange{Float64} (constructor with 1
method),
while that of mu_0 is Array{Float64,2}
Could you let be know the basics that I still need to practice?
Many thanks.
Re: [julia-users] Strange Type Errors
Le mercredi 14 janvier 2015 à 13:00 -0800, jspark a écrit :
Hi,
I am trying to port following simple Matlab code into Julia to get mu
M=500
m_plus=M*0.2;
m_0=M*0.1;
m_minus=M*0.7;
mu_plus=0.15+0.5*(1:m_plus)/m_plus;
mu_minus=-3*(1:m_minus)/m_minus;
mu_0=zeros(1,m_0);
mu=[mu_plus mu_0 mu_minus]
However, with Julia, this is never a simple task because of the too
sensitive type specification.
I have no problem upto line 6 but I had error on line 7 or zeros().
`Array{T,N}` has no method matching
Array{T,N}(::Type{Float64}, ::Int64, ::Float64)
while loading In[121], in expression starting on line 1 in zeros at
array.jl:170
It worked when I changed 50.0 into 50 in zeros() and I made change in
code to convert float into integer with convert()and ::
convert(Int32,m_0);
m_0= m_0::Int32
but not works
Yes, zeros() only accepts integers currently. Maybe this could be
changed to automatically do the conversion when possible.
You can simply write
m_0=Int(M*0.1);
(::Int does not perform a conversion, it merely asserts that the type
matches. And Int is an alias for Int32 or Int64 depending on the
platform, better use it as a general rule.)
The second error was concatenation.
mu_plus=0.15+0.5*(1:m_plus)/m_plus;
mu_minus=-3*(1:m_minus)/m_minus;
mu_0=zeros(1,50);
mu=[mu_plus mu_0 mu_minus]
number of rows must match while loading In[133], in expression starting on
line 4
in hcat at abstractarray.jl:571
This may be the reason of different date type as well.
The type of mu_plus and mu_minus are FloatRange{Float64} (constructor with 1
method),
while that of mu_0 is Array{Float64,2}
This is not a only a type problem, but a dimensionality one, as the message
says:
julia size(mu_plus)
(100,)
julia size(mu_0)
(1,50)
julia size(mu_minus)
(350,)
I'm not sure how you'd expect to be able to concatenate these arrays
whose sizes are completely different, not even multiples of one another.
At the very least, I think you want
mu_0=zeros(50);
to get a vector, instead of a one-row matrix.
Could you let be know the basics that I still need to practice?
I'd start with the manual of course, but you can also have a look at the
Noteworthy differences from MATLAB section.
Regards
[julia-users] Re: New method should respect previous syntax?
You can choose to defer those more complicated cases to Base: signif(x::Float64, digits::Integer) = println(Felipe's swanky customized signif) signif(args…) = Base.signif(args…) # Punt to the Base implementation for all other cases On Wednesday, January 14, 2015 at 1:24:34 PM UTC-5, Felipe Jiménez wrote: Thank you, Steven. Your explanations are clear and helpful. But then I don't know how to obtain the behavior I want. A) I don't want to completely replace Base's signif because I still want access to Julia's methods. For instance, my method only works in base 10, so I don't want to lose Julia's ability to calculate signif() in other bases. When I personally call signif (e.g. at the REPL), I want my new method to be dispatched for specific-enough input types. If I do signif(1.2,2) I want to get 1.2. If signif(1.2,2,2), I want 1.0 (base 2). Even if at some point I want to invoke Julia's method on base 10, I still want to be able to do signif(1.2,2,10) and get 1.2002 instead of my method's 1.2. That is easy to achieve, because Julia's methods are: signif(x, digits::Integer) signif(x, digits::Integer, base::Integer) which do not specify the type of x, so after import Base.signif, as soon as I add a method like function signif(x::Float64, digits::Integer) if x is a Float64 my method will be chosen, because it is more type-specific. B) But neither do I want to affect all modules calling signif, because then any package that calls signif would alter its behavior. This means that my method should be invisible to packages. [If I understand you well, both defining function Base.signif, or alternatively doing import Base.signif before defining function signif, both will affect all modules calling signif, no?] Summarising: my REPL (or my Main module or whatever module I want) should see Julia's methods plus my own; but installed packages should only see Julia's methods. P.S.1 Choosing a different function name, like function felipesignif(), would work, because no package will call felipesignif(), but it is not something I like too much, because my function does essentially the same thing as Julia's, only with more care about roundoff errors (at the cost of some speed, which is not needed for my intended purposes). The natural thing is to use the same function name, possibly with an optional third input argument options to control its behavior regarding dealing with roundoff errors. P.S.2 Of course my question was a somewhat general one regarding best practices, rather than this specific signif() issue. Julia's design encourages adding new methods to existing functions. Is nobody else worried that installed packages can be affected by new methods? On Tuesday, January 13, 2015 at 8:30:21 PM UTC+1, Steven G. Johnson wrote: In any module, if you define function signif, it will completely replace Base's signif (for *all* argument types), but only within that module; other modules will not be affected. Defining things in the REPL is equivalent to defining them within the module Main. If, instead, you want to add a new method signature to the Base.signif function, you should define function Base.signif, or alternatively import Base.signif before defining function signif. This will affect all modules calling signif.
Re: [julia-users] The dark side of types
OK, I've uploaded the code to IUP repo.
What I mean in last message is that if I remove the type assignment in line
19 of
https://github.com/joa-quim/IUP.jl/blob/master/examples/cdtest_.jl
than the line 133 does not error, otherwise it happens what I described.
Sorry but don't know how to make a shorter example.
quarta-feira, 14 de Janeiro de 2015 às 18:58:54 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 10:44 -0800, J Luis a écrit :
What I found is if, for simplification, I restrict the type to (that
is without type assignment)
type tCTC_l
iup_canvas
end
than it works. But if I change it to
type tCTC_l
iup_canvas::Ptr{cdCanvas}
end
it errors again. For curiosity I tried also
type tCTC_l
iup_canvas::Int64
end
and now
t = Ptr{cdCanvas} @0x21c3f4a0
ctgc_l.iup_canvas = 566490272
ERROR: `cdActivate` has no method matching cdActivate(::Int64)
that is, it converted the Ptr{cdCanvas} (the 't') to Int64, so it
seams that in the first instance it converted one Ptr{cdCanvas} to
another Ptr{cdCanvas} ending up with TWO declarations of the
Ptr{cdCanvas}.
Does it make any sense?
No. I think you should at the very least show us a copy/paste of the
code you run. Debugging without a reproducible example is hard enough;
debugging without seeing the commands that triggered the bug is
impossible.
Regards
quarta-feira, 14 de Janeiro de 2015 às 17:50:51 UTC, J Luis escreveu:
Yes, an synthetic example would be nice, but I strongly
suspect that if I was able to create one than it would because
I had found the problem.
quarta-feira, 14 de Janeiro de 2015 às 16:15:20 UTC, Milan
Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 07:42 -0800, J Luis a
écrit :
Well, I can make the current (failing) code
available in the IUP repo
but to run it implies installing the IUP lib, and
IUP.jl which
probably no one tested in other than Windows.
But the problem does not seem to involve IUP (or via a
nasty memory
corruption bug). You should be able to reproduce it
with a short
artificial example.
Regards
quarta-feira, 14 de Janeiro de 2015 às 15:30:20 UTC,
Milan Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 06:54 -0800, J
Luis a écrit :
I already fall in those two forms of
troubles (double definition and
double inclusion of the file where the
type is defined) so I'm aware
of it. As much as I can tell with
grepping, that is not occurring
now.
Maybe a third (unknown to me) form of this
type of issue?
Would you be able to create a reproducible
example?
Regards
quarta-feira, 14 de Janeiro de 2015 às
14:41:56 UTC, Keno Fischer
escreveu:
Are you maybe accidentally
defining cdCanvas twice or in two
different modules?
On Wed, Jan 14, 2015 at 3:40 PM, J
Luis jmf...@gmail.com
wrote:
BTW, if that matters,
'ctgc' is a global variable.
quarta-feira, 14 de
Janeiro de 2015 às 14:37:05 UTC, J
Luis escreveu:
Hi, thanks for
looking into this.
If I make them
show, as
@show
ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show
ctgc.iup_canvas
Re: [julia-users] The dark side of types
Le mercredi 14 janvier 2015 à 10:44 -0800, J Luis a écrit :
What I found is if, for simplification, I restrict the type to (that
is without type assignment)
type tCTC_l
iup_canvas
end
than it works. But if I change it to
type tCTC_l
iup_canvas::Ptr{cdCanvas}
end
it errors again. For curiosity I tried also
type tCTC_l
iup_canvas::Int64
end
and now
t = Ptr{cdCanvas} @0x21c3f4a0
ctgc_l.iup_canvas = 566490272
ERROR: `cdActivate` has no method matching cdActivate(::Int64)
that is, it converted the Ptr{cdCanvas} (the 't') to Int64, so it
seams that in the first instance it converted one Ptr{cdCanvas} to
another Ptr{cdCanvas} ending up with TWO declarations of the
Ptr{cdCanvas}.
Does it make any sense?
No. I think you should at the very least show us a copy/paste of the
code you run. Debugging without a reproducible example is hard enough;
debugging without seeing the commands that triggered the bug is
impossible.
Regards
quarta-feira, 14 de Janeiro de 2015 às 17:50:51 UTC, J Luis escreveu:
Yes, an synthetic example would be nice, but I strongly
suspect that if I was able to create one than it would because
I had found the problem.
quarta-feira, 14 de Janeiro de 2015 às 16:15:20 UTC, Milan
Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 07:42 -0800, J Luis a
écrit :
Well, I can make the current (failing) code
available in the IUP repo
but to run it implies installing the IUP lib, and
IUP.jl which
probably no one tested in other than Windows.
But the problem does not seem to involve IUP (or via a
nasty memory
corruption bug). You should be able to reproduce it
with a short
artificial example.
Regards
quarta-feira, 14 de Janeiro de 2015 às 15:30:20 UTC,
Milan Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 06:54 -0800, J
Luis a écrit :
I already fall in those two forms of
troubles (double definition and
double inclusion of the file where the
type is defined) so I'm aware
of it. As much as I can tell with
grepping, that is not occurring
now.
Maybe a third (unknown to me) form of this
type of issue?
Would you be able to create a reproducible
example?
Regards
quarta-feira, 14 de Janeiro de 2015 às
14:41:56 UTC, Keno Fischer
escreveu:
Are you maybe accidentally
defining cdCanvas twice or in two
different modules?
On Wed, Jan 14, 2015 at 3:40 PM, J
Luis jmf...@gmail.com
wrote:
BTW, if that matters,
'ctgc' is a global variable.
quarta-feira, 14 de
Janeiro de 2015 às 14:37:05 UTC, J
Luis escreveu:
Hi, thanks for
looking into this.
If I make them
show, as
@show
ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show
ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas =
Ptr{cdCanvas}
@0x
t = Ptr{cdCanvas}
@0x22c6d6c0
ctgc.iup_canvas =
Ptr{cdCanvas}
@0x22c6d6c0
Re: [julia-users] Foro julia-user-es, para discutir acerca de Julia en español.
Genial :) El 14/01/2015 17:59, Ismael VC ismael.vc1...@gmail.com escribió: Foro julia-user-es, para discutir acerca de Julia en español: :D https://groups.google.com/forum/#!forum/julia-users-es
Re: [julia-users] Strange Type Errors
On Wednesday, January 14, 2015 at 4:19:35 PM UTC-5, Milan Bouchet-Valat wrote: Yes, zeros() only accepts integers currently. Maybe this could be changed to automatically do the conversion when possible. See https://github.com/JuliaLang/julia/issues/1972
Re: [julia-users] readdir returns inconsistent types
On Thursday, January 15, 2015 at 3:02:13 AM UTC+10, Steven G. Johnson wrote:
On Tuesday, January 13, 2015 at 10:38:23 PM UTC-5, ele...@gmail.com wrote:
Probably right if the mutations for adding extensions etc are not
conveniently available with Vector{uint8}.
It would certainly be possible to define these operations, e.g.
concatenation of a string with a bytevector. But even then I think a
bytevector would be the wrong choice. When I look at a filename, I don't
want to see UInt8[0x66,0x6f,0x6f,0x2e,0x74,0x78,0x74], I want to see
foo.txt.
Good point, I would too.
And by returning a (potentially invalid) UTF8String, that's what I get in
the *vast* majority of cases—non-UTF8 filenames seem to be pretty rare
nowadays even on Unix systems (e.g. many GNU/Linux systems have defaulted
to displaying filenames as UTF-8 for a decade now).
I see it mostly in non-English locales on Windows or where windows disks
are mounted on Linux, and it is still a fairly common problem. Those of us
in English locales shouldn't extrapolate our easy ride with encodings to
the rest of the world :)
Even for a non-UTF8 filename where I get mojibake, in most cases it will
be in some other 1-byte superset of ASCII, so the displayed results will
still be somewhat useful: I'd much rather see Foo££££.txt than
a list of byte values.
I guess a third alternative would be to define an UnknownEncodingString
type that stores an array of bytes and displays by default as UTF-8 (or
even tries to guess the encoding) and supports concatenation and a few
other carefully chosen operations, but not iteration over codepoints and
other things that can't be implemented without knowing the encoding. The
idea being to prevent programmers from trying to perform operations on
filenames that may fail on strings with unknown encodings. But this seems
like it would be a lot of hassle for little benefit these days.
To me this would be preferable, that way functions that treat the
UnknownEncodingString as UTF-8 know they have to be robust when
encountering invalid UTF-8. Otherwise it might be necessary for all UTF-8
handling functions to check for invalid sequences so they don't cause
problems, which has a possible performance penalty.
I have done work on an application that tries to guess encodings, and other
than ASCII or valid UTF-8, its not often right. :) It very much depends on
the order of trying alternatives, and it is performance intensive, though
most filenames are so short this wouldn't matter so much.
[julia-users] Re: rfft: Lack of type annotations causes major allocation overhead
Your typeof() in f1 prints the run-time type of the array, the type of the
actual array returned by rfft(), but the code is generated using the
compile time type of the return from rfft(). But as Andreas shows, the
compile time type is incorrectly Any. Using Any the compiler has to
generate runtime type checking and often lots of copying so its slow and
allocates. For f2 you have told the compiler to assume the return type is
the right type so it can generate better code.
Cheers
Lex
On Wednesday, January 14, 2015 at 5:39:14 PM UTC+10, emilhe...@gmail.com
wrote:
Hi all,
In the code below I define two functions, f1 and f2, that take a
three-dimensional array of Float64, computes the real FFT (rfft) and loops
once over the computed values of the rfft. In f1, a lot of time is spent in
the simple for loop, and many, many bytes are allocated. In f2, very little
time is spent in the for loop, and no bytes are allocated, as would be
expected. The only difference between the two functions is X = rfft(x)
in f1 and X = rfft(x) :: Array{Complex{Float64}, 3} in f2. For both
functions, typeof(X) says that X is an Array{Complex{Float64}, 3}, so the
extra type annotation in f2 should not be necessary.
I encountered this problem in Julia version 0.3.6 and it persists in
version 0.4.0-dev+2666. In 0.4.0 the macro @code_warntype can be used to
reveal that X is of type ANY in f1 but Array{Complex{Float64}, 3} in f2.
This seems to contradict the output of typeof(X) and is very confusing to
me.
Cheers,
Emil
### Code
function f1(x :: Array{Float64, 3})
@time X = rfft(x)
println(typeof(X) = $(typeof(X)))
@time for i = 1 : length(X)
X[i] *= X[i]
end
X
end
function f2(x :: Array{Float64, 3})
@time X = rfft(x) :: Array{Complex{Float64}, 3}
println(typeof(X) = $(typeof(X)))
@time for i = 1 : length(X)
X[i] *= X[i]
end
X
end
println(Compiling...)
f1(rand(2,2,2))
f2(rand(2,2,2))
println(f1...)
f1(rand(128,128,128))
println(f2...)
f2(rand(128,128,128))
@code_warntype f1(rand(2,2,2))
@code_warntype f2(rand(2,2,2))
### Output
Compiling...
elapsed time: 0.165980813 seconds (5783476 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.008426071 seconds (319840 bytes allocated)
elapsed time: 9.8616e-5 seconds (3560 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 6.28e-7 seconds (0 bytes allocated)
f1...
elapsed time: 0.022922817 seconds (17042840 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.419889359 seconds (144836816 bytes allocated, 16.67% gc
time)
f2...
elapsed time: 0.023057751 seconds (17042840 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.002572673 seconds (0 bytes allocated)
[output of @code_warntype is omitted]
[julia-users] Re: Help with using sublime iJulia
Also when I run similar code in python it would take 3 seconds. Am I doing something wrong?
Re: [julia-users] Speed of Julia when a function is passed as an argument, and a different, but much faster coding.
*julia **type GGG end*
*julia **call(::Type{GGG}, d::Int) = d*
*call (generic function with 858 methods)*
*julia **GGG(4)*
*4*
*julia **GGG(2)*
*2*
Cheers
Tobias
Am Mittwoch, 14. Januar 2015 23:09:26 UTC+1 schrieb Petr Krysl:
Hi Tobias,
Is there an example of the use of this new syntax for 0.4?
Thanks,
Petr
On Sunday, January 11, 2015 at 12:20:39 PM UTC-8, Tobias Knopp wrote:
The call syntax is part of 0.4
Cheers
Tobi
Am Sonntag, 11. Januar 2015 19:35:06 UTC+1 schrieb Petr Krysl:
On Sunday, January 11, 2015 at 10:22:05 AM UTC-8, Tim Holy wrote:
Already implement in julia 0.4.
Very cool! Just checking: are you saying that the solution I proposed
with the empty types would actually address the problem of functions
being inefficient as when passed in as callbacks, and that this is now
part of 0.4? Or rather that the syntactic sugar of being able to call on
object is part of 0.4?
Thanks,
P
Re: [julia-users] macros using global variables problem
Well, I don't get it very clearly. I learnt that 'esc' changes variable names of a local variable in the macro. But I want to reference the global variable out of the macro. I have little idea of Lisp macros, so I think I still cannot handle this. Would you please add more details? Yi On Wed, Jan 14, 2015 at 11:37 PM, Isaiah Norton isaiah.nor...@gmail.com wrote: You need to use 'esc' -- see the hygiene part of the metaprog section in the manual. On Jan 14, 2015 8:56 AM, yi lu zhiwudazhanjiang...@gmail.com wrote: Hi, I am able to write a simple macro to drop brackets. https://gist.github.com/eccstartup/36637d96355bd5ca8188 But there is some problem with this. You can see the @nobrace macro that drop brackets of functions. For example: ``` @nobrace map (x-x^2-1) 1:0.01:2 ``` get a list of Float numbers. This is fine. However, in the macro, we cannot see global variables. For example: ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 print(arr) ``` will print the arr list, but ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 @nobrace print arr ``` will report arr not found. Is there a remedy? Yours, Yi
Re: [julia-users] Speed of Julia when a function is passed as an argument, and a different, but much faster coding.
Hi Tobias, Is there an example of the use of this new syntax for 0.4? Thanks, Petr On Sunday, January 11, 2015 at 12:20:39 PM UTC-8, Tobias Knopp wrote: The call syntax is part of 0.4 Cheers Tobi Am Sonntag, 11. Januar 2015 19:35:06 UTC+1 schrieb Petr Krysl: On Sunday, January 11, 2015 at 10:22:05 AM UTC-8, Tim Holy wrote: Already implement in julia 0.4. Very cool! Just checking: are you saying that the solution I proposed with the empty types would actually address the problem of functions being inefficient as when passed in as callbacks, and that this is now part of 0.4? Or rather that the syntactic sugar of being able to call on object is part of 0.4? Thanks, P
[julia-users] Julia previous versions download
I have installed the current version of Julia 0.3.5 and as far as I know the Rmath library is no longer available (also it gave me an error when I tried to install it). I have some previous programs that I have created using Julia 0.2.0 in which I use Rmath. Is there any archive where I can download Julia version 0.2.0 so that it is compatible with my program? If not, is there a way to install Rmath for Julia version 0.3.5? In my programs I use the dnorm function and this is why I need to use Rmath. Thank you! Georgiana
Re: [julia-users] macros using global variables problem
I don't know why my previous version won't work,BUT ``` macro nb(f, args...) :($f($(arg...))) end ``` will get the right result. What's the difference between `quote .. end` and `:( .. )` then? :P On Thu, Jan 15, 2015 at 11:06 AM, Isaiah Norton isaiah.nor...@gmail.com wrote: julia macro nb(f, args...) arg1 = map(x-:($(esc(x))), args) :($f($(arg1...))) end julia @nb print arr [0.0,0.020107, ... If you haven't used it already, I would suggest to look at macroexpand to see the expression resulting from each macro (for example, look at why the previous version didn't work). julia macroexpand( :(@nb print arr) ) On Wed, Jan 14, 2015 at 8:32 PM, yi lu zhiwudazhanjiang...@gmail.com wrote: Well, I don't get it very clearly. I learnt that 'esc' changes variable names of a local variable in the macro. But I want to reference the global variable out of the macro. I have little idea of Lisp macros, so I think I still cannot handle this. Would you please add more details? Yi On Wed, Jan 14, 2015 at 11:37 PM, Isaiah Norton isaiah.nor...@gmail.com wrote: You need to use 'esc' -- see the hygiene part of the metaprog section in the manual. On Jan 14, 2015 8:56 AM, yi lu zhiwudazhanjiang...@gmail.com wrote: Hi, I am able to write a simple macro to drop brackets. https://gist.github.com/eccstartup/36637d96355bd5ca8188 But there is some problem with this. You can see the @nobrace macro that drop brackets of functions. For example: ``` @nobrace map (x-x^2-1) 1:0.01:2 ``` get a list of Float numbers. This is fine. However, in the macro, we cannot see global variables. For example: ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 print(arr) ``` will print the arr list, but ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 @nobrace print arr ``` will report arr not found. Is there a remedy? Yours, Yi
Re: [julia-users] help piping julia script in shell
Thank you for your help. I now have to make my script switch from file input to STDIN input if required. Le jeudi 15 janvier 2015 04:16:27 UTC+1, Isaiah a écrit : isaiah@titan:/tmp$ cat t3.jl x = readline(STDIN) println(input was: , x) isaiah@titan:/tmp$ echo hello | julia t3.jl input was: hello On Wed, Jan 14, 2015 at 5:19 AM, lobrea...@gmail.com javascript: wrote: Hi, I have written different scripts in julia for which the input is so far a file provided as an argument. The output is printed on stdout. I would like to be able to use them with files as input or to pipe them in unix shell so the output of a script is taken as input by the next script in the pipe : script2 file or script1 file | script2 But so far I have not found how to handle that in the code in julia. So if someone knows how to that, his help would be highly appreciated. Thanks, Stephane
[julia-users] Re: Complex infinity
And here are additional unfortunate behaviors with complex arithmetic as currently implemented. First, dividing nonzero by zero should give an infinite result. It does for real, but not complex: julia 1/0 Inf julia 1/(0+0*im) # Should be some form of infinity NaN + NaN*im Second: Dividing by infinity (expect inf/inf) should give 0, but this is inconsistent: julia 1/Inf 0.0 julia 1/(Inf*im) 0.0 - 0.0im julia 1/(Inf+Inf*im) # should be complex zero NaN + NaN*im On Saturday, January 10, 2015 at 8:55:09 AM UTC-5, Ed Scheinerman wrote: Is there a way to have a single complex infinity? This may come at the cost of computational efficiency I suppose, but I can think of situations where all of the following give the same result: julia (1+1im)/0 Inf + Inf*im julia 1im/0 NaN + Inf*im julia 1/0 + im Inf + 1.0im It would be nice (sometimes) if these were all the same ComplexInf, say. Perhaps there's an extended complex numbers module for this sort of work?
Re: [julia-users] macros using global variables problem
julia macro nb(f, args...) arg1 = map(x-:($(esc(x))), args) :($f($(arg1...))) end julia @nb print arr [0.0,0.020107, ... If you haven't used it already, I would suggest to look at macroexpand to see the expression resulting from each macro (for example, look at why the previous version didn't work). julia macroexpand( :(@nb print arr) ) On Wed, Jan 14, 2015 at 8:32 PM, yi lu zhiwudazhanjiang...@gmail.com wrote: Well, I don't get it very clearly. I learnt that 'esc' changes variable names of a local variable in the macro. But I want to reference the global variable out of the macro. I have little idea of Lisp macros, so I think I still cannot handle this. Would you please add more details? Yi On Wed, Jan 14, 2015 at 11:37 PM, Isaiah Norton isaiah.nor...@gmail.com wrote: You need to use 'esc' -- see the hygiene part of the metaprog section in the manual. On Jan 14, 2015 8:56 AM, yi lu zhiwudazhanjiang...@gmail.com wrote: Hi, I am able to write a simple macro to drop brackets. https://gist.github.com/eccstartup/36637d96355bd5ca8188 But there is some problem with this. You can see the @nobrace macro that drop brackets of functions. For example: ``` @nobrace map (x-x^2-1) 1:0.01:2 ``` get a list of Float numbers. This is fine. However, in the macro, we cannot see global variables. For example: ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 print(arr) ``` will print the arr list, but ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 @nobrace print arr ``` will report arr not found. Is there a remedy? Yours, Yi
Re: [julia-users] help piping julia script in shell
isaiah@titan:/tmp$ cat t3.jl x = readline(STDIN) println(input was: , x) isaiah@titan:/tmp$ echo hello | julia t3.jl input was: hello On Wed, Jan 14, 2015 at 5:19 AM, lobreaux@gmail.com wrote: Hi, I have written different scripts in julia for which the input is so far a file provided as an argument. The output is printed on stdout. I would like to be able to use them with files as input or to pipe them in unix shell so the output of a script is taken as input by the next script in the pipe : script2 file or script1 file | script2 But so far I have not found how to handle that in the code in julia. So if someone knows how to that, his help would be highly appreciated. Thanks, Stephane
Re: [julia-users] The dark side of types
I already fall in those two forms of troubles (double definition and double
inclusion of the file where the type is defined) so I'm aware of it. As
much as I can tell with grepping, that is not occurring now.
Maybe a third (unknown to me) form of this type of issue?
quarta-feira, 14 de Janeiro de 2015 às 14:41:56 UTC, Keno Fischer escreveu:
Are you maybe accidentally defining cdCanvas twice or in two different
modules?
On Wed, Jan 14, 2015 at 3:40 PM, J Luis jmf...@gmail.com javascript:
wrote:
BTW, if that matters, 'ctgc' is a global variable.
quarta-feira, 14 de Janeiro de 2015 às 14:37:05 UTC, J Luis escreveu:
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas} @0x
t = Ptr{cdCanvas} @0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas} @0x22c6d6c0
which shows that type has not changed after the attribution and that it
has the correct return type of cdCreateCanvas().
That is why I initialized the ctgc type with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015 às 13:39:21 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 05:32 -0800, J Luis a écrit :
Hi,
I have had quite some head-aches with types (converted from C
structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t = cdCreateCanvas(cdContextIup(), IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
cdActivate(ctgc.iup_canvas);
the last line in the chunk above errors with
ERROR: `cdActivate` has no method matching
cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:125
in cdtest at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:92
So `t` and `ctgc.iup_canvas` are actually two different entities
(although their pointers are ofc the same as I can see if I @show
them)?
Well, you need to show us more details, e.g. tell us what
cdCreateCanvas() does, and what type it returns. The pointers might
hold
the same address, but they still may be of different types. @show
should
make this visible, but without the output we cannot check.
Regards
Re: [julia-users] Does TypeCheck specify which methods failed ?
Hi, Yes, the method signatures should print out between the call the checkreturntypes and the The total number... line. Currently, it often prints out a lot of unnecessary new lines, so you may need to scroll up. If you don't see that output at all, please file an issue on the TypeCheck.jl github repo. (Sorry for not responding more promptly.) -- Leah On Thu Jan 08 2015 at 4:00:44 AM lapeyre.math1...@gmail.com wrote: I see this when I use TypeCheck: checkreturntypes(ModuleName) blah blah The total number of failed methods in ModuleName is 2 But I can't see which methods failed. Am I missing something ? --John
Re: [julia-users] The dark side of types
Le mercredi 14 janvier 2015 à 06:54 -0800, J Luis a écrit :
I already fall in those two forms of troubles (double definition and
double inclusion of the file where the type is defined) so I'm aware
of it. As much as I can tell with grepping, that is not occurring
now.
Maybe a third (unknown to me) form of this type of issue?
Would you be able to create a reproducible example?
Regards
quarta-feira, 14 de Janeiro de 2015 às 14:41:56 UTC, Keno Fischer
escreveu:
Are you maybe accidentally defining cdCanvas twice or in two
different modules?
On Wed, Jan 14, 2015 at 3:40 PM, J Luis jmf...@gmail.com
wrote:
BTW, if that matters, 'ctgc' is a global variable.
quarta-feira, 14 de Janeiro de 2015 às 14:37:05 UTC, J
Luis escreveu:
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas}
@0x
t = Ptr{cdCanvas} @0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas}
@0x22c6d6c0
which shows that type has not changed after
the attribution and that it has the correct
return type of cdCreateCanvas().
That is why I initialized the ctgc type with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015 às
13:39:21 UTC, Milan Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 05:32
-0800, J Luis a écrit :
Hi,
I have had quite some head-aches
with types (converted from C structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t =
cdCreateCanvas(cdContextIup(),
IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
cdActivate(ctgc.iup_canvas);
the last line in the chunk above
errors with
ERROR: `cdActivate` has no method
matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits
\IUP.jl\examples\cdtest_.jl:125
in cdtest at C:\programs\Gits
\IUP.jl\examples\cdtest_.jl:92
So `t` and `ctgc.iup_canvas` are
actually two different entities
(although their pointers are ofc the
same as I can see if I @show
them)?
Well, you need to show us more
details, e.g. tell us what
cdCreateCanvas() does, and what
Re: [julia-users] macros using global variables problem
You need to use 'esc' -- see the hygiene part of the metaprog section in the manual. On Jan 14, 2015 8:56 AM, yi lu zhiwudazhanjiang...@gmail.com wrote: Hi, I am able to write a simple macro to drop brackets. https://gist.github.com/eccstartup/36637d96355bd5ca8188 But there is some problem with this. You can see the @nobrace macro that drop brackets of functions. For example: ``` @nobrace map (x-x^2-1) 1:0.01:2 ``` get a list of Float numbers. This is fine. However, in the macro, we cannot see global variables. For example: ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 print(arr) ``` will print the arr list, but ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 @nobrace print arr ``` will report arr not found. Is there a remedy? Yours, Yi
Re: [julia-users] The dark side of types
Well, I can make the current (failing) code available in the IUP repo but
to run it implies installing the IUP lib, and IUP.jl which probably no one
tested in other than Windows.
quarta-feira, 14 de Janeiro de 2015 às 15:30:20 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 06:54 -0800, J Luis a écrit :
I already fall in those two forms of troubles (double definition and
double inclusion of the file where the type is defined) so I'm aware
of it. As much as I can tell with grepping, that is not occurring
now.
Maybe a third (unknown to me) form of this type of issue?
Would you be able to create a reproducible example?
Regards
quarta-feira, 14 de Janeiro de 2015 às 14:41:56 UTC, Keno Fischer
escreveu:
Are you maybe accidentally defining cdCanvas twice or in two
different modules?
On Wed, Jan 14, 2015 at 3:40 PM, J Luis jmf...@gmail.com
wrote:
BTW, if that matters, 'ctgc' is a global variable.
quarta-feira, 14 de Janeiro de 2015 às 14:37:05 UTC, J
Luis escreveu:
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas}
@0x
t = Ptr{cdCanvas} @0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas}
@0x22c6d6c0
which shows that type has not changed after
the attribution and that it has the correct
return type of cdCreateCanvas().
That is why I initialized the ctgc type with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015 às
13:39:21 UTC, Milan Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 05:32
-0800, J Luis a écrit :
Hi,
I have had quite some head-aches
with types (converted from C structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t =
cdCreateCanvas(cdContextIup(),
IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
cdActivate(ctgc.iup_canvas);
the last line in the chunk above
errors with
ERROR: `cdActivate` has no method
matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits
\IUP.jl\examples\cdtest_.jl:125
in cdtest at C:\programs\Gits
\IUP.jl\examples\cdtest_.jl:92
So `t` and `ctgc.iup_canvas` are
Re: [julia-users] The dark side of types
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas} @0x
t = Ptr{cdCanvas} @0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas} @0x22c6d6c0
which shows that type has not changed after the attribution and that it
has the correct return type of cdCreateCanvas().
That is why I initialized the ctgc type with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015 às 13:39:21 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 05:32 -0800, J Luis a écrit :
Hi,
I have had quite some head-aches with types (converted from C structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t = cdCreateCanvas(cdContextIup(), IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
cdActivate(ctgc.iup_canvas);
the last line in the chunk above errors with
ERROR: `cdActivate` has no method matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:125
in cdtest at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:92
So `t` and `ctgc.iup_canvas` are actually two different entities
(although their pointers are ofc the same as I can see if I @show
them)?
Well, you need to show us more details, e.g. tell us what
cdCreateCanvas() does, and what type it returns. The pointers might hold
the same address, but they still may be of different types. @show should
make this visible, but without the output we cannot check.
Regards
Re: [julia-users] should I use types
On Jan 14, 2015, at 6:02 , Simon Danisch sdani...@gmail.com wrote:
You could in addition use ImmutableArrays:
immutable Packet{T}
ID::{T}
position::Vector3{T}
direction::Vector3{T}
energy::{T}
time::{T}
end
Which makes Packet a bitstype, with efficient memory layout.
Thanks for the pointer to Vector3.
This memory layout is efficient in the sense that there is no memory allocation
to create a new Packet. However, if there are loops over multiple Packets, then
these would most likely not be SIMD vectorized, whereas they migh if you use
separate arrays for each packet element.
-erik
If you need to mutate these, there are actually ways, when the Packets are
stored in an array. I'm implementing FixedSizeArrays at the moment, which
would have this feature. Otherwise, you need to replace the whole struct in
the array, which can be reasonable, considering the benefits.
Other benefit? If you want to Visualize this in OpenGL, it should be fairly
easy to upload, as it has a dense memory layout =) (With T= Float32, you
wouldn't even need conversions)
Am Mittwoch, 14. Januar 2015 05:34:55 UTC+1 schrieb tugul...@gmail.com:
I am writing a monte carlo radiation transport code (for applications in
astrophysics), where I follow the temporal and spacial evolution of millions
of whats called monte-carlo packets. And I am wondering whether if I should
use the Julia's type system, if so how should I implement it and also if
there is any performance loss/gain.
Let's say I define a type like following (based on this example tutorial):
type Packet{T}
ID::{T}
position::Vector{T}
direction::Vector{T}
energy::{T}
time::{T}
end
obviously this could make the code much more easier to read than a version
with all information represented in separate arrays. But beside this
elegance, is there anything else I should know about types? when I apply this
to millions of objects will there be any effect to the performance?
thanks,
--
Erik Schnetter schnet...@gmail.com
http://www.perimeterinstitute.ca/personal/eschnetter/
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu/.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [julia-users] The dark side of types
Are you maybe accidentally defining cdCanvas twice or in two different
modules?
On Wed, Jan 14, 2015 at 3:40 PM, J Luis jmfl...@gmail.com wrote:
BTW, if that matters, 'ctgc' is a global variable.
quarta-feira, 14 de Janeiro de 2015 às 14:37:05 UTC, J Luis escreveu:
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas} @0x
t = Ptr{cdCanvas} @0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas} @0x22c6d6c0
which shows that type has not changed after the attribution and that it
has the correct return type of cdCreateCanvas().
That is why I initialized the ctgc type with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015 às 13:39:21 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 05:32 -0800, J Luis a écrit :
Hi,
I have had quite some head-aches with types (converted from C structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t = cdCreateCanvas(cdContextIup(), IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
cdActivate(ctgc.iup_canvas);
the last line in the chunk above errors with
ERROR: `cdActivate` has no method matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:125
in cdtest at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:92
So `t` and `ctgc.iup_canvas` are actually two different entities
(although their pointers are ofc the same as I can see if I @show
them)?
Well, you need to show us more details, e.g. tell us what
cdCreateCanvas() does, and what type it returns. The pointers might hold
the same address, but they still may be of different types. @show should
make this visible, but without the output we cannot check.
Regards
[julia-users] rfft: Lack of type annotations causes major allocation overhead
Hi all,
In the code below I define two functions, f1 and f2, that take a
three-dimensional array of Float64, computes the real FFT (rfft) and loops
once over the computed values of the rfft. In f1, a lot of time is spent in
the simple for loop, and many, many bytes are allocated. In f2, very little
time is spent in the for loop, and no bytes are allocated, as would be
expected. The only difference between the two functions is X = rfft(x) in
f1 and X = rfft(x) :: Array{Complex{Float64}, 3} in f2. For both
functions, typeof(X) says that X is an Array{Complex{Float64}, 3}, so the
extra type annotation in f2 should not be necessary.
I encountered this problem in Julia version 0.3.6 and it persists in
version 0.4.0-dev+2666. In 0.4.0 the macro @code_warntype can be used to
reveal that X is of type ANY in f1 but Array{Complex{Float64}, 3} in f2.
This seems to contradict the output of typeof(X) and is very confusing to
me.
Cheers,
Emil
### Code
function f1(x :: Array{Float64, 3})
@time X = rfft(x)
println(typeof(X) = $(typeof(X)))
@time for i = 1 : length(X)
X[i] *= X[i]
end
X
end
function f2(x :: Array{Float64, 3})
@time X = rfft(x) :: Array{Complex{Float64}, 3}
println(typeof(X) = $(typeof(X)))
@time for i = 1 : length(X)
X[i] *= X[i]
end
X
end
println(Compiling...)
f1(rand(2,2,2))
f2(rand(2,2,2))
println(f1...)
f1(rand(128,128,128))
println(f2...)
f2(rand(128,128,128))
@code_warntype f1(rand(2,2,2))
@code_warntype f2(rand(2,2,2))
### Output
Compiling...
elapsed time: 0.165980813 seconds (5783476 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.008426071 seconds (319840 bytes allocated)
elapsed time: 9.8616e-5 seconds (3560 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 6.28e-7 seconds (0 bytes allocated)
f1...
elapsed time: 0.022922817 seconds (17042840 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.419889359 seconds (144836816 bytes allocated, 16.67% gc
time)
f2...
elapsed time: 0.023057751 seconds (17042840 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.002572673 seconds (0 bytes allocated)
[output of @code_warntype is omitted]
[julia-users] Moving a point to constraint
Hi, I am very new to Julia Programming. Is there a package/easy way to project a point onto a constraint line/plane, or at least calculate the distance(maybe euclidean distance) between the point and constraint plane/line and move the point later on by adding the distance(later changed to vector) to the point?
[julia-users] module PyPlot won't initialize on julia 0.3.5
I'm new to julia, trying to get PyPlot working. Eventually I hope to see graphics in iJulia, but the GUI is not needed to reproduce the problem detailed below. At the command line, saying julia reveals the header logo, including relevant version info: Version 0.3.5 (2015-01-08 22:33 UTC) Official http://julialang.org release x86_64-linux-gnu Then here is a transcript of my one-command interactive session: julia using PyPlot Warning: error initializing module PyPlot: PyCall.PyError(msg=:PyImport_ImportModule, T=PyCall.PyObject(o=0x93e401e0), val=PyCall.PyObject(o=0x9131a1b8), traceback=PyCall.PyObject(o=0x91319fc8)) At this point I'm lost. Any suggestions? Searching this archive and others suggested another command: julia Pkg.test(PyCall) INFO: Testing PyCall INFO: PyCall tests passed INFO: No packages to install, update or remove My system is Ubuntu 14.04.1 LTS. The Ubuntu-supplied package python-matplotlib is installed; so are ipython, ipython-notebook, python-pip. Inside julia, I have used Pkg.add(x) with each x in Winston, Gadfly, PyPlot, and IJulia. I have another Ubuntu box on which all this works, but apparently I was too casual about taking notes on my previous installation to be able to succeed with a second one. Suggestions would be most warmly welcomed -- thanks!
[julia-users] help piping julia script in shell
Hi, I have written different scripts in julia for which the input is so far a file provided as an argument. The output is printed on stdout. I would like to be able to use them with files as input or to pipe them in unix shell so the output of a script is taken as input by the next script in the pipe : script2 file or script1 file | script2 But so far I have not found how to handle that in the code in julia. So if someone knows how to that, his help would be highly appreciated. Thanks, Stephane
Re: [julia-users] rfft: Lack of type annotations causes major allocation overhead
There appears to be a problem with rfft.
julia @code_typed rfft(randn(10))
1-element Array{Any,1}:
:($(Expr(:lambda, Any[:X],
Any[Any[],Any[Any[:X,Array{Float64,1},0]],Any[]], :(begin # fftw.jl, line
639:
return rfft(X::Array{Float64,1},$(Expr(:new, UnitRange{Int64}, 1,
:(((top(getfield))(Intrinsics,:select_value))((top(sle_int))(1,1)::Bool,1,(top(box))(Int64,(top(sub_int))(1,1)))::Int64
::Any
end::Any
Could you file an issue?
2015-01-14 2:39 GMT-05:00 emilhedev...@gmail.com:
Hi all,
In the code below I define two functions, f1 and f2, that take a
three-dimensional array of Float64, computes the real FFT (rfft) and loops
once over the computed values of the rfft. In f1, a lot of time is spent in
the simple for loop, and many, many bytes are allocated. In f2, very little
time is spent in the for loop, and no bytes are allocated, as would be
expected. The only difference between the two functions is X = rfft(x)
in f1 and X = rfft(x) :: Array{Complex{Float64}, 3} in f2. For both
functions, typeof(X) says that X is an Array{Complex{Float64}, 3}, so the
extra type annotation in f2 should not be necessary.
I encountered this problem in Julia version 0.3.6 and it persists in
version 0.4.0-dev+2666. In 0.4.0 the macro @code_warntype can be used to
reveal that X is of type ANY in f1 but Array{Complex{Float64}, 3} in f2.
This seems to contradict the output of typeof(X) and is very confusing to
me.
Cheers,
Emil
### Code
function f1(x :: Array{Float64, 3})
@time X = rfft(x)
println(typeof(X) = $(typeof(X)))
@time for i = 1 : length(X)
X[i] *= X[i]
end
X
end
function f2(x :: Array{Float64, 3})
@time X = rfft(x) :: Array{Complex{Float64}, 3}
println(typeof(X) = $(typeof(X)))
@time for i = 1 : length(X)
X[i] *= X[i]
end
X
end
println(Compiling...)
f1(rand(2,2,2))
f2(rand(2,2,2))
println(f1...)
f1(rand(128,128,128))
println(f2...)
f2(rand(128,128,128))
@code_warntype f1(rand(2,2,2))
@code_warntype f2(rand(2,2,2))
### Output
Compiling...
elapsed time: 0.165980813 seconds (5783476 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.008426071 seconds (319840 bytes allocated)
elapsed time: 9.8616e-5 seconds (3560 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 6.28e-7 seconds (0 bytes allocated)
f1...
elapsed time: 0.022922817 seconds (17042840 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.419889359 seconds (144836816 bytes allocated, 16.67% gc
time)
f2...
elapsed time: 0.023057751 seconds (17042840 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.002572673 seconds (0 bytes allocated)
[output of @code_warntype is omitted]
Re: [julia-users] The dark side of types
BTW, if that matters, 'ctgc' is a global variable.
quarta-feira, 14 de Janeiro de 2015 às 14:37:05 UTC, J Luis escreveu:
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas} @0x
t = Ptr{cdCanvas} @0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas} @0x22c6d6c0
which shows that type has not changed after the attribution and that it
has the correct return type of cdCreateCanvas().
That is why I initialized the ctgc type with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015 às 13:39:21 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 05:32 -0800, J Luis a écrit :
Hi,
I have had quite some head-aches with types (converted from C structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t = cdCreateCanvas(cdContextIup(), IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
cdActivate(ctgc.iup_canvas);
the last line in the chunk above errors with
ERROR: `cdActivate` has no method matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:125
in cdtest at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:92
So `t` and `ctgc.iup_canvas` are actually two different entities
(although their pointers are ofc the same as I can see if I @show
them)?
Well, you need to show us more details, e.g. tell us what
cdCreateCanvas() does, and what type it returns. The pointers might hold
the same address, but they still may be of different types. @show should
make this visible, but without the output we cannot check.
Regards
Re: [julia-users] The dark side of types
Le mercredi 14 janvier 2015 à 07:42 -0800, J Luis a écrit :
Well, I can make the current (failing) code available in the IUP repo
but to run it implies installing the IUP lib, and IUP.jl which
probably no one tested in other than Windows.
But the problem does not seem to involve IUP (or via a nasty memory
corruption bug). You should be able to reproduce it with a short
artificial example.
Regards
quarta-feira, 14 de Janeiro de 2015 às 15:30:20 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 06:54 -0800, J Luis a écrit :
I already fall in those two forms of troubles (double definition
and
double inclusion of the file where the type is defined) so I'm
aware
of it. As much as I can tell with grepping, that is not occurring
now.
Maybe a third (unknown to me) form of this type of issue?
Would you be able to create a reproducible example?
Regards
quarta-feira, 14 de Janeiro de 2015 às 14:41:56 UTC, Keno Fischer
escreveu:
Are you maybe accidentally defining cdCanvas twice or in
two
different modules?
On Wed, Jan 14, 2015 at 3:40 PM, J Luis jmf...@gmail.com
wrote:
BTW, if that matters, 'ctgc' is a global variable.
quarta-feira, 14 de Janeiro de 2015 às 14:37:05
UTC, J
Luis escreveu:
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas}
@0x
t = Ptr{cdCanvas} @0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas}
@0x22c6d6c0
which shows that type has not changed after
the attribution and that it has the
correct
return type of cdCreateCanvas().
That is why I initialized the ctgc type
with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015 às
13:39:21 UTC, Milan Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 05:32
-0800, J Luis a écrit :
Hi,
I have had quite some head-aches
with types (converted from C
structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t =
cdCreateCanvas(cdContextIup(),
IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
Re: [julia-users] The dark side of types
Yes, an synthetic example would be nice, but I strongly suspect that if I
was able to create one than it would because I had found the problem.
quarta-feira, 14 de Janeiro de 2015 às 16:15:20 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 07:42 -0800, J Luis a écrit :
Well, I can make the current (failing) code available in the IUP repo
but to run it implies installing the IUP lib, and IUP.jl which
probably no one tested in other than Windows.
But the problem does not seem to involve IUP (or via a nasty memory
corruption bug). You should be able to reproduce it with a short
artificial example.
Regards
quarta-feira, 14 de Janeiro de 2015 às 15:30:20 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 06:54 -0800, J Luis a écrit :
I already fall in those two forms of troubles (double
definition and
double inclusion of the file where the type is defined) so I'm
aware
of it. As much as I can tell with grepping, that is not
occurring
now.
Maybe a third (unknown to me) form of this type of issue?
Would you be able to create a reproducible example?
Regards
quarta-feira, 14 de Janeiro de 2015 às 14:41:56 UTC, Keno
Fischer
escreveu:
Are you maybe accidentally defining cdCanvas twice or
in two
different modules?
On Wed, Jan 14, 2015 at 3:40 PM, J Luis
jmf...@gmail.com
wrote:
BTW, if that matters, 'ctgc' is a global
variable.
quarta-feira, 14 de Janeiro de 2015 às
14:37:05 UTC, J
Luis escreveu:
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas}
@0x
t = Ptr{cdCanvas} @0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas}
@0x22c6d6c0
which shows that type has not changed
after
the attribution and that it has the
correct
return type of cdCreateCanvas().
That is why I initialized the ctgc
type with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015 às
13:39:21 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à
05:32
-0800, J Luis a écrit :
Hi,
I have had quite some
head-aches
with types (converted from C
structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
[julia-users] ANN: CUDArt and CUFFT
Due to an oversight on my part, I never made official packages out of CUDArt and CUFFT. That has now been rectified. As you might guess from the names, these package are part of julia's growing collection of GPU-computing resources. https://github.com/JuliaGPU/CUDArt.jl https://github.com/JuliaGPU/CUFFT.jl CUDArt has been recently updated in several ways, but I have not yet looked at integrating/merging with Tim Besard's really cool recent work. Best, --Tim
Re: [julia-users] readdir returns inconsistent types
On Tuesday, January 13, 2015 at 10:38:23 PM UTC-5, ele...@gmail.com wrote:
Probably right if the mutations for adding extensions etc are not
conveniently available with Vector{uint8}.
It would certainly be possible to define these operations, e.g.
concatenation of a string with a bytevector. But even then I think a
bytevector would be the wrong choice. When I look at a filename, I don't
want to see UInt8[0x66,0x6f,0x6f,0x2e,0x74,0x78,0x74], I want to see
foo.txt. And by returning a (potentially invalid) UTF8String, that's
what I get in the *vast* majority of cases—non-UTF8 filenames seem to be
pretty rare nowadays even on Unix systems (e.g. many GNU/Linux systems have
defaulted to displaying filenames as UTF-8 for a decade now). Even for a
non-UTF8 filename where I get mojibake, in most cases it will be in some
other 1-byte superset of ASCII, so the displayed results will still be
somewhat useful: I'd much rather see Foo££££.txt than a list of
byte values.
I guess a third alternative would be to define an UnknownEncodingString
type that stores an array of bytes and displays by default as UTF-8 (or
even tries to guess the encoding) and supports concatenation and a few
other carefully chosen operations, but not iteration over codepoints and
other things that can't be implemented without knowing the encoding. The
idea being to prevent programmers from trying to perform operations on
filenames that may fail on strings with unknown encodings. But this seems
like it would be a lot of hassle for little benefit these days.
Re: [julia-users] rfft: Lack of type annotations causes major allocation overhead
Done in https://github.com/JuliaLang/julia/issues/9772
2015-01-14 10:19 GMT-05:00 Andreas Noack andreasnoackjen...@gmail.com:
There appears to be a problem with rfft.
julia @code_typed rfft(randn(10))
1-element Array{Any,1}:
:($(Expr(:lambda, Any[:X],
Any[Any[],Any[Any[:X,Array{Float64,1},0]],Any[]], :(begin # fftw.jl, line
639:
return rfft(X::Array{Float64,1},$(Expr(:new, UnitRange{Int64}, 1,
:(((top(getfield))(Intrinsics,:select_value))((top(sle_int))(1,1)::Bool,1,(top(box))(Int64,(top(sub_int))(1,1)))::Int64
::Any
end::Any
Could you file an issue?
2015-01-14 2:39 GMT-05:00 emilhedev...@gmail.com:
Hi all,
In the code below I define two functions, f1 and f2, that take a
three-dimensional array of Float64, computes the real FFT (rfft) and loops
once over the computed values of the rfft. In f1, a lot of time is spent in
the simple for loop, and many, many bytes are allocated. In f2, very little
time is spent in the for loop, and no bytes are allocated, as would be
expected. The only difference between the two functions is X = rfft(x)
in f1 and X = rfft(x) :: Array{Complex{Float64}, 3} in f2. For both
functions, typeof(X) says that X is an Array{Complex{Float64}, 3}, so the
extra type annotation in f2 should not be necessary.
I encountered this problem in Julia version 0.3.6 and it persists in
version 0.4.0-dev+2666. In 0.4.0 the macro @code_warntype can be used to
reveal that X is of type ANY in f1 but Array{Complex{Float64}, 3} in f2.
This seems to contradict the output of typeof(X) and is very confusing to
me.
Cheers,
Emil
### Code
function f1(x :: Array{Float64, 3})
@time X = rfft(x)
println(typeof(X) = $(typeof(X)))
@time for i = 1 : length(X)
X[i] *= X[i]
end
X
end
function f2(x :: Array{Float64, 3})
@time X = rfft(x) :: Array{Complex{Float64}, 3}
println(typeof(X) = $(typeof(X)))
@time for i = 1 : length(X)
X[i] *= X[i]
end
X
end
println(Compiling...)
f1(rand(2,2,2))
f2(rand(2,2,2))
println(f1...)
f1(rand(128,128,128))
println(f2...)
f2(rand(128,128,128))
@code_warntype f1(rand(2,2,2))
@code_warntype f2(rand(2,2,2))
### Output
Compiling...
elapsed time: 0.165980813 seconds (5783476 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.008426071 seconds (319840 bytes allocated)
elapsed time: 9.8616e-5 seconds (3560 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 6.28e-7 seconds (0 bytes allocated)
f1...
elapsed time: 0.022922817 seconds (17042840 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.419889359 seconds (144836816 bytes allocated, 16.67% gc
time)
f2...
elapsed time: 0.023057751 seconds (17042840 bytes allocated)
typeof(X) = Array{Complex{Float64},3}
elapsed time: 0.002572673 seconds (0 bytes allocated)
[output of @code_warntype is omitted]
[julia-users] Re: New method should respect previous syntax?
Thank you, Steven. Your explanations are clear and helpful. But then I don't know how to obtain the behavior I want. A) I don't want to completely replace Base's signif because I still want access to Julia's methods. For instance, my method only works in base 10, so I don't want to lose Julia's ability to calculate signif() in other bases. When I personally call signif (e.g. at the REPL), I want my new method to be dispatched for specific-enough input types. If I do signif(1.2,2) I want to get 1.2. If signif(1.2,2,2), I want 1.0 (base 2). Even if at some point I want to invoke Julia's method on base 10, I still want to be able to do signif(1.2,2,10) and get 1.2002 instead of my method's 1.2. That is easy to achieve, because Julia's methods are: signif(x, digits::Integer) signif(x, digits::Integer, base::Integer) which do not specify the type of x, so after import Base.signif, as soon as I add a method like function signif(x::Float64, digits::Integer) if x is a Float64 my method will be chosen, because it is more type-specific. B) But neither do I want to affect all modules calling signif, because then any package that calls signif would alter its behavior. This means that my method should be invisible to packages. [If I understand you well, both defining function Base.signif, or alternatively doing import Base.signif before defining function signif, both will affect all modules calling signif, no?] Summarising: my REPL (or my Main module or whatever module I want) should see Julia's methods plus my own; but installed packages should only see Julia's methods. P.S.1 Choosing a different function name, like function felipesignif(), would work, because no package will call felipesignif(), but it is not something I like too much, because my function does essentially the same thing as Julia's, only with more care about roundoff errors (at the cost of some speed, which is not needed for my intended purposes). The natural thing is to use the same function name, possibly with an optional third input argument options to control its behavior regarding dealing with roundoff errors. P.S.2 Of course my question was a somewhat general one regarding best practices, rather than this specific signif() issue. Julia's design encourages adding new methods to existing functions. Is nobody else worried that installed packages can be affected by new methods? On Tuesday, January 13, 2015 at 8:30:21 PM UTC+1, Steven G. Johnson wrote: In any module, if you define function signif, it will completely replace Base's signif (for *all* argument types), but only within that module; other modules will not be affected. Defining things in the REPL is equivalent to defining them within the module Main. If, instead, you want to add a new method signature to the Base.signif function, you should define function Base.signif, or alternatively import Base.signif before defining function signif. This will affect all modules calling signif.
[julia-users] Re: working with dense parallel matrices
These capabilities are being actively developed. Beyond the parallel section of the Julia manual, also see: https://github.com/JuliaParallel/MPI.jl/ -viral On Saturday, January 10, 2015 at 1:29:11 AM UTC+5:30, Francis Poulin wrote: Hello, I am very new to Julia and trying to learn how to do some very basic linear algebra in parallel. As a simple example I wanted to be able to define a dense matrix in parallel and then multiply it to a vector. I have seen how this works in mpi4py at the following tutorial http://mpi4py.scipy.org/docs/usrman/tutorial.html and am wondering how this can be accomplished in julia. I did find a number of posts that discussed how to do this with sparse matrices, which seems more complicated than it should be. I did read about distributed arrays and that seems like it should be able to do something along these lines but I didn't seen any examples and am unsure of the syntax. Is this the best direction to go or is there something else I should be looking into? I am sorry for asking such a simple question but would appreciate any assistance. Cheers, Francis
[julia-users] Re: Julia cannot compute factorial(21) while Octave can
I am guessing, that like Matlab, octave uses doubles to represent integers, and hence you can go a bit farther than with integers. That should be the same as factorial(21.0) in julia. Of course, you can also use BigInt and such, which has already been discussed here. -viral On Tuesday, January 13, 2015 at 8:40:06 AM UTC+5:30, Carlos Baptista wrote: I understand that factorial(21) is quite a large number and therefore an OverflowError is perfectly understandable. However, with Octave I can go up to factorial(170) (if I go higher I receive Inf). Is there a way to go beyond factorial(20) in Julia?
Re: [julia-users] The dark side of types
What I found is if, for simplification, I restrict the type to (that is
without type assignment)
type tCTC_l
iup_canvas
end
than it works. But if I change it to
type tCTC_l
iup_canvas::Ptr{cdCanvas}
end
it errors again. For curiosity I tried also
type tCTC_l
iup_canvas::Int64
end
and now
t = Ptr{cdCanvas} @0x21c3f4a0
ctgc_l.iup_canvas = 566490272
ERROR: `cdActivate` has no method matching cdActivate(::Int64)
that is, it converted the Ptr{cdCanvas} (the 't') to Int64, so it seams
that in the first instance it converted one Ptr{cdCanvas} to another
Ptr{cdCanvas} ending up with TWO declarations of the Ptr{cdCanvas}.
Does it make any sense?
quarta-feira, 14 de Janeiro de 2015 às 17:50:51 UTC, J Luis escreveu:
Yes, an synthetic example would be nice, but I strongly suspect that if I
was able to create one than it would because I had found the problem.
quarta-feira, 14 de Janeiro de 2015 às 16:15:20 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à 07:42 -0800, J Luis a écrit :
Well, I can make the current (failing) code available in the IUP repo
but to run it implies installing the IUP lib, and IUP.jl which
probably no one tested in other than Windows.
But the problem does not seem to involve IUP (or via a nasty memory
corruption bug). You should be able to reproduce it with a short
artificial example.
Regards
quarta-feira, 14 de Janeiro de 2015 às 15:30:20 UTC, Milan
Bouchet-Valat escreveu:
Le mercredi 14 janvier 2015 à 06:54 -0800, J Luis a écrit :
I already fall in those two forms of troubles (double
definition and
double inclusion of the file where the type is defined) so
I'm aware
of it. As much as I can tell with grepping, that is not
occurring
now.
Maybe a third (unknown to me) form of this type of issue?
Would you be able to create a reproducible example?
Regards
quarta-feira, 14 de Janeiro de 2015 às 14:41:56 UTC, Keno
Fischer
escreveu:
Are you maybe accidentally defining cdCanvas twice or
in two
different modules?
On Wed, Jan 14, 2015 at 3:40 PM, J Luis
jmf...@gmail.com
wrote:
BTW, if that matters, 'ctgc' is a global
variable.
quarta-feira, 14 de Janeiro de 2015 às
14:37:05 UTC, J
Luis escreveu:
Hi, thanks for looking into this.
If I make them show, as
@show ctgc.iup_canvas
ctgc.iup_canvas = t
@show t
@show ctgc.iup_canvas
it 'shows'
ctgc.iup_canvas = Ptr{cdCanvas}
@0x
t = Ptr{cdCanvas}
@0x22c6d6c0
ctgc.iup_canvas = Ptr{cdCanvas}
@0x22c6d6c0
which shows that type has not changed
after
the attribution and that it has the
correct
return type of cdCreateCanvas().
That is why I initialized the ctgc
type with
convert(Ptr{cdCanvas},0)
(see first member in my first post)
quarta-feira, 14 de Janeiro de 2015
às
13:39:21 UTC, Milan Bouchet-Valat
escreveu:
Le mercredi 14 janvier 2015 à
05:32
-0800, J Luis a écrit :
Hi,
I have had quite some
head-aches
with types (converted from C
structs)
but this one wins.
I have this type (from IUP)
type tCTC
[julia-users] How can I write a @map macro?
Hi, I want to write a macro which works as map function. It should work for these. ``` @map x-x+1 1:10 @map + 1:10 11:20 ``` I know it is just copying the argument list in the macro to the map function, but I get stuck. ``` macro map(f,args...) quote map($f, $args...) end end ``` won't work. ``` macro map(f,args...) quote map($f, $args[1:end]) end end ``` won't work either. What is the problem here? How can I get a correct @map macro? Best wishes, Yi
Re: [julia-users] exemplar package for 0.4-style documentation
On Tue, Jan 13 2015, Tom Short tshort.rli...@gmail.com wrote: If you want to try the Sims docs at the REPL, you'll need to checkout that package and enter using Sims, Sims.Lib, Lexicon. Then you can do ?Resistor or ?Capacitor. Note that the question mark doesn't work in ESS. Is that an intrinsic limitation of the documentation system/julia/ESS, or just something that has not been implemented yet? It would be very nice, since other languages (eg R) use ?function too and that works nicely in ESS so users are used to it. Best, Tamas
Re: [julia-users] How can I write a @map macro?
Using $(args...) should do the trick, I think. On 14 January 2015 at 09:20, yi lu zhiwudazhanjiang...@gmail.com wrote: Hi, I want to write a macro which works as map function. It should work for these. ``` @map x-x+1 1:10 @map + 1:10 11:20 ``` I know it is just copying the argument list in the macro to the map function, but I get stuck. ``` macro map(f,args...) quote map($f, $args...) end end ``` won't work. ``` macro map(f,args...) quote map($f, $args[1:end]) end end ``` won't work either. What is the problem here? How can I get a correct @map macro? Best wishes, Yi
Re: [julia-users] How can I write a @map macro?
@map + 1:10 11:20 failed :) On Wed, Jan 14, 2015 at 5:23 PM, Mike Innes mike.j.in...@gmail.com wrote: Using $(args...) should do the trick, I think. On 14 January 2015 at 09:20, yi lu zhiwudazhanjiang...@gmail.com wrote: Hi, I want to write a macro which works as map function. It should work for these. ``` @map x-x+1 1:10 @map + 1:10 11:20 ``` I know it is just copying the argument list in the macro to the map function, but I get stuck. ``` macro map(f,args...) quote map($f, $args...) end end ``` won't work. ``` macro map(f,args...) quote map($f, $args[1:end]) end end ``` won't work either. What is the problem here? How can I get a correct @map macro? Best wishes, Yi
Re: [julia-users] How can I write a @map macro?
I think that's because it's being parsed as @map (+1):10 11:20 If you're using operators on their own, it's a good idea to put them in parens: @map (+) 1:10 11:20 On 14 January 2015 at 09:36, yi lu zhiwudazhanjiang...@gmail.com wrote: @map + 1:10 11:20 failed :) On Wed, Jan 14, 2015 at 5:23 PM, Mike Innes mike.j.in...@gmail.com wrote: Using $(args...) should do the trick, I think. On 14 January 2015 at 09:20, yi lu zhiwudazhanjiang...@gmail.com wrote: Hi, I want to write a macro which works as map function. It should work for these. ``` @map x-x+1 1:10 @map + 1:10 11:20 ``` I know it is just copying the argument list in the macro to the map function, but I get stuck. ``` macro map(f,args...) quote map($f, $args...) end end ``` won't work. ``` macro map(f,args...) quote map($f, $args[1:end]) end end ``` won't work either. What is the problem here? How can I get a correct @map macro? Best wishes, Yi
Re: [julia-users] exemplar package for 0.4-style documentation
It just hasn't been implemented, yet. Lexicon complains with type BasicREPL has no field interface. I'm guessing that a simpler approach could be used in Lexicon, or it could be implemented in ESS (unfortunately, no ESS developers really use Julia). On Wed, Jan 14, 2015 at 4:23 AM, Tamas Papp tkp...@gmail.com wrote: On Tue, Jan 13 2015, Tom Short tshort.rli...@gmail.com wrote: If you want to try the Sims docs at the REPL, you'll need to checkout that package and enter using Sims, Sims.Lib, Lexicon. Then you can do ?Resistor or ?Capacitor. Note that the question mark doesn't work in ESS. Is that an intrinsic limitation of the documentation system/julia/ESS, or just something that has not been implemented yet? It would be very nice, since other languages (eg R) use ?function too and that works nicely in ESS so users are used to it. Best, Tamas
[julia-users] macros using global variables problem
Hi, I am able to write a simple macro to drop brackets. https://gist.github.com/eccstartup/36637d96355bd5ca8188 But there is some problem with this. You can see the @nobrace macro that drop brackets of functions. For example: ``` @nobrace map (x-x^2-1) 1:0.01:2 ``` get a list of Float numbers. This is fine. However, in the macro, we cannot see global variables. For example: ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 print(arr) ``` will print the arr list, but ``` arr = @nobrace map (x-x^2-1) 1:0.01:2 @nobrace print arr ``` will report arr not found. Is there a remedy? Yours, Yi
[julia-users] Help with using sublime iJulia
So I am trying the sublime IDE again after failing to resolve problems in Juno. So far I got julia installed and working, but it is a bit slower on running code than LightTable. I am thinking about switching but I have two concerns 1. Plotting in Gadfly does not work 2. Plotting speed is slow. Lets say I have code like this: using DataFrames using Gadfly plot(x=collect(1:100), y=sort(rand(100))) 日本 = ([1 2; 3 4]) job = DataFrame(ID = [1, 2, 3, 4,5], Color = [Red, Blue,Red, Green, Blue], Location = [US, US,CN, US,UK] ) println (日本) println(job) names = DataFrame(ID = [1, 2], Name = [John Doe, Jane Doe]) jobs = DataFrame(ID = [1, 2], Job = [Lawyer, Doctor]) full = join(names, jobs, on = :ID) println(full) I will output this in sublime text 3 when I run with CTRL+B: [1 2 3 4] 5x3 DataFrame | Row | ID | Color | Location | |-||-|--| | 1 | 1 | Red | US | | 2 | 2 | Blue | US | | 3 | 3 | Red | CN | | 4 | 4 | Green | US | | 5 | 5 | Blue | UK | 2x3 DataFrame | Row | ID | Name | Job | |-|||--| | 1 | 1 | John Doe | Lawyer | | 2 | 2 | Jane Doe | Doctor | [Finished in 26.4s] Note that it takes 26 seconds and no plot. Light table will be faster but have an error if I plot
Re: [julia-users] Size of Julia types
Hi Jan,
since mutable julia object require a type tag, they always require a pointer
and cannot be structurally inlined. The assertion would hold if both types
were declared `immutable`.
On Wed, Jan 14, 2015 at 11:22 AM, Jan Niklas Hasse jha...@gmail.com wrote:
Hi!
I'm new to Julia and was wondering why
type A
x::Ptr{Void}
y::Ptr{Void}
end
type B
x::A
end
assert(sizeof(A) == sizeof(B))
doesn't work while the C version
#include assert.h
struct A {
void* x;
void* y;
};
struct B {
A x;
};
int main() {
assert(sizeof(A) == sizeof(B));
}
does? This causes a segfault in my FreeType.jl wrapper.
Re: [julia-users] exemplar package for 0.4-style documentation
Just as a note regarding this new syntax for anyone reading: It’s still being experimented with in Docile/Lexicon, though so far I’ve found it much more enjoyable to use. Package load times aren’t affected nearly as much as with @doc since collection and parsing of docstrings only happens once a user queries the help system. If anyone has thoughts/ideas they’d like to discuss regarding these kind of things then please do head over to the issues list for either Docile https://github.com/MichaelHatherly/Docile.jl/issues or Lexicon https://github.com/MichaelHatherly/Lexicon.jl/issues. — Mike On Wednesday, 14 January 2015 00:06:44 UTC+2, tshort wrote: It's still a bit in flux as the old style is: @doc my docs... - myfun(x) = ... The new style is: my docs... myfun(x) = ... The new style is in Docile but not in v0.4-, yet. The documentation inside Docile is a good start. It uses the new style. Some other notable packages include: * https://github.com/johnmyleswhite/CSVReaders.jl * https://tshort.github.io/Sims.jl/ In Sims.jl, I used Mkdocs (mkdocs.org) along with Docile/Lexicon to create that documentation site. On Tue, Jan 13, 2015 at 4:59 PM, Douglas Bates dmb...@gmail.com javascript: wrote: I'm having difficulty navigating my way around documentation standards for v0.4-, and whether the Docile or Lexicon or Markdown packages are needed. What would be a good package to study to see how @doc, etc. should be used?
Re: [julia-users] Re: Later methods definition replaces the previous one?
There has been some talk about overloading `.` which could accommodate your suggestion. Have a look at https://github.com/JuliaLang/julia/issues/1974 On Tue, 2015-01-13 at 23:08, Ivan Ogasawara ivan.ogasaw...@gmail.com wrote: Hi, I am newbie yet, but maybe julia could have an operator to wrap a function call to specific type from specific module: ## module file module modA export TypeC, setx type TypeC x end function setx(c::TypeC, v::Any) c.x = v end end ## other file and on other file maybe we can call the setx like: objC.setx(v) and this would be a wrap to setx(objC, v). I know we can define a function into the type ... but this probably will down the performance and will go to different way for the multiple dispatch. PS:: again, sorry i'm a newbie julian :) Ivan Ogasawara El 13/01/2015 19:45, Mauro mauro...@runbox.com escribió: I would argue that this would be prohibited by the compiler as it could not distinguish between foo(x::Number) = 2 and foo(x::Float64) = 3 Yes it can: julia foo(x::Number)=1 foo (generic function with 1 method) julia foo(x::Float64)=2 foo (generic function with 2 methods) julia foo(5) 1 julia foo(5.) 2 In the example I gave, count was allowed to be exported from my two modules just by being defined by Base. Yet the two count's have different meanings from each other and from the Base.count. On the other hand steadystate() was not merged even though the end-result is the SAME: one would have two methods that work on different types of arguments and do different things. I don't think it is good practice to add unrelated methods to generic functions in Base. A guide-line could be to check whether your methods matches up with the help text, if so, add it to Base.count otherwise not. If not, either give it a different name or do not export it, so the user has to fully qualify it MyMod.count. This is just my opinion but I suspect at least some share it.
Re: [julia-users] The dark side of types
Le mercredi 14 janvier 2015 à 05:32 -0800, J Luis a écrit :
Hi,
I have had quite some head-aches with types (converted from C structs)
but this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t = cdCreateCanvas(cdContextIup(), IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
cdActivate(ctgc.iup_canvas);
the last line in the chunk above errors with
ERROR: `cdActivate` has no method matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:125
in cdtest at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:92
So `t` and `ctgc.iup_canvas` are actually two different entities
(although their pointers are ofc the same as I can see if I @show
them)?
Well, you need to show us more details, e.g. tell us what
cdCreateCanvas() does, and what type it returns. The pointers might hold
the same address, but they still may be of different types. @show should
make this visible, but without the output we cannot check.
Regards
[julia-users] Size of Julia types
Hi!
I'm new to Julia and was wondering why
type A
x::Ptr{Void}
y::Ptr{Void}
end
type B
x::A
end
assert(sizeof(A) == sizeof(B))
doesn't work while the C version
#include assert.h
struct A {
void* x;
void* y;
};
struct B {
A x;
};
int main() {
assert(sizeof(A) == sizeof(B));
}
does? This causes a segfault in my FreeType.jl wrapper.
Re: [julia-users] Size of Julia types
If you can, use
immutable B
x::A
end
The type version contains a reference to an A, not the entire A structure
itself. The C analog of what you were doing would be
struct B {
A* x;
};
which of course doesn't have the same size as A.
--Tim
On Wednesday, January 14, 2015 02:22:19 AM Jan Niklas Hasse wrote:
Hi!
I'm new to Julia and was wondering why
type A
x::Ptr{Void}
y::Ptr{Void}
end
type B
x::A
end
assert(sizeof(A) == sizeof(B))
doesn't work while the C version
#include assert.h
struct A {
void* x;
void* y;
};
struct B {
A x;
};
int main() {
assert(sizeof(A) == sizeof(B));
}
does? This causes a segfault in my FreeType.jl wrapper.
[julia-users] Re: should I use types
You could in addition use ImmutableArrays:
immutable Packet{T}
ID::{T}
position::Vector3{T}
direction::Vector3{T}
energy::{T}
time::{T}
end
Which makes Packet a bitstype, with efficient memory layout.
If you need to mutate these, there are actually ways, when the Packets are
stored in an array. I'm implementing FixedSizeArrays at the moment, which
would have this feature. Otherwise, you need to replace the whole struct in
the array, which can be reasonable, considering the benefits.
Other benefit? If you want to Visualize this in OpenGL, it should be fairly
easy to upload, as it has a dense memory layout =) (With T= Float32, you
wouldn't even need conversions)
Am Mittwoch, 14. Januar 2015 05:34:55 UTC+1 schrieb tugul...@gmail.com:
I am writing a monte carlo radiation transport code (for applications in
astrophysics), where I follow the temporal and spacial evolution of
millions of whats called monte-carlo packets. And I am wondering whether
if I should use the Julia's type system, if so how should I implement it
and also if there is any performance loss/gain.
Let's say I define a type like following (based on this example tutorial
http://forio.com/labs/julia-studio/tutorials/advanced/1/):
type Packet{T}
ID::{T}
position::Vector{T}
direction::Vector{T}
energy::{T}
time::{T}
end
obviously this could make the code much more easier to read than a version
with all information represented in separate arrays. But beside this
elegance, is there anything else I should know about types? when I apply
this to millions of objects will there be any effect to the performance?
thanks,
[julia-users] The dark side of types
Hi,
I have had quite some head-aches with types (converted from C structs) but
this one wins.
I have this type (from IUP)
type tCTC
iup_canvas::Ptr{cdCanvas}
w::Cint
h::Cint
...
which I initialize as
ctgc = tCTC(
convert(Ptr{cdCanvas},0),
int32(0), int32(0),
...
and now the mystery.
t = cdCreateCanvas(cdContextIup(), IupGetHandle(cnvMain))
ctgc.iup_canvas = t
cdActivate(t);
cdActivate(ctgc.iup_canvas);
the last line in the chunk above errors with
ERROR: `cdActivate` has no method matching cdActivate(::Ptr{cdCanvas})
in CDTestInit at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:125
in cdtest at C:\programs\Gits\IUP.jl\examples\cdtest_.jl:92
So `t` and `ctgc.iup_canvas` are actually two different entities (although
their pointers are ofc the same as I can see if I @show them)?
Re: [julia-users] Size of Julia types
2015-01-14 11:43 GMT+01:00 Tim Holy tim.h...@gmail.com:
If you can, use
immutable B
x::A
end
The type version contains a reference to an A, not the entire A structure
itself. The C analog of what you were doing would be
struct B {
A* x;
};
which of course doesn't have the same size as A.
--Tim
On Wednesday, January 14, 2015 02:22:19 AM Jan Niklas Hasse wrote:
Hi!
I'm new to Julia and was wondering why
type A
x::Ptr{Void}
y::Ptr{Void}
end
type B
x::A
end
assert(sizeof(A) == sizeof(B))
doesn't work while the C version
#include assert.h
struct A {
void* x;
void* y;
};
struct B {
A x;
};
int main() {
assert(sizeof(A) == sizeof(B));
}
does? This causes a segfault in my FreeType.jl wrapper.
I see. Thanks to you both :)
Now I got it working:
https://github.com/jhasse/FreeType.jl/commit/2297d9c2c93c27466920acba46f9983dac882635
Re: [julia-users] How can I write a @map macro?
Thanks Mike, this works. On Wed, Jan 14, 2015 at 5:40 PM, Mike Innes mike.j.in...@gmail.com wrote: I think that's because it's being parsed as @map (+1):10 11:20 If you're using operators on their own, it's a good idea to put them in parens: @map (+) 1:10 11:20 On 14 January 2015 at 09:36, yi lu zhiwudazhanjiang...@gmail.com wrote: @map + 1:10 11:20 failed :) On Wed, Jan 14, 2015 at 5:23 PM, Mike Innes mike.j.in...@gmail.com wrote: Using $(args...) should do the trick, I think. On 14 January 2015 at 09:20, yi lu zhiwudazhanjiang...@gmail.com wrote: Hi, I want to write a macro which works as map function. It should work for these. ``` @map x-x+1 1:10 @map + 1:10 11:20 ``` I know it is just copying the argument list in the macro to the map function, but I get stuck. ``` macro map(f,args...) quote map($f, $args...) end end ``` won't work. ``` macro map(f,args...) quote map($f, $args[1:end]) end end ``` won't work either. What is the problem here? How can I get a correct @map macro? Best wishes, Yi
