Re: [julia-users] Re: Factorization of big integers is taking too long

[Bill Hart]

To make a concrete suggestion that might help, Julia might benefit from One
Line Factor and Lehman's algorithm (misspelled in my previous post). There
are C implementations here:

https://github.com/wbhart/flint2/blob/trunk/ulong_extras/factor_one_line.c
https://github.com/wbhart/flint2/blob/trunk/ulong_extras/factor_lehman.c

These are efficient up to around numbers of 44 bits or so. They have
heuristic complexity O(n^1/3).

If you want to go up to 64 bits, you probably want SQUFOF with a fallback
to Lehmer. That gives you at least heuristic complexity O(n^1/4):

https://github.com/wbhart/flint2/blob/trunk/ulong_extras/factor_SQUFOF.c

Feel free to derive BSD or MIT licensed versions of these for Julia.

Bill.

On 16 March 2015 at 07:42, Hans W Borchers  wrote:

> Thanks, I know. When I need to factor large numbers I can use specialized
> software, and for mid-sized problems I can easily live with PARI/GP (or
> perhaps Flint in the future). And I can live with probabilistic prime
> testing.
>
> All that is not my problem. I would like to have factor() in Julia work as
> fast as in R or Python, and certainly not try to factor big integers with
> trial division. Elliptic curve or quadratic sieve methods may come later.
>
>
>
> On Monday, March 16, 2015 at 7:14:00 AM UTC+1, Bill Hart wrote:
>>
>> Factoring large integers is an open research problem. The issue is
>> definitely nothing to do with Julia's handling of bignums, or its use of
>> GMP (there is no competitive factoring algorithm in GMP).
>>
>> Fixing that problem properly is on the order of about 120,000 lines of C
>> code, if you want to be truly up-to-date.
>>
>> Here is a list of algorithms you need to factor big numbers fast:
>>
>> trial division
>> perfect power testing
>> lehmer
>> pollard rho
>> SQUFOF
>> p-1
>> p+1
>> elliptic curve method
>> quadratic sieve (self initialising, multiple polynomial, small, large and
>> double large prime variants)
>> general number field sieve (active open research area)
>>
>> then you need to be able to check for primality reliably to certify that
>> you have actually fully factored your numbers, for which you will want
>>
>> a lookup table for small primes
>> trial division
>> strong probable prime test
>> Lucas test
>> Baillie-PSW
>> Miller-Rabin
>> Pocklington-Lehmer p-1 test
>> Morrison's p+1 test (+ Brillhart, Lehmer, Selfridge improvements)
>> APR-CL or ECPP
>>
>> You might like to look at the msieve library and the GMP-ECM library.
>> That will take most of the burden off you. If you want to factor numbers
>> bigger than about 100 decimal digits, you need something like CADO-NFS. If
>> you want to factor numbers bigger than 200 digits you need a miracle.
>>
>> Hopefully flint will also have something relatively competitive by the
>> end of the summer, though it isn't specialised just on those problems. We
>> are still missing APR-CL, qsieve, ECM which we plan to add over the next
>> few months to a year, and we don't have any plans for a general number
>> field sieve at this point.
>>
>> Note that the primality testing in GMP is for probable prime testing
>> only. It sometimes (exceedingly rarely) says composite numbers are prime.
>> It does no primality proving (i.e. it has no APR-CL or ECPP).
>>
>

Re: [julia-users] Re: dict comprehension syntax in 0.4

[Tamas Papp]

I think that in 0.4, => is not merely syntax, but a constructor for a
Pair. So you can do

julia> [Pair(i,2*i) for i = 1:3]
3-element Array{Pair{Int64,Int64},1}:
 1=>2
 2=>4
 3=>6

and using the => is just syntactic sugar.

My understanding that [1=>2, 3=>4] is deprecated because it will
eventually construct [Pair(1,2), Pair(3,4)] to be consistent.

(type1=>type2)[...] comprehensions are syntactic sugar for creating
Dicts.

HTH,

Tamas

On Mon, Mar 16 2015, Jim Garrison wrote:

> Bumping this since I am still curious and have been unable to figure out
> the answer.
>
> Is intentional that dict comprehensions (and typed dict comprehensions)
> still use the old syntax for dictionaries?
>
> julia> (Int=>Int)[i=>i for i in 1:2] == Dict{Int,Int}(1=>1, 2=>2)
> true
>
> On Thursday, March 12, 2015 at 9:08:56 AM UTC-7, Jim Garrison wrote:
>>
>> It is well known that the dict syntax in 0.4 has changed
>>
>>  julia> [1=>2,3=>4]
>>  WARNING: deprecated syntax "[a=>b, ...]".
>>  Use "Dict(a=>b, ...)" instead.
>>
>> However, I was surprised to notice that a similar syntax still works for
>> dict comprehensions, without warning:
>>
>>  julia> [i => 2i for i = 1:3]
>>  Dict{Int64,Int64} with 3 entries:
>>2 => 4
>>3 => 6
>>1 => 2
>>
>> Is this intentional?
>>

Re: [julia-users] Re: Factorization of big integers is taking too long

[Bill Hart]

I'm not sure what you mean by "big". Without ECM or QS you won't
efficiently factor numbers bigger than about 20 digits (except in random
cases where you happen to get lucky).

Bill.

On 16 March 2015 at 07:42, Hans W Borchers  wrote:

> Thanks, I know. When I need to factor large numbers I can use specialized
> software, and for mid-sized problems I can easily live with PARI/GP (or
> perhaps Flint in the future). And I can live with probabilistic prime
> testing.
>
> All that is not my problem. I would like to have factor() in Julia work as
> fast as in R or Python, and certainly not try to factor big integers with
> trial division. Elliptic curve or quadratic sieve methods may come later.
>
>
>
> On Monday, March 16, 2015 at 7:14:00 AM UTC+1, Bill Hart wrote:
>>
>> Factoring large integers is an open research problem. The issue is
>> definitely nothing to do with Julia's handling of bignums, or its use of
>> GMP (there is no competitive factoring algorithm in GMP).
>>
>> Fixing that problem properly is on the order of about 120,000 lines of C
>> code, if you want to be truly up-to-date.
>>
>> Here is a list of algorithms you need to factor big numbers fast:
>>
>> trial division
>> perfect power testing
>> lehmer
>> pollard rho
>> SQUFOF
>> p-1
>> p+1
>> elliptic curve method
>> quadratic sieve (self initialising, multiple polynomial, small, large and
>> double large prime variants)
>> general number field sieve (active open research area)
>>
>> then you need to be able to check for primality reliably to certify that
>> you have actually fully factored your numbers, for which you will want
>>
>> a lookup table for small primes
>> trial division
>> strong probable prime test
>> Lucas test
>> Baillie-PSW
>> Miller-Rabin
>> Pocklington-Lehmer p-1 test
>> Morrison's p+1 test (+ Brillhart, Lehmer, Selfridge improvements)
>> APR-CL or ECPP
>>
>> You might like to look at the msieve library and the GMP-ECM library.
>> That will take most of the burden off you. If you want to factor numbers
>> bigger than about 100 decimal digits, you need something like CADO-NFS. If
>> you want to factor numbers bigger than 200 digits you need a miracle.
>>
>> Hopefully flint will also have something relatively competitive by the
>> end of the summer, though it isn't specialised just on those problems. We
>> are still missing APR-CL, qsieve, ECM which we plan to add over the next
>> few months to a year, and we don't have any plans for a general number
>> field sieve at this point.
>>
>> Note that the primality testing in GMP is for probable prime testing
>> only. It sometimes (exceedingly rarely) says composite numbers are prime.
>> It does no primality proving (i.e. it has no APR-CL or ECPP).
>>
>

Re: [julia-users] Re: Factorization of big integers is taking too long

[Hans W Borchers]

Thanks, I know. When I need to factor large numbers I can use specialized 
software, and for mid-sized problems I can easily live with PARI/GP (or 
perhaps Flint in the future). And I can live with probabilistic prime 
testing.

All that is not my problem. I would like to have factor() in Julia work as 
fast as in R or Python, and certainly not try to factor big integers with 
trial division. Elliptic curve or quadratic sieve methods may come later.


On Monday, March 16, 2015 at 7:14:00 AM UTC+1, Bill Hart wrote:
>
> Factoring large integers is an open research problem. The issue is 
> definitely nothing to do with Julia's handling of bignums, or its use of 
> GMP (there is no competitive factoring algorithm in GMP).
>
> Fixing that problem properly is on the order of about 120,000 lines of C 
> code, if you want to be truly up-to-date.
>
> Here is a list of algorithms you need to factor big numbers fast:
>
> trial division
> perfect power testing
> lehmer
> pollard rho
> SQUFOF
> p-1
> p+1
> elliptic curve method
> quadratic sieve (self initialising, multiple polynomial, small, large and 
> double large prime variants)
> general number field sieve (active open research area)
>
> then you need to be able to check for primality reliably to certify that 
> you have actually fully factored your numbers, for which you will want
>
> a lookup table for small primes
> trial division
> strong probable prime test
> Lucas test
> Baillie-PSW
> Miller-Rabin
> Pocklington-Lehmer p-1 test
> Morrison's p+1 test (+ Brillhart, Lehmer, Selfridge improvements)
> APR-CL or ECPP
>
> You might like to look at the msieve library and the GMP-ECM library. That 
> will take most of the burden off you. If you want to factor numbers bigger 
> than about 100 decimal digits, you need something like CADO-NFS. If you 
> want to factor numbers bigger than 200 digits you need a miracle.
>
> Hopefully flint will also have something relatively competitive by the end 
> of the summer, though it isn't specialised just on those problems. We are 
> still missing APR-CL, qsieve, ECM which we plan to add over the next few 
> months to a year, and we don't have any plans for a general number field 
> sieve at this point.
>
> Note that the primality testing in GMP is for probable prime testing only. 
> It sometimes (exceedingly rarely) says composite numbers are prime. It does 
> no primality proving (i.e. it has no APR-CL or ECPP).
>

[julia-users] Re: dict comprehension syntax in 0.4

[Jim Garrison]

Bumping this since I am still curious and have been unable to figure out 
the answer.

Is intentional that dict comprehensions (and typed dict comprehensions) 
still use the old syntax for dictionaries?

julia> (Int=>Int)[i=>i for i in 1:2] == Dict{Int,Int}(1=>1, 2=>2)
true

On Thursday, March 12, 2015 at 9:08:56 AM UTC-7, Jim Garrison wrote:
>
> It is well known that the dict syntax in 0.4 has changed 
>
>  julia> [1=>2,3=>4] 
>  WARNING: deprecated syntax "[a=>b, ...]". 
>  Use "Dict(a=>b, ...)" instead. 
>
> However, I was surprised to notice that a similar syntax still works for 
> dict comprehensions, without warning: 
>
>  julia> [i => 2i for i = 1:3] 
>  Dict{Int64,Int64} with 3 entries: 
>2 => 4 
>3 => 6 
>1 => 2 
>
> Is this intentional? 
>

Re: [julia-users] Re: Factorization of big integers is taking too long

[Bill Hart]

Factoring large integers is an open research problem. The issue is 
definitely nothing to do with Julia's handling of bignums, or its use of 
GMP (there is no competitive factoring algorithm in GMP).

Fixing that problem properly is on the order of about 120,000 lines of C 
code, if you want to be truly up-to-date.

Here is a list of algorithms you need to factor big numbers fast:

trial division
perfect power testing
lehmer
pollard rho
SQUFOF
p-1
p+1
elliptic curve method
quadratic sieve (self initialising, multiple polynomial, small, large and 
double large prime variants)
general number field sieve (active open research area)

then you need to be able to check for primality reliably to certify that 
you have actually fully factored your numbers, for which you will want

a lookup table for small primes
trial division
strong probable prime test
Lucas test
Baillie-PSW
Miller-Rabin
Pocklington-Lehmer p-1 test
Morrison's p+1 test (+ Brillhart, Lehmer, Selfridge improvements)
APR-CL or ECPP

You might like to look at the msieve library and the GMP-ECM library. That 
will take most of the burden off you. If you want to factor numbers bigger 
than about 100 decimal digits, you need something like CADO-NFS. If you 
want to factor numbers bigger than 200 digits you need a miracle.

Hopefully flint will also have something relatively competitive by the end 
of the summer, though it isn't specialised just on those problems. We are 
still missing APR-CL, qsieve, ECM which we plan to add over the next few 
months to a year, and we don't have any plans for a general number field 
sieve at this point.

Note that the primality testing in GMP is for probable prime testing only. 
It sometimes (exceedingly rarely) says composite numbers are prime. It does 
no primality proving (i.e. it has no APR-CL or ECPP).

[julia-users] Re: how should I let this macro worked?

[Miao Yang]

Need something like Clojure "~@" unquote-splice?

Re: [julia-users] Some simple use cases for multi-threading

[Viral Shah]

This is a great example. If you are familiar with it, can you submit a PR? I 
think it would be a great addition to our perf suite in general, and an 
excellent candidate for multi-threading.

-viral



> On 16-Mar-2015, at 10:22 am, James Fairbanks  wrote:
> 
> The graph 500 benchmark was developed to help people benchmark machines and 
> programming environments for graph algorithms which tend to be different from 
> numerical algorithms. There is a reference implementation in octave 
> available. It should be a good example problem.
> 
> http://www.graph500.org/specifications
> 
> http://www.graph500.org/referencecode

[julia-users] how should I let this macro worked?

[Miao Yang]

macro awhen(expr, body...)
esc(quote
let it = $(expr)
  if it != nothing
$(body...)
  end
end
   end)
end

julia> @awhen([1, 2, 3], it[2]) # workds fine
2
julia> @awhen(nothing, it[2]) # workds fine

julia> @awhen([1, 2, 3], x = 1, it[x]) # :(, failed

ERROR: unsupported or misplaced expression kw


julia> macroexpand(:@awhen([1,2,3], x = 1, it[x]))
quote  # none, line 3:
let it = [1,2,3] # line 4:
if it != nothing # line 5:
x=1
it[x]
end
end
end


Have no idea how to let this worked...
Please help me, thanks.

Re: [julia-users] Re: Factorization of big integers is taking too long

[andy hayden]

Perhaps this (factor of large big int) is a good perf/test case for 
https://github.com/JuliaLang/julia/pull/10084

On Sunday, 15 March 2015 06:54:51 UTC-7, Tim Holy wrote:
>
> I don't know the algorithm, but my point is that 
> c = a*b 
> will, for a BigInt, allocate memory. Because Numbers are immutable and 
> BigInts 
> are Numbers, you can't write an algorithm mult!(c, a, b) that stores the 
> result in a pre-allocated "scratch space" c. Hence, you're doomed to 
> inefficiency compared to an implementation in C that uses such tricks. 
> Don't get 
> me wrong, in the context of the overall Julia ecosystem our current design 
> is 
> right one (immutability is a really awesome and important property), but 
> there 
> are downsides. 
>
> But you don't have to live with the status quo. If you need efficient 
> BigInt 
> calculations, perhaps a MutableBigInts.jl package would be in order. You 
> could 
> define an OpaqueBigInt type (which would _not_ be a subtype of Number) and 
> implement mult!(c, a, b), add!(c, a, b), etc for that type. You could 
> basically copy the bigint implementation in base. gmp.jl is only 500 lines 
> of 
> code and the changes might be very minimal, so you may be able to knock 
> this 
> out in an afternoon :-). That is, unless making them not-numbers has too 
> many 
> negative consequences. (You may find yourself creating additional methods 
> of 
> other functions.) 
>
> Best, 
> --Tim 
>
> On Sunday, March 15, 2015 06:39:23 AM Hans W Borchers wrote: 
> > Tim, sorry, I do not understand what you mean here. 
> > Do you argue that it is not possible to write a relatively fast 
> > implementation of, e.g., Pollard's Rho algorithm in Julia. 
> > 
> > On Sunday, March 15, 2015 at 2:19:47 PM UTC+1, Tim Holy wrote: 
> > > It's more than a question of which algorithm to use: the immutability 
> of 
> > > numbers means that every single bignum addition or multiplication 
> requires 
> > > allocation. So currently, julia is going to have a hard time competing 
> > > with a 
> > > hand-rolled method that allocates a cache of numbers to (re)use as 
> scratch 
> > > space for calculations. You can do this if you're willing to manage 
> all 
> > > these 
> > > temporaries manually. 
> > > 
> > > The best solution would be to make julia smart enough to do that 
> "behind 
> > > the 
> > > scenes." This is a very interesting but nontrivial problem (with 
> potential 
> > > costs if it's "close but not smart enough"). 
> > > 
> > > --Tim 
>
>

[julia-users] Some simple use cases for multi-threading

[James Fairbanks]

The graph 500 benchmark was developed to help people benchmark machines and 
programming environments for graph algorithms which tend to be different from 
numerical algorithms. There is a reference implementation in octave available. 
It should be a good example problem.

http://www.graph500.org/specifications

http://www.graph500.org/referencecode

[julia-users] Re: Unable to find were it breaks IUP (0.4 after 0.4.0-dev+3703)

[J Luis]

In my machine (Win8 64), 488 is the size limit for that immutable. 

With 489 ==> Kaboomm

segunda-feira, 16 de Março de 2015 às 04:27:38 UTC, J Luis escreveu:
>
> I may have found a very important piece.
>
> If I shrink the immutable Array_1024_Uint8 in
>  https://github.com/joa-quim/IUP.jl/blob/master/src/libcd_h.jl#L154
> to, let say, 4 members than the whole program works again. So apparently 
> it's a size matter!
>
> segunda-feira, 16 de Março de 2015 às 03:06:14 UTC, J Luis escreveu:
>>
>> The changes referred in 
>> https://groups.google.com/forum/?fromgroups=#!topic/julia-users/qi6HpMrAS_A 
>> broke IUP.jl in a way that I simply cannot even identify where the breakage 
>> occurs.
>>
>> I managed to reproduce the crash with only one instruction, but even than 
>> makes no sense to me. The next two lines crash julia
>>
>> julia> using im_view_
>> julia> a=IUP.IupCanvas()
>>
>> It can be seen in 
>> https://github.com/joa-quim/IUP.jl/blob/master/src/libiup.jl#L480 that 
>> the wrapper is OK and if fact if I comment the two lines (that leave in 
>> another module)
>>
>> https://github.com/joa-quim/IUP.jl/blob/master/src/IUP_CD.jl#L349
>> https://github.com/joa-quim/IUP.jl/blob/master/src/IUP_CD.jl#L350
>>
>> that are include from the module im_view_ than I get an error of missing 
>> function (normal, since I commented its inclusions) but otherwise all seam 
>> to work.
>> So I'm left with this back trace of which I'm unable to extract any 
>> useful information.
>>
>> (On Win64 with a nightly from 2 days ago)
>>
>> Please submit a bug report with steps to reproduce this fault, and any 
>> error messages that follow (in their entirety). Thanks.
>> Exception: EXCEPTION_ACCESS_VIOLATION at 0x6bfb2b56 -- 
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown 
>> line)
>> jl_gc_collect at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> allocobj at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> jl_init_tasks at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> jl_alloc_cell_1d at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> jl_f_new_expr at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> inlineable at inference.jl:2372
>> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> inlining_pass at inference.jl:2914
>> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> inlining_pass at inference.jl:2809
>> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> typeinf_uncached at inference.jl:1745
>> jlcall_typeinf_uncached_111 at  (unknown line)
>> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> typeinf at inference.jl:1386
>> jlcall_typeinf_84 at  (unknown line)
>> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
>> typeinf at inference.jl:1345
>> jl_apply_generic at V:\Julia-0.4.0-dev
>> ...
>
>

[julia-users] Re: Unable to find were it breaks IUP (0.4 after 0.4.0-dev+3703)

[J Luis]

I may have found a very important piece.

If I shrink the immutable Array_1024_Uint8 in
 https://github.com/joa-quim/IUP.jl/blob/master/src/libcd_h.jl#L154
to, let say, 4 members than the whole program works again. So apparently 
it's a size matter!

segunda-feira, 16 de Março de 2015 às 03:06:14 UTC, J Luis escreveu:
>
> The changes referred in 
> https://groups.google.com/forum/?fromgroups=#!topic/julia-users/qi6HpMrAS_A 
> broke IUP.jl in a way that I simply cannot even identify where the breakage 
> occurs.
>
> I managed to reproduce the crash with only one instruction, but even than 
> makes no sense to me. The next two lines crash julia
>
> julia> using im_view_
> julia> a=IUP.IupCanvas()
>
> It can be seen in 
> https://github.com/joa-quim/IUP.jl/blob/master/src/libiup.jl#L480 that 
> the wrapper is OK and if fact if I comment the two lines (that leave in 
> another module)
>
> https://github.com/joa-quim/IUP.jl/blob/master/src/IUP_CD.jl#L349
> https://github.com/joa-quim/IUP.jl/blob/master/src/IUP_CD.jl#L350
>
> that are include from the module im_view_ than I get an error of missing 
> function (normal, since I commented its inclusions) but otherwise all seam 
> to work.
> So I'm left with this back trace of which I'm unable to extract any useful 
> information.
>
> (On Win64 with a nightly from 2 days ago)
>
> Please submit a bug report with steps to reproduce this fault, and any 
> error messages that follow (in their entirety). Thanks.
> Exception: EXCEPTION_ACCESS_VIOLATION at 0x6bfb2b56 -- 
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_profile_is_running at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line
> )
> jl_gc_collect at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> allocobj at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> jl_init_tasks at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> jl_alloc_cell_1d at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> jl_f_new_expr at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> inlineable at inference.jl:2372
> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> inlining_pass at inference.jl:2914
> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> inlining_pass at inference.jl:2809
> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> typeinf_uncached at inference.jl:1745
> jlcall_typeinf_uncached_111 at  (unknown line)
> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> typeinf at inference.jl:1386
> jlcall_typeinf_84 at  (unknown line)
> jl_apply_generic at V:\Julia-0.4.0-dev\bin\libjulia.dll (unknown line)
> typeinf at inference.jl:1345
> jl_apply_generic at V:\Julia-0.4.0-dev
> ...

Re: [julia-users] Re: indexing with non Integer Reals is deprecated

[elextr]

Stephan, do we know that a real is always float64?

Cheers
Lex

On Monday, March 16, 2015 at 9:34:57 AM UTC+10, Stefan Karpinski wrote:
>
> On Sun, Mar 15, 2015 at 7:24 PM, > wrote:
>
>> The problem is that its fairly easy to be casually wrong when using reals 
>> as indexes.  What does 10. index? (Hint: floating point numbers can't 
>> represent 10 exactly, its 9.99...)
>
>
> This is simply untrue. All integers between ±2^53 can be represented 
> exactly as Float64s. Beyond that, many integers can be represented exactly, 
> but not all of them.
>

Re: [julia-users] Looking for incomplete SVD -- need only some of the singular values

[Jiahao Chen]

> I've looked for other packages that could be wrapped, but couldn't find 
any that offers this feature. The only thing I found is a description of 
the "svds" Matlab routine, which is apparently based on "eigs". 

If you want a canned routine, you're best off with svds(A) in base Julia 
(wraps ARPACK) or tsvd(A) in https://github.com/andreasnoack/PROPACK.jl 
(work in progress to wrap PROPACK). The other package I'm aware of is 
SLEPc, but it requires the entire PETSc stack.

Note that the singular values of A are essentially the square root of the 
magnitude of the eigenvalues of AA', or A'A, or [0 A; A' 0], so eigenvalue 
routines can be used to solve the singular value problem.

If you only need the largest singular value and its left singular vector, a 
simple quick and dirty DIY scheme is to do power iteration on AA':

A = randn(m, n)
u = randn(n) #some guess
for i=1:10 #some number of iterations
   u = A*(A'u)
   scale!(u, 1/norm(u))
end
σ = norm(A'u) #σ, u are the largest singular value and its left singular 
vector

There is a simple generalization to the largest k singular values and their 
left singular vectors.

Re: [julia-users] Looking for incomplete SVD -- need only some of the singular values

[Viral Shah]

There's svds, which uses Arnoldi iterations.

-viral

On Monday, March 16, 2015 at 5:54:57 AM UTC+5:30, Erik Schnetter wrote:
>
> I am looking for an algorithm that produces only some of the singular 
> values, not all of them. I assume that would be cheaper. I didn't see such 
> a function in Julia's documentation. 
>
> -erik 
>
> > On Mar 15, 2015, at 18:22 , Christian Peel  wrote: 
> > 
> > What's the reason that you don't want to use Julia's SVD directly?   Is 
> your matrix especially large?   Some links that may be useful: 
> > 
> > Approximating the SVD using Julia: 
> >
> http://beowulf.lcs.mit.edu/18.337/projects/Turner-Presentation_SVD-Julia.pdf 
> >https://github.com/alexjturner/SVDapprox 
> > Approximating the SVD using the power method 
> >http://www.sci.ccny.cuny.edu/~szlam/npisvdnipsshort.pdf 
> >https://en.wikipedia.org/wiki/Power_iteration 
> > 
> > 
> > On Sun, Mar 15, 2015 at 1:10 PM, Erik Schnetter  
> wrote: 
> > I am looking for a routine that calculate the SVD (singular value 
> decomposition) of a square, complex, dense, non-symmetric matrix. I am 
> aware of Julia's SVD routine (and the respective LAPACK routines that one 
> could call directly). However, I don't need all of the singular values -- I 
> need only the largest one (or some of the largest ones), as well as the 
> associated entries of U. Is there such a routine? I didn't find one in 
> Julia. 
> > 
> > I've looked for other packages that could be wrapped, but couldn't find 
> any that offers this feature. The only thing I found is a description of 
> the "svds" Matlab routine, which is apparently based on "eigs". 
> > 
> > -erik 
> > 
> > -- 
> > Erik Schnetter  
> > 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 
> https://sks-keyservers.net. 
> > 
> > 
> > 
> > 
> > -- 
> > chris.p...@ieee.org 
>
> -- 
> Erik Schnetter  
> 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 https://sks-keyservers.net. 
>
>
>

Re: [julia-users] Some simple use cases for multi-threading

[Viral Shah]

Hi Erik,

On the threading branch, there is a 3d laplace benchmark in 
test/perf/threads or some such directory. Could you take a look at that and 
see if that serves as a good test case for you? That already shows good 
scaling to 40 processors, IIRC.

-viral

On Saturday, March 14, 2015 at 10:58:57 PM UTC+5:30, Erik Schnetter wrote:
>
> On Mar 12, 2015, at 23:52 , Viral Shah  wrote: 
> > 
> > I am looking to put together a set of use cases for our multi-threading 
> capabilities - mainly to push forward as well as a showcase. I am thinking 
> of starting with stuff in the microbenchmarks and the shootout 
> implementations that are already in test/perf. 
> > 
> > I am looking for other ideas that would be of interest. If there is real 
> interest, we can collect all of these in a repo in JuliaParallel. 
>
> Viral 
>
> I am interested in solving PDEs (partial differential equations). These 
> would be discretized on a grid or mesh, and are typically based on stencil 
> operations. Using distributed computing (multiple processes) requires ghost 
> zone exchanges that are less efficient than having multiple threads work on 
> the same array. 
>
> I can create a sample micro-benchmark if there isn't any already. 
>
> -erik 
>
> -- 
> Erik Schnetter  
> 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 https://sks-keyservers.net. 
>
>
>

Re: [julia-users] Re: Some simple use cases for multi-threading

[elextr]

On Monday, March 16, 2015 at 10:47:46 AM UTC+10, Jameson wrote:
>
> unhelpfully, i think gui's are actually a case where you may be better off 
> splitting your application into a client display process and one (or more) 
> parallel client processes, and not trying to carefully synchronize a bunch 
> of threads.
>

YMMV
 

>
> On Sun, Mar 15, 2015 at 7:28 PM > wrote:
>
>> I guess one of the standard rather simple benefits of multi-threading is 
>> to allow long running computations to not freeze an applications UI.
>>
>> Its not a sexy highly parallel benefit, but very useful :)
>>
>> Cheers
>> Lex
>>
>>
>> On Friday, March 13, 2015 at 1:52:37 PM UTC+10, Viral Shah wrote:
>>>
>>> I am looking to put together a set of use cases for our multi-threading 
>>> capabilities - mainly to push forward as well as a showcase. I am thinking 
>>> of starting with stuff in the microbenchmarks and the shootout 
>>> implementations that are already in test/perf. 
>>>
>>> I am looking for other ideas that would be of interest. If there is real 
>>> interest, we can collect all of these in a repo in JuliaParallel. 
>>>
>>> -viral 
>>>
>>>
>>>
>>>

[julia-users] Re: Some simple use cases for multi-threading

[Viral Shah]

I think the upcoming designs for building UIs with Julia should address 
this - good idea to keep it on the radar for a use case.

-viral

On Monday, March 16, 2015 at 4:58:54 AM UTC+5:30, ele...@gmail.com wrote:
>
> I guess one of the standard rather simple benefits of multi-threading is 
> to allow long running computations to not freeze an applications UI.
>
> Its not a sexy highly parallel benefit, but very useful :)
>
> Cheers
> Lex
>
> On Friday, March 13, 2015 at 1:52:37 PM UTC+10, Viral Shah wrote:
>>
>> I am looking to put together a set of use cases for our multi-threading 
>> capabilities - mainly to push forward as well as a showcase. I am thinking 
>> of starting with stuff in the microbenchmarks and the shootout 
>> implementations that are already in test/perf. 
>>
>> I am looking for other ideas that would be of interest. If there is real 
>> interest, we can collect all of these in a repo in JuliaParallel. 
>>
>> -viral 
>>
>>
>>
>>

Re: [julia-users] Some simple use cases for multi-threading

[Viral Shah]

Yes, I am referring to the real multi-threading. Thanks.

-viral

On Saturday, March 14, 2015 at 1:26:47 AM UTC+5:30, Erik Schnetter wrote:
>
> Viral 
>
> I assume you are referring to real multi-threading that is currently under 
> development, and not the multi-tasking that has been around in Julia for a 
> long time? I also assume that you are looking for use cases that will 
> benefit, not only for cases that have already benefitted? 
>
> -erik 
>
> > On Mar 12, 2015, at 23:52 , Viral Shah  wrote: 
> > 
> > I am looking to put together a set of use cases for our multi-threading 
> capabilities - mainly to push forward as well as a showcase. I am thinking 
> of starting with stuff in the microbenchmarks and the shootout 
> implementations that are already in test/perf. 
> > 
> > I am looking for other ideas that would be of interest. If there is real 
> interest, we can collect all of these in a repo in JuliaParallel. 
> > 
> > -viral 
>
> -- 
> Erik Schnetter  
> 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 https://sks-keyservers.net. 
>
>
>

Re: [julia-users] Some simple use cases for multi-threading

[Viral Shah]

This is not a completely crazy idea. We could take the building blocks from 
OpenBLAS or BLIS and do the multi-threading in Julia. The benefits will be 
that we will not have the OS threads vs. Julia threads issue, and improve 
on the current state of threading in OpenBLAS. 

Of course, this will take a bit of time.

-viral

On Saturday, March 14, 2015 at 11:20:06 PM UTC+5:30, Jameson wrote:
>
> in that case, one usage might be that it's necessary for porting a 
> competitive BLAS into julia.
>
> On Sat, Mar 14, 2015 at 1:26 PM Erik Schnetter  
> wrote:
>
>> As long as linear algebra is handled by BLAS, using multi-threading in 
>> Julia isn't really necessary. If the matrices are large enough to warrant 
>> multithreading, then using a multi-threaded BLAS is usually more 
>> efficient...
>>
>> -erik
>>
>> On Mar 13, 2015, at 16:54 , Tobias Knopp  
>> wrote:
>> >
>> > you can start with a simple matrix-vector or matrix-matrix product. 
>> imfilter (Images.jl) is also a function that can benefit from 
>> multithreading.
>> >
>> > Am Freitag, 13. März 2015 04:52:37 UTC+1 schrieb Viral Shah:
>> > I am looking to put together a set of use cases for our multi-threading 
>> capabilities - mainly to push forward as well as a showcase. I am thinking 
>> of starting with stuff in the microbenchmarks and the shootout 
>> implementations that are already in test/perf.
>> >
>> > I am looking for other ideas that would be of interest. If there is 
>> real interest, we can collect all of these in a repo in JuliaParallel.
>>
>> --
>> Erik Schnetter 
>> 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 
>> https://sks-keyservers.net.
>>
>> 

Re: [julia-users] Re: Some simple use cases for multi-threading

[Jameson Nash]

unhelpfully, i think gui's are actually a case where you may be better off
splitting your application into a client display process and one (or more)
parallel client processes, and not trying to carefully synchronize a bunch
of threads.

On Sun, Mar 15, 2015 at 7:28 PM  wrote:

> I guess one of the standard rather simple benefits of multi-threading is
> to allow long running computations to not freeze an applications UI.
>
> Its not a sexy highly parallel benefit, but very useful :)
>
> Cheers
> Lex
>
>
> On Friday, March 13, 2015 at 1:52:37 PM UTC+10, Viral Shah wrote:
>>
>> I am looking to put together a set of use cases for our multi-threading
>> capabilities - mainly to push forward as well as a showcase. I am thinking
>> of starting with stuff in the microbenchmarks and the shootout
>> implementations that are already in test/perf.
>>
>> I am looking for other ideas that would be of interest. If there is real
>> interest, we can collect all of these in a repo in JuliaParallel.
>>
>> -viral
>>
>>
>>
>>

Re: [julia-users] Looking for incomplete SVD -- need only some of the singular values

[Erik Schnetter]

I am looking for an algorithm that produces only some of the singular values, 
not all of them. I assume that would be cheaper. I didn't see such a function 
in Julia's documentation.

-erik

> On Mar 15, 2015, at 18:22 , Christian Peel  wrote:
> 
> What's the reason that you don't want to use Julia's SVD directly?   Is your 
> matrix especially large?   Some links that may be useful:
> 
> Approximating the SVD using Julia:
>
> http://beowulf.lcs.mit.edu/18.337/projects/Turner-Presentation_SVD-Julia.pdf
>https://github.com/alexjturner/SVDapprox
> Approximating the SVD using the power method
>http://www.sci.ccny.cuny.edu/~szlam/npisvdnipsshort.pdf
>https://en.wikipedia.org/wiki/Power_iteration
> 
> 
> On Sun, Mar 15, 2015 at 1:10 PM, Erik Schnetter  wrote:
> I am looking for a routine that calculate the SVD (singular value 
> decomposition) of a square, complex, dense, non-symmetric matrix. I am aware 
> of Julia's SVD routine (and the respective LAPACK routines that one could 
> call directly). However, I don't need all of the singular values -- I need 
> only the largest one (or some of the largest ones), as well as the associated 
> entries of U. Is there such a routine? I didn't find one in Julia.
> 
> I've looked for other packages that could be wrapped, but couldn't find any 
> that offers this feature. The only thing I found is a description of the 
> "svds" Matlab routine, which is apparently based on "eigs".
> 
> -erik
> 
> --
> Erik Schnetter 
> 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 https://sks-keyservers.net.
> 
> 
> 
> 
> --
> chris.p...@ieee.org

--
Erik Schnetter 
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 https://sks-keyservers.net.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[Tim Holy]

You likely have to do the same thing to Gtk as in 
https://github.com/timholy/Images.jl/commit/68126750d07dec407ed0dbbd8ba01be28ce176d1

--Tim

On Sunday, March 15, 2015 10:32:32 AM J Luis wrote:
> and bad luck with Gtk too
> 
> julia> Img = imread(
> "C://progs_cygw//GMTdev//gmt5//branches//5.2.0//test//grdimage//gdal//needle
> .jpg" );
> 
> julia> view(Img)
> (ImageCanvas,ImageSlice2d: zoom = BoundingBox(0.0,430.0,0.0,300.0))
> 
> julia> ERROR: `width` has no method matching width(::GtkCanvas)
>  in setbb! at C:\j\.julia\v0.3\ImageView\src\display.jl:80
>  in resize at C:\j\.julia\v0.3\ImageView\src\display.jl:582
>  in anonymous at C:\j\.julia\v0.3\ImageView\src\display.jl:420
>  in draw at C:\j\.julia\v0.3\Gtk\src\cairo.jl:72
>  in notify_resize at C:\j\.julia\v0.3\Gtk\src\cairo.jl:52
> 
> domingo, 15 de Março de 2015 às 16:03:00 UTC, J Luis escreveu:
> > Bear with me that I'm still very rough with the packaging system but the
> > fact that I see in my .julia/v0.4/Gtk/REQUIRE
> > 
> > Cairo 0.2.2
> > julia 0.2-
> > Graphics 0.1
> > BinDeps
> > @windows WinRPM
> > @osx Homebrew
> > 
> > does not mean that the Graphics dependency is already there?
> > 
> > domingo, 15 de Março de 2015 às 14:26:46 UTC, Tim Holy escreveu:
> >> Can you add Graphics to the REQUIRE file and submit a pull request
> >> against the
> >> gtk branch?
> >> 
> >> --Tim
> >> 
> >> On Sunday, March 15, 2015 07:13:02 AM J Luis wrote:
> >> > Thanks. On v0.3.4 it seams to work (I mean no errors on "using
> >> 
> >> ImageView")
> >> 
> >> > but on 0.4
> >> > 
> >> > julia> Pkg.checkout("ImageView", "gtk")
> >> > INFO: Checking out ImageView gtk...
> >> > INFO: Pulling ImageView latest gtk...
> >> > INFO: No packages to install, update or remove
> >> > 
> >> > julia> using ImageView
> >> > ERROR: LoadError: UndefVarError: Graphics not defined
> >> > while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in
> >> 
> >> expression
> >> 
> >> > starting on line 3
> >> > 
> >> > domingo, 15 de Março de 2015 às 13:27:23 UTC, Tim Holy escreveu:
> >> > > Pkg.checkout("ImageView", "gtk")
> >> > > 
> >> > > But I haven't updated that branch in a long time---it's being held up
> >> > > because
> >> > > I have an ambitious revamping plan for ImageView, and I just haven't
> >> > > cleared
> >> > > the two weeks it will take to implement it. So you may need to be
> >> 
> >> prepared
> >> 
> >> > > to
> >> > > fix up that gtk branch. Pull requests welcome :-).
> >> > > 
> >> > > --Tim
> >> > > 
> >> > > On Sunday, March 15, 2015 05:57:35 AM J Luis wrote:
> >> > > > Hi,
> >> > > > 
> >> > > > I can't use ImageView because of issue #67
> >> > > >  (the "Can't find
> >> 
> >> usable
> >> 
> >> > > > init.tcl"). But should this problem be avoidable by using a GTK
> >> > > 
> >> > > ImageView?
> >> > > 
> >> > > > And if yes, how to make ImageView use the GTK render?

Re: [julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[Tim Holy]

No problem. I meant in the gtk branch of ImageView, for which the last change 
long predates the existence of Graphics.jl.

--Tim

On Sunday, March 15, 2015 09:03:00 AM J Luis wrote:
> Bear with me that I'm still very rough with the packaging system but the
> fact that I see in my .julia/v0.4/Gtk/REQUIRE
> 
> Cairo 0.2.2
> julia 0.2-
> Graphics 0.1
> BinDeps
> @windows WinRPM
> @osx Homebrew
> 
> does not mean that the Graphics dependency is already there?
> 
> domingo, 15 de Março de 2015 às 14:26:46 UTC, Tim Holy escreveu:
> > Can you add Graphics to the REQUIRE file and submit a pull request against
> > the
> > gtk branch?
> > 
> > --Tim
> > 
> > On Sunday, March 15, 2015 07:13:02 AM J Luis wrote:
> > > Thanks. On v0.3.4 it seams to work (I mean no errors on "using
> > 
> > ImageView")
> > 
> > > but on 0.4
> > > 
> > > julia> Pkg.checkout("ImageView", "gtk")
> > > INFO: Checking out ImageView gtk...
> > > INFO: Pulling ImageView latest gtk...
> > > INFO: No packages to install, update or remove
> > > 
> > > julia> using ImageView
> > > ERROR: LoadError: UndefVarError: Graphics not defined
> > > while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in expression
> > > starting on line 3
> > > 
> > > domingo, 15 de Março de 2015 às 13:27:23 UTC, Tim Holy escreveu:
> > > > Pkg.checkout("ImageView", "gtk")
> > > > 
> > > > But I haven't updated that branch in a long time---it's being held up
> > > > because
> > > > I have an ambitious revamping plan for ImageView, and I just haven't
> > > > cleared
> > > > the two weeks it will take to implement it. So you may need to be
> > 
> > prepared
> > 
> > > > to
> > > > fix up that gtk branch. Pull requests welcome :-).
> > > > 
> > > > --Tim
> > > > 
> > > > On Sunday, March 15, 2015 05:57:35 AM J Luis wrote:
> > > > > Hi,
> > > > > 
> > > > > I can't use ImageView because of issue #67
> > > > >  (the "Can't find
> > 
> > usable
> > 
> > > > > init.tcl"). But should this problem be avoidable by using a GTK
> > > > 
> > > > ImageView?
> > > > 
> > > > > And if yes, how to make ImageView use the GTK render?

[julia-users] Re: Time type

[colintbowers]

Just thought I'd add my voice here that I can think of several use cases 
for this in high-frequency finance, although it would need millisecond 
precision (at the least). Cheers, -Colin

On Saturday, 14 March 2015 00:06:28 UTC+11, David Anthoff wrote:
>
> Hi,
>
>  
>
> is there a Time datatype, analogous to the Date type? I ran into a 
> situation where I need to represent times (like 12:34 pm) that don’t have a 
> date associated. I understand that in the case of dates that don’t have a 
> time component I’d use Date (instead of DateTime), but I couldn’t find 
> anything the other way around, for times that don’t have a date.
>
>  
>
> Thanks,
>
> David
>
>  
>

Re: [julia-users] Re: indexing with non Integer Reals is deprecated

[Christian Peel]

> More generally, it is important to keep the option of
> very simple (Matlab-style) Julia. I wonder whether users
> could come up with other examples where "simplicity,
>  convenience" are sacrificed for "performance, elegance
> of design, etc" ?

I confess that I don't like that all four of the following display in major
or slightly different ways in 0.4.  Yes, Float16 is only a storage class
and so on for the other types, but it still looks awkward to me that they
all display differently.
exp(Float16(1))
exp(Float32(1))
exp(Float64(1))
exp(BigFloat(1))

Also, I really want to type [1:2] rather than [1:2;] for a column vector.

Even though I occasionally have problems like those above, I generally find
Julia simple to learn and that I can use simple (Matlab-style) code if I
want to.

On Sun, Mar 15, 2015 at 4:34 PM, Stefan Karpinski 
wrote:

> On Sun, Mar 15, 2015 at 7:24 PM,  wrote:
>
>> The problem is that its fairly easy to be casually wrong when using reals
>> as indexes.  What does 10. index? (Hint: floating point numbers can't
>> represent 10 exactly, its 9.99...)
>
>
> This is simply untrue. All integers between ±2^53 can be represented
> exactly as Float64s. Beyond that, many integers can be represented exactly,
> but not all of them.
>



-- 
chris.p...@ieee.org

Re: [julia-users] Re: indexing with non Integer Reals is deprecated

[Stefan Karpinski]

On Sun, Mar 15, 2015 at 7:24 PM,  wrote:

> The problem is that its fairly easy to be casually wrong when using reals
> as indexes.  What does 10. index? (Hint: floating point numbers can't
> represent 10 exactly, its 9.99...)


This is simply untrue. All integers between ±2^53 can be represented
exactly as Float64s. Beyond that, many integers can be represented exactly,
but not all of them.

[julia-users] Re: Some simple use cases for multi-threading

[elextr]

I guess one of the standard rather simple benefits of multi-threading is to 
allow long running computations to not freeze an applications UI.

Its not a sexy highly parallel benefit, but very useful :)

Cheers
Lex

On Friday, March 13, 2015 at 1:52:37 PM UTC+10, Viral Shah wrote:
>
> I am looking to put together a set of use cases for our multi-threading 
> capabilities - mainly to push forward as well as a showcase. I am thinking 
> of starting with stuff in the microbenchmarks and the shootout 
> implementations that are already in test/perf. 
>
> I am looking for other ideas that would be of interest. If there is real 
> interest, we can collect all of these in a repo in JuliaParallel. 
>
> -viral 
>
>
>
>

[julia-users] Re: indexing with non Integer Reals is deprecated

[elextr]

On Monday, March 16, 2015 at 12:13:42 AM UTC+10, Christoph Ortner wrote:
>
> I've started to work mostly with Julia 0.4 recently since has a lot of 
> useful tools for me. I noticed the following error message:
>
> "indexing with non Integer Reals is deprecated"
>
> I guess this is due to Issue 
> https://github.com/JuliaLang/julia/issues/10154. I may well be missing a 
> crucial point here, but I think it is a huge mistake to take this step and 
> it is taking Julia in the wrong direction. It feels to be something along 
> the lines of "premature optimisation". For casual scripting, or just quick 
> testing, teaching numerical computing to beginners, converting from Matlab, 
> and probably for many other reasons, not having to worry about types is 
> really important.
>
>
The problem is that its fairly easy to be casually wrong when using reals 
as indexes.  What does 10. index? (Hint: floating point numbers can't 
represent 10 exactly, its 9.99...) 

Do we round? truncate? how far is the real allowed to be away from an 
integer to "convert cleanly"?

Its setting people up with more ways of getting errors, and it will be 
harder for inexperienced programmers to debug those problems.  

Cheers
Lex
 

> More generally, it is important to keep the option of very simple 
> (Matlab-style) Julia. I wonder whether users could come up with other 
> examples where "simplicity, convenience" are sacrificed for "performance, 
> elegance of design, etc" ? 
>
> Christoph
>
>
>

Re: [julia-users] Looking for incomplete SVD -- need only some of the singular values

[Christian Peel]

What's the reason that you don't want to use Julia's SVD directly?   Is
your matrix especially large?   Some links that may be useful:

Approximating the SVD using Julia:

http://beowulf.lcs.mit.edu/18.337/projects/Turner-Presentation_SVD-Julia.pdf
   https://github.com/alexjturner/SVDapprox
Approximating the SVD using the power method
   http://www.sci.ccny.cuny.edu/~szlam/npisvdnipsshort.pdf
   https://en.wikipedia.org/wiki/Power_iteration


On Sun, Mar 15, 2015 at 1:10 PM, Erik Schnetter  wrote:

> I am looking for a routine that calculate the SVD (singular value
> decomposition) of a square, complex, dense, non-symmetric matrix. I am
> aware of Julia's SVD routine (and the respective LAPACK routines that one
> could call directly). However, I don't need all of the singular values -- I
> need only the largest one (or some of the largest ones), as well as the
> associated entries of U. Is there such a routine? I didn't find one in
> Julia.
>
> I've looked for other packages that could be wrapped, but couldn't find
> any that offers this feature. The only thing I found is a description of
> the "svds" Matlab routine, which is apparently based on "eigs".
>
> -erik
>
> --
> Erik Schnetter 
> 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 https://sks-keyservers.net
> .
>
>


-- 
chris.p...@ieee.org

[julia-users] Looking for incomplete SVD -- need only some of the singular values

[Erik Schnetter]

I am looking for a routine that calculate the SVD (singular value 
decomposition) of a square, complex, dense, non-symmetric matrix. I am aware of 
Julia's SVD routine (and the respective LAPACK routines that one could call 
directly). However, I don't need all of the singular values -- I need only the 
largest one (or some of the largest ones), as well as the associated entries of 
U. Is there such a routine? I didn't find one in Julia.

I've looked for other packages that could be wrapped, but couldn't find any 
that offers this feature. The only thing I found is a description of the "svds" 
Matlab routine, which is apparently based on "eigs".

-erik

--
Erik Schnetter 
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 https://sks-keyservers.net.



signature.asc
Description: Message signed with OpenPGP using GPGMail

[julia-users] Re: Copy a directory inclusive subfolders and keeping any symlinks.

[Ivar Nesje]

Just for further reference when people find this thread through search: 
#10506 

(sorry for bumping the thread for everyone who will read this)

fredag 13. mars 2015 00.29.23 UTC+1 skrev Julia User følgende:
>
> hi!
>
> Is there an ready or prefered way to copy a directory inclusive subfolders 
> and **keeping any symlinks / relative symlinks**.
>
>
>

[julia-users] Re: "print" and "write" for VTK export

[Tobias Knopp]

Hey Simon,

this sounds great. Will respond at the issue.

Cheers,

Tobi

Am Sonntag, 15. März 2015 18:48:51 UTC+1 schrieb Simon Danisch:
>
> I actually just opened an issue 
> over 
> at Images.jl, to further modularize it, so that all the actual import 
> functions are not part of it and live in their own package.
> This is nice, if you for example just need an jpg importer, or nrrd 
> importer without the rest.
> This fits in my greater scheme of having a unified IO infrastructure, 
> which is why I created JuliaIO .
> See the proposed interface in FileIO 
> .
> I personally think this will be awesome! If anyone finds any short comings 
> in this approach, please open issues =)
> If you have any IO package, feel free to join JuliaIO and contribute to it!
> It's not very sophisticated yet, so I'd appreciate any help in sketching 
> this further out.
>
> Am Samstag, 14. März 2015 13:41:04 UTC+1 schrieb Christian Dengler:
>>
>> Hello,
>>
>> I'm trying to save my data as .vtk files, and ran into a problem with the 
>> "print" and "write" function.
>>
>> Resumee of what would solve my problems:
>> - Using print(filestream, data), but omitting the square brackets, and
>> - using print(filestream, vector), and actually writes the vector, one 
>> element per line
>>
>> Does anyone know how this is done?
>>
>> Another way of creating .vtk files using binary data, using the write 
>> function, didn't lead to any success, but i cant really say whats wrong, 
>> because the files are unreadable. Could it be, that write also somehow 
>> includes brackets?
>>
>>
>> For those who want to see my problem in code, i attached a script, 
>> creating and saving a simple veocity field as .vtk (ASCII) file.
>> After manually deleting the brackets, atleast the velocity can be 
>> imported into paraview.
>> In order to create the binary .vtk file (thats not working at all), i 
>> used to replace "ASCII" by "BINARY", and "print" in line 22 and  41 by 
>> "write".
>>
>> Greetings, 
>> Christian
>>
>

[julia-users] Re: "print" and "write" for VTK export

[Simon Danisch]

I actually just opened an issue 
over 
at Images.jl, to further modularize it, so that all the actual import 
functions are not part of it and live in their own package.
This is nice, if you for example just need an jpg importer, or nrrd 
importer without the rest.
This fits in my greater scheme of having a unified IO infrastructure, which 
is why I created JuliaIO .
See the proposed interface in FileIO .
I personally think this will be awesome! If anyone finds any short comings 
in this approach, please open issues =)
If you have any IO package, feel free to join JuliaIO and contribute to it!
It's not very sophisticated yet, so I'd appreciate any help in sketching 
this further out.

Am Samstag, 14. März 2015 13:41:04 UTC+1 schrieb Christian Dengler:
>
> Hello,
>
> I'm trying to save my data as .vtk files, and ran into a problem with the 
> "print" and "write" function.
>
> Resumee of what would solve my problems:
> - Using print(filestream, data), but omitting the square brackets, and
> - using print(filestream, vector), and actually writes the vector, one 
> element per line
>
> Does anyone know how this is done?
>
> Another way of creating .vtk files using binary data, using the write 
> function, didn't lead to any success, but i cant really say whats wrong, 
> because the files are unreadable. Could it be, that write also somehow 
> includes brackets?
>
>
> For those who want to see my problem in code, i attached a script, 
> creating and saving a simple veocity field as .vtk (ASCII) file.
> After manually deleting the brackets, atleast the velocity can be imported 
> into paraview.
> In order to create the binary .vtk file (thats not working at all), i used 
> to replace "ASCII" by "BINARY", and "print" in line 22 and  41 by "write".
>
> Greetings, 
> Christian
>

Re: [julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[J Luis]

and bad luck with Gtk too

julia> Img = imread(
"C://progs_cygw//GMTdev//gmt5//branches//5.2.0//test//grdimage//gdal//needle.jpg"
);

julia> view(Img)
(ImageCanvas,ImageSlice2d: zoom = BoundingBox(0.0,430.0,0.0,300.0))

julia> ERROR: `width` has no method matching width(::GtkCanvas)
 in setbb! at C:\j\.julia\v0.3\ImageView\src\display.jl:80
 in resize at C:\j\.julia\v0.3\ImageView\src\display.jl:582
 in anonymous at C:\j\.julia\v0.3\ImageView\src\display.jl:420
 in draw at C:\j\.julia\v0.3\Gtk\src\cairo.jl:72
 in notify_resize at C:\j\.julia\v0.3\Gtk\src\cairo.jl:52



domingo, 15 de Março de 2015 às 16:03:00 UTC, J Luis escreveu:
>
> Bear with me that I'm still very rough with the packaging system but the 
> fact that I see in my .julia/v0.4/Gtk/REQUIRE
>
> Cairo 0.2.2
> julia 0.2-
> Graphics 0.1
> BinDeps
> @windows WinRPM
> @osx Homebrew
>
> does not mean that the Graphics dependency is already there?
>
> domingo, 15 de Março de 2015 às 14:26:46 UTC, Tim Holy escreveu:
>>
>> Can you add Graphics to the REQUIRE file and submit a pull request 
>> against the 
>> gtk branch? 
>>
>> --Tim 
>>
>> On Sunday, March 15, 2015 07:13:02 AM J Luis wrote: 
>> > Thanks. On v0.3.4 it seams to work (I mean no errors on "using 
>> ImageView") 
>> > but on 0.4 
>> > 
>> > julia> Pkg.checkout("ImageView", "gtk") 
>> > INFO: Checking out ImageView gtk... 
>> > INFO: Pulling ImageView latest gtk... 
>> > INFO: No packages to install, update or remove 
>> > 
>> > julia> using ImageView 
>> > ERROR: LoadError: UndefVarError: Graphics not defined 
>> > while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in 
>> expression 
>> > starting on line 3 
>> > 
>> > domingo, 15 de Março de 2015 às 13:27:23 UTC, Tim Holy escreveu: 
>> > > Pkg.checkout("ImageView", "gtk") 
>> > > 
>> > > But I haven't updated that branch in a long time---it's being held up 
>> > > because 
>> > > I have an ambitious revamping plan for ImageView, and I just haven't 
>> > > cleared 
>> > > the two weeks it will take to implement it. So you may need to be 
>> prepared 
>> > > to 
>> > > fix up that gtk branch. Pull requests welcome :-). 
>> > > 
>> > > --Tim 
>> > > 
>> > > On Sunday, March 15, 2015 05:57:35 AM J Luis wrote: 
>> > > > Hi, 
>> > > > 
>> > > > I can't use ImageView because of issue #67 
>> > > >  (the "Can't find 
>> usable 
>> > > > init.tcl"). But should this problem be avoidable by using a GTK 
>> > > 
>> > > ImageView? 
>> > > 
>> > > > And if yes, how to make ImageView use the GTK render? 
>>
>>

Re: [julia-users] Re: indexing with non Integer Reals is deprecated

[Ivar Nesje]

That's one place off at the end of a 10 petabyte array. We're really planning 
for the future. But as I think about it, we've grown 10 MB to 10 GB arrays in 
20 years, so who knows what the future will bring. 

Personally I think learning the difference between Float and Int is a pretty 
basic programming skill, that is better thought at entry level, than in a "post 
mortem" when something really bad happened. This distinction also makes 
programs easier to read, because it forces one style of programming.

[julia-users] Re: "print" and "write" for VTK export

[Tobias Knopp]

Your welcome, I had recently written code to write and read the "Analyze" 
format which I needed to get data into a medical image registration 
software. Might be good to polish this up (also your vtk code) and get this 
into a package. Not entirely sure if this should stand on its own or be 
integrated into Images.jl.

Cheers

Tobi

Am Sonntag, 15. März 2015 16:10:56 UTC+1 schrieb Christian Dengler:
>
> "bswap()" worked perfectly! Everything is working now, finally :) For 
> those interested, the appended file contains a working vtk export function.
> Thanks for the help Tobias!
>
> Am Sonntag, 15. März 2015 13:28:58 UTC+1 schrieb Tobias Knopp:
>>
>> for l=1:length(x)
>>   x[l] = bswap(x[l])
>>   y[l] = bswap(y[l])
>>   z[l] = bswap(z[l])
>> end
>>
>>
>> Am Sonntag, 15. März 2015 11:17:53 UTC+1 schrieb Christian Dengler:
>>>
>>> Hello again,
>>>
>>> No that did not do the trick, but i managed to compare the julia output 
>>> to a working .vtk file, using a binary reader. The problem with the julia 
>>> output, is that it is written LittleEndian, while paraview needs BigEndian. 
>>> Also the structure must be write(fid, hcat(x[:]', y[:]', z[:]') ), but 
>>> written with BigEndians, which i haven't figured out how to do yet. I tried 
>>> the hton() function, as well as NetworkByteOrder from the docs, but i 
>>> guess i'm applying it wrong. I tried
>>>
>>> write(fid, hcat(x[:]', y[:]', z[:]') , NetworkByteOrder) -> 
>>> NetworkByteOrder 
>>> not defined
>>> write(fid, hcat(x[:]', y[:]', z[:]') , "NetworkByteOrder") -> writes 
>>> the string to the file, instead of changing endianness
>>> write(fid, hton(hcat(x[:]', y[:]', z[:]'))) -> ERROR: `bswap` has no 
>>> method matching bswap(::Array{Float64,2})
>>>
>>> Any suggestions how to write big endian?
>>>
>>>
>>> Am Samstag, 14. März 2015 20:05:50 UTC+1 schrieb Tobias Knopp:

 not familiar with the vtk format but are you sure the the x,y,z 
 coordinates lay not directly after each other?
 Could try:

 write(fid, vcat(x[:]', y[:]', z[:]') )

 Am Samstag, 14. März 2015 18:54:59 UTC+1 schrieb Christian Dengler:
>
> Ty for your answers. I'm not familiar with vtk export on python, and 
> i'm confident that finding my mistake will be easier than trying to 
> understand what you did there with pycall.
> As for the nrrd code, it seems to be doing exactly what i did. I found 
> one mistake i did previously though, telling paraview to load float 
> instead 
> of double values. Now with the function below, paraview loads the files 
> withoud error message, yet doesnt display anything reasonable, seems that 
> there is another mistake somewhere, i still assume it to be the "write" 
> function, where i'm not sure if it does what i want it to.
> I'll keep you up to date, should i find my mistake
>
> function exportVTK(DataMat, NameMat ,filename, dh, Nxyz)
>
> nx = dh[1]*(Nxyz[1]-1);
> ny = dh[2]*(Nxyz[2]-1);
> nz = dh[3]*(Nxyz[3]-1);
>
> x, y, z = ndgrid(0:dh[1]:nx, 0:dh[2]:ny, 0:dh[3]:nz );
>
> nr_of_elements = length(x);
> fid = open(filename, "w"); 
>
> #ASCII file header
> println(fid, "# vtk DataFile Version 3.0");
> println(fid, "VTK from Julia");
> println(fid, "BINARY\n");
> println(fid, "DATASET STRUCTURED_GRID");
> println(fid, "DIMENSIONS $(size(x,1)) $(size(x,2)) $(size(x,3)) ");
> println(fid, "POINTS $(nr_of_elements) double");
> write(fid, [x[:] y[:] z[:]] )
>
> #append data
> print(fid, "\nPOINT_DATA $(nr_of_elements) \n");
>
> for i = 1:length(DataMat)
>
> if size(DataMat[i], 2) == 3
> #append a vector
> println(fid, "\nVECTORS $(NameMat[i]) double"); 
> elseif size(DataMat[i], 2) == 1
> #append a scalar
> println(fid, "\nSCALARS $(NameMat[i]) double");
> println(fid, "LOOKUP_TABLE default"); 
> else
> error("DataMat $i is not a vector or scalar, or not shaped 
> the way it should be")
> end
> 
> write(fid, DataMat[i]);
>
> end
>
> close(fid);
>
> end
>
>
>
>
>
> Am Samstag, 14. März 2015 17:49:50 UTC+1 schrieb Kristoffer Carlsson:
>>
>> One method that I have used to export VTK from Julia is simply using 
>> the VTK-library from python and calling it with PyCall.
>>
>> Something like this: 
>> https://gist.github.com/KristofferC/9a989a2c0518bb70009c
>>
>>
>>
>> On Saturday, March 14, 2015 at 1:41:04 PM UTC+1, Christian Dengler 
>> wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to save my data as .vtk files, and ran into a problem 
>>> with the "print" and "write" function.
>>>
>>> Resumee of what would solve my problems:
>>> - Using print(filestream, data), but omitting the square brackets, 
>>> and
>>> - using print(filestream, vector), 

Re: [julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[J Luis]

Bear with me that I'm still very rough with the packaging system but the 
fact that I see in my .julia/v0.4/Gtk/REQUIRE

Cairo 0.2.2
julia 0.2-
Graphics 0.1
BinDeps
@windows WinRPM
@osx Homebrew

does not mean that the Graphics dependency is already there?

domingo, 15 de Março de 2015 às 14:26:46 UTC, Tim Holy escreveu:
>
> Can you add Graphics to the REQUIRE file and submit a pull request against 
> the 
> gtk branch? 
>
> --Tim 
>
> On Sunday, March 15, 2015 07:13:02 AM J Luis wrote: 
> > Thanks. On v0.3.4 it seams to work (I mean no errors on "using 
> ImageView") 
> > but on 0.4 
> > 
> > julia> Pkg.checkout("ImageView", "gtk") 
> > INFO: Checking out ImageView gtk... 
> > INFO: Pulling ImageView latest gtk... 
> > INFO: No packages to install, update or remove 
> > 
> > julia> using ImageView 
> > ERROR: LoadError: UndefVarError: Graphics not defined 
> > while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in expression 
> > starting on line 3 
> > 
> > domingo, 15 de Março de 2015 às 13:27:23 UTC, Tim Holy escreveu: 
> > > Pkg.checkout("ImageView", "gtk") 
> > > 
> > > But I haven't updated that branch in a long time---it's being held up 
> > > because 
> > > I have an ambitious revamping plan for ImageView, and I just haven't 
> > > cleared 
> > > the two weeks it will take to implement it. So you may need to be 
> prepared 
> > > to 
> > > fix up that gtk branch. Pull requests welcome :-). 
> > > 
> > > --Tim 
> > > 
> > > On Sunday, March 15, 2015 05:57:35 AM J Luis wrote: 
> > > > Hi, 
> > > > 
> > > > I can't use ImageView because of issue #67 
> > > >  (the "Can't find 
> usable 
> > > > init.tcl"). But should this problem be avoidable by using a GTK 
> > > 
> > > ImageView? 
> > > 
> > > > And if yes, how to make ImageView use the GTK render? 
>
>

Re: [julia-users] Re: Some simple use cases for multi-threading

[Jiahao Chen]

On Sun, Mar 15, 2015 at 1:44 AM, Jeff Waller  wrote:
> Something like auto-parallel sort would be cool.

The Fortress programming language had lots of ideas about aggressively
parallelizing code. Could be interesting to try out those ideas again.

Thanks,

Jiahao Chen
Staff Research Scientist
MIT Computer Science and Artificial Intelligence Laboratory

Re: [julia-users] Re: indexing with non Integer Reals is deprecated

[Jiahao Chen]

One edge case that arises is indexing with a float where epsilon > 1:

julia> (1:10^17)[1e16:(1e16+5)] #Not the same as indexing with (10^16:10^16+5)
5-element Array{Int64,1}:
 1
 1
 10002
 10004
 10004

Thanks,

Jiahao Chen
Staff Research Scientist
MIT Computer Science and Artificial Intelligence Laboratory


On Sun, Mar 15, 2015 at 9:47 AM, Stefan Karpinski  wrote:
> I have to confess that I find it overly finicky to require indices to be of
> integer type. Reals that convert cleanly to Int generally seem reasonable to
> me.
>
> On Sun, Mar 15, 2015 at 10:14 AM, Christoph Ortner
>  wrote:
>>
>> Here is, right away, one other  example that has annoyed me for a long
>> time: `meshgrid`. It may not be "Julian", but it is incredibly convenient
>> for quick experiments. I know I can get it from examples, but I don't
>> understand why it hurts having it in Base.
>>
>> Christoph
>>
>

Re: [julia-users] Re: indexing with non Integer Reals is deprecated

[Stefan Karpinski]

I have to confess that I find it overly finicky to require indices to be of
integer type. Reals that convert cleanly to Int generally seem reasonable
to me.

On Sun, Mar 15, 2015 at 10:14 AM, Christoph Ortner <
christophortn...@gmail.com> wrote:

> Here is, right away, one other  example that has annoyed me for a long
> time: `meshgrid`. It may not be "Julian", but it is incredibly convenient
> for quick experiments. I know I can get it from examples, but I don't
> understand why it hurts having it in Base.
>
> Christoph
>
>

Re: [julia-users] Re: Performance - what am I doing wrong?

[Kyle Barbary]

Hi Dallas,

One additional note: Your first two functions as written don’t actually
modify the input y array. You could therefore rewrite them as

vec(x) = x.*x
comp(x) = [xi*xi for xi in x]

For an explanation of *why* they don’t modify the input array, see this
excellent blog post:
http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/
Note that the same behavior holds for Python as well.

Kyle
​

On Sun, Mar 15, 2015 at 8:18 AM, Dallas Morisette 
wrote:

> Thanks everyone for the suggestions! Here is my updated test:
>
> using TimeIt
> function vec!(x,y)
> y = x.*x
> end
>
> function comp!(x,y)
> y = [xi*xi for xi in x]
> end
>
> function forloop!(x,y,n)
> for i = 1:n
> y[i] = x[i]*x[i]
> end
> end
>
> function forloop2!(x,y,n)
> @simd for i = 1:n
> @inbounds y[i] = x[i]*x[i]
> end
> end
>
> function test()
> n = 1
> x = linspace(0.0,1.0,n)
> y = zeros(x)
> @timeit vec!(x,y)
> @timeit comp!(x,y)
> @timeit forloop!(x,y,n)
> @timeit forloop2!(x,y,n)
> end
> test();
>
> 1 loops, best of 3: 87.82 µs per loop
> 1000 loops, best of 3: 62.73 µs per loop
> 1 loops, best of 3: 12.66 µs per loop
> 10 loops, best of 3: 3.54 µs per loop
>
>
> So the SIMD macros combined with a literal for loop give performance
> essentially equivalent to a call to numpy. I switched to @time so I could
> see the allocations:
>
> elapsed time: 2.467e-5 seconds (80512 bytes allocated)
> elapsed time: 2.1358e-5 seconds (80048 bytes allocated)
> elapsed time: 1.5124e-5 seconds (0 bytes allocated)
> elapsed time: 6.108e-6 seconds (0 bytes allocated)
>
>
> Looks like one temporary array has to be allocated in both vectorized and
> comprehension forms, which reduced the performance by about 5-7X. I suppose
> this would depend on the exact calculation being done and the size of the
> arrays involved and would have to be tested on a case-by-case basis.
>
> Thanks for the help - I'm sure I'll be back with more questions!
>
> Dallas
>

Re: [julia-users] Re: Performance - what am I doing wrong?

[Dallas Morisette]

Thanks everyone for the suggestions! Here is my updated test:

using TimeIt
function vec!(x,y)
y = x.*x
end

function comp!(x,y)
y = [xi*xi for xi in x]
end

function forloop!(x,y,n)
for i = 1:n 
y[i] = x[i]*x[i]
end
end

function forloop2!(x,y,n)
@simd for i = 1:n 
@inbounds y[i] = x[i]*x[i] 
end
end

function test()
n = 1
x = linspace(0.0,1.0,n)
y = zeros(x)
@timeit vec!(x,y)
@timeit comp!(x,y)
@timeit forloop!(x,y,n)
@timeit forloop2!(x,y,n)
end
test();

1 loops, best of 3: 87.82 µs per loop
1000 loops, best of 3: 62.73 µs per loop
1 loops, best of 3: 12.66 µs per loop
10 loops, best of 3: 3.54 µs per loop


So the SIMD macros combined with a literal for loop give performance 
essentially equivalent to a call to numpy. I switched to @time so I could 
see the allocations:

elapsed time: 2.467e-5 seconds (80512 bytes allocated)
elapsed time: 2.1358e-5 seconds (80048 bytes allocated)
elapsed time: 1.5124e-5 seconds (0 bytes allocated)
elapsed time: 6.108e-6 seconds (0 bytes allocated)


Looks like one temporary array has to be allocated in both vectorized and 
comprehension forms, which reduced the performance by about 5-7X. I suppose 
this would depend on the exact calculation being done and the size of the 
arrays involved and would have to be tested on a case-by-case basis. 

Thanks for the help - I'm sure I'll be back with more questions!

Dallas

[julia-users] Re: "print" and "write" for VTK export

[Christian Dengler]

"bswap()" worked perfectly! Everything is working now, finally :) For those 
interested, the appended file contains a working vtk export function.
Thanks for the help Tobias!

Am Sonntag, 15. März 2015 13:28:58 UTC+1 schrieb Tobias Knopp:
>
> for l=1:length(x)
>   x[l] = bswap(x[l])
>   y[l] = bswap(y[l])
>   z[l] = bswap(z[l])
> end
>
>
> Am Sonntag, 15. März 2015 11:17:53 UTC+1 schrieb Christian Dengler:
>>
>> Hello again,
>>
>> No that did not do the trick, but i managed to compare the julia output 
>> to a working .vtk file, using a binary reader. The problem with the julia 
>> output, is that it is written LittleEndian, while paraview needs BigEndian. 
>> Also the structure must be write(fid, hcat(x[:]', y[:]', z[:]') ), but 
>> written with BigEndians, which i haven't figured out how to do yet. I tried 
>> the hton() function, as well as NetworkByteOrder from the docs, but i 
>> guess i'm applying it wrong. I tried
>>
>> write(fid, hcat(x[:]', y[:]', z[:]') , NetworkByteOrder) -> NetworkByteOrder 
>> not defined
>> write(fid, hcat(x[:]', y[:]', z[:]') , "NetworkByteOrder") -> writes the 
>> string to the file, instead of changing endianness
>> write(fid, hton(hcat(x[:]', y[:]', z[:]'))) -> ERROR: `bswap` has no 
>> method matching bswap(::Array{Float64,2})
>>
>> Any suggestions how to write big endian?
>>
>>
>> Am Samstag, 14. März 2015 20:05:50 UTC+1 schrieb Tobias Knopp:
>>>
>>> not familiar with the vtk format but are you sure the the x,y,z 
>>> coordinates lay not directly after each other?
>>> Could try:
>>>
>>> write(fid, vcat(x[:]', y[:]', z[:]') )
>>>
>>> Am Samstag, 14. März 2015 18:54:59 UTC+1 schrieb Christian Dengler:

 Ty for your answers. I'm not familiar with vtk export on python, and 
 i'm confident that finding my mistake will be easier than trying to 
 understand what you did there with pycall.
 As for the nrrd code, it seems to be doing exactly what i did. I found 
 one mistake i did previously though, telling paraview to load float 
 instead 
 of double values. Now with the function below, paraview loads the files 
 withoud error message, yet doesnt display anything reasonable, seems that 
 there is another mistake somewhere, i still assume it to be the "write" 
 function, where i'm not sure if it does what i want it to.
 I'll keep you up to date, should i find my mistake

 function exportVTK(DataMat, NameMat ,filename, dh, Nxyz)

 nx = dh[1]*(Nxyz[1]-1);
 ny = dh[2]*(Nxyz[2]-1);
 nz = dh[3]*(Nxyz[3]-1);

 x, y, z = ndgrid(0:dh[1]:nx, 0:dh[2]:ny, 0:dh[3]:nz );

 nr_of_elements = length(x);
 fid = open(filename, "w"); 

 #ASCII file header
 println(fid, "# vtk DataFile Version 3.0");
 println(fid, "VTK from Julia");
 println(fid, "BINARY\n");
 println(fid, "DATASET STRUCTURED_GRID");
 println(fid, "DIMENSIONS $(size(x,1)) $(size(x,2)) $(size(x,3)) ");
 println(fid, "POINTS $(nr_of_elements) double");
 write(fid, [x[:] y[:] z[:]] )

 #append data
 print(fid, "\nPOINT_DATA $(nr_of_elements) \n");

 for i = 1:length(DataMat)

 if size(DataMat[i], 2) == 3
 #append a vector
 println(fid, "\nVECTORS $(NameMat[i]) double"); 
 elseif size(DataMat[i], 2) == 1
 #append a scalar
 println(fid, "\nSCALARS $(NameMat[i]) double");
 println(fid, "LOOKUP_TABLE default"); 
 else
 error("DataMat $i is not a vector or scalar, or not shaped the 
 way it should be")
 end
 
 write(fid, DataMat[i]);

 end

 close(fid);

 end





 Am Samstag, 14. März 2015 17:49:50 UTC+1 schrieb Kristoffer Carlsson:
>
> One method that I have used to export VTK from Julia is simply using 
> the VTK-library from python and calling it with PyCall.
>
> Something like this: 
> https://gist.github.com/KristofferC/9a989a2c0518bb70009c
>
>
>
> On Saturday, March 14, 2015 at 1:41:04 PM UTC+1, Christian Dengler 
> wrote:
>>
>> Hello,
>>
>> I'm trying to save my data as .vtk files, and ran into a problem with 
>> the "print" and "write" function.
>>
>> Resumee of what would solve my problems:
>> - Using print(filestream, data), but omitting the square brackets, and
>> - using print(filestream, vector), and actually writes the vector, 
>> one element per line
>>
>> Does anyone know how this is done?
>>
>> Another way of creating .vtk files using binary data, using the write 
>> function, didn't lead to any success, but i cant really say whats wrong, 
>> because the files are unreadable. Could it be, that write also somehow 
>> includes brackets?
>>
>>
>> For those who want to see my problem in code, i attached a script, 
>> creating and saving a simple veocity field as .vtk (ASCII) file.
>> Af

Re: [julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[Tim Holy]

Can you add Graphics to the REQUIRE file and submit a pull request against the 
gtk branch?

--Tim

On Sunday, March 15, 2015 07:13:02 AM J Luis wrote:
> Thanks. On v0.3.4 it seams to work (I mean no errors on "using ImageView")
> but on 0.4
> 
> julia> Pkg.checkout("ImageView", "gtk")
> INFO: Checking out ImageView gtk...
> INFO: Pulling ImageView latest gtk...
> INFO: No packages to install, update or remove
> 
> julia> using ImageView
> ERROR: LoadError: UndefVarError: Graphics not defined
> while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in expression
> starting on line 3
> 
> domingo, 15 de Março de 2015 às 13:27:23 UTC, Tim Holy escreveu:
> > Pkg.checkout("ImageView", "gtk")
> > 
> > But I haven't updated that branch in a long time---it's being held up
> > because
> > I have an ambitious revamping plan for ImageView, and I just haven't
> > cleared
> > the two weeks it will take to implement it. So you may need to be prepared
> > to
> > fix up that gtk branch. Pull requests welcome :-).
> > 
> > --Tim
> > 
> > On Sunday, March 15, 2015 05:57:35 AM J Luis wrote:
> > > Hi,
> > > 
> > > I can't use ImageView because of issue #67
> > >  (the "Can't find usable
> > > init.tcl"). But should this problem be avoidable by using a GTK
> > 
> > ImageView?
> > 
> > > And if yes, how to make ImageView use the GTK render?

[julia-users] Re: indexing with non Integer Reals is deprecated

[Christoph Ortner]

Here is, right away, one other  example that has annoyed me for a long 
time: `meshgrid`. It may not be "Julian", but it is incredibly convenient 
for quick experiments. I know I can get it from examples, but I don't 
understand why it hurts having it in Base.

Christoph

[julia-users] indexing with non Integer Reals is deprecated

[Christoph Ortner]

I've started to work mostly with Julia 0.4 recently since has a lot of 
useful tools for me. I noticed the following error message:

"indexing with non Integer Reals is deprecated"

I guess this is due to 
Issue https://github.com/JuliaLang/julia/issues/10154. I may well be 
missing a crucial point here, but I think it is a huge mistake to take this 
step and it is taking Julia in the wrong direction. It feels to be 
something along the lines of "premature optimisation". For casual 
scripting, or just quick testing, teaching numerical computing to 
beginners, converting from Matlab, and probably for many other reasons, not 
having to worry about types is really important.

More generally, it is important to keep the option of very simple 
(Matlab-style) Julia. I wonder whether users could come up with other 
examples where "simplicity, convenience" are sacrificed for "performance, 
elegance of design, etc" ? 

Christoph

Re: [julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[J Luis]

Thanks. On v0.3.4 it seams to work (I mean no errors on "using ImageView") 
but on 0.4

julia> Pkg.checkout("ImageView", "gtk")
INFO: Checking out ImageView gtk...
INFO: Pulling ImageView latest gtk...
INFO: No packages to install, update or remove

julia> using ImageView
ERROR: LoadError: UndefVarError: Graphics not defined
while loading C:\j\.julia\v0.4\ImageView\src\ImageView.jl, in expression 
starting on line 3




domingo, 15 de Março de 2015 às 13:27:23 UTC, Tim Holy escreveu:
>
> Pkg.checkout("ImageView", "gtk") 
>
> But I haven't updated that branch in a long time---it's being held up 
> because 
> I have an ambitious revamping plan for ImageView, and I just haven't 
> cleared 
> the two weeks it will take to implement it. So you may need to be prepared 
> to 
> fix up that gtk branch. Pull requests welcome :-). 
>
> --Tim 
>
> On Sunday, March 15, 2015 05:57:35 AM J Luis wrote: 
> > Hi, 
> > 
> > I can't use ImageView because of issue #67 
> >  (the "Can't find usable 
> > init.tcl"). But should this problem be avoidable by using a GTK 
> ImageView? 
> > And if yes, how to make ImageView use the GTK render? 
>
>

Re: [julia-users] Re: Factorization of big integers is taking too long

[Tim Holy]

I don't know the algorithm, but my point is that
c = a*b
will, for a BigInt, allocate memory. Because Numbers are immutable and BigInts 
are Numbers, you can't write an algorithm mult!(c, a, b) that stores the 
result in a pre-allocated "scratch space" c. Hence, you're doomed to 
inefficiency compared to an implementation in C that uses such tricks. Don't 
get 
me wrong, in the context of the overall Julia ecosystem our current design is 
right one (immutability is a really awesome and important property), but there 
are downsides.

But you don't have to live with the status quo. If you need efficient BigInt 
calculations, perhaps a MutableBigInts.jl package would be in order. You could 
define an OpaqueBigInt type (which would _not_ be a subtype of Number) and 
implement mult!(c, a, b), add!(c, a, b), etc for that type. You could 
basically copy the bigint implementation in base. gmp.jl is only 500 lines of 
code and the changes might be very minimal, so you may be able to knock this 
out in an afternoon :-). That is, unless making them not-numbers has too many 
negative consequences. (You may find yourself creating additional methods of 
other functions.)

Best,
--Tim

On Sunday, March 15, 2015 06:39:23 AM Hans W Borchers wrote:
> Tim, sorry, I do not understand what you mean here.
> Do you argue that it is not possible to write a relatively fast
> implementation of, e.g., Pollard's Rho algorithm in Julia.
> 
> On Sunday, March 15, 2015 at 2:19:47 PM UTC+1, Tim Holy wrote:
> > It's more than a question of which algorithm to use: the immutability of
> > numbers means that every single bignum addition or multiplication requires
> > allocation. So currently, julia is going to have a hard time competing
> > with a
> > hand-rolled method that allocates a cache of numbers to (re)use as scratch
> > space for calculations. You can do this if you're willing to manage all
> > these
> > temporaries manually.
> > 
> > The best solution would be to make julia smart enough to do that "behind
> > the
> > scenes." This is a very interesting but nontrivial problem (with potential
> > costs if it's "close but not smart enough").
> > 
> > --Tim

Re: [julia-users] Re: Factorization of big integers is taking too long

[Hans W Borchers]

Tim, sorry, I do not understand what you mean here.
Do you argue that it is not possible to write a relatively fast 
implementation of, e.g., Pollard's Rho algorithm in Julia.

On Sunday, March 15, 2015 at 2:19:47 PM UTC+1, Tim Holy wrote:
>
> It's more than a question of which algorithm to use: the immutability of 
> numbers means that every single bignum addition or multiplication requires 
> allocation. So currently, julia is going to have a hard time competing 
> with a 
> hand-rolled method that allocates a cache of numbers to (re)use as scratch 
> space for calculations. You can do this if you're willing to manage all 
> these 
> temporaries manually. 
>
> The best solution would be to make julia smart enough to do that "behind 
> the 
> scenes." This is a very interesting but nontrivial problem (with potential 
> costs if it's "close but not smart enough"). 
>
> --Tim 
>
>

[julia-users] Re: SIAM CSE meetup?

[Lars Ruthotto]

I am. How about going for dinner tonight? We could meet in the morning 
coffee break to discuss!

On Saturday, March 14, 2015 at 9:12:45 AM UTC-6, Jiahao Chen wrote:
>
> I presume that there are other Julia users attending the SIAM CSE 
> conference in Salt Lake City this weekend. Would anyone be interested in 
> meeting up?
>

Re: [julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[Tim Holy]

Pkg.checkout("ImageView", "gtk")

But I haven't updated that branch in a long time---it's being held up because 
I have an ambitious revamping plan for ImageView, and I just haven't cleared 
the two weeks it will take to implement it. So you may need to be prepared to 
fix up that gtk branch. Pull requests welcome :-).

--Tim

On Sunday, March 15, 2015 05:57:35 AM J Luis wrote:
> Hi,
> 
> I can't use ImageView because of issue #67
>  (the "Can't find usable
> init.tcl"). But should this problem be avoidable by using a GTK ImageView?
> And if yes, how to make ImageView use the GTK render?

Re: [julia-users] Re: Factorization of big integers is taking too long

[Tim Holy]

It's more than a question of which algorithm to use: the immutability of 
numbers means that every single bignum addition or multiplication requires 
allocation. So currently, julia is going to have a hard time competing with a 
hand-rolled method that allocates a cache of numbers to (re)use as scratch 
space for calculations. You can do this if you're willing to manage all these 
temporaries manually.

The best solution would be to make julia smart enough to do that "behind the 
scenes." This is a very interesting but nontrivial problem (with potential 
costs if it's "close but not smart enough").

--Tim

On Friday, March 13, 2015 01:38:18 PM Hans W Borchers wrote:
> That's right; I looked into the source of the 'gmp' package,
> the C code in there is the same as the demo code you are linking to.
> It uses Pollard's Rho and Miller Rabin for primality testing.
> That code is under GPL license.
> 
> As Miller Rabin is used for Julia's isprime() function, it would be nice
> implement Pollard Rho in pure Julia and demo how fast it can be.
> 
> But consider that there will be improvements and newer versions
> of this algorithm that should be taken into account.
> 
> On Friday, March 13, 2015 at 8:54:37 PM UTC+1, Simon Byrne wrote:
> > The R gmp docs say that they use the Pollard Rho algorithm, and there is
> > an implementation of it in the GMP demos directory:
> > https://gmplib.org/repo/gmp/file/2d027c920892/demos/factorize.c
> > 
> > So presumably they're using that code?
> > 
> > simon
> > 
> > On Friday, 13 March 2015 18:46:21 UTC, Steven G. Johnson wrote:
> >> On Friday, March 13, 2015 at 1:25:14 PM UTC-4, Jake Bolewski wrote:
> >>> This is falling back to factor() for generic integers, so the GMP method
> >>> does not looked to be wrapped.  The generic version will be terribly
> >>> slow
> >>> for bigints.  Would be easy to add if you would like to submit a Pull
> >>> Request.
> >> 
> >> At first glance, I'm not seeing a built-in factorization method in GMP.
> >> 
> >>  Googling "factorization gmp" turns up a bunch of algorithms that people
> >> 
> >> have built on top of GMP, but nothing in GMP itself.   (We should see
> >> what
> >> algorithm/code R is using.)

[julia-users] ImageView and the "Can't find usable init.tcl" vs GTK

[J Luis]

Hi,

I can't use ImageView because of issue #67 
 (the "Can't find usable 
init.tcl"). But should this problem be avoidable by using a GTK ImageView? 
And if yes, how to make ImageView use the GTK render?

Re: [julia-users] Re: Factorization of big integers is taking too long

[Simon Byrne]

You're right the issue is that Char <: Integer, but segmentation
faults still shouldn't happen. I actually see a stack overflow in
0.3.6 (on OS X).

In 0.4, it is simply a MethodError, as Char is no longer a subtype of Integer.

-simon

On 15 March 2015 at 12:25, Hans W Borchers  wrote:
> I thought about writing my own `factorize` function. Testing the "argument
> checking" of `factor` I ended with the following events:
>
> julia> factor(0)
> ERROR: number to be factored must be positive
>  in factor at primes.jl:79
>
> julia> factor("0")
> ERROR: `factor` has no method matching factor(::ASCIIString)
>
> what is to be expected, I think, but the following killed my Julia process:
>
> julia> factor('0')
>
> signal (11): Segmentation fault
> rem at promotion.jl:174
>
> Segmentation fault (core dumped)
>
> I assume this happens because characters are also (almost) integers.
>
> Anyway, it should under no circumstances kill the whole process.
> This is Julia 0.3.6. Does this behaviour still occur under version 0.4?
>

[julia-users] Re: "print" and "write" for VTK export

[Tobias Knopp]

for l=1:length(x)
  x[l] = bswap(x[l])
  y[l] = bswap(y[l])
  z[l] = bswap(z[l])
end


Am Sonntag, 15. März 2015 11:17:53 UTC+1 schrieb Christian Dengler:
>
> Hello again,
>
> No that did not do the trick, but i managed to compare the julia output to 
> a working .vtk file, using a binary reader. The problem with the julia 
> output, is that it is written LittleEndian, while paraview needs BigEndian. 
> Also the structure must be write(fid, hcat(x[:]', y[:]', z[:]') ), but 
> written with BigEndians, which i haven't figured out how to do yet. I tried 
> the hton() function, as well as NetworkByteOrder from the docs, but i 
> guess i'm applying it wrong. I tried
>
> write(fid, hcat(x[:]', y[:]', z[:]') , NetworkByteOrder) -> NetworkByteOrder 
> not defined
> write(fid, hcat(x[:]', y[:]', z[:]') , "NetworkByteOrder") -> writes the 
> string to the file, instead of changing endianness
> write(fid, hton(hcat(x[:]', y[:]', z[:]'))) -> ERROR: `bswap` has no 
> method matching bswap(::Array{Float64,2})
>
> Any suggestions how to write big endian?
>
>
> Am Samstag, 14. März 2015 20:05:50 UTC+1 schrieb Tobias Knopp:
>>
>> not familiar with the vtk format but are you sure the the x,y,z 
>> coordinates lay not directly after each other?
>> Could try:
>>
>> write(fid, vcat(x[:]', y[:]', z[:]') )
>>
>> Am Samstag, 14. März 2015 18:54:59 UTC+1 schrieb Christian Dengler:
>>>
>>> Ty for your answers. I'm not familiar with vtk export on python, and i'm 
>>> confident that finding my mistake will be easier than trying to understand 
>>> what you did there with pycall.
>>> As for the nrrd code, it seems to be doing exactly what i did. I found 
>>> one mistake i did previously though, telling paraview to load float instead 
>>> of double values. Now with the function below, paraview loads the files 
>>> withoud error message, yet doesnt display anything reasonable, seems that 
>>> there is another mistake somewhere, i still assume it to be the "write" 
>>> function, where i'm not sure if it does what i want it to.
>>> I'll keep you up to date, should i find my mistake
>>>
>>> function exportVTK(DataMat, NameMat ,filename, dh, Nxyz)
>>>
>>> nx = dh[1]*(Nxyz[1]-1);
>>> ny = dh[2]*(Nxyz[2]-1);
>>> nz = dh[3]*(Nxyz[3]-1);
>>>
>>> x, y, z = ndgrid(0:dh[1]:nx, 0:dh[2]:ny, 0:dh[3]:nz );
>>>
>>> nr_of_elements = length(x);
>>> fid = open(filename, "w"); 
>>>
>>> #ASCII file header
>>> println(fid, "# vtk DataFile Version 3.0");
>>> println(fid, "VTK from Julia");
>>> println(fid, "BINARY\n");
>>> println(fid, "DATASET STRUCTURED_GRID");
>>> println(fid, "DIMENSIONS $(size(x,1)) $(size(x,2)) $(size(x,3)) ");
>>> println(fid, "POINTS $(nr_of_elements) double");
>>> write(fid, [x[:] y[:] z[:]] )
>>>
>>> #append data
>>> print(fid, "\nPOINT_DATA $(nr_of_elements) \n");
>>>
>>> for i = 1:length(DataMat)
>>>
>>> if size(DataMat[i], 2) == 3
>>> #append a vector
>>> println(fid, "\nVECTORS $(NameMat[i]) double"); 
>>> elseif size(DataMat[i], 2) == 1
>>> #append a scalar
>>> println(fid, "\nSCALARS $(NameMat[i]) double");
>>> println(fid, "LOOKUP_TABLE default"); 
>>> else
>>> error("DataMat $i is not a vector or scalar, or not shaped the 
>>> way it should be")
>>> end
>>> 
>>> write(fid, DataMat[i]);
>>>
>>> end
>>>
>>> close(fid);
>>>
>>> end
>>>
>>>
>>>
>>>
>>>
>>> Am Samstag, 14. März 2015 17:49:50 UTC+1 schrieb Kristoffer Carlsson:

 One method that I have used to export VTK from Julia is simply using 
 the VTK-library from python and calling it with PyCall.

 Something like this: 
 https://gist.github.com/KristofferC/9a989a2c0518bb70009c



 On Saturday, March 14, 2015 at 1:41:04 PM UTC+1, Christian Dengler 
 wrote:
>
> Hello,
>
> I'm trying to save my data as .vtk files, and ran into a problem with 
> the "print" and "write" function.
>
> Resumee of what would solve my problems:
> - Using print(filestream, data), but omitting the square brackets, and
> - using print(filestream, vector), and actually writes the vector, one 
> element per line
>
> Does anyone know how this is done?
>
> Another way of creating .vtk files using binary data, using the write 
> function, didn't lead to any success, but i cant really say whats wrong, 
> because the files are unreadable. Could it be, that write also somehow 
> includes brackets?
>
>
> For those who want to see my problem in code, i attached a script, 
> creating and saving a simple veocity field as .vtk (ASCII) file.
> After manually deleting the brackets, atleast the velocity can be 
> imported into paraview.
> In order to create the binary .vtk file (thats not working at all), i 
> used to replace "ASCII" by "BINARY", and "print" in line 22 and  41 by 
> "write".
>
> Greetings, 
> Christian
>

[julia-users] Re: Factorization of big integers is taking too long

[Hans W Borchers]

I thought about writing my own `factorize` function. Testing the "argument 
checking" of `factor` I ended with the following events:

julia> factor(0)
ERROR: number to be factored must be positive
 in factor at primes.jl:79

julia> factor("0")
ERROR: `factor` has no method matching factor(::ASCIIString)

what is to be expected, I think, but the following killed my Julia process:

julia> factor('0')

signal (11): Segmentation fault
rem at promotion.jl:174

Segmentation fault (core dumped)

I assume this happens because characters are also (almost) integers. 

Anyway, it should under no circumstances kill the whole process.
This is Julia 0.3.6. Does this behaviour still occur under version 0.4?

[julia-users] Re: isnull woes

[Avik Sengupta]

I think while a Java Null and Nullable Null are different, asking the 
question "isnull" is  a similar enough concept to deserve the same 
function. The Base/Nullable method is isnull(::Nullable), while the 
JavaCall method is isnull(::JavaObject{T}) .. which is the way it should 
be, afaics. It's only my wish to write a package that works accross 0.3 and 
0.4 that introduces the problem. 


On Saturday, 14 March 2015 11:14:58 UTC, Toivo Henningsson wrote:
>
> Do we consider nullness of java objects and nullables to be similar enough 
> that they should actually be checked with the same predicate? I guess the 
> two concepts do have a lot of things in common, though methods written to 
> work with nullables might not be prepared to accept java objects.

[julia-users] Re: "print" and "write" for VTK export

[Christian Dengler]

Hello again,

No that did not do the trick, but i managed to compare the julia output to 
a working .vtk file, using a binary reader. The problem with the julia 
output, is that it is written LittleEndian, while paraview needs BigEndian. 
Also the structure must be write(fid, hcat(x[:]', y[:]', z[:]') ), but 
written with BigEndians, which i haven't figured out how to do yet. I tried 
the hton() function, as well as NetworkByteOrder from the docs, but i guess 
i'm applying it wrong. I tried

write(fid, hcat(x[:]', y[:]', z[:]') , NetworkByteOrder) -> NetworkByteOrder 
not defined
write(fid, hcat(x[:]', y[:]', z[:]') , "NetworkByteOrder") -> writes the 
string to the file, instead of changing endianness
write(fid, hton(hcat(x[:]', y[:]', z[:]'))) -> ERROR: `bswap` has no method 
matching bswap(::Array{Float64,2})

Any suggestions how to write big endian?


Am Samstag, 14. März 2015 20:05:50 UTC+1 schrieb Tobias Knopp:
>
> not familiar with the vtk format but are you sure the the x,y,z 
> coordinates lay not directly after each other?
> Could try:
>
> write(fid, vcat(x[:]', y[:]', z[:]') )
>
> Am Samstag, 14. März 2015 18:54:59 UTC+1 schrieb Christian Dengler:
>>
>> Ty for your answers. I'm not familiar with vtk export on python, and i'm 
>> confident that finding my mistake will be easier than trying to understand 
>> what you did there with pycall.
>> As for the nrrd code, it seems to be doing exactly what i did. I found 
>> one mistake i did previously though, telling paraview to load float instead 
>> of double values. Now with the function below, paraview loads the files 
>> withoud error message, yet doesnt display anything reasonable, seems that 
>> there is another mistake somewhere, i still assume it to be the "write" 
>> function, where i'm not sure if it does what i want it to.
>> I'll keep you up to date, should i find my mistake
>>
>> function exportVTK(DataMat, NameMat ,filename, dh, Nxyz)
>>
>> nx = dh[1]*(Nxyz[1]-1);
>> ny = dh[2]*(Nxyz[2]-1);
>> nz = dh[3]*(Nxyz[3]-1);
>>
>> x, y, z = ndgrid(0:dh[1]:nx, 0:dh[2]:ny, 0:dh[3]:nz );
>>
>> nr_of_elements = length(x);
>> fid = open(filename, "w"); 
>>
>> #ASCII file header
>> println(fid, "# vtk DataFile Version 3.0");
>> println(fid, "VTK from Julia");
>> println(fid, "BINARY\n");
>> println(fid, "DATASET STRUCTURED_GRID");
>> println(fid, "DIMENSIONS $(size(x,1)) $(size(x,2)) $(size(x,3)) ");
>> println(fid, "POINTS $(nr_of_elements) double");
>> write(fid, [x[:] y[:] z[:]] )
>>
>> #append data
>> print(fid, "\nPOINT_DATA $(nr_of_elements) \n");
>>
>> for i = 1:length(DataMat)
>>
>> if size(DataMat[i], 2) == 3
>> #append a vector
>> println(fid, "\nVECTORS $(NameMat[i]) double"); 
>> elseif size(DataMat[i], 2) == 1
>> #append a scalar
>> println(fid, "\nSCALARS $(NameMat[i]) double");
>> println(fid, "LOOKUP_TABLE default"); 
>> else
>> error("DataMat $i is not a vector or scalar, or not shaped the 
>> way it should be")
>> end
>> 
>> write(fid, DataMat[i]);
>>
>> end
>>
>> close(fid);
>>
>> end
>>
>>
>>
>>
>>
>> Am Samstag, 14. März 2015 17:49:50 UTC+1 schrieb Kristoffer Carlsson:
>>>
>>> One method that I have used to export VTK from Julia is simply using the 
>>> VTK-library from python and calling it with PyCall.
>>>
>>> Something like this: 
>>> https://gist.github.com/KristofferC/9a989a2c0518bb70009c
>>>
>>>
>>>
>>> On Saturday, March 14, 2015 at 1:41:04 PM UTC+1, Christian Dengler wrote:

 Hello,

 I'm trying to save my data as .vtk files, and ran into a problem with 
 the "print" and "write" function.

 Resumee of what would solve my problems:
 - Using print(filestream, data), but omitting the square brackets, and
 - using print(filestream, vector), and actually writes the vector, one 
 element per line

 Does anyone know how this is done?

 Another way of creating .vtk files using binary data, using the write 
 function, didn't lead to any success, but i cant really say whats wrong, 
 because the files are unreadable. Could it be, that write also somehow 
 includes brackets?


 For those who want to see my problem in code, i attached a script, 
 creating and saving a simple veocity field as .vtk (ASCII) file.
 After manually deleting the brackets, atleast the velocity can be 
 imported into paraview.
 In order to create the binary .vtk file (thats not working at all), i 
 used to replace "ASCII" by "BINARY", and "print" in line 22 and  41 by 
 "write".

 Greetings, 
 Christian

>>>

[julia-users] Re: Some simple use cases for multi-threading

[Jeff Waller]

I'll like for sure  the ability for Julia to support event driven tasks 
within the same
process, in particular (of course) for web-originated requests and the 
originating
thread never waits. Could the threading model allow auto-scale? Is it 
possible to
automatically decompose aggregate ops from to MATLAB form without
intermediaries? Something like auto-parallel sort would be cool.

Re: [julia-users] Re: Performance - what am I doing wrong?

[elextr]

On Sunday, March 15, 2015 at 4:31:56 PM UTC+10, Kyle Barbary wrote:
>
> Lex is right that the devectorized form [xi^2 for xi in x] suffers from 
> not being in a function. However, the x.^2 form is already simply a 
> function call, so it shouldn’t benefit much from being wrapped in a 
> function. 
>
Yes, the 40X was for the  `[xi^2 for xi in x]` but the `x.^2` still showed 
a 5X improvement in a function on 0.3.6.  The .^ function is written in 
Julia so it still has the issues accessing globals.

Perhaps I should have made it clear that `n`, `x` and `y` were also moved 
into the function so they are not global.

Cheers
Lex 


 

> Note that one of the other performance tips in Julia v0.3 is that you 
> should use x*x instead of x.^2 (I think this will not be the case in 
> v0.4). On Julia v0.3.6:
>
> julia> x = rand(1);
>
> julia> @timeit x.^2
>
> 1000 loops, best of 3: 100.46 µs per loop
>
> julia> @timeit x.*x
> 1 loops, best of 3: 30.15 µs per loop
>
> I get about the same timing as the second version when writing a custom 
> function with @simd and @inbounds.
>
> In Python:
>
> In [19]: from numpy.random import rand
>
> In [20]: x = rand(1);
>
> In [21]: %timeit x**210 loops, best of 3: 4.47 µs per loop
>
> So, I’m still seeing a difference of about a factor of 6 between numpy and 
> Julia here (but found that the difference does depend on array size and is 
> generally less). I’m curious what the difference is caused by in this case. 
> Alex’s email shows that a lot of the time is due to allocating the result 
> array (his x2! and x2simd! functions don’t include the allocation), but I 
> think the above is a “fair” comparison, as Python allocates an array to 
> perform x**2 as well.
>
> Kyle
> ​
>
> On Sat, Mar 14, 2015 at 9:24 PM, > wrote:
>
>> Read 
>> http://docs.julialang.org/en/latest/manual/performance-tips/?highlight=performance#performance-tips
>>  
>> in particular the first one avoiding global variables.  I get up to 40 
>> times the performance by putting your code in a function.
>>
>> Cheers
>> Lex
>>
>>
>> On Sunday, March 15, 2015 at 2:10:29 PM UTC+10, Dallas Morisette wrote:
>>>
>>> I am very new to Julia. I'm working on adding some features to a fairly 
>>> simple Fortran simulation, and decided to try writing it in Python to make 
>>> it easier to explore variations. After a lot of optimization work I got it 
>>> within about 8x slower than the Fortran code. I had read about Julia and 
>>> had wanted a reason to try it, so I thought I'd see if I could get closer 
>>> to Fortran speeds in Julia. My initial results were depressingly slow 
>>> (140x slower than Fortran and 17x slower than Python) and before trying to 
>>> optimize it I tried some very simple benchmarks to try to understand how to 
>>> get good performance from Julia. One I tried was two different versions of 
>>> squaring each element of a 10,000 element array, one vectorized, and one 
>>> for-loop. I fully expected there to be a large difference in performance of 
>>> Python between the two, but I didn't expect Julia to be slower than Python 
>>> in BOTH cases. I also expected the for loop and vectorized versions to be 
>>> similar, if not the for loop faster given what I'd read 
>>> about devectjorizing Julia code. 
>>>
>>> I'm sure I'm doing something wrong, but can someone point out what?
>>>
>>> Here are the results
>>>
>>> # Python Version
>>> import numpy as np
>>> n = 1
>>> x = np.linspace(0.0,1.0,n)
>>> y = np.zeros_like(x)
>>> %timeit y = x**2
>>> %timeit y = [xi**2 for xi in x]
>>> 10 loops, best of 3: 5.42 µs per loop
>>> 100 loops, best of 3: 3.19 ms per loop
>>>
>>>
>>>
>>> # Julia Version
>>> using TimeIt
>>> n = 1
>>> x = linspace(0.0,1.0,n)
>>> y = zeros(x)
>>> @timeit y = x.^2
>>> @timeit y = [xi^2 for xi in x]
>>> 1000 loops, best of 3: 433.29 µs per loop
>>> 100 loops, best of 3: 8.57 ms per loop
>>>
>>>
>>> Thanks!
>>>
>>> Dallas Morisette
>>>
>>>
>