[julia-users] Re: String(Vector{UInt8}) Question

[joshbode]

OK, I understand now: they're continuation bytes for UTF-8 and can't appear 
in that context so they get stripped from the string representation.

On Wednesday, October 5, 2016 at 2:38:54 PM UTC+11, josh...@fastmail.com 
wrote:
>
> Hello julia-users,
>
> I'm scratching my head as to the following behaviour with using String on 
> a Vector of UInt8 values:
>
> for x in 0x00:0xff
> print("$(lpad(x, 5)): ")
> print(length(String([x])))
> if (x + 1) % 8 == 0 println() end
> end
> which on OS X and Linux using Julia 0.5 yields:
> 0: 11: 12: 13: 14: 15: 16: 17: 1
> 8: 19: 1   10: 1   11: 1   12: 1   13: 1   14: 1   15: 1
>16: 1   17: 1   18: 1   19: 1   20: 1   21: 1   22: 1   23: 1
>24: 1   25: 1   26: 1   27: 1   28: 1   29: 1   30: 1   31: 1
>32: 1   33: 1   34: 1   35: 1   36: 1   37: 1   38: 1   39: 1
>40: 1   41: 1   42: 1   43: 1   44: 1   45: 1   46: 1   47: 1
>48: 1   49: 1   50: 1   51: 1   52: 1   53: 1   54: 1   55: 1
>56: 1   57: 1   58: 1   59: 1   60: 1   61: 1   62: 1   63: 1
>64: 1   65: 1   66: 1   67: 1   68: 1   69: 1   70: 1   71: 1
>72: 1   73: 1   74: 1   75: 1   76: 1   77: 1   78: 1   79: 1
>80: 1   81: 1   82: 1   83: 1   84: 1   85: 1   86: 1   87: 1
>88: 1   89: 1   90: 1   91: 1   92: 1   93: 1   94: 1   95: 1
>96: 1   97: 1   98: 1   99: 1  100: 1  101: 1  102: 1  103: 1
>   104: 1  105: 1  106: 1  107: 1  108: 1  109: 1  110: 1  111: 1
>   112: 1  113: 1  114: 1  115: 1  116: 1  117: 1  118: 1  119: 1
>   120: 1  121: 1  122: 1  123: 1  124: 1  125: 1  126: 1  127: 1
>
>
>
>
>
>
>
> *  128: 0  129: 0  130: 0  131: 0  132: 0  133: 0  134: 0  135: 0  136: 0 
>  137: 0  138: 0  139: 0  140: 0  141: 0  142: 0  143: 0  144: 0  145: 0 
>  146: 0  147: 0  148: 0  149: 0  150: 0  151: 0  152: 0  153: 0  154: 0 
>  155: 0  156: 0  157: 0  158: 0  159: 0  160: 0  161: 0  162: 0  163: 0 
>  164: 0  165: 0  166: 0  167: 0  168: 0  169: 0  170: 0  171: 0  172: 0 
>  173: 0  174: 0  175: 0  176: 0  177: 0  178: 0  179: 0  180: 0  181: 0 
>  182: 0  183: 0  184: 0  185: 0  186: 0  187: 0  188: 0  189: 0  190: 0 
>  191: 0*
>   192: 1  193: 1  194: 1  195: 1  196: 1  197: 1  198: 1  199: 1
>   200: 1  201: 1  202: 1  203: 1  204: 1  205: 1  206: 1  207: 1
>   208: 1  209: 1  210: 1  211: 1  212: 1  213: 1  214: 1  215: 1
>   216: 1  217: 1  218: 1  219: 1  220: 1  221: 1  222: 1  223: 1
>   224: 1  225: 1  226: 1  227: 1  228: 1  229: 1  230: 1  231: 1
>   232: 1  233: 1  234: 1  235: 1  236: 1  237: 1  238: 1  239: 1
>   240: 1  241: 1  242: 1  243: 1  244: 1  245: 1  246: 1  247: 1
>   248: 1  249: 1  250: 1  251: 1  252: 1  253: 1  254: 1  255: 1
>
> Why would the range 128-191 yield an empty vector?
> Note: this occurs regardless of the length of the vector being converted 
> (i.e. any element in this range is omitted in the converted string)
>
> Cheers,
> Josh
>

[julia-users] String(Vector{UInt8}) Question

[joshbode]

Hello julia-users,

I'm scratching my head as to the following behaviour with using String on a 
Vector of UInt8 values:

for x in 0x00:0xff
print("$(lpad(x, 5)): ")
print(length(String([x])))
if (x + 1) % 8 == 0 println() end
end
which on OS X and Linux using Julia 0.5 yields:
0: 11: 12: 13: 14: 15: 16: 17: 1
8: 19: 1   10: 1   11: 1   12: 1   13: 1   14: 1   15: 1
   16: 1   17: 1   18: 1   19: 1   20: 1   21: 1   22: 1   23: 1
   24: 1   25: 1   26: 1   27: 1   28: 1   29: 1   30: 1   31: 1
   32: 1   33: 1   34: 1   35: 1   36: 1   37: 1   38: 1   39: 1
   40: 1   41: 1   42: 1   43: 1   44: 1   45: 1   46: 1   47: 1
   48: 1   49: 1   50: 1   51: 1   52: 1   53: 1   54: 1   55: 1
   56: 1   57: 1   58: 1   59: 1   60: 1   61: 1   62: 1   63: 1
   64: 1   65: 1   66: 1   67: 1   68: 1   69: 1   70: 1   71: 1
   72: 1   73: 1   74: 1   75: 1   76: 1   77: 1   78: 1   79: 1
   80: 1   81: 1   82: 1   83: 1   84: 1   85: 1   86: 1   87: 1
   88: 1   89: 1   90: 1   91: 1   92: 1   93: 1   94: 1   95: 1
   96: 1   97: 1   98: 1   99: 1  100: 1  101: 1  102: 1  103: 1
  104: 1  105: 1  106: 1  107: 1  108: 1  109: 1  110: 1  111: 1
  112: 1  113: 1  114: 1  115: 1  116: 1  117: 1  118: 1  119: 1
  120: 1  121: 1  122: 1  123: 1  124: 1  125: 1  126: 1  127: 1







*  128: 0  129: 0  130: 0  131: 0  132: 0  133: 0  134: 0  135: 0  136: 0 
 137: 0  138: 0  139: 0  140: 0  141: 0  142: 0  143: 0  144: 0  145: 0 
 146: 0  147: 0  148: 0  149: 0  150: 0  151: 0  152: 0  153: 0  154: 0 
 155: 0  156: 0  157: 0  158: 0  159: 0  160: 0  161: 0  162: 0  163: 0 
 164: 0  165: 0  166: 0  167: 0  168: 0  169: 0  170: 0  171: 0  172: 0 
 173: 0  174: 0  175: 0  176: 0  177: 0  178: 0  179: 0  180: 0  181: 0 
 182: 0  183: 0  184: 0  185: 0  186: 0  187: 0  188: 0  189: 0  190: 0 
 191: 0*
  192: 1  193: 1  194: 1  195: 1  196: 1  197: 1  198: 1  199: 1
  200: 1  201: 1  202: 1  203: 1  204: 1  205: 1  206: 1  207: 1
  208: 1  209: 1  210: 1  211: 1  212: 1  213: 1  214: 1  215: 1
  216: 1  217: 1  218: 1  219: 1  220: 1  221: 1  222: 1  223: 1
  224: 1  225: 1  226: 1  227: 1  228: 1  229: 1  230: 1  231: 1
  232: 1  233: 1  234: 1  235: 1  236: 1  237: 1  238: 1  239: 1
  240: 1  241: 1  242: 1  243: 1  244: 1  245: 1  246: 1  247: 1
  248: 1  249: 1  250: 1  251: 1  252: 1  253: 1  254: 1  255: 1

Why would the range 128-191 yield an empty vector?
Note: this occurs regardless of the length of the vector being converted 
(i.e. any element in this range is omitted in the converted string)

Cheers,
Josh

Re: [julia-users] Re: Julia-i18n logo proposal

[Islam Badreldin]

+1 for the letters 'جو' in the green circle. (Yes, these are two letters, a 
consonant and a vowel!)
Another option is to only use the first single letter 'ج', or its modern 
variation 'چ', which would be the equivalent of 'J' in Arabic. Personally, I 
think it'd look nicer too.
Thanks,Islam
PS: I'm a native Arabic speaker, and I'm actively using Julia :) I hope the 
Arabic letters in this email display correctly on your system
_
From: Waldir Pimenta 
Sent: Tuesday, October 4, 2016 3:58 AM
Subject: Re: [julia-users] Re: Julia-i18n logo proposal
To: julia-users 


That's an interesting idea. And Arabic tends to be associated with the color 
green (well, Islam moreso, but the correlation is pretty high nevertheless), so 
we'd also get a nice pairing of character-color as with the Chinese one :)
Looking forward to hear what other folks think.

On Tuesday, October 4, 2016 at 5:49:06 AM UTC+1, David P. Sanders wrote:Or just 
remove the J and put the three characters from the other scripts? 

Re: [julia-users] Re: Julia-i18n logo proposal

[Avik Sengupta]

>Or just remove the J and put the three characters from the other scripts?

+1. I like this. 


On Tuesday, 4 October 2016 08:58:10 UTC+1, Waldir Pimenta wrote:
>
> That's an interesting idea. And Arabic tends to be associated with the 
> color green (well, Islam moreso 
> , but the correlation is 
> pretty high nevertheless), so we'd also get a nice pairing of 
> character-color as with the Chinese one :)
>
> Looking forward to hear what other folks think.
>
> On Tuesday, October 4, 2016 at 5:49:06 AM UTC+1, David P. Sanders wrote:
>>
>> Or just remove the J and put the three characters from the other scripts? 
>
>

[julia-users] Re: memory allocation in nested loops

[Christoph Ortner]

also look at `StaticArrays` and `reinterpret`

E.g.,
R = reinterpret(SVector{3,Float64}, r, m)

I use this a lot and find it very convenient.

Re: [julia-users] efficiently add floats to a particular element of a vector

[Jeff]

Ah, of course. Thanks!


On Tuesday, October 4, 2016 at 12:20:08 PM UTC-7, Yichao Yu wrote:
>
> On Tue, Oct 4, 2016 at 3:11 PM, Jeff  
> wrote: 
> > Adding floats to an element of a vector takes about twice as long as 
> adding 
> > float to a variable. For example, 
> > 
> > ``` 
> > val = zeros(1) 
> > for i in 1:1000 
> > val[1] += 9. 
> > end 
> > ``` 
> > finishes in 0.034 seconds whereas 
> > ``` 
> > a = 0. 
> > for i in 1:1000 
> > a += 9. 
> > end 
> > ``` 
> > take just 0.015 seconds. 
> > 
> > Is the former block of code looking up the address in memory of `val[1]` 
> at 
> > every iteration? Or does have something to do with `a` being stack 
> allocated 
> > whereas `val` is heap allocated? 
>
> It's because of bounds check. 
>
> > 
> > Is there a way to add floats to a particular index of a vector without 
> > incurring runtime overhead, if I know at compile time what the index is? 
>
> The optimizations the compiler can do is actually a little limited in 
> this case. But if you know that no one else will be using the same 
> array at the same time you can do the unsafe optimization manually by 
> hoisting the load and the store out of the loop. 
>
> val1 = val[1] 
> for ... 
>  val1 += 9. 
> end 
> val[1] = val1 
>
> > 
> > Thanks! 
> > 
>

Re: [julia-users] efficiently add floats to a particular element of a vector

[Yichao Yu]

On Tue, Oct 4, 2016 at 3:11 PM, Jeff  wrote:
> Adding floats to an element of a vector takes about twice as long as adding
> float to a variable. For example,
>
> ```
> val = zeros(1)
> for i in 1:1000
> val[1] += 9.
> end
> ```
> finishes in 0.034 seconds whereas
> ```
> a = 0.
> for i in 1:1000
> a += 9.
> end
> ```
> take just 0.015 seconds.
>
> Is the former block of code looking up the address in memory of `val[1]` at
> every iteration? Or does have something to do with `a` being stack allocated
> whereas `val` is heap allocated?

It's because of bounds check.

>
> Is there a way to add floats to a particular index of a vector without
> incurring runtime overhead, if I know at compile time what the index is?

The optimizations the compiler can do is actually a little limited in
this case. But if you know that no one else will be using the same
array at the same time you can do the unsafe optimization manually by
hoisting the load and the store out of the loop.

val1 = val[1]
for ...
 val1 += 9.
end
val[1] = val1

>
> Thanks!
>

[julia-users] efficiently add floats to a particular element of a vector

[Jeff]

Adding floats to an element of a vector takes about twice as long as adding 
float to a variable. For example,

```
val = zeros(1)
for i in 1:1000
val[1] += 9.
end
```
finishes in 0.034 seconds whereas
```
a = 0.
for i in 1:1000
a += 9.
end 
```
take just 0.015 seconds.

Is the former block of code looking up the address in memory of `val[1]` at 
every iteration? Or does have something to do with `a` being stack 
allocated whereas `val` is heap allocated?

Is there a way to add floats to a particular index of a vector without 
incurring runtime overhead, if I know at compile time what the index is?

Thanks!

Re: [julia-users] Gadfly plots no longer showing in Juno

[James Noeckel]

Thanks for the prompt response.

On Tuesday, October 4, 2016 at 2:17:19 PM UTC-4, Mike Innes wrote:
>
> Try Pkg.checkout("Gadfly"). We recently moved the integration code from 
> Atom to Gadfly, but I guess Gadfly hasn't been tagged yet.
>
> On Tue, 4 Oct 2016 at 19:14 James Noeckel  
> wrote:
>
>> With the latest update, it seems that display(::Gadfly.Plot) no longer 
>> opens a plot tab in the Atom editor. Instead, it prints the contents of the 
>> plot object in the console. Gadfly is Juno's preferred plotting 
>> environment, but I don't know if this is an issue with Gadfly.jl or 
>> Atom.jl. Can anybody figure out a workaround?
>>
>

Re: [julia-users] Gadfly plots no longer showing in Juno

[Mike Innes]

Try Pkg.checkout("Gadfly"). We recently moved the integration code from
Atom to Gadfly, but I guess Gadfly hasn't been tagged yet.

On Tue, 4 Oct 2016 at 19:14 James Noeckel  wrote:

> With the latest update, it seems that display(::Gadfly.Plot) no longer
> opens a plot tab in the Atom editor. Instead, it prints the contents of the
> plot object in the console. Gadfly is Juno's preferred plotting
> environment, but I don't know if this is an issue with Gadfly.jl or
> Atom.jl. Can anybody figure out a workaround?
>

[julia-users] Gadfly plots no longer showing in Juno

[James Noeckel]

With the latest update, it seems that display(::Gadfly.Plot) no longer 
opens a plot tab in the Atom editor. Instead, it prints the contents of the 
plot object in the console. Gadfly is Juno's preferred plotting 
environment, but I don't know if this is an issue with Gadfly.jl or 
Atom.jl. Can anybody figure out a workaround?

Re: [julia-users] Simple test functions generates different codegen

[mmh]

Ah right, I forgot @code_lowered even existed , thanks for that. Yeah 
gcc/clang all have the same native code from this snippet, which is why I 
was surprised that the same julia code was produced different  code native. 
 

On Tuesday, October 4, 2016 at 9:13:17 AM UTC-4, Isaiah wrote:
>
> These expressions are lowered differently because `test2` gets a temporary 
> due to the conditional reassignment of `u`, whereas `test1` is just a 
> straight line switch and jump (look at `code_lowered` and `code_typed`).
>
> For the same C code, the lowered IR from Clang looks similar, but it 
> appears to constant fold and reduce down to identical assembly at `-O1` and 
> above. The fact that Julia doesn't is probably due to difference in LLVM 
> optimization passes or order.
>
> As far as style, personally I think the first one is cleaner.
>
> On Fri, Sep 30, 2016 at 1:48 PM, mmh  
> wrote:
>
>> I would have that thought that these two function would produce the same 
>> code, but they do not.
>>
>> Could someone care to explain the difference and which is preferred and 
>> why
>>
>>
>> http://pastebin.com/GJ8YPfV3
>>
>> function test1(x)
>> y = 2.0
>> u = 2.320
>> x < 0 && (u = 32.0)
>> x > 1 && (u = 1.0)
>> return u + y
>> end
>>
>>
>> function test2(x)
>> y = 2.0
>> u = 2.320
>> u = x < 0 ? 32.0 : u
>> u = x > 1 ? 1.0 : u
>> return u + y
>> end
>>
>>
>> @code_llvm test1(2.2)
>>
>> @code_llvm test2(2.2)
>>
>>
>

[julia-users] Re: Error showing value

[alx]

Oh, thanks

El martes, 4 de octubre de 2016, 18:21:17 (UTC+2), Kristoffer Carlsson 
escribió:
>
> Restart julia and try again with my version. 

[julia-users] Re: Error showing value

[Kristoffer Carlsson]

Restart julia and try again with my version. 

[julia-users] Re: Error showing value

[alx]

also it gives me error


El martes, 4 de octubre de 2016, 17:53:52 (UTC+2), Kristoffer Carlsson 
escribió:
>
> Did you mean
>
> Base.show(io::IO, n::One) = print(io, n.*o*)?
>
> On Tuesday, October 4, 2016 at 4:21:57 PM UTC+2, alx wrote:
>>
>> Hi, I do wrong, please
>>
>> --
>> using PyCall
>>
>> type One
>>   o::PyObject
>>   One() = new( PyObject(1) )
>> end
>>
>> Base.show(io::IO, n::One) = print(io, n)
>>
>> n=One()
>>
>> Error showing value of type One:
>> ERROR: StackOverflowError:
>>  in print(::IOContext{Base.Terminals.TTYTerminal}, ::One) at ./strings/io
>> .jl:7
>>  in print(::IOContext{Base.Terminals.TTYTerminal}, ::One) at ./strings/io
>> .jl:8 (repeats 48 times)
>>
>>
>>
>>

[julia-users] Re: memory allocation in nested loops

[Niccolo' Antonello]

Thank you so much for all your help! ;)

On Tuesday, October 4, 2016 at 4:12:43 PM UTC+2, Greg Plowman wrote:
>
> Not sure what the best way is, especially on Julia 0.5 where maybe some 
> sort of view.
>
> But you could always use an Array of Arrays if you don't really need a 
> true multi-dimensional array elsewhere:
>
> d = randn(3,n)
> d2 = [ d[:,i]::Vector{Float64} for i=1:n ]
> r = randn(3,m)
> r2 = [ r[:,i]::Vector{Float64} for i=1:m ]
>
> function nested_loop!(Y::Array{Complex{Float64}},X::Array{Complex{Float64
> }},
>   d::Vector{Vector{Float64}},r::Vector{Vector{Float64
> }},n::Int64,m::Int64,f::Int64)
> for i_1 = 1:f
> for i_3 = 1:n
> k = 2*π*i_1*d[i_3]
> for i_2 = 1:m
> A = exp(im*dot(k,r[i_2]))
> Y[i_1,i_2] += X[i_1,i_3] * A
> end
> end
> end
> end
>
>  nested_loop!(Y,X,d2,r2,n,m,f)
>
> On V0.4 this has less allocations and runs slightly faster (maybe 2-3x)
>
>
> On Tuesday, October 4, 2016 at 11:45:53 PM UTC+11, Niccolo' Antonello 
> wrote:
>
>> what is the best way to slice an array without allocating? I thank you!
>>
>> On Tuesday, October 4, 2016 at 1:20:29 PM UTC+2, Kristoffer Carlsson 
>> wrote:
>>>
>>> The slicing of "r" will also make a new array and thus allocate. 
>>
>>

[julia-users] Re: Error showing value

[Kristoffer Carlsson]

Did you mean

Base.show(io::IO, n::One) = print(io, n.*o*)?

On Tuesday, October 4, 2016 at 4:21:57 PM UTC+2, alx wrote:
>
> Hi, I do wrong, please
>
> --
> using PyCall
>
> type One
>   o::PyObject
>   One() = new( PyObject(1) )
> end
>
> Base.show(io::IO, n::One) = print(io, n)
>
> n=One()
>
> Error showing value of type One:
> ERROR: StackOverflowError:
>  in print(::IOContext{Base.Terminals.TTYTerminal}, ::One) at ./strings/io.
> jl:7
>  in print(::IOContext{Base.Terminals.TTYTerminal}, ::One) at ./strings/io.
> jl:8 (repeats 48 times)
>
>
>
>

[julia-users] Error showing value

[alx]

Hi, I do wrong, please

--
using PyCall

type One
  o::PyObject
  One() = new( PyObject(1) )
end

Base.show(io::IO, n::One) = print(io, n)

n=One()

Error showing value of type One:
ERROR: StackOverflowError:
 in print(::IOContext{Base.Terminals.TTYTerminal}, ::One) at ./strings/io.jl
:7
 in print(::IOContext{Base.Terminals.TTYTerminal}, ::One) at ./strings/io.jl
:8 (repeats 48 times)

[julia-users] Re: memory allocation in nested loops

['Greg Plowman' via julia-users]

Not sure what the best way is, especially on Julia 0.5 where maybe some 
sort of view.

But you could always use an Array of Arrays if you don't really need a true 
multi-dimensional array elsewhere:

d = randn(3,n)
d2 = [ d[:,i]::Vector{Float64} for i=1:n ]
r = randn(3,m)
r2 = [ r[:,i]::Vector{Float64} for i=1:m ]

function nested_loop!(Y::Array{Complex{Float64}},X::Array{Complex{Float64}},
  d::Vector{Vector{Float64}},r::Vector{Vector{Float64}},
n::Int64,m::Int64,f::Int64)
for i_1 = 1:f
for i_3 = 1:n
k = 2*π*i_1*d[i_3]
for i_2 = 1:m
A = exp(im*dot(k,r[i_2]))
Y[i_1,i_2] += X[i_1,i_3] * A
end
end
end
end

 nested_loop!(Y,X,d2,r2,n,m,f)

On V0.4 this has less allocations and runs slightly faster (maybe 2-3x)


On Tuesday, October 4, 2016 at 11:45:53 PM UTC+11, Niccolo' Antonello wrote:

> what is the best way to slice an array without allocating? I thank you!
>
> On Tuesday, October 4, 2016 at 1:20:29 PM UTC+2, Kristoffer Carlsson wrote:
>>
>> The slicing of "r" will also make a new array and thus allocate. 
>
>

[julia-users] Re: memory allocation in nested loops

[Andrew]

You can do view(r, :, i_2) in 0.5. I think slice does the same thing in 0.4.

Also as a general point, you would have realized you hadn't defined r in 
the function if you had wrapped your entire program in a function, like
function test()
(your code)
end
test()
This would throw an error with your original code since r would not be in 
scope in nested_loop!().

I occasionally have accidentally used outside global variables in my 
functions like you did, and this can lead to bizarre and difficult to find 
bugs.

On Tuesday, October 4, 2016 at 8:45:53 AM UTC-4, Niccolo' Antonello wrote:
>
> what is the best way to slice an array without allocating? I thank you!
>
> On Tuesday, October 4, 2016 at 1:20:29 PM UTC+2, Kristoffer Carlsson wrote:
>>
>> The slicing of "r" will also make a new array and thus allocate. 
>
>

Re: [julia-users] Simple test functions generates different codegen

[Isaiah Norton]

These expressions are lowered differently because `test2` gets a temporary
due to the conditional reassignment of `u`, whereas `test1` is just a
straight line switch and jump (look at `code_lowered` and `code_typed`).

For the same C code, the lowered IR from Clang looks similar, but it
appears to constant fold and reduce down to identical assembly at `-O1` and
above. The fact that Julia doesn't is probably due to difference in LLVM
optimization passes or order.

As far as style, personally I think the first one is cleaner.

On Fri, Sep 30, 2016 at 1:48 PM, mmh  wrote:

> I would have that thought that these two function would produce the same
> code, but they do not.
>
> Could someone care to explain the difference and which is preferred and why
>
>
> http://pastebin.com/GJ8YPfV3
>
> function test1(x)
> y = 2.0
> u = 2.320
> x < 0 && (u = 32.0)
> x > 1 && (u = 1.0)
> return u + y
> end
>
>
> function test2(x)
> y = 2.0
> u = 2.320
> u = x < 0 ? 32.0 : u
> u = x > 1 ? 1.0 : u
> return u + y
> end
>
>
> @code_llvm test1(2.2)
>
> @code_llvm test2(2.2)
>
>

Re: [julia-users] Subset a DataFrame without a #NULL value in a column

[Min-Woong Sohn]

Thank you.

On Tuesday, October 4, 2016 at 6:05:22 AM UTC-4, Milan Bouchet-Valat wrote:
>
> Le lundi 03 octobre 2016 à 18:14 -0700, Min-Woong Sohn a écrit : 
> > Previously, under DataArray, I could do 
> > 
> > df2 = df[!isna(df[:somvar),:] 
> > 
> > Is there a NullableArray equivalent to isna()? I've tried isnull(), 
> > which is not defined. 
> isnull() is defined in Julia Base. But it's not a vectorized operation: 
> isnull(df[:somevar]) will return false when you seem to be looking for 
> a boolean vector. What you're looking for should work when written as 
> isnull.(df[:somevar]), but currently there's a bug that makes it fail. 
> That's on our TODO list: 
> https://github.com/JuliaStats/NullableArrays.jl/issues/153 
>
>
> Regards 
>

[julia-users] Re: memory allocation in nested loops

[Niccolo' Antonello]

what is the best way to slice an array without allocating? I thank you!

On Tuesday, October 4, 2016 at 1:20:29 PM UTC+2, Kristoffer Carlsson wrote:
>
> The slicing of "r" will also make a new array and thus allocate. 

[julia-users] Re: memory allocation in nested loops

[Niccolo' Antonello]

Thank you so much both of you!

On Tuesday, October 4, 2016 at 1:20:29 PM UTC+2, Kristoffer Carlsson wrote:
>
> The slicing of "r" will also make a new array and thus allocate. 

[julia-users] ANN: LLVM.jl, wrapper of the LLVM C API

[Tim Besard]

Hi all,

LLVM.jl  wraps the C API of the LLVM 
compiler toolkit. I've decided to wrap this API because is more stable than 
the C++ one, and easier to use (ie. with Cxx.jl currently being relatively 
hard to build).

It forms a relatively shallow wrapper around the API (where Jake Bolewski's 
LLVM.jl  provides a much 
higher-level interface), only exposing it with somewhat more idiomatic 
Julia constructs. For example, reimplementing the example from here 

:

mod = LLVM.Module("my_module")

param_types = [LLVM.Int32Type(), LLVM.Int32Type()]
ret_type = LLVM.FunctionType(LLVM.Int32Type(), param_types)
sum = LLVM.Function(mod, "sum", ret_type)

Builder() do builder
entry = BasicBlock(sum, "entry")
position!(builder, entry)

tmp = add!(builder, parameters(sum)[1], parameters(sum)[2], "tmp")
ret!(builder, tmp)

println(mod)
verify(mod)
end

Interpreter(mod) do engine
x, y = parse.([Int], ARGS[1:2])
args = [GenericValue(LLVM.Int32Type(), x),
GenericValue(LLVM.Int32Type(), y)]

res = LLVM.run(engine, sum, args)
println(convert(Int, res))

dispose.(args)
dispose(res)
end

For documentation, refer to the LLVM docs 
. Even though it'll 
require users to have a look at code or tests, the wrapper is fairly 
shallow and I don't have the time to redocument the entire API. Note that a 
lot of API functions aren't covered yet 
, and our API 
might still change.

The package requires LLVM 3.9 but also supports 4.0 (for now), and works 
with Julia 0.5 and current nightly. Do note that we require a _full_ LLVM 
installation, ie. not only libLLVM.so but also llvm-config and its headers, 
to compile sources with additional C API functions. Both these requirements 
make it currently impossible to use this package on a binary Julia 
installation (shipping only libLLVM-3.7.so) without an external LLVM, but I 
hope to improve that situation in the future. For now, use this package on 
a Julia source installation compiled with LLVM_VER=3.9, or on a system with 
LLVM 3.9+ installed. If running Pkg.build with environment variable DEBUG=1, 
you'll get more information about the different installations it picked up 
and ended up selecting.

An interesting technical detail: the C API flattens the C++ type hierarchy, 
but exposes enums to differentiate between generically-typed pointers. We 
use that information to reconstruct the type hierarchy (only when 
necessary, sometimes the return subtype is known by definition), making the 
API somewhat more type-safe again.

Main user of this package is CUDAnative, to implement the PTX JIT in Julia 
.
 
Next version will also support writing LLVM passes in Julia (sneak peek 

).

Best,
Tim

[julia-users] Re: memory allocation in nested loops

[Kristoffer Carlsson]

The slicing of "r" will also make a new array and thus allocate. 

[julia-users] Re: memory allocation in nested loops

['Greg Plowman' via julia-users]

You haven't passed in r as argument to function.
Try nested_loop!(Y,X,d,r,n,m,f)


On Tuesday, October 4, 2016 at 8:05:41 PM UTC+11, Niccolo' Antonello wrote:

> Hi all,
>
> I'm trying to make this code to go faster:
>
> n,m = 100,25
> f = 100
> d = randn(3,n)
> r = randn(3,m)
>
> Y = zeros(Complex{Float64},f,m)
> X = ones(f,n)+im*ones(f,n)
>
> function 
> nested_loop!(Y::Array{Complex{Float64}},X::Array{Complex{Float64}},
>   d::Array{Float64,2},n::Int64,m::Int64,f::Int64)
> for i_1 = 1:f
> for i_3 = 1:n
> k = 2*π*i_1*d[:,i_3]
> for i_2 = 1:m
> A = exp(im*dot(k,r[:,i_2]))
> Y[i_1,i_2] += X[i_1,i_3] * A
> end
> end
> end
> end
>
> @time nested_loop!(Y,X,d,n,m,f)
> Profile.clear_malloc_data()
> Y = zeros(Complex{Float64},f,m)
> @time nested_loop!(Y,X,d,n,m,f)
>
> I see that it is allocating a lot of memory. 
> So I also tried to put k and A on Arrays and preallocate that, but this 
> didn't remove the allocations. 
> Could you please tell me what could be possibly done to make this code 
> faster?
> I thank you! 
>
>

Re: [julia-users] Subset a DataFrame without a #NULL value in a column

[Milan Bouchet-Valat]

Le lundi 03 octobre 2016 à 18:14 -0700, Min-Woong Sohn a écrit :
> Previously, under DataArray, I could do
> 
> df2 = df[!isna(df[:somvar),:]
> 
> Is there a NullableArray equivalent to isna()? I've tried isnull(),
> which is not defined.
isnull() is defined in Julia Base. But it's not a vectorized operation:
isnull(df[:somevar]) will return false when you seem to be looking for
a boolean vector. What you're looking for should work when written as
isnull.(df[:somevar]), but currently there's a bug that makes it fail.
That's on our TODO list:
https://github.com/JuliaStats/NullableArrays.jl/issues/153


Regards

[julia-users] memory allocation in nested loops

[Niccolo' Antonello]

Hi all,

I'm trying to make this code to go faster:

n,m = 100,25
f = 100
d = randn(3,n)
r = randn(3,m)

Y = zeros(Complex{Float64},f,m)
X = ones(f,n)+im*ones(f,n)

function nested_loop!(Y::Array{Complex{Float64}},X::Array{Complex{Float64}},
  d::Array{Float64,2},n::Int64,m::Int64,f::Int64)
for i_1 = 1:f
for i_3 = 1:n
k = 2*π*i_1*d[:,i_3]
for i_2 = 1:m
A = exp(im*dot(k,r[:,i_2]))
Y[i_1,i_2] += X[i_1,i_3] * A
end
end
end
end

@time nested_loop!(Y,X,d,n,m,f)
Profile.clear_malloc_data()
Y = zeros(Complex{Float64},f,m)
@time nested_loop!(Y,X,d,n,m,f)

I see that it is allocating a lot of memory. 
So I also tried to put k and A on Arrays and preallocate that, but this 
didn't remove the allocations. 
Could you please tell me what could be possibly done to make this code 
faster?
I thank you! 

Re: [julia-users] Re: Julia-i18n logo proposal

[mmh]

Cool logo, IMO the "J" at the top looks a little out of place and not 
balanced with the other two glyphs

Re: [julia-users] Re: Julia-i18n logo proposal

[Waldir Pimenta]

That's an interesting idea. And Arabic tends to be associated with the 
color green (well, Islam moreso 
, but the correlation is 
pretty high nevertheless), so we'd also get a nice pairing of 
character-color as with the Chinese one :)

Looking forward to hear what other folks think.

On Tuesday, October 4, 2016 at 5:49:06 AM UTC+1, David P. Sanders wrote:
>
> Or just remove the J and put the three characters from the other scripts? 

[julia-users] Re: Ancient Gfortran/GCC version in Travis-CI image

[Helge Eichhorn]

Thanks Tony, that worked!

Here is my new Travis config for the public record:
https://github.com/KosmosML/LLEA.jl/blob/a2ea6ffa80f8a8d8c2f3198ec94a26136281c3ee/.travis.yml

Am Montag, 3. Oktober 2016 23:44:50 UTC+2 schrieb Tony Kelman:
>
> Check the travis docs for the apt sources and packages addons to install 
> newer compiler versions from the Ubuntu toolchain ppa.