[julia-users] Is the compiler able to give warnings that an iterator's internal state modified?

[FANG Colin]

I guess the following is buggy code

   dict = Dict(x=>x for x in 1:100);
for x in keys(dict)
delete!(dict, x)
end


As we need to `collect(keys(...))` to make a copy.

However the code above still runs with correct results. Even when it fails 
to return correct results, no error would be thrown. 

Just wondering in the language design point of view if the compiler or 
runtime can detect this sort of behaviour always?

Re: [julia-users] How to tell if Val{T} is using a fast route

[FANG Colin]

Typo, should be

module ...

ff(x::Type{Val{1}}) = 1

x = 1
a = ff(Val{x})

const y = 1
a = ff(Val{y})

end

>
>

[julia-users] How to tell if Val{T} is using a fast route

[FANG Colin]

In performance tips, it says

Essentially, Val{T}works only when T is either hard-coded (Val{3}) or 
already specified in the type-domain.

Suppose I have

ff(::Type{Val{1}}) = 1

I guess the following is on a slower route.

x = 1
a = ff(::Type{Val{x}})

And maybe this one can be determined in compile time

const y = 1
a = ff(::Type{Val{y}})

How can I tell if it is fast or slow? @code_warntype doesn't tell the 
difference here?

Re: [julia-users] Good way to organize constants?

[FANG Colin]

Is there going to be overhead if I create constant group modules and use
them via module_name.abc?

On 16 November 2016 at 13:31, Milan Bouchet-Valat <nalimi...@club.fr> wrote:

> Le mercredi 16 novembre 2016 à 04:18 -0800, FANG Colin a écrit :
> > Say, I have a few constants
> >
> > const VTYPE_BINARY = 'B'
> > const VTYPE_INTEGER = 'I'
> > const VTYPE_CONTINUOUS = 'C'
> >
> > What's a good way to have a namespace on it?
> >
> > So that I can use Vtype.BINARY, Vtype.INTEGER, Vtype.CONTINUOUS
> >
> > Should I put those in a separator module? or create a type and get an
> > instance of it?
> >
> > module Vtype
> > const 
> > end
> >
> > immutable Vtype
> > BINARY::Char
> > INTEGER::Char
> > CONTINUOUS::Char
> > end
> >
> > const vtype = Vtype('B','I','C')?
> Putting it in a module is fine if you want to regroup these under the
> same namespace. That's the standard practice with enums too (when
> constants correspond to integer codes, which isn't the case here).
>
>
> Regards
>

[julia-users] Re: Syntax sugar for composite type decomposition?

[FANG Colin]

Macro seems to have answered this in a different thread 
https://github.com/mauro3/Parameters.jl

On Wednesday, November 16, 2016 at 1:01:32 PM UTC, FANG Colin wrote:
>
> Do we have a decomposition syntax or macro that simplifies this
>
>
> a = x.a
> b = x.b
> c = x.c
> ...
>
>
>

[julia-users] Syntax sugar for composite type decomposition?

[FANG Colin]

Do we have a decomposition syntax or macro that simplifies this


a = x.a
b = x.b
c = x.c
...

[julia-users] Good way to organize constants?

[FANG Colin]

Say, I have a few constants

const VTYPE_BINARY = 'B'
const VTYPE_INTEGER = 'I'
const VTYPE_CONTINUOUS = 'C'

What's a good way to have a namespace on it?

So that I can use Vtype.BINARY, Vtype.INTEGER, Vtype.CONTINUOUS

Should I put those in a separator module? or create a type and get an 
instance of it?

module Vtype
const 
end

immutable Vtype
BINARY::Char
INTEGER::Char
CONTINUOUS::Char
end

const vtype = Vtype('B','I','C')?

[julia-users] Does Julia support Integer literal suffix like 1234L or 1234U

[FANG Colin]

Just wondering if Julia has any integer literal suffix support?

So we don't have to write Int64(1234) or Int32(1234) in a long expression 
containing constants, but use 1234L or 1234S instead.

[julia-users] Re: canonical binary representation for Array

[FANG Colin]

Are you trying to serialise Julia objects? Why don't you try json or 
msgpack or so as your encoding?

The default serialize could also work but you need to be careful it doesn't 
guarantee version safe.

Re: [julia-users] hashing floating point zeroes

[FANG Colin]

I would suggest replace `round(result, 10)` with `round(result, 10) + 0.0`

On Saturday, July 9, 2016 at 1:34:43 PM UTC+1, Davide Lasagna wrote:
>
> Thanks, interesting point.
>
> In my specific use case -0.0 and 0.0 actually need to have the same hash, 
> as they represent conceptually the same abstract quantity. My data is the 
> result of an iterative computation which is eventually rounded to 10 
> decimal places and then hashed. I use the result's hash to check if a given 
> computation, (with tolerance a bit finer than the rounding), produces a new 
> solution.
>
> A more robust approach would be to test if abs(result - result_i) < \delta 
> for each result_i in a collection of previous results. However, this 
> operation scales linearly with the length of the collection, whereas using 
> a set, hence requiring overloading hash(::result), is a constant-time 
> operation. 
>
> Any thoughts on possible alternatives?
>
>
> On Saturday, July 9, 2016 at 12:40:58 PM UTC+1, Tom Breloff wrote:
>>
>> Yes. They are different numbers. In a way, negative zero represents "a 
>> really small negative number" that can't be represented exactly using 
>> floating point. 
>>
>> On Saturday, July 9, 2016, Davide Lasagna  wrote:
>>
>>> Hi, 
>>>
>>> I have just been bitten by a function hashing a custom type containing a 
>>> vector of floats. It turns out that hashing positive and negative floating 
>>> point zeros returns different hashes. 
>>>
>>> Demo:
>>> julia> hash(-0.0)
>>> 0x3be7d0f7780de548
>>>
>>> julia> hash(0.0)
>>> 0x77cfa1eef01bca90
>>>
>>> julia> hash(0)
>>> 0x77cfa1eef01bca90
>>>
>>> Is this expected behaviour?
>>>
>>>

[julia-users] Re: Fun Fact: Julia is space sensitive (in some sense)

[FANG Colin]

Agree. It is very hard to spot the issue if it is combined with the bug 
that error message sometimes cannot get the line number right.

[julia-users] Re: VS code extension

[FANG Colin]

Thank you.

I used to use https://github.com/Mike43110/julia.vscode which unfortunately 
doesn't provide the command for mark selection as comments.

[julia-users] Which way is preferred to define a closure?

[FANG Colin]

it seems there are 2 ways to define a closure. I am wondering why one is 
recommended.

const myfun = let
x = ...
function f()
do_something(x)
end

f
end

or


let
x = ..
global myfun()
function myfun()
do_something(x)
end
end

[julia-users] Re: Another nested function scope issue

[FANG Colin]

Never mind, I get it.

On the third run, the `state` variable that `counter` modified is the one 
from the second let block.

[julia-users] Another nested function scope issue

[FANG Colin]

I am wondering why the following happens:

Julia 0.4.6

let
state = 0
counter() = state += 1
counter()

@show state
end

let
state = 0
global counter
counter() = state += 1
counter()

@show state
end

let
state = 0
global counter
counter() = state += 1
counter()

@show state
end

state = 1
state = 1
state = 0

[julia-users] good practice with dictionary pop!?

[FANG Colin]

I find myself often writing code like this when dealing pop! with a Dict{A, 
B}


if !haskey(my_dict, key)
do_something...
end

value = pop!(my_dict, key)

do_something_else...


The code above has an issue: it looks up the key in a dict twice 
unnecessary.

I know I can opt for the alternative pattern:


v = pop!(my_dict, key, nothing)

if v == nothing
do_something...
end

value::B = v

do_something_else...

Note this piece of code is also a bit annoying, as v is no longer type 
stable. I have to think of another name "value" and apply an assignment 
with type assert. (naming variables is hard)


Probably I can extend `pop!` with pop!(f, key, v) so that I can do:

value = pop!(my_dict, key) do
   do_something...
end

do_something_else...

But using an anonymous function here seems an overkill with overhead?

What do people do in such case?

[julia-users] Why these 2 functions generate very different llvm?

[FANG Colin]

function t1(n::Int, x::Int, a::Float64)
   x::Float64 = x
   for i in 1:n
x += a
   end
x
end
@time t1(10^6, 1, 1.0)

0.005445 seconds (1.00 M allocations: 15.259 MB)




function t2(n::Int, y::Int, a::Float64)
   x::Float64 = y
   for i in 1:n
x += a
   end
x
end
@time t2(10^6, 1, 1.0)

0.001044 seconds (6 allocations: 192 bytes)




The @code_warntype of the 2 functions are very similar. However, the llvm 
code generated from t2 is a lot simpler.


Does it suggest that if we want to change the type of an argument, we'd 
better create a new variable?

Re: [julia-users] Change of immutable memory layout in julia v0.5?

[FANG Colin]

@Steven My wrong usage of the phrase "memory layout" I guess. I meant heap 
-> stack change (I thought this belongs to the term "memory layout"...).
Also, I had though as long as I don't use any variables from the global 
scope the benchmark should be all right.

@yichao The versioninfo for v0.5 in my case is

Julia Version 0.5.0-dev+3305
Commit c45175f (2016-03-29 03:51 UTC)


It seems to be a bit earlier than your commit.





On Sunday, May 22, 2016 at 1:26:28 AM UTC+1, Yichao Yu wrote:
>
> On Sat, May 21, 2016 at 7:04 PM, FANG Colin <coli...@gmail.com 
> > wrote: 
> > immutable MyType 
> > x::AbstractString 
> > y::Int 
> > end 
> > 
> > 
> > @time for i in 1:10^5 MyType("a", 1).y end 
> > 
> > 
> > In julia v0.4 
> > 
> > 0.000813 seconds (100.00 k allocations: 3.052 MB) 
> > 
> > 
> > In julia v0.5 
> > 
> > 0.03 seconds (5 allocations: 176 bytes) 
> > 
> > 
> > It seems the memory layout for immutable which contains fields with 
> non-bit 
> > types has changed in v0.5. 
>
> I believe this is due to better allocation elimination in type 
> inference[1]. This is exactly the case I meant by "allocation 
> benchmark doesn't work". 
>
> [1] https://github.com/JuliaLang/julia/pull/16021#issuecomment-213789309 
>
> > 
> > 
> > I would like to know more in details about such change, Where can I find 
> the 
> > related issues, discussion in GitHub or mailing list? 
>

[julia-users] Change of immutable memory layout in julia v0.5?

[FANG Colin]

immutable MyType
x::AbstractString
y::Int
end


@time for i in 1:10^5 MyType("a", 1).y end 


In julia v0.4

0.000813 seconds (100.00 k allocations: 3.052 MB)


In julia v0.5

0.03 seconds (5 allocations: 176 bytes)


It seems the memory layout for immutable which contains fields with non-bit 
types has changed in v0.5.


I would like to know more in details about such change, Where can I find 
the related issues, discussion in GitHub or mailing list?

Re: [julia-users] Re: Is there a function/macro that shows the line number where it is called?

[FANG Colin]

Thank you!

On Tuesday, May 10, 2016 at 3:20:48 PM UTC+1, Isaiah wrote:
>
> Use `@__LINE__` and `@__FILE__`.
>
> (note, however, `@__LINE__` does not work when used within another macro, 
> see https://github.com/JuliaLang/julia/issues/9577)
>
> On Tue, May 10, 2016 at 6:25 AM, FANG Colin <coli...@gmail.com 
> > wrote:
>
>> Currently I am using
>>
>> macro markup(line_number)
>> println("compile time OK: #$(line_number)")
>> quote
>> x = $(esc(line_number))
>> println("run time OK: #$x")
>> end
>> end
>>
>> For example
>>
>> I want to debug a function "to_debug".
>>
>> function to_debug()
>> @markup(1)
>> end
>>
>> compile time OK: #1
>>
>>
>> to_debug()
>>
>>
>> run time OK: #1
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tuesday, May 10, 2016 at 11:16:20 AM UTC+1, FANG Colin wrote:
>>>
>>> I am debugging some code.
>>>
>>> I would like to insert some markup function/macro in my code, so that I 
>>> know my code at least works fine until certain line number 
>>>
>>
>

[julia-users] Re: Is there a function/macro that shows the line number where it is called?

[FANG Colin]

Currently I am using

macro markup(line_number)
println("compile time OK: #$(line_number)")
quote
x = $(esc(line_number))
println("run time OK: #$x")
end
end

For example

I want to debug a function "to_debug".

function to_debug()
@markup(1)
end

compile time OK: #1


to_debug()


run time OK: #1








On Tuesday, May 10, 2016 at 11:16:20 AM UTC+1, FANG Colin wrote:
>
> I am debugging some code.
>
> I would like to insert some markup function/macro in my code, so that I 
> know my code at least works fine until certain line number 
>

[julia-users] Is there a function/macro that shows the line number where it is called?

[FANG Colin]

I am debugging some code.

I would like to insert some markup function/macro in my code, so that I 
know my code at least works fine until certain line number 

[julia-users] what's good practice for default value in optional arguments?

[FANG Colin]

For example,

function f(x::Int; y::Union{Void, Dict})
z = y == nothing ? Dict() : y
...
end


Or

function f(x::Int; y::Dict=Dict())
...
end

Which one should I use?

Re: [julia-users] What is Task switch not allowed from inside gc finalizer?

[FANG Colin]

What's the easiest way to print the object in finalizer?

On 12 April 2016 at 14:16, Yichao Yu <yyc1...@gmail.com> wrote:

> On Tue, Apr 12, 2016 at 8:15 AM, FANG Colin <colinf...@gmail.com> wrote:
> >  type C
> >x::Symbol
> >
> >function C(x::Symbol)
> >   c = new(x)
> >   finalizer(c, c->println(1, c, 2))
> >   c
> > end
> >  end
> >
> > a = C(:x)
> > a = 1
> > gc()
> >
> > error in running finalizer: ErrorException("task switch not allowed from
> > inside gc finalizer")
>
> Since otherwise task switch can happen during any allocation and most
> people will find this surprising. (it's effectively impossible to
> create a task-switch-free block)
>
> >
> > However, it works if I manually call finalizer(a).
>
> It is less of a problem since you know when you do that.
>
> >
> > So, what's wrong with my usage of finalizer?
> >
> > Also, it seems I can only use finalizer(a) once, it doesn't work for the
> 2nd
> > time?
>
> It should, there's a bug that this causes the finalizers to be called
> less frequently https://github.com/JuliaLang/julia/pull/13995
>
> There was another bug that old object don't get finalized if you call
> `finalize` on it but I think it is fixed on both 0.4 and 0.5
> https://github.com/JuliaLang/julia/pull/13988
>

[julia-users] Re: scoping wat

[FANG Colin]

I think the complicated scoping rules are inevitable in Julia as it is a 
dynamic language.

Every layer of flexibility in the language comes with a  cost.

static languages normally have simple scoping rules (And IDE can help a lot 
with static analysis).
Functional languages have even simpler rules.

On Tuesday, April 12, 2016 at 10:16:48 AM UTC+1, Didier Verna wrote:
>
>
>   Hi, 
>
> I'm quite puzzled by the complication of Julia's scoping rules, and in 
> particular this way of constantly and implicitly mixing binding and 
> assignment, with varying semantics according to the context. 
>
> The manual is not convincing (at least to me) in justifying what's 
> happening. Most of the scoping behavior looks like a big DWIM machinery 
> which is evil. 
>
> What's the history behind all this? Technical debt? Inspiration from 
> other languages (certainly not Scheme!)? Actual, arbitrary design 
> decisions? 
>
> Thank you! 
>
> -- 
> ELS'16 registration open! http://www.european-lisp-symposium.org 
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info 
>

Re: [julia-users] scoping wat

[FANG Colin]

Python has similar rules.

x = 10 
def foo(): 
print x
x = 5 
print x 
foo()

UnboundLocalError: local variable 'x' referenced before assignment


On Tuesday, April 12, 2016 at 1:52:23 PM UTC+1, Didier Verna wrote:
>
> Mauro  wrote: 
>
> > Maybe you can be a bit more explicit in what you mean, examples would 
> > help too. 
>
>   Sorry for the fuzziness. This is an example of what I mean: 
>
> let 
>   x = 10 
> end 
>
> here, the same expression "x = 10" will either assign a new value to x 
> if such a /global/ exists, or create a new /local/ binding. This is 
> already bad enough[1]. Then, begin/end behaves differently. Then, "if" 
> doesn't introduce a new block, but some others constructs do, and some 
> don't. And then, some like "for" do or don't, it depends. 
>
> Now even worse: 
> x = 10 
> function foo() 
>   println(x) 
>   x = 5 
>   println(x) 
> end 
>
> will break on the first println (one could expect to get 10, the global 
> value for x) because since there is an assignment /later on/, a new 
> /local/ binding will be created for x (which BTW is the exact opposite 
> of what let does!), but this binding isn't available to the first 
> println. And also, since a variable cannot switch from global to local 
> (or vice-versa) in the same block, the intuition (well, mine anyway ;-)) 
> that after the assignment, the scoping changes, is wrong. 
>
> And then, as you mention, nested functions will behave yet 
> differently. All of this looks really bad. 
>
> So IMHO, the real problem is that there are two distinct concepts: 
> assigning a new value to an existing binding, and creating a new 
> binding, possibly with an initial assignment. These are separate things 
> and mixing the two in such ways is wrong, and also quite surprising, 
> knowing the lispy side of this language. 
>
>
>
> Footnotes: 
> [1]  consider that a simple typo in your code may lead to silently 
> creating a new variable, which will never be used. 
>
> -- 
> ELS'16 registration open! http://www.european-lisp-symposium.org 
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info 
>

[julia-users] What is Task switch not allowed from inside gc finalizer?

[FANG Colin]

 type C
   x::Symbol
 
   function C(x::Symbol)
  c = new(x)
  finalizer(c, c->println(1, c, 2))
  c
end
 end

a = C(:x)
a = 1
gc()

error in running finalizer: ErrorException("task switch not allowed from 
inside gc finalizer")

However, it works if I manually call finalizer(a).

So, what's wrong with my usage of finalizer?

Also, it seems I can only use finalizer(a) once, it doesn't work for the 
2nd time? 

[julia-users] Re: What version of libstdc++6 does libjulia.so use?

[FANG Colin]

I am writing a library in Python that needs to import julia. If I do the 
"load julia's libstdc++ first" trick, it means all users of my library have 
to do the same.

Are there any alternative solutions?

On Monday, April 11, 2016 at 1:07:43 PM UTC+1, Tony Kelman wrote:
>
> Load Julia's libstdc++ before anything else?

[julia-users] What version of libstdc++6 does libjulia.so use?

[FANG Colin]

I installed julia via the official linux generic binaries. And I managed to 
call julia from python.

However, because libjulia.so links to its own libstdc++.so.6, if I import 
other libraries which need system libstdc++.so in python before julia, I 
would end up with missing symbol when link libjulia.so (Becuase it reuses 
the system's libstdc++ instead)

My system libstdc++.so.6 is version 4.8.4, the error is version 
`GLIBCXX_3.4.20' not found
I tried to upgrade my system libstdc++.so.t to version, 5.3.0, still error: 
symbol _ZTTNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE, 
version GLIBCXX_3.4.21 not defined.

I don't like change LD_LIBRARY_PATH to julia's `libstdc++` so that 
overrides the system's one either.

What should I do then?

Re: [julia-users] constructor & function have different promotion rules?

[FANG Colin]

Thank you

On 5 April 2016 at 15:47, Josh Langsfeld <jdla...@gmail.com> wrote:

> This is noted in the docs. See a few paragraphs down, "When a type is
> applied like a function..."
>
> http://docs.julialang.org/en/release-0.4/manual/types/#composite-types
>
> On Tuesday, April 5, 2016 at 10:19:05 AM UTC-4, FANG Colin wrote:
>>
>> methods(TT)
>>
>>  call(::Type{TT}, x::Float64, y::Float64) at In[22]:2
>>  call(::Type{TT}, x, y) at In[22]:2
>>  call{T}(::Type{T}, arg) at essentials.jl:56
>>  call{T}(::Type{T}, args...) at essentials.jl:57
>>
>>
>> So I guess the rule is applied in  call(::Type{TT}, x, y)
>>
>> What does it do? Does it try to convert(Float64, x) & convert(Float64,
>> y)? I.e does it always try to convert each argument to the type of the
>> field defined in the type?
>>
>> On 5 April 2016 at 15:11, Yichao Yu <yyc...@gmail.com> wrote:
>>
>>> On Tue, Apr 5, 2016 at 10:09 AM, FANG Colin <coli...@gmail.com> wrote:
>>> > Sorry if this has been discussed somewhere as I am unable to find the
>>> > relative post.
>>> >
>>> > immutable TT
>>> > x::Float64
>>> > y::Float64
>>> > end
>>> >
>>> > function tt(x::Float64, y::Float64)
>>> > x + y
>>> >
>>> > end
>>> > tt(1,2) # doesn't work
>>> > TT(1,2) # works
>>>
>>> There are automatic constructors defined with conversion not promotion.
>>> See `methods(TT)`
>>>
>>> >
>>> > What rule applies here for TT(1,2)?
>>>
>>
>>

Re: [julia-users] constructor & function have different promotion rules?

[FANG Colin]

methods(TT)

 call(::Type{TT}, x::Float64, y::Float64) at In[22]:2
 call(::Type{TT}, x, y) at In[22]:2
 call{T}(::Type{T}, arg) at essentials.jl:56
 call{T}(::Type{T}, args...) at essentials.jl:57


So I guess the rule is applied in  call(::Type{TT}, x, y)

What does it do? Does it try to convert(Float64, x) & convert(Float64, y)?
I.e does it always try to convert each argument to the type of the field
defined in the type?

On 5 April 2016 at 15:11, Yichao Yu <yyc1...@gmail.com> wrote:

> On Tue, Apr 5, 2016 at 10:09 AM, FANG Colin <colinf...@gmail.com> wrote:
> > Sorry if this has been discussed somewhere as I am unable to find the
> > relative post.
> >
> > immutable TT
> > x::Float64
> > y::Float64
> > end
> >
> > function tt(x::Float64, y::Float64)
> > x + y
> >
> > end
> > tt(1,2) # doesn't work
> > TT(1,2) # works
>
> There are automatic constructors defined with conversion not promotion.
> See `methods(TT)`
>
> >
> > What rule applies here for TT(1,2)?
>

[julia-users] constructor & function have different promotion rules?

[FANG Colin]

Sorry if this has been discussed somewhere as I am unable to find the 
relative post.

immutable TT
x::Float64
y::Float64
end

function tt(x::Float64, y::Float64)
x + y

end
tt(1,2) # doesn't work
TT(1,2) # works

What rule applies here for TT(1,2)?

[julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

[FANG Colin]

+ 1 to Gabriel's reply.

On Tuesday, April 5, 2016 at 2:36:09 PM UTC+1, Gabriel Gellner wrote:
>
> you can do the python example as:
>
> a[[1, 4] + range(7, 17, 2)]
> (ignoring the issues that this is not the same range as julia since python 
> uses 0-based indices ...)
>
> you don't need to index with an ndarray, and that way you can get the nice 
> use of the + operator for concatenate.
>
> Lacking the : for range does make some code more verbose, but you get used 
> to it.
>
> For the julia example isn't matlab like concatenation using ';' being 
> removed from julia?
>
> As to the overall topic I don't think it is fair to have to poo-poo python 
> to also feel that julia does it well. I really like both. Arguing about 0 
> vs 1 based indexing is like emacs vs vi ... it leads to nothing but madness 
> ...
>
> R + matlab + julia + fortran + Mathematica use 1 based and the world 
> hasn't ended
>
> sometimes 0 based is nice, but you get used to not having it, just like 
> you get used to having it.
>
> As for the truncating integer div ... I do hate that that in python and do 
> "from __future__ import division" always ;)
>
> On Monday, April 4, 2016 at 11:55:40 PM UTC-7, DNF wrote:
>>
>> Typo, I meant to type:
>>
>> Python 3.5
>> a[i*len(a)//n:(i+1)*len(a)//n]
>>
>> Julia:
>> a[1+i*end÷n:(i+1)end÷n]
>>
>> I'm just learning Python, and must say I find indexing in Python to be 
>> very awkward compared to Julia or Matlab. Do you have any suggestion for 
>> how I should do this in Python?
>> a[[1; 4; 7:2:15]]
>> So far I've got:
>> a[np.concatenate(([1,4], np.arange(7,17,2)))]
>>
>>
>>
>>
>> On Tuesday, April 5, 2016 at 8:46:57 AM UTC+2, DNF wrote:
>>>
>>>
>>> On Saturday, April 2, 2016 at 1:55:55 PM UTC+2, Spiritus Pap wrote:

 A simple example why it makes my *life hard*: Assume there is an array 
 of size 100, and i want to take the i_th portion of it out of n. This is a 
 common scenario for research-code, at least for me and my friends.
 In python:
 a[i*100/n:(i+1)*100/n]
 In julia:
 a[1+div(i*100,n):div((i+1)*100,n)]

 A lot more cumbersome in julia, and it is annoying and unattractive. 
 This is just a simple example.

>>>
>>> Python 3.5
>>> a[i*len(a)//n:(i+1)*len(a)//n]
>>>
>>> Julia:
>>> a[1+i*end÷5:(i+1)end÷5] 
>>>
>>>

[julia-users] Re: Is there a performance penalty for defining functions inside functions?

[FANG Colin]

What about include in a function?

function mainFunc()
include("helper.jl")

call helper() and do stuff
return something
end


inside helper.jl

function helper()
do stuff
return something
end



On Wednesday, March 30, 2016 at 1:26:22 PM UTC+1, Christopher Fisher wrote:
>
> There might be some cases where defining functions within functions can 
> improve speed. As Mauro noted, this may not be true in .4 but will be fixed 
> in .5. See the following for examples:
>
>
> https://groups.google.com/forum/#!searchin/julia-users/Passing$20data$20through$20Optim/julia-users/a_81sxvb-3c/9q6RvjfkBwAJ
>
> On Tuesday, March 29, 2016 at 12:31:42 PM UTC-4, Evan Fields wrote:
>>
>> To keep namespaces clear and to help with code readability, I might like 
>> to do this:
>>
>> function mainFunc()
>> function helper()
>> do stuff
>> return something
>> end
>>
>> call helper() and do stuff
>> return something
>> end
>>
>> That way the helper function is only visible to the function that needs 
>> it and when reading the code it's obvious that the helper "belongs to" the 
>> main function. Is there any performance penalty for doing this? Or is this 
>> bad practice for some reason I don't know?
>>
>

[julia-users] Nothing conditional operator

[FANG Colin]

Hi All


I found my self writing code like this a lot:

x = get_a(...)

if x != nothing
y::A = x
do_sth(y, ...)
end

In the above, I have to check for nothing first, and if it is not nothing, 
then I do a type assert to make sure the type is what I expected.

Is there any function or macro in Julia that can help this?

I know in F#, I have option.bind, so option.bind f x is equivalent to a 
pattern match:  if x is None - > None; if x is something -> f(something)

Also in C#, I have "customers?[0]?.Orders?.Count();"  (as long as there is 
null before ?, it returns null immediately)

Does Julia have something similar?

[julia-users] Re: Abstract typed array construction JIT performance

[FANG Colin]

All right that makes sense.

On Thursday, March 3, 2016 at 1:50:09 PM UTC, Lutfullah Tomak wrote:
>
> Hi Colin,
> I think if getindex inlined in vect it is not compiled seperately for your 
> second run. Check code generated with @code_* for youreself.

[julia-users] is Union type a preferred way in Julia?

[FANG Colin]

I know in F# people encourage Discriminated Unions, what about in Julia?

I would like to do the following:

immutable B end
immutable C end

typealias A Union{B,C}

function A(x::Int)
if x > 0
B()
else
C()
end
end

But it doesn't work because I cannot add a constructor for union type?

Is Union a preferred way in Julia in this case, or abstract type + 
inheritance is better?

Does union type solves the problem of unstable return type from the 
function at all?

[julia-users] Re: immutability, value types and reference types?

[FANG Colin]

My guess purely:  I thought if a immutable type is big enough, it was 
implemented as a reference type. (Otherwise each time when it is passed to 
a function, a lot of memory copy is performed).

immutable Big
a1::Int
a2::Int
...
a1000::Int
end



On Thursday, January 21, 2016 at 3:55:49 AM UTC, asy...@gmail.com wrote:
>
> Julia's immutable types are value types and mutable types are reference 
> types. In the Julia docs on types there is a paragraph that begins:
>
>  "It is instructive, particularly for readers whose background is C/C++, 
> to consider why these two properties go hand in hand. [...]" 
>
> However this paragraph only explains why value types should be immutable, 
> it doesn't describe why you can't define a reference type that is 
> immutable. So, why not? 
>

[julia-users] Symbol & Expr

[FANG Colin]

Hi all

I have got 2 questions:

1. I have a list, e.g. [:a, :(a + 1)], and I am not sure that type I should 
give to it.

There are 3 possible solutions I can think of.

A. Do we have something that can convert a Symbol to an Expr?
B. Or, should I assign the list to be Union{Symbol, Expr}?
C. Perhaps, do we already have any abstract types that means evalable?


2. I have a complex nested expression, and I would like to get all user 
defined symbols out of it.

A. Do we have something that can flatten the expression into a list of 
symbols?
B. Do we have something that filters out all julia base class symbols? (so 
what's remaining is the user defined symbols).
C. Or maybe there are smarter ways of doing it?

Thanks

[julia-users] Re: typealias vs. const

[FANG Colin]

I have got the same confusion. Any ideas?

I have even seen usage of A = T (no const) 
(http://docs.julialang.org/en/release-0.4/manual/types/#type-unions), is it 
supposed to be bad (slow) because it is a global variable?



On Thursday, November 6, 2014 at 3:38:41 PM UTC, Steven G. Johnson wrote:
>
> Given a type T, what is the difference in practice between
>  typealias A T
> and 
>  const A = T
> ?
>
> There seems to be some disagreement over which one to use (e.g. 
> https://github.com/JuliaLang/Compat.jl/commit/8211e38ac7d8448298a2bb3ab36d6f0b6398b577
> ).
>
> My impression is that there is no difference, and that the only advantage 
> of a typealias is that it can be parameterized.  Is that right?
>
> If they are equivalent, what is the Julian style?  Even in Julia Base it 
> doesn't seem to be entirely consistent.
>

Re: [julia-users] Re: in place version of .* and .+ for matrix piecewise operation?

[FANG Colin]

Thanks for the tip, just about time I try out @devec.
Right I forgot that I can make use of blas manually!

On 28 October 2015 at 14:25, STAR0SS  wrote:

> You can try axpy! for the addition case, might be faster:
>
>
> http://docs.julialang.org/en/release-0.4/stdlib/linalg/#Base.LinAlg.BLAS.axpy
> !
>

[julia-users] in place version of .* and .+ for matrix piecewise operation?

[FANG Colin]

Hi all

I am wondering if there exist the in place version of .* and .+, for matrix 
piecewise operation, so that it reduces memory allocation?

Or is there a plan to add them?

For the moment, 

(.*)(A::SparseMatrixCSC, B::Number) = SparseMatrixCSC(A.m, A.n, copy(A.colptr), 
copy(A.rowval), A.nzval .* B) which copies the content.
Thanks

[julia-users] Re: For loop = or in?

[FANG Colin]

Thank you. In that case I will happily stick with `in`.

On Monday, October 26, 2015 at 8:43:22 PM UTC, Alireza Nejati wrote:
>
> There is no difference, as far as I know.
>
> '=' seems to be used more for explicit ranges (i = 1:5) and 'in' seems to 
> be used more for variables (i in mylist). But using 'in' for everything is 
> ok too.
>
> The '=' is there for familiarity with matlab. Remember that julia's syntax 
> was in part designed to be familiar to matlab users.
>
> On Tuesday, October 27, 2015 at 8:26:07 AM UTC+13, FANG Colin wrote:
>>
>> Hi All
>>
>> I have got a stupid question:
>>
>> Are there any difference in "for i in 1:5" and "for i = 1:5"?
>>
>> Does the julia community prefer one to the other? I see use of both in 
>> the documentations and source code.
>>
>> Personally I haven't seen much use of "for i = 1:5" in other languages.
>>
>> Thanks.
>>
>

[julia-users] For loop = or in?

[FANG Colin]

Hi All

I have got a stupid question:

Are there any difference in "for i in 1:5" and "for i = 1:5"?

Does the julia community prefer one to the other? I see use of both in the 
documentations and source code.

Personally I haven't seen much use of "for i = 1:5" in other languages.

Thanks.