Re: [julia-users] Can't overwrite some methods in 0.5.0

[Yichao Yu]

On Wed, Oct 19, 2016 at 10:33 PM, Alex Mellnik 
wrote:

> Yichao,
>
> I'm afraid I'm not following -- could you expand on that a bit?  Thanks,
>

https://github.com/JuliaLang/julia/issues/265


>
> Alex
>
> On Wednesday, October 19, 2016 at 4:41:30 PM UTC-7, Yichao Yu wrote:
>
>> On Oct 19, 2016 7:26 PM, "Alex Mellnik"  wrote:
>> >
>> > Here's my bizarre find of the day.  Most functions can be overwritten
>> without problems:
>> >
>> > function add7(i)
>> > 7 + i
>> > end
>> > Out[1]:
>> > add7 (generic function with 1 method)
>> > In [2]:
>> >
>> > add7(0)
>> > add7(0)
>> > Out[2]:
>> > 7
>> > In [3]:
>> >
>> > function add7(i)
>> > 9 + i
>> > end
>> > function add7(i)
>> > 9 + i
>> > end
>> > Out[3]:
>> > add7 (generic function with 1 method)
>> > WARNING: Method definition add7(Any) in module Main at In[1]:2
>> overwritten at In[3]:2.
>> > In [4]:
>> >
>> > add7(0)
>> > Out[4]:
>> > 9
>> >
>> > However, others can not:
>> >
>> > using DataFrames
>> > df = DataFrame(A=[1,2,3], B=["A", "B", "C"])
>> > println(df)
>> > 3×2 DataFrames.DataFrame
>> > │ Row │ A │ B   │
>> > ├─┼───┼─┤
>> > │ 1   │ 1 │ "A" │
>> > │ 2   │ 2 │ "B" │
>> > │ 3   │ 3 │ "C" │
>> > In [3]:
>> >
>> > row[:A] > 2
>> > function filter(row)
>> > if row[:A] > 2
>> > return 1
>> > else
>> > return 3
>> > end
>> > end
>> > Out[3]:
>> > filter (generic function with 1 method)
>> > In [4]:
>> >
>> > [filter(row) for row in eachrow(df)]
>> > [filter(row) for row in eachrow(df)]
>> > Out[4]:
>> > 3-element Array{Int64,1}:
>> >  3
>> >  3
>> >  1
>> > In [5]:
>> >
>> > rand() > 0.5
>> > function filter(row)
>> > if row[:A] > 2
>> > return 2
>> > else
>> > return 4
>> > end
>> > end
>> > WARNING: Method definition filter(Any) in module Main at In[3]:2
>> overwritten at In[5]:2
>> > Out[5]:
>> > filter (generic function with 1 method)
>> > .
>> > In [6]:
>> >
>> > [filter(row) for row in eachrow(df)]
>> > Out[6]:
>> > 3-element Array{Int64,1}:
>> >  3
>> >  3
>> >  1
>> >
>> > What is it about this second example that prevents the newer method
>> from being used?
>>
>> Nothing about it but how you use it. It's inlined to the comprehension.
>>
>>

Re: [julia-users] congratulations to Indian dost

[Michele Zaffalon]

Tim Holy: I had hoped you learnt to be more careful with untested versions. 
See what happened this time around: 
https://www.theguardian.com/science/2016/oct/20/bad-day-for-space-probes-one-lost-on-mars-another-in-safe-mode-at-jupiter?

On Wednesday, September 24, 2014 at 5:27:52 PM UTC+2, Tim Holy wrote:
>
> "Sorry, sir, but our Mars probe crashed. It's a complete loss." 
>
> "Oh no! Why?" 
>
> "Well, just before it was about to dock, Tim Holy tagged a new version of 
> Images. Turns out it had a bug in it that prevented the cameras from 
> saving 
> images to disk. So we were flying blind. We tried rolling back to an 
> earlier 
> version, but recent changes to Pkg meant that `pin` wasn't working either. 
> So 
> we hit the planet." 
>
> "Next time, don't run master." 
>
> --Tim 
>
> On Wednesday, September 24, 2014 08:12:35 AM John Myles White wrote: 
> > Not that I’m aware of. I’d say the thread is probably off-topic. 
> > 
> >  — John 
> > 
> > On Sep 24, 2014, at 8:10 AM, Stefan Karpinski  > wrote: 
> > > Is there any evidence that Julia was used to accomplish that? 
> > > 
> > > On Wed, Sep 24, 2014 at 11:05 AM, John Myles White 
> > > > wrote: I think this is the 
> flight to Mars that 
> > > India just finsihed. 
> > > 
> > >  — John 
> > > 
> > > On Sep 24, 2014, at 8:04 AM, Stefan Karpinski  > 
> wrote: 
> > >> I have no idea what this is about. Can you clarify? 
> > >> 
> > >> On Wed, Sep 24, 2014 at 3:47 AM, K Leo  > wrote: 
> > >> for the wonderful achievement with Mangalyaan! 
> > >> 
> > >> With a budget less than a Hollywood movie, I bet they must have 
> largely 
> > >> used (and supported?) open sources - Julia included? 
>
>

[julia-users] Re: BLAS.set_num_threads() and peakflops scaling

[Thomas Covert]

So are you suggesting that real numerical workloads under 
BLAS.set_num_threads(4) will indeed be faster than 
under BLAS.set_num_threads(2)?  That hasn't been my experience and I 
figured the peakflops() example would constitute an MWE.  Is there another 
workload you would suggest I try to figure out if this is just a peak 
flops() aberration or a real issue?

On Wednesday, October 19, 2016 at 8:28:16 PM UTC-5, Ralph Smith wrote:
>
> At least 2 things contribute to erratic results from peakflops(). With 
> hyperthreading, the threads are not always put on separate cores. Secondly, 
> the measured time includes
> the allocation of the result matrix, so garbage collection affects some of 
> the results.  Most available advice says to disable hyperthreading on 
> dedicated number crunchers
> (most full loads work slightly more efficiently without the extra context 
> switching).  The GC issue seems to be a mistake, if "peak" is to be taken 
> seriously.
>
> On Wednesday, October 19, 2016 at 12:04:00 PM UTC-4, Thomas Covert wrote:
>>
>> I have a recent iMac with 4 logical cores (and 8 hyper threads).  I would 
>> have thought that peakflops(N) for a large enough N should be increasing in 
>> the number of threads I allow BLAS to use.  I do find that peakflops(N) 
>> with 1 thread is about half as high as peakflops(N) with 2 threads, but 
>> there is no gain to 4 threads.  Are my expectations wrong here, or is it 
>> possible that BLAS is somehow configured incorrectly on my machine?  In the 
>> example below, N = 6755, a number relevant for my work, but the results are 
>> similar with 5000 or 1.
>>
>> here is my versioninfo()
>> julia> versioninfo()
>> Julia Version 0.5.0
>> Commit 3c9d753* (2016-09-19 18:14 UTC)
>> Platform Info:
>>   System: Darwin (x86_64-apple-darwin15.6.0)
>>   CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
>>   LAPACK: libopenblas
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.7.1 (ORCJIT, haswell)
>>
>> here is an example peakflops() exercise:
>> julia> BLAS.set_num_threads(1)
>>
>> julia> mean(peakflops(6755) for i=1:10)
>> 5.225580459387056e10
>>
>> julia> BLAS.set_num_threads(2)
>>
>> julia> mean(peakflops(6755) for i=1:10)
>> 1.004317640281997e11
>>
>> julia> BLAS.set_num_threads(4)
>>
>> julia> mean(peakflops(6755) for i=1:10)
>> 9.838116463900085e10
>>
>>
>>
>>
>>
>>

Re: [julia-users] Can't overwrite some methods in 0.5.0

[Alex Mellnik]

Yichao,

I'm afraid I'm not following -- could you expand on that a bit?  Thanks,

Alex

On Wednesday, October 19, 2016 at 4:41:30 PM UTC-7, Yichao Yu wrote:
>
> On Oct 19, 2016 7:26 PM, "Alex Mellnik" > 
> wrote:
> >
> > Here's my bizarre find of the day.  Most functions can be overwritten 
> without problems:
> >
> > function add7(i)
> > 7 + i
> > end
> > Out[1]:
> > add7 (generic function with 1 method)
> > In [2]:
> >
> > add7(0)
> > add7(0)
> > Out[2]:
> > 7
> > In [3]:
> >
> > function add7(i)
> > 9 + i
> > end
> > function add7(i)
> > 9 + i
> > end
> > Out[3]:
> > add7 (generic function with 1 method)
> > WARNING: Method definition add7(Any) in module Main at In[1]:2 
> overwritten at In[3]:2.
> > In [4]:
> >
> > add7(0)
> > Out[4]:
> > 9
> >
> > However, others can not:
> >
> > using DataFrames
> > df = DataFrame(A=[1,2,3], B=["A", "B", "C"])
> > println(df)
> > 3×2 DataFrames.DataFrame
> > │ Row │ A │ B   │
> > ├─┼───┼─┤
> > │ 1   │ 1 │ "A" │
> > │ 2   │ 2 │ "B" │
> > │ 3   │ 3 │ "C" │
> > In [3]:
> >
> > row[:A] > 2
> > function filter(row)
> > if row[:A] > 2
> > return 1
> > else
> > return 3
> > end
> > end  
> > Out[3]:
> > filter (generic function with 1 method)
> > In [4]:
> >
> > [filter(row) for row in eachrow(df)]
> > [filter(row) for row in eachrow(df)]
> > Out[4]:
> > 3-element Array{Int64,1}:
> >  3
> >  3
> >  1
> > In [5]:
> >
> > rand() > 0.5
> > function filter(row)
> > if row[:A] > 2
> > return 2
> > else
> > return 4
> > end
> > end  
> > WARNING: Method definition filter(Any) in module Main at In[3]:2 
> overwritten at In[5]:2
> > Out[5]:
> > filter (generic function with 1 method)
> > .
> > In [6]:
> >
> > [filter(row) for row in eachrow(df)]
> > Out[6]:
> > 3-element Array{Int64,1}:
> >  3
> >  3
> >  1
> >
> > What is it about this second example that prevents the newer method from 
> being used?
>
> Nothing about it but how you use it. It's inlined to the comprehension.
>
>

[julia-users] Re: BLAS.set_num_threads() and peakflops scaling

[Ralph Smith]

At least 2 things contribute to erratic results from peakflops(). With 
hyperthreading, the threads are not always put on separate cores. Secondly, 
the measured time includes
the allocation of the result matrix, so garbage collection affects some of 
the results.  Most available advice says to disable hyperthreading on 
dedicated number crunchers
(most full loads work slightly more efficiently without the extra context 
switching).  The GC issue seems to be a mistake, if "peak" is to be taken 
seriously.

On Wednesday, October 19, 2016 at 12:04:00 PM UTC-4, Thomas Covert wrote:
>
> I have a recent iMac with 4 logical cores (and 8 hyper threads).  I would 
> have thought that peakflops(N) for a large enough N should be increasing in 
> the number of threads I allow BLAS to use.  I do find that peakflops(N) 
> with 1 thread is about half as high as peakflops(N) with 2 threads, but 
> there is no gain to 4 threads.  Are my expectations wrong here, or is it 
> possible that BLAS is somehow configured incorrectly on my machine?  In the 
> example below, N = 6755, a number relevant for my work, but the results are 
> similar with 5000 or 1.
>
> here is my versioninfo()
> julia> versioninfo()
> Julia Version 0.5.0
> Commit 3c9d753* (2016-09-19 18:14 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin15.6.0)
>   CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.7.1 (ORCJIT, haswell)
>
> here is an example peakflops() exercise:
> julia> BLAS.set_num_threads(1)
>
> julia> mean(peakflops(6755) for i=1:10)
> 5.225580459387056e10
>
> julia> BLAS.set_num_threads(2)
>
> julia> mean(peakflops(6755) for i=1:10)
> 1.004317640281997e11
>
> julia> BLAS.set_num_threads(4)
>
> julia> mean(peakflops(6755) for i=1:10)
> 9.838116463900085e10
>
>
>
>
>
>

Re: [julia-users] Can't overwrite some methods in 0.5.0

[Yichao Yu]

On Oct 19, 2016 7:26 PM, "Alex Mellnik"  wrote:
>
> Here's my bizarre find of the day.  Most functions can be overwritten
without problems:
>
> function add7(i)
> 7 + i
> end
> Out[1]:
> add7 (generic function with 1 method)
> In [2]:
>
> add7(0)
> add7(0)
> Out[2]:
> 7
> In [3]:
>
> function add7(i)
> 9 + i
> end
> function add7(i)
> 9 + i
> end
> Out[3]:
> add7 (generic function with 1 method)
> WARNING: Method definition add7(Any) in module Main at In[1]:2
overwritten at In[3]:2.
> In [4]:
>
> add7(0)
> Out[4]:
> 9
>
> However, others can not:
>
> using DataFrames
> df = DataFrame(A=[1,2,3], B=["A", "B", "C"])
> println(df)
> 3×2 DataFrames.DataFrame
> │ Row │ A │ B   │
> ├─┼───┼─┤
> │ 1   │ 1 │ "A" │
> │ 2   │ 2 │ "B" │
> │ 3   │ 3 │ "C" │
> In [3]:
>
> row[:A] > 2
> function filter(row)
> if row[:A] > 2
> return 1
> else
> return 3
> end
> end
> Out[3]:
> filter (generic function with 1 method)
> In [4]:
>
> [filter(row) for row in eachrow(df)]
> [filter(row) for row in eachrow(df)]
> Out[4]:
> 3-element Array{Int64,1}:
>  3
>  3
>  1
> In [5]:
>
> rand() > 0.5
> function filter(row)
> if row[:A] > 2
> return 2
> else
> return 4
> end
> end
> WARNING: Method definition filter(Any) in module Main at In[3]:2
overwritten at In[5]:2
> Out[5]:
> filter (generic function with 1 method)
> .
> In [6]:
>
> [filter(row) for row in eachrow(df)]
> Out[6]:
> 3-element Array{Int64,1}:
>  3
>  3
>  1
>
> What is it about this second example that prevents the newer method from
being used?

Nothing about it but how you use it. It's inlined to the comprehension.

[julia-users] Can't overwrite some methods in 0.5.0

[Alex Mellnik]

Here's my bizarre find of the day.  Most functions can be overwritten 
without problems:

function add7(i)
7 + i
end
Out[1]:
add7 (generic function with 1 method)
In [2]:

add7(0)
add7(0)
Out[2]:
7
In [3]:

function add7(i)
9 + i
end
function add7(i)
9 + i
end
Out[3]:
add7 (generic function with 1 method)
WARNING: Method definition add7(Any) in module Main at In[1]:2 overwritten 
at In[3]:2.
In [4]:

add7(0)
Out[4]:
9

However, others can not:

using DataFrames
df = DataFrame(A=[1,2,3], B=["A", "B", "C"])
println(df)
3×2 DataFrames.DataFrame
│ Row │ A │ B   │
├─┼───┼─┤
│ 1   │ 1 │ "A" │
│ 2   │ 2 │ "B" │
│ 3   │ 3 │ "C" │
In [3]:

row[:A] > 2
function filter(row)
if row[:A] > 2
return 1
else
return 3
end
end  
Out[3]:
filter (generic function with 1 method)
In [4]:

[filter(row) for row in eachrow(df)]
[filter(row) for row in eachrow(df)]
Out[4]:
3-element Array{Int64,1}:
 3
 3
 1
In [5]:

rand() > 0.5
function filter(row)
if row[:A] > 2
return 2
else
return 4
end
end  
WARNING: Method definition filter(Any) in module Main at In[3]:2 
overwritten at In[5]:2
Out[5]:
filter (generic function with 1 method)
.
In [6]:

[filter(row) for row in eachrow(df)]
Out[6]:
3-element Array{Int64,1}:
 3
 3
 1

What is it about this second example that prevents the newer method from 
being used?

[julia-users] Re: mktemp doesn't accept anonymous function?

[Ralph Smith]

specifically: 

>   mktemp(parent) Returns (path, io), where path is the path of a new 
>> temporary file in parent
>
>   and io is an open file object for this path.
>
>
>> so you would normally use the second entry (x in my example) in the 
function block. 

On Wednesday, October 19, 2016 at 5:45:56 PM UTC-4, Ralph Smith wrote:
>
> mktemp returns a 2-tuple, so (at least in v0.5)
>
> julia> mktemp() do y,x
>println(y)
>end
> /tmp/tmpS63NPs
>
> julia> mktemp((y,x) -> println(y))
> /tmp/tmpA2p0Y1
>
> julia> 
>
>
>
>
> On Wednesday, October 19, 2016 at 5:06:55 PM UTC-4, John Brock wrote:
>>
>>
>>
>> Am I doing something wrong or is this a bug? It seems like if the 1st 
>> version works, the 2nd and 3rd should, too.
>>
>> julia> mktemp(println)
>> /var/folders/jd/1skd5rh11hnc_s19lmx93zywgp/T/tmpf7HaUHIOStream(> >)
>>
>>
>> julia> mktemp(x->println(x))
>> ERROR: wrong number of arguments
>>  in anonymous at none:1
>>  in mktemp at file.jl:218
>>  in mktemp at file.jl:216
>>
>>
>> julia> mktemp() do x
>>  println(x)
>>end
>> ERROR: wrong number of arguments
>>  in anonymous at none:2
>>  in mktemp at file.jl:218
>>  in mktemp at file.jl:216
>>  
>>
>>
>> julia> versioninfo()
>> Julia Version 0.4.7
>> Commit ae26b25* (2016-09-18 16:17 UTC)
>> Platform Info:
>>   System: Darwin (x86_64-apple-darwin15.6.0)
>>   CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
>>   WORD_SIZE: 64
>>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>>   LAPACK: libopenblas64_
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.3
>>
>>

[julia-users] Re: Create EPS files with Gadfly

[Christopher Fisher]

Thanks Avik. I saw there is no official backend, but I wasn't sure if there 
was a clever way to hack something together from one of the other packages. 
Your idea involving the PS file might be an easier workaround. 

On Wednesday, October 19, 2016 at 5:42:05 PM UTC-4, Avik Sengupta wrote:
>
> The list of available backends to Gadfly are available here: 
> http://gadflyjl.org/stable/man/backends.html
>
> There is no EPS backend, only a PS backend, which you may be able to 
> convert to eps??
>
> Regards
> -
> Avik
>
>
> On Wednesday, 19 October 2016 21:20:13 UTC+1, Christopher Fisher wrote:
>>
>> Is it possible to create .eps files in Gadfly?
>>
>> Thanks,
>>
>> Chris 
>>
>

[julia-users] Re: mktemp doesn't accept anonymous function?

[Ralph Smith]

mktemp returns a 2-tuple, so (at least in v0.5)

julia> mktemp() do y,x
   println(y)
   end
/tmp/tmpS63NPs

julia> mktemp((y,x) -> println(y))
/tmp/tmpA2p0Y1

julia> 




On Wednesday, October 19, 2016 at 5:06:55 PM UTC-4, John Brock wrote:
>
>
>
> Am I doing something wrong or is this a bug? It seems like if the 1st 
> version works, the 2nd and 3rd should, too.
>
> julia> mktemp(println)
> /var/folders/jd/1skd5rh11hnc_s19lmx93zywgp/T/tmpf7HaUHIOStream( >)
>
>
> julia> mktemp(x->println(x))
> ERROR: wrong number of arguments
>  in anonymous at none:1
>  in mktemp at file.jl:218
>  in mktemp at file.jl:216
>
>
> julia> mktemp() do x
>  println(x)
>end
> ERROR: wrong number of arguments
>  in anonymous at none:2
>  in mktemp at file.jl:218
>  in mktemp at file.jl:216
>  
>
>
> julia> versioninfo()
> Julia Version 0.4.7
> Commit ae26b25* (2016-09-18 16:17 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin15.6.0)
>   CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
>
>

[julia-users] Re: Create EPS files with Gadfly

[Avik Sengupta]

The list of available backends to Gadfly are available 
here: http://gadflyjl.org/stable/man/backends.html

There is no EPS backend, only a PS backend, which you may be able to 
convert to eps??

Regards
-
Avik


On Wednesday, 19 October 2016 21:20:13 UTC+1, Christopher Fisher wrote:
>
> Is it possible to create .eps files in Gadfly?
>
> Thanks,
>
> Chris 
>

[julia-users] mktemp doesn't accept anonymous function?

[John Brock]

Am I doing something wrong or is this a bug? It seems like if the 1st 
version works, the 2nd and 3rd should, too.

julia> mktemp(println)
/var/folders/jd/1skd5rh11hnc_s19lmx93zywgp/T/tmpf7HaUHIOStream()


julia> mktemp(x->println(x))
ERROR: wrong number of arguments
 in anonymous at none:1
 in mktemp at file.jl:218
 in mktemp at file.jl:216


julia> mktemp() do x
 println(x)
   end
ERROR: wrong number of arguments
 in anonymous at none:2
 in mktemp at file.jl:218
 in mktemp at file.jl:216
 


julia> versioninfo()
Julia Version 0.4.7
Commit ae26b25* (2016-09-18 16:17 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin15.6.0)
  CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[julia-users] Create EPS files with Gadfly

[Christopher Fisher]

Is it possible to create .eps files in Gadfly?

Thanks,

Chris 

[julia-users] Re: How to install JuMP without SSL errors?

[Tony Kelman]

If you don't have a really good reason to be using 0.6-dev right now, you 
shouldn't be. Use 0.5.0 if at all possible.


On Sunday, October 16, 2016 at 8:55:07 AM UTC-7, Rick Graham wrote:
>
> Ref:  https://github.com/JuliaOpt/JuMP.jl/issues/864
>
> I can't seem to add package JuMP.  Other packages seem to be added fine.
>
> How can I fix this?
>
> OS: Fedora 24
>
> julia> versioninfo()
> Julia Version 0.6.0-dev.986
> Commit 6c9f5af (2016-10-16 05:19 UTC)
> Platform Info:
>   OS: Linux (x86_64-redhat-linux)
>   CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)
>
>
>
> julia> Pkg.add("JuMP")
> INFO: Cloning cache of Calculus from 
> https://github.com/johnmyleswhite/Calculus.jl.git
> INFO: Cloning cache of DataStructures from 
> https://github.com/JuliaLang/DataStructures.jl.git
> INFO: Cloning cache of ForwardDiff from 
> https://github.com/JuliaDiff/ForwardDiff.jl.git
> INFO: Cloning cache of JuMP from https://github.com/JuliaOpt/JuMP.jl.git
> ERROR: Cannot clone JuMP from https://github.com/JuliaOpt/JuMP.jl.git. SSL 
> error:  - UNKNOWN ERROR CODE (0001)
>  in prefetch(::String, ::String, ::Array{String,1}) at ./pkg/cache.jl:56
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}, ::Dict{String,VersionNumber}, 
> ::Set{String}) at ./pkg/entry.jl:512
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}) at ./pkg/entry.jl:476
>  in edit(::Function, ::String, ::Base.Pkg.Types.VersionSet, 
> ::Vararg{Base.Pkg.Types.VersionSet,N}) at ./pkg/entry.jl:30
>  in (::Base.Pkg.Entry.##2#5{String,Base.Pkg.Types.VersionSet})() at 
> ./task.jl:363
>  in sync_end() at ./task.jl:314
>  in macro expansion at ./task.jl:330 [inlined]
>  in add(::String, ::Base.Pkg.Types.VersionSet) at ./pkg/entry.jl:50
>  in (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}})() 
> at ./pkg/dir.jl:31
>  in cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}}, 
> ::String) at ./file.jl:69
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, ::Vararg{Any,N}) 
> at ./pkg/dir.jl:31
>  in add(::String) at ./pkg/pkg.jl:100
>
>

[julia-users] Re: kill asynchronous tasks

[ggggg]

https://github.com/JuliaLang/julia/issues/6283

Re: [julia-users] Re: product of Int64 and Float64 is Int64

[Michele Zaffalon]

A bad habit learnt using Python...

On Wed, Oct 19, 2016 at 3:53 PM, Krisztián Pintér 
wrote:

>
> i know i shouldn't, but i'm kinda angry at this "1." notation. saving one
> character really worth losing readability? also leading to errors like
> this. personally, i would not even allow this syntax at all.
>
> On Wednesday, October 19, 2016 at 1:11:38 PM UTC+2, Michele Zaffalon wrote:
>>
>> I am confused by the type of the result of `1.*80`, which is `Int64`,
>> despite the fact that `1.` is `Float64`, and that `Float64(1)*80` is a
>> `Float64`:
>>
>

Re: [julia-users] iterator trait

[Mauro]

In principle you could use method_exists to check whether the start,
next & done are defined for a particular type to make the isiterator
function.  In practice this may run into
https://github.com/JuliaLang/julia/issues/8959 which should be fixed
with https://github.com/JuliaLang/julia/pull/18457 .

So until then this is not 100% possible.  (Well, Traits.jl could do it,
but one of the main reasons that package never made it passed
experimental-status is indeed the difficulty to work around issue 8959)

If you need this now, use SimpleTraits.jl, follow above approach and
advise your users to manually add or remove types from the IsIterable
trait if method_exists hits 8959.  Let me know if you need help.

Mauro

On Wed, 2016-10-19 at 19:57, David Anthoff  wrote:
> Is there some way to find out whether a type can be iterated? I'm looking
> for something like `isiterator(IterType)`, that would return `false` from a
> default implementation and which any type that actually supports the
> standard iterator interface would return `true`.
>
>
>
> If we had that, we could actually define a SimpleTrait ``IsIterator`` and
> use method dispatch to have methods that operate on iterators, which would
> be really powerful.
>
>
>
> Cheers,
>
> David

[julia-users] Re: How to install JuMP without SSL errors?

[Jonathan Goldfarb]

FYI: https://github.com/JuliaLang/julia/issues/18871

On Sunday, October 16, 2016 at 11:55:07 AM UTC-4, Rick Graham wrote:
>
> Ref:  https://github.com/JuliaOpt/JuMP.jl/issues/864
>
> I can't seem to add package JuMP.  Other packages seem to be added fine.
>
> How can I fix this?
>
> OS: Fedora 24
>
> julia> versioninfo()
> Julia Version 0.6.0-dev.986
> Commit 6c9f5af (2016-10-16 05:19 UTC)
> Platform Info:
>   OS: Linux (x86_64-redhat-linux)
>   CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)
>
>
>
> julia> Pkg.add("JuMP")
> INFO: Cloning cache of Calculus from 
> https://github.com/johnmyleswhite/Calculus.jl.git
> INFO: Cloning cache of DataStructures from 
> https://github.com/JuliaLang/DataStructures.jl.git
> INFO: Cloning cache of ForwardDiff from 
> https://github.com/JuliaDiff/ForwardDiff.jl.git
> INFO: Cloning cache of JuMP from https://github.com/JuliaOpt/JuMP.jl.git
> ERROR: Cannot clone JuMP from https://github.com/JuliaOpt/JuMP.jl.git. SSL 
> error:  - UNKNOWN ERROR CODE (0001)
>  in prefetch(::String, ::String, ::Array{String,1}) at ./pkg/cache.jl:56
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}, ::Dict{String,VersionNumber}, 
> ::Set{String}) at ./pkg/entry.jl:512
>  in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, 
> ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, 
> ::Dict{String,Tuple{VersionNumber,Bool}}, 
> ::Dict{String,Base.Pkg.Types.Fixed}) at ./pkg/entry.jl:476
>  in edit(::Function, ::String, ::Base.Pkg.Types.VersionSet, 
> ::Vararg{Base.Pkg.Types.VersionSet,N}) at ./pkg/entry.jl:30
>  in (::Base.Pkg.Entry.##2#5{String,Base.Pkg.Types.VersionSet})() at 
> ./task.jl:363
>  in sync_end() at ./task.jl:314
>  in macro expansion at ./task.jl:330 [inlined]
>  in add(::String, ::Base.Pkg.Types.VersionSet) at ./pkg/entry.jl:50
>  in (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}})() 
> at ./pkg/dir.jl:31
>  in cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}}, 
> ::String) at ./file.jl:69
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, ::Vararg{Any,N}) 
> at ./pkg/dir.jl:31
>  in add(::String) at ./pkg/pkg.jl:100
>
>

[julia-users] iterator trait

[David Anthoff]

Is there some way to find out whether a type can be iterated? I'm looking
for something like `isiterator(IterType)`, that would return `false` from a
default implementation and which any type that actually supports the
standard iterator interface would return `true`.

 

If we had that, we could actually define a SimpleTrait ``IsIterator`` and
use method dispatch to have methods that operate on iterators, which would
be really powerful.

 

Cheers,

David

[julia-users] kill asynchronous tasks

[Ryan Gardner]

I'm looking for a way to reliably kill asynchronous tasks.

My code is roughly:


   task = @async call_external_program_that_may_never_return

   #do stuff of interest

   exit(0)  #please really exit now, no matter what

Currently, if the external program never returns, neither does my program, 
which is really bad.  Note that I have no control over the external program 
-- I can't add an exit condition.

I want a way to ensure the program really quits no matter what.

I have tried

   throwto(task, InterruptException())
   interrupt()

These don't actually stop the @async code and thus prevent exiting.

I'm not married to using @async, but need to run the async stuff on this 
process (not a worker).

Thanks. 

[julia-users] Re: Python Callbacks using pyjulia

[Steven G. Johnson]

A workaround from pyjulia might be to create a Julia function that can wrap 
a Julia Function around a Python function

fwrap = j.eval('f -> (args...) -> f(args...)')


and then do

j.dasslSolve(fwrap(f), 1.0, [0.0, 10.0])


Not super elegant, but occasionally inter-language calling requires this 
kind of "type massaging".  (We occasionally have to do a similar thing in 
PyCall when passing Julia functions to Python, since some Python code only 
works with "native" Python functions.)

Re: [julia-users] Embedding Julia in C++ - Determining returned array types

[Isaiah Norton]

e.g. http://half.sourceforge.net/

But if you aren't sure you need to support this, then just throw an error
(Float16 is relatively new and AFAICT only useful in specialized
applications because of the precision limit, which is why support is rare)

If you are sure you (a) need it but (b) only need to up- and down-convert,
see the routines in `base/float.jl`. They should be straightforward to port
to C++.

On Wed, Oct 19, 2016 at 1:00 PM, Yichao Yu  wrote:

>
>
> On Wed, Oct 19, 2016 at 12:54 PM, Kyle Kotowick  wrote:
>
>> Aha, that fixed it!
>>
>> I'm running into one issue though. What do I do with the data when it's a
>> "Float16" type? C++ has no way to represent a 16-bit float, so I'm having
>> difficulty converting it to a regular 32-bit float.
>>
>
> Find a compiler / library that supports it? ;-p
>
> I'm only half joking. You can always just keep a pointer to the value or
> store it in a int16_t as long as you don't need to do any operation on it.
> If you want to operate on them in C++ natively you would have to find a
> C/C++ compiler/library (or write the necessary operations yourself) that
> supports __fp16.
>
>
>>
>> jl_value_t *ret = jl_eval_string(code_string);
>> jl_array_t *ret_array = (jl_array_t*)ret;
>>
>> if (jl_array_eltype(ret) == jl_float16_type) {
>>
>>  /* now I need to convert the 'ret_array' to a C++ array of floats, but
>> how do I do that when they're given in Float16? */
>>
>> }
>>
>>
>> On Tuesday, 18 October 2016 20:57:10 UTC-4, Isaiah wrote:
>>>
>>> The issue here is that `jl_array_eltype` is already returning a type.
>>>
>>> `jl_typeis(v, t)` becomes `jl_typeof(v) == t`, so your checks become:
>>>
>>> jl_typeof(array_type) == jl_int64_type
>>>
>>> But
>>>
>>> jl_typeof(array_type) -> DataType
>>>
>>> Instead, either do the equality check directly:
>>>
>>>   array_type == jl_int64_type
>>>
>>> Or use the exported API only (jlapi.c):
>>>
>>>   strcmp(jl_typename_str(array_type), jl_typename_str(jl_int64_type))
>>>
>>> On Tue, Oct 18, 2016 at 7:52 PM, Kyle Kotowick 
>>> wrote:
>>>
 I apologize for the formatting, that should be:

 jl_value_t *ret = jl_eval_string(code_string);
 void* array_type = jl_array_eltype(ret);
 jl_array_t *ret_array = (jl_array_t*)ret;

 if (jl_typeis(array_type, jl_int64_type)) {
   long *data = (long*) jl_array_data(ret_array);
 }
 else if (jl_typeis(array_type, jl_float64_type)) {
   double *data = (double*) jl_array_data(ret_array);
 }


 And the issue is that even if it is an Int64 or Float64, neither of
 those IF statements will return true.



 On Sunday, 16 October 2016 21:36:03 UTC-4, Kyle Kotowick wrote:
>
> Awesome, thanks. Could you show how to use it in a minimal code
> example? Here's what I'm currently trying, but it does not appear to be
> working:
>
> jl_value_t *ret = jl_eval_string(code_string);
> void* array_type = jl_array_eltype(ret);
> jl_array_t *ret_array = (jl_array_t*)ret;
>
>
>
> if (jl_typeis(array_type, jl_int64_type)) {
>  long *data = (long*) jl_array_data(ret_array);
> }
> else if (jl_typeis(array_type, jl_float64_type)) { double *data = (
> double*) jl_array_data(ret_array);
> }
>
>
> On Friday, 14 October 2016 20:45:18 UTC-4, Isaiah wrote:
>>
>> On Fri, Oct 14, 2016 at 2:28 PM, Kyle Kotowick 
>> wrote:
>>>
>>>
>>> After determining that an array was returned, how would you
>>> determine what the inner type of the array is (i.e. the type of the 
>>> objects
>>> it contains)?
>>>
>>
>> `jl_array_eltype`
>>
>>
>>>
>>> And furthermore, if it returns an array of type "Any", would there
>>> be any way to tell what the type is of any arbitrary element in that 
>>> array?
>>>
>>
>> `jl_typeof`, after retrieving the element (which will be boxed)
>>
>>
>>>
>>> Thanks!
>>>
>>
>>
>>>
>

Re: [julia-users] Embedding Julia in C++ - Determining returned array types

[Stefan Karpinski]

You can pull the significant bits and the exponent values out of a Float16
and then use those to compute the value as a Float32:
https://en.wikipedia.org/wiki/Half-precision_floating-point_format

On Wed, Oct 19, 2016 at 1:00 PM, Yichao Yu  wrote:

>
>
> On Wed, Oct 19, 2016 at 12:54 PM, Kyle Kotowick  wrote:
>
>> Aha, that fixed it!
>>
>> I'm running into one issue though. What do I do with the data when it's a
>> "Float16" type? C++ has no way to represent a 16-bit float, so I'm having
>> difficulty converting it to a regular 32-bit float.
>>
>
> Find a compiler / library that supports it? ;-p
>
> I'm only half joking. You can always just keep a pointer to the value or
> store it in a int16_t as long as you don't need to do any operation on it.
> If you want to operate on them in C++ natively you would have to find a
> C/C++ compiler/library (or write the necessary operations yourself) that
> supports __fp16.
>
>
>>
>> jl_value_t *ret = jl_eval_string(code_string);
>> jl_array_t *ret_array = (jl_array_t*)ret;
>>
>> if (jl_array_eltype(ret) == jl_float16_type) {
>>
>>  /* now I need to convert the 'ret_array' to a C++ array of floats, but
>> how do I do that when they're given in Float16? */
>>
>> }
>>
>>
>> On Tuesday, 18 October 2016 20:57:10 UTC-4, Isaiah wrote:
>>>
>>> The issue here is that `jl_array_eltype` is already returning a type.
>>>
>>> `jl_typeis(v, t)` becomes `jl_typeof(v) == t`, so your checks become:
>>>
>>> jl_typeof(array_type) == jl_int64_type
>>>
>>> But
>>>
>>> jl_typeof(array_type) -> DataType
>>>
>>> Instead, either do the equality check directly:
>>>
>>>   array_type == jl_int64_type
>>>
>>> Or use the exported API only (jlapi.c):
>>>
>>>   strcmp(jl_typename_str(array_type), jl_typename_str(jl_int64_type))
>>>
>>> On Tue, Oct 18, 2016 at 7:52 PM, Kyle Kotowick 
>>> wrote:
>>>
 I apologize for the formatting, that should be:

 jl_value_t *ret = jl_eval_string(code_string);
 void* array_type = jl_array_eltype(ret);
 jl_array_t *ret_array = (jl_array_t*)ret;

 if (jl_typeis(array_type, jl_int64_type)) {
   long *data = (long*) jl_array_data(ret_array);
 }
 else if (jl_typeis(array_type, jl_float64_type)) {
   double *data = (double*) jl_array_data(ret_array);
 }


 And the issue is that even if it is an Int64 or Float64, neither of
 those IF statements will return true.



 On Sunday, 16 October 2016 21:36:03 UTC-4, Kyle Kotowick wrote:
>
> Awesome, thanks. Could you show how to use it in a minimal code
> example? Here's what I'm currently trying, but it does not appear to be
> working:
>
> jl_value_t *ret = jl_eval_string(code_string);
> void* array_type = jl_array_eltype(ret);
> jl_array_t *ret_array = (jl_array_t*)ret;
>
>
>
> if (jl_typeis(array_type, jl_int64_type)) {
>  long *data = (long*) jl_array_data(ret_array);
> }
> else if (jl_typeis(array_type, jl_float64_type)) { double *data = (
> double*) jl_array_data(ret_array);
> }
>
>
> On Friday, 14 October 2016 20:45:18 UTC-4, Isaiah wrote:
>>
>> On Fri, Oct 14, 2016 at 2:28 PM, Kyle Kotowick 
>> wrote:
>>>
>>>
>>> After determining that an array was returned, how would you
>>> determine what the inner type of the array is (i.e. the type of the 
>>> objects
>>> it contains)?
>>>
>>
>> `jl_array_eltype`
>>
>>
>>>
>>> And furthermore, if it returns an array of type "Any", would there
>>> be any way to tell what the type is of any arbitrary element in that 
>>> array?
>>>
>>
>> `jl_typeof`, after retrieving the element (which will be boxed)
>>
>>
>>>
>>> Thanks!
>>>
>>
>>
>>>
>

Re: [julia-users] Embedding Julia in C++ - Determining returned array types

[Yichao Yu]

On Wed, Oct 19, 2016 at 12:54 PM, Kyle Kotowick  wrote:

> Aha, that fixed it!
>
> I'm running into one issue though. What do I do with the data when it's a
> "Float16" type? C++ has no way to represent a 16-bit float, so I'm having
> difficulty converting it to a regular 32-bit float.
>

Find a compiler / library that supports it? ;-p

I'm only half joking. You can always just keep a pointer to the value or
store it in a int16_t as long as you don't need to do any operation on it.
If you want to operate on them in C++ natively you would have to find a
C/C++ compiler/library (or write the necessary operations yourself) that
supports __fp16.


>
> jl_value_t *ret = jl_eval_string(code_string);
> jl_array_t *ret_array = (jl_array_t*)ret;
>
> if (jl_array_eltype(ret) == jl_float16_type) {
>
>  /* now I need to convert the 'ret_array' to a C++ array of floats, but
> how do I do that when they're given in Float16? */
>
> }
>
>
> On Tuesday, 18 October 2016 20:57:10 UTC-4, Isaiah wrote:
>>
>> The issue here is that `jl_array_eltype` is already returning a type.
>>
>> `jl_typeis(v, t)` becomes `jl_typeof(v) == t`, so your checks become:
>>
>> jl_typeof(array_type) == jl_int64_type
>>
>> But
>>
>> jl_typeof(array_type) -> DataType
>>
>> Instead, either do the equality check directly:
>>
>>   array_type == jl_int64_type
>>
>> Or use the exported API only (jlapi.c):
>>
>>   strcmp(jl_typename_str(array_type), jl_typename_str(jl_int64_type))
>>
>> On Tue, Oct 18, 2016 at 7:52 PM, Kyle Kotowick  wrote:
>>
>>> I apologize for the formatting, that should be:
>>>
>>> jl_value_t *ret = jl_eval_string(code_string);
>>> void* array_type = jl_array_eltype(ret);
>>> jl_array_t *ret_array = (jl_array_t*)ret;
>>>
>>> if (jl_typeis(array_type, jl_int64_type)) {
>>>   long *data = (long*) jl_array_data(ret_array);
>>> }
>>> else if (jl_typeis(array_type, jl_float64_type)) {
>>>   double *data = (double*) jl_array_data(ret_array);
>>> }
>>>
>>>
>>> And the issue is that even if it is an Int64 or Float64, neither of
>>> those IF statements will return true.
>>>
>>>
>>>
>>> On Sunday, 16 October 2016 21:36:03 UTC-4, Kyle Kotowick wrote:

 Awesome, thanks. Could you show how to use it in a minimal code
 example? Here's what I'm currently trying, but it does not appear to be
 working:

 jl_value_t *ret = jl_eval_string(code_string);
 void* array_type = jl_array_eltype(ret);
 jl_array_t *ret_array = (jl_array_t*)ret;



 if (jl_typeis(array_type, jl_int64_type)) {
  long *data = (long*) jl_array_data(ret_array);
 }
 else if (jl_typeis(array_type, jl_float64_type)) { double *data = (
 double*) jl_array_data(ret_array);
 }


 On Friday, 14 October 2016 20:45:18 UTC-4, Isaiah wrote:
>
> On Fri, Oct 14, 2016 at 2:28 PM, Kyle Kotowick 
> wrote:
>>
>>
>> After determining that an array was returned, how would you determine
>> what the inner type of the array is (i.e. the type of the objects it
>> contains)?
>>
>
> `jl_array_eltype`
>
>
>>
>> And furthermore, if it returns an array of type "Any", would there be
>> any way to tell what the type is of any arbitrary element in that array?
>>
>
> `jl_typeof`, after retrieving the element (which will be boxed)
>
>
>>
>> Thanks!
>>
>
>
>>

Re: [julia-users] Embedding Julia in C++ - Determining returned array types

[Kyle Kotowick]

Aha, that fixed it!

I'm running into one issue though. What do I do with the data when it's a 
"Float16" type? C++ has no way to represent a 16-bit float, so I'm having 
difficulty converting it to a regular 32-bit float.

jl_value_t *ret = jl_eval_string(code_string);
jl_array_t *ret_array = (jl_array_t*)ret;

if (jl_array_eltype(ret) == jl_float16_type) {

 /* now I need to convert the 'ret_array' to a C++ array of floats, but how 
do I do that when they're given in Float16? */

}


On Tuesday, 18 October 2016 20:57:10 UTC-4, Isaiah wrote:
>
> The issue here is that `jl_array_eltype` is already returning a type.
>
> `jl_typeis(v, t)` becomes `jl_typeof(v) == t`, so your checks become:
>
> jl_typeof(array_type) == jl_int64_type
>
> But
>
> jl_typeof(array_type) -> DataType
>
> Instead, either do the equality check directly:
>
>   array_type == jl_int64_type
>
> Or use the exported API only (jlapi.c):
>
>   strcmp(jl_typename_str(array_type), jl_typename_str(jl_int64_type))
>
> On Tue, Oct 18, 2016 at 7:52 PM, Kyle Kotowick  > wrote:
>
>> I apologize for the formatting, that should be:
>>
>> jl_value_t *ret = jl_eval_string(code_string);
>> void* array_type = jl_array_eltype(ret);
>> jl_array_t *ret_array = (jl_array_t*)ret;
>>
>> if (jl_typeis(array_type, jl_int64_type)) {
>>   long *data = (long*) jl_array_data(ret_array);
>> }
>> else if (jl_typeis(array_type, jl_float64_type)) { 
>>   double *data = (double*) jl_array_data(ret_array);
>> }
>>
>>
>> And the issue is that even if it is an Int64 or Float64, neither of those 
>> IF statements will return true.
>>
>>
>>
>> On Sunday, 16 October 2016 21:36:03 UTC-4, Kyle Kotowick wrote:
>>>
>>> Awesome, thanks. Could you show how to use it in a minimal code example? 
>>> Here's what I'm currently trying, but it does not appear to be working:
>>>
>>> jl_value_t *ret = jl_eval_string(code_string);
>>> void* array_type = jl_array_eltype(ret);
>>> jl_array_t *ret_array = (jl_array_t*)ret;
>>>
>>>
>>>
>>> if (jl_typeis(array_type, jl_int64_type)) {
>>>  long *data = (long*) jl_array_data(ret_array);
>>> }
>>> else if (jl_typeis(array_type, jl_float64_type)) { double *data = (
>>> double*) jl_array_data(ret_array);
>>> }
>>>
>>>
>>> On Friday, 14 October 2016 20:45:18 UTC-4, Isaiah wrote:

 On Fri, Oct 14, 2016 at 2:28 PM, Kyle Kotowick  
 wrote:
>
>
> After determining that an array was returned, how would you determine 
> what the inner type of the array is (i.e. the type of the objects it 
> contains)?
>

 `jl_array_eltype`
  

>
> And furthermore, if it returns an array of type "Any", would there be 
> any way to tell what the type is of any arbitrary element in that array?
>

 `jl_typeof`, after retrieving the element (which will be boxed)
  

>
> Thanks!
>


>

[julia-users] BLAS.set_num_threads() and peakflops scaling

[Thomas Covert]

I have a recent iMac with 4 logical cores (and 8 hyper threads).  I would 
have thought that peakflops(N) for a large enough N should be increasing in 
the number of threads I allow BLAS to use.  I do find that peakflops(N) 
with 1 thread is about half as high as peakflops(N) with 2 threads, but 
there is no gain to 4 threads.  Are my expectations wrong here, or is it 
possible that BLAS is somehow configured incorrectly on my machine?  In the 
example below, N = 6755, a number relevant for my work, but the results are 
similar with 5000 or 1.

here is my versioninfo()
julia> versioninfo()
Julia Version 0.5.0
Commit 3c9d753* (2016-09-19 18:14 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin15.6.0)
  CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, haswell)

here is an example peakflops() exercise:
julia> BLAS.set_num_threads(1)

julia> mean(peakflops(6755) for i=1:10)
5.225580459387056e10

julia> BLAS.set_num_threads(2)

julia> mean(peakflops(6755) for i=1:10)
1.004317640281997e11

julia> BLAS.set_num_threads(4)

julia> mean(peakflops(6755) for i=1:10)
9.838116463900085e10

Re: [julia-users] matrix multiplications

[Cameron McBride]

I agree on the consistency part with other in-place operations. I certainly
don’t feel it’s hard to just use A_mul_B!, but my familiarity with BLAS
shouldn’t be taken for granted. And if an in-place operator syntax exists
in the language already…

How about the flip side of the argument, it appears to works now — but
doesn’t do what one expects. I understand why it doesn’t, and not a big
deal with an evolving landscape of a developing language, but it certainly
can be confusing and suggests matrices are a different beast. I’m not sure
that is consistent with Julian way.  But yeah, no fusing like broadcast so
the gain is much reduced in implementing this.

Cameron

On Wed, Oct 19, 2016 at 8:58 AM, Milan Bouchet-Valat 
wrote:

> Le mardi 18 octobre 2016 à 15:28 -0700, Steven G. Johnson a écrit :
> >
> >
> > > Since it uses the in-place assignment operator .= it could be made
> > > to work as desired, but there's some designing to do.
> > >
> >
> > The problem is that it doesn't know that * is a matrix multiplication
> > until compile-time.
> >
> > In any case, I don't think there's a huge amount to be gained from
> > special syntax here.  Unlike broadcast operations, matrix
> > multiplications cannot in general be fused with other operations.
> > So you might as well do A_mul_B!.
> I think the biggest gain would be discoverability and consistency with
> other in-place operations. A_mul_B! isn't the most Julian of our APIs
> (to say the least)...
>
>
> Regards
>

[julia-users] Re: product of Int64 and Float64 is Int64

[Steven Sagaert]

agreed

On Wednesday, October 19, 2016 at 3:53:00 PM UTC+2, Krisztián Pintér wrote:
>
>
> i know i shouldn't, but i'm kinda angry at this "1." notation. saving one 
> character really worth losing readability? also leading to errors like 
> this. personally, i would not even allow this syntax at all.
>
> On Wednesday, October 19, 2016 at 1:11:38 PM UTC+2, Michele Zaffalon wrote:
>>
>> I am confused by the type of the result of `1.*80`, which is `Int64`, 
>> despite the fact that `1.` is `Float64`, and that `Float64(1)*80` is a 
>> `Float64`:
>>
>

[julia-users] Re: Python Callbacks using pyjulia

[cdm]

it seems a near term work around could be had through PyCall ... ?

   https://github.com/JuliaPy/PyCall.jl




On Wednesday, October 19, 2016 at 7:21:05 AM UTC-7, Steven G. Johnson wrote:
>
> It looks like this is a problem in the DASSL.jl package.  They made the 
> common mistake of over-specifying the types of their arguments, and in 
> particular they require you to pass a Julia ::Function argument for the 
> equations to be solved, rather than any callable object (here, the Python 
> function is passed as a callable ::PyObject).
>
> https://github.com/pwl/DASSL.jl/issues/8
>

[julia-users] Re: product of Int64 and Float64 is Int64

[Steven G. Johnson]

Also https://github.com/JuliaLang/julia/pull/11529

[julia-users] Re: product of Int64 and Float64 is Int64

[Steven G. Johnson]

On Wednesday, October 19, 2016 at 9:53:00 AM UTC-4, Krisztián Pintér wrote:
>
>
> i know i shouldn't, but i'm kinda angry at this "1." notation. saving one 
> character really worth losing readability? also leading to errors like 
> this. personally, i would not even allow this syntax at all.
>

https://github.com/JuliaLang/julia/issues/15731 

Re: [julia-users] Re: product of Int64 and Float64 is Int64

[Tamas Papp]

And the same goes for the closely related .1 syntax.

Perhaps you could create an issue, if there isn't one already?

On Wed, Oct 19 2016, Krisztián Pintér wrote:

> i know i shouldn't, but i'm kinda angry at this "1." notation. saving one
> character really worth losing readability? also leading to errors like
> this. personally, i would not even allow this syntax at all.
>
> On Wednesday, October 19, 2016 at 1:11:38 PM UTC+2, Michele Zaffalon wrote:
>>
>> I am confused by the type of the result of `1.*80`, which is `Int64`,
>> despite the fact that `1.` is `Float64`, and that `Float64(1)*80` is a
>> `Float64`:
>>

[julia-users] Re: Python Callbacks using pyjulia

[Steven G. Johnson]

It looks like this is a problem in the DASSL.jl package.  They made the 
common mistake of over-specifying the types of their arguments, and in 
particular they require you to pass a Julia ::Function argument for the 
equations to be solved, rather than any callable object (here, the Python 
function is passed as a callable ::PyObject).

https://github.com/pwl/DASSL.jl/issues/8

[julia-users] Re: Python Callbacks using pyjulia

[cdm]

any luck with replicating the example from the README at

   https://github.com/pwl/DASSL.jl

Re: [julia-users] variable scope inside @threads loop?

[Yichao Yu]

On Wed, Oct 19, 2016 at 10:08 AM, Jingpeng Wu  wrote:

>
>
> Currently, it seems that every variable was shared to all threads, which
> limit the application range a lot. Is there anyway to define private
> variable to each threads? similar with OpenMP.
>

Same as normal loop. Use let.

[julia-users] variable scope inside @threads loop?

[Jingpeng Wu]

Currently, it seems that every variable was shared to all threads, which 
limit the application range a lot. Is there anyway to define private 
variable to each threads? similar with OpenMP.

[julia-users] Re: UTF8, how to procesed text data

[Krisztián Pintér]

On Wednesday, October 19, 2016 at 1:46:38 PM UTC+2, program...@gmail.com 
wrote:
>
>
> julia> temp[61:65]
> "aźdz"
>
> julia> findin(temp[61:65],"d")
> ERROR: invalid UTF-8 character index
>

in addition to other answers, you have the *search* function that is 
string-specific, and might work with older versions (can't test now)

[julia-users] Re: Python Callbacks using pyjulia

[Frank Hellmann]

The python script looks like this (sorry, thought attachments would be 
inlined):


import julia 
 
j = julia.Julia() 
 
j.using("DASSL") 
 
f = lambda t, x, dx: x - dx 
r = j.dasslSolve(f, 1., [0., 10.])

Re: [julia-users] matrix multiplications

[zamani . majid1989]

yes exactly ! 

On Wednesday, October 19, 2016 at 4:28:21 PM UTC+3:30, Milan Bouchet-Valat 
wrote:
>
> Le mardi 18 octobre 2016 à 15:28 -0700, Steven G. Johnson a écrit : 
> > 
> > 
> > > Since it uses the in-place assignment operator .= it could be made 
> > > to work as desired, but there's some designing to do. 
> > > 
> > 
> > The problem is that it doesn't know that * is a matrix multiplication 
> > until compile-time. 
> > 
> > In any case, I don't think there's a huge amount to be gained from 
> > special syntax here.  Unlike broadcast operations, matrix 
> > multiplications cannot in general be fused with other operations.   
> > So you might as well do A_mul_B!. 
> I think the biggest gain would be discoverability and consistency with 
> other in-place operations. A_mul_B! isn't the most Julian of our APIs 
> (to say the least)... 
>
>
> Regards 
>

[julia-users] Re: product of Int64 and Float64 is Int64

[Krisztián Pintér]

i know i shouldn't, but i'm kinda angry at this "1." notation. saving one 
character really worth losing readability? also leading to errors like 
this. personally, i would not even allow this syntax at all.

On Wednesday, October 19, 2016 at 1:11:38 PM UTC+2, Michele Zaffalon wrote:
>
> I am confused by the type of the result of `1.*80`, which is `Int64`, 
> despite the fact that `1.` is `Float64`, and that `Float64(1)*80` is a 
> `Float64`:
>

Re: [julia-users] UTF8, how to procesed text data

[Milan Bouchet-Valat]

Le mercredi 19 octobre 2016 à 06:02 -0700, programista...@gmail.com a
écrit :
> Version 0.3.12, udate to 5 ?
Yes. 0.3.x versions are unsupported for some time now.


Regards

> > Le mercredi 19 octobre 2016 à 04:46 -0700, program...@gmail.com a 
> > écrit : 
> > > Data file is coding UTF8 but i cant procedsed this datain Julia
> > ? 
> > > What wrong ? 
> > > 
> > > o=open("data.txt") 
> > > 
> > > julia> temp=readline(io) 
> > > "3699778,13,2,gdbiehz jablej gupując szybgi Injehnej dg 26 
> > > paździehniga,1\n" 
> > > 
> > > julia> temp[61:65] 
> > > "aźdz" 
> > > 
> > > julia> findin(temp[61:65],"d") 
> > > ERROR: invalid UTF-8 character index 
> > >  in next at utf8.jl:64 
> > >  in findin at array.jl:1179 
> > You didn't say what version of Julia you're using. The bug seems
> > to 
> > happen on 0.4.7, but not on 0.5.0, so I'd encourage you to
> > upgrade. 
> > 
> > (Note that in general you shouldn't index into strings with
> > arbitrary 
> > integers: only values referring to the beginning of a Unicode code 
> > point are valid.) 
> > 
> > 
> > Regards 
>  

Re: [julia-users] UTF8, how to procesed text data

[programistawpf]

Version 0.3.12, udate to 5 ?

W dniu środa, 19 października 2016 14:56:15 UTC+2 użytkownik Milan 
Bouchet-Valat napisał:
>
> Le mercredi 19 octobre 2016 à 04:46 -0700, program...@gmail.com 
>  a 
> écrit : 
> > Data file is coding UTF8 but i cant procedsed this datain Julia ? 
> > What wrong ? 
> > 
> > o=open("data.txt") 
> > 
> > julia> temp=readline(io) 
> > "3699778,13,2,gdbiehz jablej gupując szybgi Injehnej dg 26 
> > paździehniga,1\n" 
> > 
> > julia> temp[61:65] 
> > "aźdz" 
> > 
> > julia> findin(temp[61:65],"d") 
> > ERROR: invalid UTF-8 character index 
> >  in next at utf8.jl:64 
> >  in findin at array.jl:1179 
> You didn't say what version of Julia you're using. The bug seems to 
> happen on 0.4.7, but not on 0.5.0, so I'd encourage you to upgrade. 
>
> (Note that in general you shouldn't index into strings with arbitrary 
> integers: only values referring to the beginning of a Unicode code 
> point are valid.) 
>
>
> Regards 
>
 

Re: [julia-users] matrix multiplications

[Milan Bouchet-Valat]

Le mardi 18 octobre 2016 à 15:28 -0700, Steven G. Johnson a écrit :
> 
> 
> > Since it uses the in-place assignment operator .= it could be made
> > to work as desired, but there's some designing to do.
> > 
> 
> The problem is that it doesn't know that * is a matrix multiplication
> until compile-time.
> 
> In any case, I don't think there's a huge amount to be gained from
> special syntax here.  Unlike broadcast operations, matrix
> multiplications cannot in general be fused with other operations.  
> So you might as well do A_mul_B!.
I think the biggest gain would be discoverability and consistency with
other in-place operations. A_mul_B! isn't the most Julian of our APIs
(to say the least)...


Regards

Re: [julia-users] UTF8, how to procesed text data

[Milan Bouchet-Valat]

Le mercredi 19 octobre 2016 à 04:46 -0700, programista...@gmail.com a
écrit :
> Data file is coding UTF8 but i cant procedsed this datain Julia ?
> What wrong ?
> 
> o=open("data.txt")
> 
> julia> temp=readline(io)
> "3699778,13,2,gdbiehz jablej gupując szybgi Injehnej dg 26
> paździehniga,1\n"
> 
> julia> temp[61:65]
> "aźdz"
> 
> julia> findin(temp[61:65],"d")
> ERROR: invalid UTF-8 character index
>  in next at utf8.jl:64
>  in findin at array.jl:1179
You didn't say what version of Julia you're using. The bug seems to
happen on 0.4.7, but not on 0.5.0, so I'd encourage you to upgrade.

(Note that in general you shouldn't index into strings with arbitrary
integers: only values referring to the beginning of a Unicode code
point are valid.)


Regards

Re: [julia-users] UTF8, how to procesed text data

[Stefan Karpinski]

http://docs.julialang.org/en/release-0.5/manual/strings/

On Wed, Oct 19, 2016 at 7:46 AM,  wrote:

> Data file is coding UTF8 but i cant procedsed this datain Julia ? What
> wrong ?
>
> o=open("data.txt")
>
> julia> temp=readline(io)
> "3699778,13,2,gdbiehz jablej gupując szybgi Injehnej dg 26
> paździehniga,1\n"
>
> julia> temp[61:65]
> "aźdz"
>
> julia> findin(temp[61:65],"d")
> ERROR: invalid UTF-8 character index
>  in next at utf8.jl:64
>  in findin at array.jl:1179
>
> Paul
>

[julia-users] Python Callbacks using pyjulia

[Frank Hellmann]

Hello,
I am evaluating using Julia for implementing some algorithms we want to 
use. As a first usecase we wanted to try using the DASSL solver in julia on 
a python function. Unfortunately we get the error below. I don't really 
know how to start debugging this problem, any pointers would be deeply 
appreciated.

Best,
Frank

==

$ python dassl-from-python.py 

Traceback (most recent call last):
  File "dassl-from-python.py", line 8, in 
r = j.dasslSolve(f, 1., [0., 10.])
RuntimeError: Julia exception: 
MethodError(DASSL.#dasslStep,(Any[:dy0,[0.0],:tstop,10.0],DASSL.dasslStep,PyObject
 
 at 0x101a69500>,[1.0],0.0))
import julia

j = julia.Julia()

j.using("DASSL")

f = lambda t, x, dx: x - dx
r = j.dasslSolve(f, 1., [0., 10.])

Re: [julia-users] product of Int64 and Float64 is Int64

[Michele Zaffalon]

Thanks.

On Wed, Oct 19, 2016 at 1:46 PM,  wrote:

> Or include a space.
>
> parse("1. * 80") --> :(1.0 * 80)
>
> parse("1.* 80")  --> :(1 .* 80)
>
> On Wednesday, October 19, 2016 at 1:30:27 PM UTC+2, Mauro wrote:
>>
>> On Wed, 2016-10-19 at 13:11, Michele Zaffalon 
>> wrote:
>> > I am confused by the type of the result of `1.*80`, which is `Int64`,
>> despite
>> > the fact that `1.` is `Float64`, and that `Float64(1)*80` is a
>> `Float64`:
>>
>> No this is parsed as 1 .* 80.  Try 1.0*80
>>
>> > julia> typeof(1.), typeof(80), typeof(1.*80), typeof(Float64(1.)*80)
>> > (Float64,Int64,Int64,Float64)
>> >
>> > Does it have to do with the fact that both 1 and 80 have an exact
>> Float64
>> > representation?
>> >
>> > julia> bits(1.)
>> > "0011"
>> >
>> > julia> bits(80.)
>> > "010001010100"
>> >
>> >
>> > Thank you,
>> > michele
>>
>

Re: [julia-users] product of Int64 and Float64 is Int64

[lapeyre . math122a]

Or include a space.  

parse("1. * 80") --> :(1.0 * 80)

parse("1.* 80")  --> :(1 .* 80)

On Wednesday, October 19, 2016 at 1:30:27 PM UTC+2, Mauro wrote:
>
> On Wed, 2016-10-19 at 13:11, Michele Zaffalon  > wrote: 
> > I am confused by the type of the result of `1.*80`, which is `Int64`, 
> despite 
> > the fact that `1.` is `Float64`, and that `Float64(1)*80` is a 
> `Float64`: 
>
> No this is parsed as 1 .* 80.  Try 1.0*80 
>
> > julia> typeof(1.), typeof(80), typeof(1.*80), typeof(Float64(1.)*80) 
> > (Float64,Int64,Int64,Float64) 
> > 
> > Does it have to do with the fact that both 1 and 80 have an exact 
> Float64 
> > representation? 
> > 
> > julia> bits(1.) 
> > "0011" 
> > 
> > julia> bits(80.) 
> > "010001010100" 
> > 
> > 
> > Thank you, 
> > michele 
>

[julia-users] UTF8, how to procesed text data

[programistawpf]

Data file is coding UTF8 but i cant procedsed this datain Julia ? What 
wrong ?

o=open("data.txt")

julia> temp=readline(io)
"3699778,13,2,gdbiehz jablej gupując szybgi Injehnej dg 26 paździehniga,1\n"

julia> temp[61:65]
"aźdz"

julia> findin(temp[61:65],"d")
ERROR: invalid UTF-8 character index
 in next at utf8.jl:64
 in findin at array.jl:1179

Paul

[julia-users] ANN: Symata.jl language for Symbolic math

[lapeyre . math122a]

[ apologies for posting twice! I forgot to include a description in the 
Subject line]

Symata.jl is a symbolic math language. (The old name was SJulia.)

You can add it with Pkg.add("Symata.jl"). The site is 
https://github.com/jlapeyre/Symata.jl

Notebook examples are here 
https://github.com/jlapeyre/Symata.jl/tree/master/examples 
(the math looks better in live Jupyter sessions)

To try the latest features, you need to use the development version using 
Pkg.checkout("Symata") after adding it.

Among the New Things:

* Builds and tests on Linux, OSX, and Windows using Travis and Appveyor.

* Installation is much easier, using Steven Johnson's PyCall recipes.

* Works in Jupyter notebook using IJulia.jl  (It typesets the math using 
LaTeX). Symata still works at the command line REPL as well.

* A few tutorial notebooks are included. They cover a small fraction of 
Symata.

* ... oh, and rudimentary plotting via Plots.jl. This could be expanded 
with little effort.

Please file an issue on github, https://github.com/jlapeyre/Symata.jl 
,
 
if you have any problems or suggestions.

Re: [julia-users] product of Int64 and Float64 is Int64

[Michele Zaffalon]

And

julia> parse("1.*80")
:(1 .* 80)
julia> parse("1.0*80")
:(1.0 * 80)


On Wednesday, October 19, 2016 at 1:36:00 PM UTC+2, Michele Zaffalon wrote:
>
> I should have realized that:
>
> julia> promote(1., 80)
> (1.0,80.0)
> julia> 80*1.
> 80.0
>
> Thank you.
>
> On Wednesday, October 19, 2016 at 1:30:27 PM UTC+2, Mauro wrote:
>>
>> On Wed, 2016-10-19 at 13:11, Michele Zaffalon  
>> wrote: 
>> > I am confused by the type of the result of `1.*80`, which is `Int64`, 
>> despite 
>> > the fact that `1.` is `Float64`, and that `Float64(1)*80` is a 
>> `Float64`: 
>>
>> No this is parsed as 1 .* 80.  Try 1.0*80 
>>
>> > julia> typeof(1.), typeof(80), typeof(1.*80), typeof(Float64(1.)*80) 
>> > (Float64,Int64,Int64,Float64) 
>> > 
>> > Does it have to do with the fact that both 1 and 80 have an exact 
>> Float64 
>> > representation? 
>> > 
>> > julia> bits(1.) 
>> > "0011" 
>> > 
>> > julia> bits(80.) 
>> > "010001010100" 
>> > 
>> > 
>> > Thank you, 
>> > michele 
>>
>

Re: [julia-users] product of Int64 and Float64 is Int64

[Michele Zaffalon]

I should have realized that:

julia> promote(1., 80)
(1.0,80.0)
julia> 80*1.
80.0

Thank you.

On Wednesday, October 19, 2016 at 1:30:27 PM UTC+2, Mauro wrote:
>
> On Wed, 2016-10-19 at 13:11, Michele Zaffalon  > wrote: 
> > I am confused by the type of the result of `1.*80`, which is `Int64`, 
> despite 
> > the fact that `1.` is `Float64`, and that `Float64(1)*80` is a 
> `Float64`: 
>
> No this is parsed as 1 .* 80.  Try 1.0*80 
>
> > julia> typeof(1.), typeof(80), typeof(1.*80), typeof(Float64(1.)*80) 
> > (Float64,Int64,Int64,Float64) 
> > 
> > Does it have to do with the fact that both 1 and 80 have an exact 
> Float64 
> > representation? 
> > 
> > julia> bits(1.) 
> > "0011" 
> > 
> > julia> bits(80.) 
> > "010001010100" 
> > 
> > 
> > Thank you, 
> > michele 
>

Re: [julia-users] product of Int64 and Float64 is Int64

[Mauro]

On Wed, 2016-10-19 at 13:11, Michele Zaffalon  
wrote:
> I am confused by the type of the result of `1.*80`, which is `Int64`, despite
> the fact that `1.` is `Float64`, and that `Float64(1)*80` is a `Float64`:

No this is parsed as 1 .* 80.  Try 1.0*80

> julia> typeof(1.), typeof(80), typeof(1.*80), typeof(Float64(1.)*80)
> (Float64,Int64,Int64,Float64)
>
> Does it have to do with the fact that both 1 and 80 have an exact Float64
> representation?
>
> julia> bits(1.)
> "0011"
>
> julia> bits(80.)
> "010001010100"
>
>
> Thank you,
> michele

[julia-users] Re: Juno workspace variable display.

[Martin Florek]

On Ubuntu: Ctrl+Shift+P 
It's great, thanks

On Tuesday, 13 September 2016 05:26:01 UTC+2, Patrick Belliveau wrote:
>
> Works for me too. Thanks Uwe! I'll put in a feature request to have a it 
> added to the menu. Juno's getting really good.
>
> Patrick
>
> On Monday, September 12, 2016 at 2:46:31 PM UTC-7, Patrick Belliveau wrote:
>>
>> Hi all,
>>   In his JuliaCon 2016 talk 
>>  on Juno's new graphical 
>> debugging capabilities, Mike Innes also showed off a workspace pane in Juno 
>> that displays currently defined variable values from an interactive Julia 
>> session. My impression from the video is that this feature should be 
>> available in the latest version of Juno but I can't get it to show up. As 
>> far as I can tell, the feature is not included in my version of Juno. Am I 
>> missing something or has this functionality not been released yet? I'm on 
>> linux, running 
>>
>> Julia 0.5.0-rc4+0
>> atom 1.9.9
>> master branches of Atom.jl,CodeTools.jl,Juno.jl checked out and up to date
>> ink 0.5.1
>> julia-client 0.5.2
>> language-julia 0.6
>> uber-juno 0.1.1
>>
>> Thanks, Patrick
>>
>> P.S. I've just started using Juno and in general I'm really liking it, 
>> especially the debugging gui features. Great work Juno team!
>>
>

[julia-users] product of Int64 and Float64 is Int64

[Michele Zaffalon]

I am confused by the type of the result of `1.*80`, which is `Int64`, 
despite the fact that `1.` is `Float64`, and that `Float64(1)*80` is a 
`Float64`:

julia> typeof(1.), typeof(80), typeof(1.*80), typeof(Float64(1.)*80)
(Float64,Int64,Int64,Float64)

Does it have to do with the fact that both 1 and 80 have an exact Float64 
representation?

julia> bits(1.)
"0011"

julia> bits(80.)
"010001010100"


Thank you,
michele

Re: [julia-users] Julia programming for engineers!

[zamani . majid1989]

yes i have read this part ... and thought that it would be nice to have 
guide that aims some engineering topics.

On Wednesday, October 19, 2016 at 2:12:18 PM UTC+3:30, Tamas Papp wrote:
>
> I suppose you are aware of 
>
>
> http://docs.julialang.org/en/release-0.5/manual/noteworthy-differences/#noteworthy-differences-from-matlab
>  
>
> On Wed, Oct 19 2016, zamani wrote: 
>
> > Hi guys .. using Julia is fun .. 
> > I'm going to write a guide for matlab users specially students but i 
> need 
> > some help with grammar as english is not my native language... its going 
> to 
> > based on a book by the title of Matlab Programming for engineers 
> > ( 
> https://www.amazon.com/MATLAB-Programming-Engineers-Stephen-Chapman/dp/049524449X)
>  
>
> > if anyone is interested and can help me to develop a community based 
> book 
> > please contact me ... 
>
>

[julia-users] Re: Is 0.6(nightlies) pretty much broken?

[lapeyre . math122a]

Nightly builds by Travis and Appveyor broke for me. For OSX and Windows, 
maybe not Linux.

  WARNING: The call to compilecache failed to create a usable precompiled cache 
file for module Combinatorics.



On Wednesday, October 12, 2016 at 8:44:16 PM UTC+2, Neal Becker wrote:
>
> Seems like nothing I try is working now: 
> Version 0.6.0-dev.896 (2016-10-07 08:16 UTC) 
> Commit 38a63bd* (3 days old master) 
> x86_64-redhat-linux 
>
> julia> using Polynomials 
> INFO: Recompiling stale cache file 
> /home/nbecker/.julia/lib/v0.6/Polynomials.ji for module Polynomials. 
> WARNING: The call to compilecache failed to create a usable precompiled 
> cache file for module Polynomials. Got: 
> WARNING: Precompile file header verification checks failed. 
> ERROR: LoadError: Declaring __precompile__(true) is only allowed in module 
> files being imported. 
>  in __precompile__(::Bool) at ./loading.jl:311 
>  in __precompile__() at ./loading.jl:307 
>  in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:66 
>  in macro expansion at ./REPL.jl:97 [inlined] 
>  in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68 
> while loading /home/nbecker/.julia/v0.6/Polynomials/src/Polynomials.jl, in 
> expression starting on line 3 
>
> julia> Pkg.add("DSP") 
> INFO: Installing DSP v0.1.1 
> INFO: Package database updated 
>
> julia> using DSP 
> INFO: Recompiling stale cache file /home/nbecker/.julia/lib/v0.6/DSP.ji 
> for 
> module DSP. 
> WARNING: The call to compilecache failed to create a usable precompiled 
> cache file for module DSP. Got: 
> WARNING: Precompile file header verification checks failed. 
> ERROR: LoadError: Declaring __precompile__(true) is only allowed in module 
> files being imported. 
>  in __precompile__(::Bool) at ./loading.jl:311 
>  in __precompile__() at ./loading.jl:307 
>  in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:66 
>  in macro expansion at ./REPL.jl:97 [inlined] 
>  in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68 
> while loading /home/nbecker/.julia/v0.6/DSP/src/DSP.jl, in expression 
> starting on line 1 
>
> julia> using PyPlot 
> INFO: Precompiling module PyPlot. 
> WARNING: Precompile file header verification checks failed. 
> ERROR: Module PyPlot declares __precompile__(true) but require failed to 
> create a usable precompiled cache file. 
>  in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:66 
>  in macro expansion at ./REPL.jl:97 [inlined] 
>  in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68 
>
>
>

Re: [julia-users] Julia programming for engineers!

[Tamas Papp]

I suppose you are aware of

http://docs.julialang.org/en/release-0.5/manual/noteworthy-differences/#noteworthy-differences-from-matlab

On Wed, Oct 19 2016, zamani wrote:

> Hi guys .. using Julia is fun ..
> I'm going to write a guide for matlab users specially students but i need 
> some help with grammar as english is not my native language... its going to 
> based on a book by the title of Matlab Programming for engineers 
> ( 
> https://www.amazon.com/MATLAB-Programming-Engineers-Stephen-Chapman/dp/049524449X)
>  
> if anyone is interested and can help me to develop a community based book 
> please contact me ...

[julia-users] Re: Nemo AcbField error

[Tommy Hofmann]

pari was not built/downloaded properly. Do a Pkg.build("Nemo") in julia and 
check again.

On Wednesday, October 19, 2016 at 2:44:20 AM UTC+2, Jeffrey Sarnoff wrote:
>
> I do not get that error.  Are you using the current versions of Julia nd 
> Nemo?  You may see a warning message with the first use each session.
>
> Here is a transcript:. Let me see yours, and  the output of versioninfo().
>
>
> > using Nemo
> > c = AcbField(64)
> Complex Field with 64 bits of precision and error bounds
>
> > c(1,1)
> ..warning...
> 1.000 + i*1.000
> > c(1,1)
> 1.000 + i*1.000
> > f = ArbField(64)
> Real Field with 64 bits of precision and error bounds
>
> julia> f(1)
>
> 1.000
>
>
>
>
>
> On Tuesday, October 18, 2016 at 6:27:28 PM UTC-4, digxx wrote:
>>
>> Hey, Sorry but I also get this error when I write
>>
>> r=AcbField(64)
>> r(1,1)
>>
>> Likewise
>>
>> r=ArbField(64)
>> r(1) 
>>
>> gives me the same error...
>>
>

[julia-users] Julia programming for engineers!

[zamani . majid1989]

Hi guys .. using Julia is fun ..
I'm going to write a guide for matlab users specially students but i need 
some help with grammar as english is not my native language... its going to 
based on a book by the title of Matlab Programming for engineers 
( 
https://www.amazon.com/MATLAB-Programming-Engineers-Stephen-Chapman/dp/049524449X)
 
if anyone is interested and can help me to develop a community based book 
please contact me ...

[julia-users] Re: Is 0.6(nightlies) pretty much broken?

[wookyoung noh]

it looks really danger command :)

rm -rf ~/.julia/lib   works to me.


Best regards,
WooKyoung Noh

On Thursday, October 13, 2016 at 7:52:16 PM UTC+9, Neal Becker wrote:
>
> Seems to be fixed with 
> rm -rf ~/.julia 
>
> Strange that Pkg.rm/Pkg.add didn't seem to fix it 
>
> Neal Becker wrote: 
>
> > Seems like nothing I try is working now: 
> > Version 0.6.0-dev.896 (2016-10-07 08:16 UTC) 
> > Commit 38a63bd* (3 days old master) 
> > x86_64-redhat-linux 
> > 
> > julia> using Polynomials 
> > INFO: Recompiling stale cache file 
> > /home/nbecker/.julia/lib/v0.6/Polynomials.ji for module Polynomials. 
> > WARNING: The call to compilecache failed to create a usable precompiled 
> > cache file for module Polynomials. Got: 
> > WARNING: Precompile file header verification checks failed. 
> > ERROR: LoadError: Declaring __precompile__(true) is only allowed in 
> module 
> > files being imported. 
> >  in __precompile__(::Bool) at ./loading.jl:311 
> >  in __precompile__() at ./loading.jl:307 
> >  in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:66 
> >  in macro expansion at ./REPL.jl:97 [inlined] 
> >  in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68 
> > while loading /home/nbecker/.julia/v0.6/Polynomials/src/Polynomials.jl, 
> in 
> > expression starting on line 3 
> > 
> > julia> Pkg.add("DSP") 
> > INFO: Installing DSP v0.1.1 
> > INFO: Package database updated 
> > 
> > julia> using DSP 
> > INFO: Recompiling stale cache file /home/nbecker/.julia/lib/v0.6/DSP.ji 
> > for module DSP. 
> > WARNING: The call to compilecache failed to create a usable precompiled 
> > cache file for module DSP. Got: 
> > WARNING: Precompile file header verification checks failed. 
> > ERROR: LoadError: Declaring __precompile__(true) is only allowed in 
> module 
> > files being imported. 
> >  in __precompile__(::Bool) at ./loading.jl:311 
> >  in __precompile__() at ./loading.jl:307 
> >  in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:66 
> >  in macro expansion at ./REPL.jl:97 [inlined] 
> >  in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68 
> > while loading /home/nbecker/.julia/v0.6/DSP/src/DSP.jl, in expression 
> > starting on line 1 
> > 
> > julia> using PyPlot 
> > INFO: Precompiling module PyPlot. 
> > WARNING: Precompile file header verification checks failed. 
> > ERROR: Module PyPlot declares __precompile__(true) but require failed to 
> > create a usable precompiled cache file. 
> >  in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:66 
> >  in macro expansion at ./REPL.jl:97 [inlined] 
> >  in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68 
>
>
>

[julia-users] Re: matrix multiplications

[zamani . majid1989]

Thanks @Stefan ...  

On Tuesday, October 18, 2016 at 8:03:46 PM UTC+3:30, zamani.m...@gmail.com 
wrote:
>
> hi guys
> is there a way to reduce allocated memory in matrix multiplications?
>
> for example this code blew in my machine gives :
>
> function test4(n)
>   a = rand(n,n)
>   for i = 1:100
>  a*a
>end
>  end
>
>
> -- answer  --
> test4(1)
> # force compiling 
>
> @time test4(1000)
> 16.589743 seconds (433 allocations: 770.587 MB, 0.68% gc time)
>

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

[Michele Zaffalon]

On Thursday, October 13, 2016 at 3:38:36 PM UTC+2, Steven G. Johnson wrote:
>
> write on a numeric array will output the raw bytes, i.e. Column-major data 
> in the native byte order. 
>
>
> Would it be a reasonable assumption that reshaping will not change the 
ordering in future Julia implementations?